kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #11843
Re: Proposal: Move to C++11 (time to revisit?)
On 12/4/2013 11:03 AM, Povilas Kanapickas wrote:
> 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.
I may be wrong but I don't share your optimism on this. A few years ago
we had to change the optimization level from 2 to 1 with GCC 4.7.0
through 4.7.2 to prevent a build bug in the boost::polygon library. Ask
JP how hard it was to find this issue. I can only imagine what would
happen if we made the -std-c++11 option part of the default build
configuration. It's not something I would spend time working on as
there are much more important issues in the KiCad code base. However,
if you have the time and and can make the KiCad code C++11 compliant
without breaking anything, then I welcome your contributions.
Regards,
Wayne
>
> 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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
References