On 9/3/12, Richard Guenther <richard.guent...@gmail.com> wrote:
> On Aug 24, 2012, Lawrence Crowl <cr...@googlers.com> wrote:
> > To take full advantage of the conversion to C++, we will need to use
>
> I'm not sure what "full advantage" of single-inheritance vs. composition
> is.
You get automatic pointer-to-base-class conversion with single
inheritance. You do not with composition.
You get the option virtual calls (should we want them) with single
inheritance, but not with composition.
>> single inheritance in some of our garbage collected structures. To
>> that end, we need to make gengtype understand single inheritance.
>> Here are my thoughts on how to make that happen.
>>
>> There are two major sections, one for non-polymorphic classes and one
>> for polymorphic classes. Each section has a series of subsection
>> pairs describing a new grammar and its implementation.
>>
>>
>> NON-POLYMORPHIC CLASSES
>>
>> The classes we care about are polymorphic in the general sense,
>> but not in the language sense, because they don't have virtual
>> members or bases. That is, they use ad-hoc polymorphism via an enum
>> discriminator to control casting.
>>
>> enum E { EA, EB, EC, ED, EE };
>>
>>
>> GRAMMAR
>>
>> The root class class must have a discriminator.
>>
>> class ATYPE GTY ((desc ("%h.type")))
>> { public: enum E type; other *pa; ... };
>>
>> No derived class may have a discriminator.
>>
>> Every allocatable class must have a tag.
>>
>> class BTYPE : GTY ((tag ("EB"))) public ATYPE
>> { public: other *pb; ... };
>>
>> The root class may be allocatable, and so may have a tag.
>>
>> class ATYPE GTY ((desc ("%h.type"), tag ("EA")))
>> { public: enum E type; other *pa; ... };
>>
>> Two derived classes may share a base, even indirectly, but be
>> otherwise unrelated.
>>
>> class CTYPE : GTY ((tag ("EC"))) public BTYPE { ... };
>> class DTYPE : GTY ((tag ("ED"))) public BTYPE { ... };
>> class ETYPE : GTY ((tag ("EE"))) public ATYPE { ... };
>>
>> Note the difference between C and D are siblings but D and E are
>> siblings once removed (i.e. nephew and uncle).
>>
>> Private and protected fields are not supported, at least for those
>> fields that gengtype cares about.
>
> I see you are targeting 'tree' ... that's not the very best thing to
> work on IMHO.
The examples were from tree, because I thought that would be more
familiar to folks. That's not where we start making changes.
>> IMPLEMENTATION
>>
>> We can probably hack into the existing generation for unions.
>> However, there is a naming problem. The current gcc union approach
>> creates a "top type" for every class hierarchy. A single-inheritance
>> class hierarchy has no "top type" and so we cannot use it to name the
>> marker. We can use the base type, (aka "bottom type").
>>
>> That is, generate gt_ggc_mx_ATYPE full of a switch statement covering
>> all known deriviations. Any gt_ggc_mx names for derived types would
>> be simply aliased to the base.
>
> I thought we agreed to switch gengtype to fully use overloads of
> a signle 'mark' function instead of its weird internal mangling.
> That also make it less/un-necessary for it to understand types,
> it only needs to be able to parse field identifiers (or in the
> inheritance case, base types (ugh)).
There is an issue in handling the table of static variables. Diego
is working on that.
> Though I'd simply declare that structures as complicated as tree need
> manually implemented mark()ers.
Manual implementation should be fine for template classes, but we
are asking for trouble if we require manual implementation for tree.
> Remove code from gengype! Do not make it more complicated.
We are agreed on minimizing the complexity of gengtype.
> Think of how you'd implement explicit garbage collection in C++
> from scratch, without the help of something external such as
> gengtype.
We are trying to get there incrementally.
--
Lawrence Crowl
