Re: language design implications for variant records in a pascal-like language

* George Neuner:


> C++ forbids a union of classes ... so you won't ever see one.


C++0X adds a restricted form. Unions of classes are fairly common in
C++ libraries and are currently emulated with placement news and some
hopeful magic to deal with alignment concerns.


> With respect to POD variant record types, I guess they depends on how
> you see your language being used. Packed POD records (including
> variant types) are very useful for hardware interfacing in a "systems"
> language, but in an "application" language the only real attraction of
> POD types is that they are (usually) lighter weight and faster than an
> equivalent class (though dynamic dispatch can be made O(1) if you are
> serious about speed ... unfortunately very few class implementations
> are that serious).


It is very difficult to use memory-mapped I/O without machine code
insertions with modern compilers. It's also likely that the device's
idea of memory layout differs from that of the host system. This
means that useful language support in this area is going to be very
difficult to provide.


Variant types are somewhat challenging to support if their values can
be (partically) unbounded. For instance, an object of such a type
cannot be placed directly into a record. Adding an indirection when
necessary certainly helps here. If you don't want to do this, you're
really facing an uphill battle because without additional measures, a
simple module system will hide the variable-sized nature of a type.


On the other hand, if all objects of variant type have some reasonable
upper bound on their size, things should be fairly straightforward.
The nice thing about variant types (particularly in constrast to
objects) are exhaustiveness checks, that is, the compiler will make
sure you've covered all cases when iterating over a particular data
structure.

Return to the comp.compilers page.
Search the comp.compilers archives again.