|Run-time representation of classes email@example.com (Jon Harrop) (2009-01-27)|
|Re: Run-time representation of classes firstname.lastname@example.org (cr88192) (2009-01-30)|
|Re: Run-time representation of classes email@example.com (George Neuner) (2009-01-30)|
|Re: Run-time representation of classes firstname.lastname@example.org (Armel) (2009-01-30)|
|Re: Run-time representation of classes email@example.com (2009-01-31)|
|Re: Run-time representation of classes firstname.lastname@example.org (Michael Schuerig) (2009-02-02)|
|Re: Run-time representation of classes email@example.com (cr88192) (2009-02-03)|
|[6 later articles]|
|From:||Jon Harrop <firstname.lastname@example.org>|
|Date:||Tue, 27 Jan 2009 22:05:05 +0000|
|Organization:||Flying Frog Consultancy Ltd.|
|Posted-Date:||27 Jan 2009 17:31:17 EST|
Firstly, what are some good overviews of this subject?
Secondly, I have been thinking about extending my compiler from supporting
algebraic datatypes to supporting classes and I believe you need a uniform
representation of subtypes so the conventional solution is to add data to
the end of the representation of the base class in order to create the
representation of a derived class. I assume a GC would be happier if the
reference types in a class were located contiguously so I am wondering if
there is any merit in extending the representation of a base type both
downwards and upwards in memory, one direction for reference types (which
are then held contiguously) and the other direction for value types (which
the GC will not touch). Is that a good idea?
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
[I wouldn't think a GC would care so long as it could tell what was a
Return to the
Search the comp.compilers archives again.