Re: C-like Structures
- Posted by mattlewis (admin) Jul 13, 2011
- 2853 views
I agree that having familiar 'words' will help using this feature but I'm still of the mind that the 'datatypes' named above should have been defined in terms of memstruct constructs rather than hard coding them in the parser. My suggestion would only require two low level words, which would be used to define the number of physical bytes of RAM to assign to a memstruct label, and to optionally modify the type of access to fetch/store data into those bytes (eg. signed data).
...snip...
I'm sure that this would simplify the parser and allow future 'predefined' data types to be much more easily built instead of updating the parser to cater for them.
I'd still rather avoid the explicit sizing in euphoria code. I'm interested in hearing what others think.
I'm actually skeptical of being able/needing to have more or less arbitrary byte size elements. Is there any place/language/compiler where this is really used for structures? Also, this would complicate the translator (and, really, the interpreter). You certainly wouldn't be able to natively access odd sized integers.
The currently implemented data types are actually fairly simply implemented in the parser and in the backend and translator. I suspect using arbitrary sizes would be at least as complex, and probably more so, especially taking into account integer sizes that C compilers don't support.
Currently, the size of various types of integers are handled for us automatically by the compiler used to build the interpreter or the translated program. So any weirdness that you get from platform to platform (like different "long int" sizes on Win64 and 64-bit Linux) is handled automatically, without having to figure out sizes. Likewise for pointers.
The one thing that neither scheme would support would be bit fields, which are nonstandard anyways, so I don't think either methodology really has anything to say about those.
Matt
