Re: [boost] [parameter] Go C++11 and above only, or keep C++03 support?

Subject: Re: [boost] [parameter] Go C++11 and above only, or keep C++03 support?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-11-04 09:35:07

On 11/4/18 11:03 AM, degski wrote:
> On Sat, 3 Nov 2018 at 16:17, Andrey Semashev via Boost 
> <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
> 
>     If by "move" you mean actively stripping Boost from C++03 support then
>     probably never.
> 
> I mean it in the same way Peter describes, progress in libraries [using 
> C++11, or later standards] might make certain libraries fall by the 
> way-side.

Sorry, I still don't understand. What exactly do you mean by "fall by 
the way-side"? Is it that they get broken? Or become irrelevant? Or 
something else?

>     But as far as I'm concerned, Boost has moved to C++11
>     and later as soon as the first C++11 was accepted.
> 
>  Â One of the problems are the libraries that got accepted into the std, 
> take std::array. Moving to C++11 means in my view using the 
> std-equivalent instead of the Boost version [which then also shift the 
> maintenance burden of those libs to the compiler vendor]. When you keep 
> saying "let's keep backward compatibility", this precludes doing that, 
> or do conditional compilation, throughout.

In many cases I don't see the advantage in switching to std equivalents. 
E.g. when boost::array is used internally, there is no reason to switch 
to std::array as it doesn't affect users and doesn't offer any benefits 
to the maintainer. On the contrary, I often trust Boost implementation 
more because (a) it is tested and maintained by us (i.e. is under our 
control) and (b) it is a single implementation as opposed to multiple 
std libraries with their own quirks and bugs. In some cases, Boost 
equivalents simply work better.

However, the case in point is not what you describe. It is not about 
standard library features that could be used to improve user experience. 
It is about a core language feature, which can be used optionally and 
even emulated in C++03.

>     At that point in
>     time, the rest of Boost, still compatible with C++03, did not disappear
>     and stayed relevant. C++03-compatible libraries are still a part of
>     Boost and very much relevant, despite how many C++ versions have
>     come out.
> 
> A library is unconditionally C++03 compatible, is code-smell.

I strongly disagree. There are plenty state of the art Boost libraries 
that support C++03. Boost.Intrusive, Boost.ASIO, Boost.Spirit, 
Boost.Interprocess to name just a few. Judging code quality by the C++ 
version it is compatible with is terribly misguided, IMO.

> Move-semantics and/or perfect forwarding will in almost all cases 
> improve performance, variadic templates improve [user-]usability.

Sure, and most of the time these features can be used optionally. And I 
think most of the actively maintained libraries have employed some C++11 
features while keeping the compatibility with C++03.

>     On a personal note, I find this "C++11 holy cow" hype quite a pointless
>     waste of breath (or... network bandwidth, I guess).
> 
> To me and many, C++11 is a big departure from C++98, while, once you 
> actually dig in, one starts to realize that C++17 is an equally big step.

I wouldn't call it a departure, more a move (no pun intended) in the 
direction everyone wanted and oftentimes already used the language. And 
I'm rather used to C++17, so I actually see the difference in the field. 
It doesn't make me choke every time I use a library that happen to be 
compatible with C++03, in fact I barely even notice. So I disagree with 
everyone who thinks such libraries are code smell and don't deserve to 
live under the sun.

>     There is no point in
>     dropping libraries on the ground of C++03 compatibility, so that's
>     never
>     going to happen.
> 
> Sure not, like Edward also says, if it works, it works, no need to do 
> anything. But that was not what you were saying, you said, please write 
> some more code so that Boost.Parameter maintains C++03 compatibility.

That was not what I was saying. I was saying "keep the existing code or 
use Boost.Move", in a rather soft way of asking, BTW.

>     Just stop debating and start writing some great code, guys! Our
>     users will be only happy. :)
> 
> The thing is, that it's much easier to write great code using C++11, 14 
> and certainly C++17.

Then go ahead and do that. As I said, Boost doesn't refuse libraries on 
the basis of the minimum required C++ version.

>  Â Peter proposed to fork Boost.Parameter03, which seems reasonable to 
> me, but then begs the question, why not for the whole of Boost and go 
> Boost 2.0 [discussed many times I know].

And I replied that I'd rather switch to C++11 than have a fork.