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: [cxx-conversion] New Hash Table (issue6244048)


Hi,

On Sun, 27 May 2012, Gabriel Dos Reis wrote:

> > people actually working on it and used to that style. ÂWe don't want to
> > have a mixture of several different styles in the compiler. ÂI (and I
> > expect many others) don't want anyone working around the latter by going
> > over the whole source base and reindent everything. ÂHence inventing a new
> > coding standard for GCC-in-C++ (by reusing existing ones or doing
> > something new) that isn't mostly the same as GCC-in-C isn't going to fly.
> 
> if this coding standard is going to be adopted as a GNU coding 
> convention, then you have to be flexible and allow yourself to see 
> beyond the past written in C. You have to ask yourself: how do I want 
> the codebase to look like in 10, 15, 20, 25 years.

No, I don't have to ask that myself.  I don't have to be flexible (just to 
be clear: I am flexible in many cases, just not because you tell me to 
be).  And no, I don't have to allow myself to see beyond the past you 
imply.  I am seeing beyond the past whenever I see fit.  Thanks for 
fathering my feelings, but please stop doing so.  And thanks for making 
clear what the whole GCC-in-c++ stunt is about. (

I didn't know beforehand that the C++ proponents for GCC set out to start 
a new GNU coding standard for C++ and wanted to make GCC the case at hand 
for that adventure including all kinds of "niceties" that c++ perhaps 
delivers.  If that would have been their open goal from the start (which 
obviously it wasn't; rather it was hidden in feel-good rhetoric about how 
c++ would magically increase the contributor base, which of course will 
never happen; I mean how naive is that thinking, a new, more complex 
language, driving more contributors to a project; hello?) I would have 
opposed it even stronger from the start.  Of course without any result 
(because a global reviewer is part of the club).

You made a reference to the coding standard as to be influenced in the way 
it is "because of the Lisp way", implying that this is the "obsolete" way, 
suggesting from wording that this is the "old" style that's somehow to be 
overcome.  (No doubt you'll now claim that this is not what you said 
explicitely; which is literally true but doesn't matter because you're 
very well aware of the mechanics of your rhetoric):

That's obviously complete bollocks.  While the backend IR is lispy (and 
even that only on the outset) the coding standard itself has nothing to do 
with that whatsoever.  Not even the RTL routines are written in a lispy 
style.  And the tree/gimple routines obviously have never seen the honor 
of being read by you.  Seeing lisp style in _those_ involves major 
inventarism.

So, if you make the suggestion that I should think and program beyond my 
(implied) small cubicle of lispy influenced old-style GNU coding standard 
C code (so as to, in a way, expand my programming capabilities), then I 
can only say: Gabriel, thanks for your suggestion, but you obviously don't 
have the slightest idea what you're talking about.  Why do you even have 
the guts to take part in this discussion (apart from being in the c++ 
fan-boy club, of course)?  When was the last submission of yours to the 
code base in areas that we're talking about?

) Namely useless noise and source change activity for the sake of it.


Only marginally interested in an answer,
Michael.

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