On Wed, Nov 11, 2015 at 07:08:38PM +0000, Artyom Beilis wrote:
Hi Artyom,
While I appreciate your point of view, I believe it is too focused on your own limited perspective. For example, Apple, Google, and Facebook are all using C++11 extensively.
Here in Silicon Valley, the startup ecosystem is using c++11/c++14 almost exclusively. They are using clang/llvm mostly, while quite a few others are using the latest g++, which is currently gcc-5.x. The vast majority of new jobs are created by the startup ecosystem. (Future boost releases should be mindful of the tool chains being used to create most of the new jobs.)
Yes... for every new project or actively developed one C++11 is great.
But there are two areas where it isn't
(a) Existing projects that need to be maintained in new environment (b) Libraries that need to support C++03 as they are used in wide range of environments (like Boost for example) and should provide same API.
Hi Artyom, Well put. Let's say your project upgrades to g++-5.2. I've never verified this, but isn't it true that you could continue to use std::auto_ptr by compiling with the -std=c++03 flag? In the context of libraries, it is an interesting issue. Every library development group must deal with this issue. Boost is a good example. I believe implementing a clean c++14 version and maintaining the existing version for backwards compatibility is the ideal solution, because it enables the new projects to see boost as viable in the long run while continuing to support long standing users associated with legacy projects that often have very long lifetimes. I realize the ideal isn't practical for many libraries.
I worked with the linux kernel for quite a few years, before focusing on C++11/14 and applications. It was a long standing policy of the kernel community to break APIs when they were getting in the way of progress.
Yes... but that is why if you want your code to work in Kernel you should push it to kernel and not keep to yourself. Kernel API is internal API of project.
On the other hand user level API (i.e. system calls) are almost NEVER broken.
Agreed. I will say the linux kernel software project is huge by any standards with a very large set of internal APIs that are used by many other subsystems. And when they break those internal APIs, folks can become engaged in heated discussions. But the policy was overriding, and progress marched on. Thank you for your comments. I enjoyed reading them. Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb