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

On 11/4/18 11:03 AM, degski wrote:

On Sat, 3 Nov 2018 at 16:17, Andrey Semashev via Boost mailto:boost@lists.boost.org> 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.