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


On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote:
> > 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.

I agree that less work-force in the transition would be a problem.  But
is C++ (perceived to be) so bad that it would make people change their
jobs?  I mean, we're not talking about the experienced hobbyists here,
or are we?

However, the concern you raised is only one part of the problem.  The
other is that, put in a simplified way, GCC is competing with LLVM about
new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
is more appealing to them, and I believe part of the reason for that is
the codebase.
Now, how many release cycles do we have until LLVM is basically good
enough to be used as a distro compiler (e.g., until code quality and
confidence in bug freedom is sufficiently similar)?  If we haven't
ensured that GCC is appealing by this time, why should new programmers
then start considering GCC and not just go by default to LLVM?

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

Please don't dismiss this so easily.  Of course this is just an example
and nothing major, but I believe many people will use tab completion on
the shell, for example, and code completion is really similar.  On the
shell, or with paths names, you start with typing something, then can
navigate from this context you provided.  That just works better when
you say context->function instead of function(context).
And I'm not a cognitive psychologist, but to me, seeing the context
first when reading left-to-right is also slightly easier to read.


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