This is the mail archive of the gcc-patches@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: [PATCH 0/6] Convert gimple to a C++ class hierarchy


On Fri, Aug 30, 2013 at 10:37 AM, Jakub Jelinek <jakub@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.

We didn't have the automation of RAII with obstacle, back then.
We do have evidence of widely use industrial
C and C++ compilers that are built around the idea of memory pools.

>> 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 { … }

I would suggest NOT to allow the {struct, class} part in the base-class clause.

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

We should not need one.  At most the base classes would have the form

   optional-typename optional-qualifying-scope  identifier
optional-template-argument-list

that should cover most of what we want.

> 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


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