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