← Back to team overview

kicad-developers team mailing list archive

Re: Proposal: Move to C++11 (time to revisit?)

 

On 12/04/2013 03:57 PM, Wayne Stambaugh wrote:
> On 12/4/2013 4:44 AM, Povilas Kanapickas wrote:
>> There was a proposal to move to C++11 in April [1]. In the end, Wayne
>> suggested[2] that we should wait until major Linux distributions ship
>> with a (mostly) C++11-compliant compiler, so the proposal was not
>> adopted. I think it may be worthwhile to revisit the issue.
>>
>> All major Linux distributions already ship GCC-4.8 as the default compiler:
>>
>> Debian testing: GCC 4.8.1 [3]
>> Debian unstable: GCC 4.8.1 [3]
>> Ubuntu 13.10: GCC 4.8.1 [4]
>> Opensuse 13.1: GCC 4.8.? [5]
>> Fedora 19: GCC 4.8.2 [6]
>>
>> According to wikimedia stats[7] the above distributions cover >98% of
>> the market.
>>
>> The list is for the newest releases, older releases will use older
>> complilers of course. Presumably, the users who stick to these older
>> releases want stability and won't update to bleeding-edge KiCad anyway.
>> Thus I think they are not very important as far as this proposal is
>> concerned.
> 
> This is why I'm still not concerned.  See:
> http://gcc.gnu.org/gcc-4.8/cxx0x_status.html.  Notice the word
> "experimental".  Also notice that in order to use C++11 support, the
> options -std=c++11 or -std=gnu++11 must be used.  KiCad builds do not
> set either of these options so unless you are setting them by
> environment variable or when running CMake, you are not compiling to
> C++11.  When GCC makes C++11 the default setting, then I'll be a bit
> more concerned.  FYI, GCC does not even default to C++0x which has been
> a standard for how long?  I'm not suggesting that C++11 isn't useful, I
> just think your jumping the gun by about 10 years given the glacial pace
> at which C++ language changes actually become the default implementation.
> 

C++0x was not a standard ;) It was an evolving draft which one couldn't
support non-experimentally.

GCC C++11 support is experimental solely because the ABI is not yet
stable. That is, using certain standard library features makes a C++11
object incompatible with C++11 objects compiled with different GCC 4.X
release. Combining C++11 and C++03 objects is safe regardless of
compiler versions, at least that's what the GCC developers say. Note,
that core language support is not experimental anymore, as indicated in
the announcements on gcc.gnu.org.

This means that for a leaf application such as KiCad that uses only
C++03 libraries and does not export (at least officially) any symbols
taking advantage of a limited set of C++11 features has almost zero
chance of causing any problems.

By the way, the times of glacial C++ evolution are over. There will be
another standard revision next year plus four or five technical
specifications documenting various features. One of the more interesting
ones is a standard filesystem library based on boost filesystem. If
everything goes well, yet another, much larger revision is planned for 2017.

>>
>> Any opinions?
> 
> In the future, I suggest you refrain from using terms like "modern
> programming practices" when trying to convince developers (at least this
> developer anyway) that the change you are proposing is worthwhile.  This
> is an automatic red flag for me.  It sounds like a bunch of marketing
> hype rather than a well thought out technical argument.  While I agree
> std::xxxx is more readable than using namespaces, there is nothing
> "modern" about writing readable code.  Good coding practices have been
> around since "good old days" of assembly and C.  Over the last 25 years,
> I've seen just about every over hyped new coding technique that was
> going to radically change the way code was written come and go.  In the
> end, it always comes back to good coding practices.
> 

I wanted to write 'modern programming practices' as in 'decade of
experience' not as 'a new fad'. It's easily possible to make a list of
observations that have led to these practices, but I thought it's better
to keep the first email short. I did not intend to say that simply
'newer == better'. Thanks for the suggestion, I'll take notice.

Regards,
Povilas



Follow ups

References