Jakub Jelinek <ja...@redhat.com> wrote:
>On Fri, Aug 30, 2013 at 11:28:34AM -0400, Diego Novillo wrote:
>> > Well, it was a wrong decision then. For some smaller types writing
>manual
>> > marker might be a sensible thing, or for some extra complicated
>> > constructs. But here we're talking about the most simple struct
>hierarchy
>> > imaginable. Having to write manual markers for that one is absurd
>IMO.
>>
>> I want to discourage extending gengtype more than necessary. Long
>> term, I would like to see memory pools replacing GC. However, that is
>> likely a long road so we should find an interim solution.
>
>I have doubts that, still somewhat remember the obstack era and memory
>pools
>would again bring all the issues back, but let's put that aside.
>
>> I vaguely remember thinking about what would be needed to have
>> gengtype deal with inheritance. It needed some pretty ugly
>> annotations. This made gengtype even more magic. That's very bad for
>> maintenance.
>
>Teaching the gengtype parser about
>{struct,class} name : public {struct,class} someothername { ... }
>as opposed to current
>{struct,class} name { ... }
>shouldn't be that hard. And, if the complaint is that we'd need to
>write
>whole C++ parser for it, then the response could be that we already
>have
>one C++ parser (and, even have plugin support and/or emit dwarf etc.).
Note that explicit markings was also about simply writing
GTY((derivesfrom(xxx))) instead of extending the parser. The result could be
as simple as gengtype emitting
ggc_mx ((xxx) *this)
In the marker routine.
Richard.
>So, gengtype could very well use a g++ plugin to emit the stuff it
>needs,
>or parse DWARF, etc. And, we even could not require everybody actually
>emitting those themselves, we could check some text form of that
>(gengtype.state?) into the tree, so only people actually changing the
>compiler would need to run the plugin.
>
>> One thing I liked is a suggestion that went something along the lines
>> of creating some base templates that could be used to facilitate
>> writing the manual markers.
>
>Even if you have some stuff that helps you writing those, still it will
>be a
>big source of bugs (very hard to debug) and a maintainance nightmare.
>
> Jakub
