This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Switching to C++ by default in 4.8
On Wed, Apr 11, 2012 at 5:57 AM, Torvald Riegel <triegel@redhat.com> wrote:
> 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?
Yes -- this should be the main motivation factor for GCC to make major
changes or even leapfrog -- LLVM is also more than 10 years old.
David
>
>>
>> > ?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.
>