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: Richard Hodges (hodges.r_at_[hidden])
Date: 2018-11-04 10:00:20

My 2c on this kind of question, for what it's worth, is that each new boost
release should only target the current standard at time of release and up.
This will force users, and more importantly *compiler vendors* to keep up
and stop dragging us all back to the stone age.

Boost is *the de-facto standard in c++*. If it demands c++17, compiler
vendors will deliver c++17 - otherwise they will go out of business.

Libraries such as boost::asio would half in size if they only had to target
c++17.

If boost only supported standards-compliant compilers, 90% of the
unreadable polyfill conditional compilation could be eradicated.

This would allow contributors to embrace the brave new world without being
distracted by putting band-aids on the old one.

On Sun, 4 Nov 2018 at 16:35, Andrey Semashev via Boost <
boost_at_[hidden]> wrote:

> 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.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Richard Hodges
hodges.r_at_[hidden]