This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thoughts on Gengtype and Single Inheritance


On 9/3/12, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Aug 24, 2012, Lawrence Crowl <crowl@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]