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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
