This is the mail archive of the 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: Switching to C++ by default in 4.8

On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <> wrote:
> On Tue, 2012-04-10 at 18:24 +0200, Michael Matz wrote:
>> Hi,
>> On Tue, 10 Apr 2012, Xinliang David Li wrote:
>> > >> > ? ? ? ? ? ? exp->as_component_ref().get_field() ..
>> > > Actually it's not questionable. ?The above stuff is _horrible_.
>> >
>> > Specifics please. ?It is _horrible_ because you are more used to the
>> > existing way and the new style does not match your taste or they are
>> > very hard to understand and use?
>> Your style (I wouldn't call it The New Style) is visually distracting, and
>> therefore harder to understand and use, longer to write and full of
>> syntactic noise without any whitespace. ?Quite frankly, how anyone could
>> ever say that
>> ? exp->as_component_ref().get_field()
>> is easier to read/write/use than
>> ? GET_FIELD_DECL (exp)
>> (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without
>> all-caps, is completely beyond me. ?I pretty much hope that we never see
>> the ugliness of the first way in GCCs code base. ?Even in C++ it's
>> possible to write non-spaghetti code.
> I don't see how this is spaghetti code. ?It it slightly longer, but
> that's just the case in this specific example.
> Think about programmers new to GCC for a second, and about code
> completion tools.

Honestly I care 1000 times more for existing GCC developers.  Before
new programmers will have an easier time with GCC _existing_ GCC
developers will have to spend at least two GCC release cycles (that's
very optimistic) turning the GCC codebase upside-down.  Every
existing GCC developer you lose on that way will slow down that
process and for every existing GCC developer you probably need more
that one "new" GCC developer starting.

It's very easy for me to do the math and conclude that losing even _one_
experienced existing GCC developer makes this whole transition-to-C++
thing a non-starter.

> ?It seems to me that with such a tool it's much easier
> to navigate from exp to the field, than having to scan through a much
> larger number of accessor functions / macros (GET_*). ?The former
> example starts at the source (exp) and yields/"builds" the result; the
> latter names some function and then says applies it to the source. ?Why
> is the former so much worse? ?To me, the former's structure is easier to
> see, and if I would have to put the spaghetti tag on something, then the
> latter.

Sounds more like missed features or bugs in the tools you use.  Heh,
after all our complaints that C++ will be harder to debug are deflected
to "that are gdb missing features / bugs".  So - file bugs against Eclipse
(or whatever new and shiny programmers use these days), that it does
not work well with a codebase like GCC.


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