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 9:24 AM, 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
> (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.

As you said, this is still about taste -- and I agree the preference
to style is totally subjective. Changing to C++ style API will needed
to be justified by other things such as better static type checking,
elimination of unnecessary opcode checking when the most derived type
is known in the context etc.

Defining macros like GET_FIELD_DECL to replace TREE_OPERAND(...) is an
improvement by itself, but it can not prevent user from directly using
TREE_OPERAND(x,...) directly.


> Ciao,
> Michael.

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