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

Florian Weimer <fw@deneb.enyo.de>
Fri, 31 Dec 2010 21:06:32 +0100

          From comp.compilers

Related articles
[14 earlier articles]
Re: language design implications for variant records in a pascal-like marcov@turtle.stack.nl (Marco van de Voort) (2010-12-30)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2010-12-31)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2010-12-31)
Re: language design implications for variant records in a pascal-like fw@deneb.enyo.de (Florian Weimer) (2010-12-31)
Re: language design implications for variant records in a pascal-like noitalmost@cox.net (noitalmost) (2010-12-31)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-02)
Re: language design implications for variant records in a pascal-like gene.ressler@gmail.com (Gene) (2011-01-02)
Re: language design implications for variant records in a pascal-like torbenm@diku.dk (2011-01-04)
Re: language design implications for variant records in a pascal-like jm@bourguet.org (Jean-Marc Bourguet) (2011-01-05)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2011-01-06)
[35 later articles]
| List of all articles for this month |

From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.compilers
Date: Fri, 31 Dec 2010 21:06:32 +0100
Organization: Compilers Central
References: 10-12-040 10-12-043
Keywords: storage, design, C++
Posted-Date: 01 Jan 2011 22:17:40 EST

* 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.


Post a followup to this message

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