Re: [boost] Boost and auto_ptr (was Boost 1.60.0 beta 1...)

Subject: Re: [boost] Boost and auto_ptr (was Boost 1.60.0 beta 1...)
From: Karen Shaeffer (shaeffer_at_[hidden])
Date: 2015-11-11 14:46:18

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