Hi, Rene. I've gone that route before, and I can do so again, although currently I'm running into an unexpected difficulty getting the legacy portions of the code generation macros to cooperate with a couple of corner cases. I removed C++03 support with the understanding that the rest of Boost would drop C++03 support starting with the upcoming release. Please let me know if I'm mistaken. Cromwell D. Enage

On Fri, Nov 2, 2018 at 10:48 PM Cromwell Enage wrote:

I removed C++03 support with the understanding that the rest of Boost would drop C++03 support starting with the upcoming release. Please let me know if I'm mistaken.

It has not been announced or finalized yet, and as such, is not the case currently for the upcoming Boost 1.69 release. Glen

Edward Diener wrote:

We have also discussed extensively that Boost will be dropping support for C++03 and what this means.

We did discuss it, but we haven't decided anything yet. And if/when we do, we'll need to announce it at least one release in advance. (We still have time, in principle, for the decision and for the announcement that 1.69 will be the last C++03 release. I doubt that we'll reach consensus so quickly though.)

On Sat, Nov 3, 2018 at 7:48 AM Cromwell Enage wrote:

It's possible to retain the old code for C++03 compilers. Which ones do your library users have?

For now, until all the library authors in question provide you with some list of C++ implementations that they want to support, you can ensure the current tested C++ implementations in the Develop and Master regression matrix, as well as any in the Travis and Appveyor, continue to pass if they did before. But since this pull request is targeting Boost 1.70, it looks like there is no rush anyway. After the ISO C++ committee meeting, I will be happy to help (with code or reviews) if you find supporting C++03 difficult in some way. Glen

On Sat, 3 Nov 2018 at 14:41, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

On 11/3/18 2:47 PM, Cromwell Enage via Boost wrote:

...

Hello, Andrey.

It's possible to retain the old code for C++03 compilers. Which ones do your library users have?

I don't have this data. Boost.Log is documented to support gcc since 4.5 and MSVC since 8.0 SP1. It might be ok to raise the minimum requirement a bit, if it makes it easier to support in Boost.Parameter and other lower level libraries, but switching sraight to C++11 might be big deal for users.

The following question has been asked many times by many posters and there never is an answer: "Those users who want to stick to the old ways of doing things and like to use unsafe compilers [Meltdown, Spectre come to mind], why can't they just use old versions of Boost?" Why does the latest version of Boost need to work with the oldest (limping) compiler in existence. If you are [as a user] sticking to C++98 [forget C++03, that's just cosmetics] you are seriously hampering yourself. Also as Edward points out, compiling things with a later std does not imply that "the" user [or Boost] code needs to change [at least in the case of C++11, there are very few changes that are required]. There was, as far as I read it, considerable support to at least move to C++11, which is already 2 standards behind the current standard [and is by now fully supported on the main platforms]. Whatever is documented is not relevant, if the docs are out of date, they have to be updated. If every time this kind of question pops up, the answer is, "let's keep backward compatibility", then when are we gonna move to a newer standard? Or to put it differently, a direct question to you Andrey, at which point in time [which new std, 20, 23, 26, 29, 32???] do you think it will be opportune to move to C++11 and break with C++98 [because doing nothing will always be easier]?

I'm not adamantly against it, not to the point I would rewrite Boost.Log just to stay C++03 compatible. But it would seem that the C++11 requirement is not that necessary in Boost.Parameter either - you can just keep the existing code in C++03 mode it it'll work as before.

I guess, it's always possible to write more code [that's what you ask all maintainers to do] and work around the C++11 specificities? Why do we even get/need new standards, if one can just as well keep writing code the old way, it's absolutely useless [those new standards], the old stuff works. There does not need to be a new Boost release either, it worked so far, and we can write code to work around the bugs [that's what (some) people seem to do] or just depend on known UB [as long as you don't change the compiler, it will keep working]. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

On 11/3/18 5:17 PM, Andrey Semashev wrote:

On 11/3/18 4:21 PM, degski wrote:

...

On Sat, 3 Nov 2018 at 14:41, Andrey Semashev via Boost mailto:boost@lists.boost.org> wrote:

    On 11/3/18 2:47 PM, Cromwell Enage via Boost wrote:      > Hello, Andrey.      >      > It's possible to retain the old code for C++03 compilers.  Which     ones do      > your library users have?

    I don't have this data. Boost.Log is documented to support gcc since     4.5     and MSVC since 8.0 SP1. It might be ok to raise the minimum requirement     a bit, if it makes it easier to support in Boost.Parameter and other     lower level libraries, but switching sraight to C++11 might be big deal     for users.

The following question has been asked many times by many posters and there never is an answer: "Those users who want to stick to the old ways of doing things and like to use unsafe compilers [Meltdown, Spectre come to mind], why can't they just use old versions of Boost?"

As it was answered, also many times: because we don't do support releases. Basically, if a bug is discovered, our recommendation is always "use a more recent Boost release". Of course, users can apply patches to their versions of Boost but this is a significant maintenance burden and may not be acceptable to everyone.

Having new features and libraries might also be desirable. That the user's code base is C++03 doesn't necessarily mean it doesn't evolve.

...

There was, as far as I read it, considerable support to at least move to C++11, which is already 2 standards behind the current standard [and is by now fully supported on the main platforms]. Whatever is documented is not relevant, if the docs are out of date, they have to be updated. If every time this kind of question pops up, the answer is, "let's keep backward compatibility", then when are we gonna move to a newer standard? Or to put it differently, a direct question to you Andrey, at which point in time [which new std, 20, 23, 26, 29, 32???] do you think it will be opportune to move to C++11 and break with C++98 [because doing nothing will always be easier]?

If by "move" you mean actively stripping Boost from C++03 support then probably never. But as far as I'm concerned, Boost has moved to C++11 and later as soon as the first C++11 was accepted.

That should read "the first C++11 library was accepted".

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.

Specifically for Boost.Log, it already does use some of the C++11 features, when available. And I even think it started doing so before C++11 was finalized. But I still consider C++03 compatibility a plus rather than a minus.

On a personal note, I find this "C++11 holy cow" hype quite a pointless waste of breath (or... network bandwidth, I guess). There is no point in dropping libraries on the ground of C++03 compatibility, so that's never going to happen. Boost never rejected libraries that targeted newer C++ versions, that's not changing either. Declaring that we're not testing C++03 compilers anymore might make sense, but we actually do. So I don't quite understand what were the recent discussions about "dropping C++03" about. Just stop debating and start writing some great code, guys! Our users will be only happy. :)

...

    I'm not adamantly against it, not to the point I would     rewrite Boost.Log just to stay C++03 compatible. But it would seem that     the C++11 requirement is not that necessary in Boost.Parameter either -     you can just keep the existing code in C++03 mode it it'll work as     before.

I guess, it's always possible to write more code [that's what you ask all maintainers to do] and work around the C++11 specificities?

It's a tradeoff, of course. In some cases, C++11 or whatever might be crucial for the library design or functionality. The particular case with Boost.Parameter doesn't seem to me like one, so yes, I'd *prefer* to keep the compatibility with C++03. If there appears a case that would make keeping the support for C++03 unreasonable (in Boost.Parameter or elswhere), I will accept it and Boost.Log, by induction, will become C++11-only.

On 11/3/2018 10:47 AM, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

So I don't quite understand what were the recent discussions about "dropping C++03" about.

It appears that not many do.

In short, the point is that much of the outside world thinks of Boost as a single thing. Our perspective as library maintainers is that libraries are independent, but that's not how others view them.

To give you a specific example, if Parameter drops C++03 support, `b2 install` will fail on all compilers where C++03 is default because Log will fail to build. This is spelled "Boost 1.70 fails to build".

I assume that the "dropping C++03 support" was also about building Boost for C++11 on up.

On 11/3/18 8:58 AM, Edward Diener via Boost wrote:

On 11/3/2018 10:47 AM, Peter Dimov via Boost wrote:

...

Andrey Semashev wrote:

...

So I don't quite understand what were the recent discussions about "dropping C++03" about.

It appears that not many do.

In short, the point is that much of the outside world thinks of Boost as a single thing. Our perspective as library maintainers is that libraries are independent, but that's not how others view them.

To give you a specific example, if Parameter drops C++03 support, `b2 install` will fail on all compilers where C++03 is default because Log will fail to build. This is spelled "Boost 1.70 fails to build".

I assume that the "dropping C++03 support" was also about building Boost for C++11 on up.

Hmmm - since C++ versions are backward compatible, almost any C++03 conforming program is also conforming to subsequent versions. The only exceptions are a very few deprecations (like auto). This leads me to not understand what it means to "drop C++03 support". If one want's to compile all of boost with C++11, it should work - subject to the few cases site above. I don't see any need for any action by anyone. Has anyone tried to build all of boost with C++ set to version 11? What are the results? If I had nothing else to do, I could do it. But it's a moot question for me in any case. Hmmm - then why am I replying here? I don't know. Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 11/3/2018 1:07 PM, John Maddock via Boost wrote:

On 03/11/2018 14:47, Peter Dimov via Boost wrote:

...

Andrey Semashev wrote:

...

So I don't quite understand what were the recent discussions about "dropping C++03" about.

It appears that not many do.

In short, the point is that much of the outside world thinks of Boost as a single thing. Our perspective as library maintainers is that libraries are independent, but that's not how others view them.

To give you a specific example, if Parameter drops C++03 support, `b2 install` will fail on all compilers where C++03 is default because Log will fail to build. This is spelled "Boost 1.70 fails to build".

Not if the Jamfile is marked up to require the C++11 (or whatever) features required - then it simply won't be built in 03 mode.  Of course that may still be an issue if 03 is the compilers default mode :(

If we have announced that Boost will no longer support C++03, one of whose meanings is that compiling in C++03 mode may no longer work, then it is up to the end-user not to compile in C++03 mode, whether that is the compiler's default mode or not.

John.

--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

...

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.

minus toolchain bugs. consider std::atomic for example: clang/libcxx had a broken implementation until mid 2014, while msvc had a but until 2016. using new standards early one may have to pay the price of the early adopters. that said, in 2018 boost should be able to safely move to c++11.

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@lists.boost.org> 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

On 11/4/18 11:03 AM, degski wrote: 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@gmail.com

Andrey Semashev wrote:

I'm not adamantly against it, not to the point I would rewrite Boost.Log just to stay C++03 compatible.

Going that far may be unnecessary; we could just fork a `parameter03` so that C++03 libraries can keep using it.

On Sunday, November 4, 2018, Edward Diener wrote:

I am really surprised that after he discussion and general agreement that Boost would be dropping support for C++03 that there would still be objections for a Boost library going from C++03 to C++11, as Parameter wishes to do under the guidance of Cromwell Enage. Was not the discussion about dropping support for C++03 a pretty clear indication that retaining backward compatibility for C++03, in a library going to C++11, should no longer be desired ?

Is this a case of the official maintainer of Parameter choosing to drop C++03 and make it a C++11+-only library? If so, under the model we discussed and that had general agreement, nobody else can block this from happening. i.e. There can be no objection. It would be the system working as intended. Parameter would become C++11+-only and affected libraries would have to do the same or drop the dependency on Parameter. However: If this is a case of a library with no official maintainer, but where a prospective contributor (or some community maintenance team) wishes to do the above, and then solicits blessing/approval from affected libraries' maintainers, and then one or more of those maintainers prefers to find a solution that will retain C++03 compatibility: Then whatever compromise was agreed upon between these parties would also be the system working as intended. Glen

-----Original Message----- From: Boost On Behalf Of Paul A. Bristow via Boost Sent: Monday, November 5, 2018 1:26 PM

My view is that it is up to you to decide (but asking for views is good too).

If it is not too difficult to make it continue to be C++03 compatible and yet allow C++11 (or higher) improvements then you should do this.

For example, if you can easily write

#ifdef BOOST_NO_C11_feature

do the current C++03 stuff (even full function definition)

#else

do the enhanced version

#endif

then you should do so, in order to avoid, as RyanAir CEO Michael O'Leary put it

"We should try to eliminate things that unnecessarily piss people off,"

(See https://www.reuters.com/article/us-ryanair/ryanair-unveils-new-strategy-be-n... customers-idUSBRE98J0DF20130920 for sordid details)

Just saying. #ifdef BOOST_NO_C11_feature can become extremely annoying for the user, because you effectively have to make sure that all translation units including that header have to be compiled with the same c++ standard setting (yes, it isn't actually necessary when you are careful, but the complexity and testing overhead will probably negate much of the advantage you gain by using c++11 features instead of 03 workarounds).

but if this proves difficult (and trying it may be the only way to find out) then you should announce that it will require some C++11 feature one release ahead of the change.

I'd give a two release heads up (Announce the change in 1.69, put an compilation warning in 1.70 and then start using the c++11 features in 1.71). Although there was tentatively agreement on the ML that c++03 support should be dropped on a general boost-wide level and that that would also mean that maintainers can drop their individual c++03 support without prior announcement, this has not yet become official policy or widely announced, so I'd tread carefully here. Best Mike

On Mon, 5 Nov 2018 at 20:38, degski via Boost wrote:

On Mon, 5 Nov 2018 at 14:26, Paul A. Bristow via Boost < boost@lists.boost.org> wrote:

...

then you should do so, in order to avoid, as RyanAir CEO Michael O'Leary put it

"We should try to eliminate things that unnecessarily piss people off,"

(See

https://www.reuters.com/article/us-ryanair/ryanair-unveils-new-strategy-be-n...

...

for sordid details)

Michael O'Leary talks a lot of shit, the quoted article is from 2013, in the meanwhile Michael O'Leary has come up with ideas like [but not limited to], travel standing up (strapped in on departure and arrival), paying to go to the loo and of course the 6-monthly change in baggage-policy [can he ever make up his mind?]. His company also violates [continuously] EU labor- and tax-law, basically takes people for granted, both personnel and customers, and makes DT look civilized.

Let's not try and learn from Michael O'Leary, because in that case you'd have to pay extra to have C++03 support and Boost would be fully C++17.

On this I am fully with Michael O'Leary. The argument for staying with c++03 is the same as the argument for staying with the biplane. Fun for nostalgic airshows but utterly useless as a business tool.

degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212 (this will be *expensive* outside Andorra!) skype: madmongo facebook: hodges.r

Thanks for your feedback, everyone! To answer Glen Fernandes's question, I am not the official maintainer, just a contributor who is willing to help improve a Boost library. I've submitted a separate pull request that includes the C++03 workarounds. I did this in case our official stance for 1.70 is to keep C++03 support, and also in an effort to ensure that the downstream libraries, a few of which I also use, won't break (or at least won't have their tests broken). Regarding Paul Bristow's input, it hasn't been a load of trouble, but it was bad enough. I'll leave it up to the official maintainer(s) to decide which PR to approve. That being said, should the new PR be the chosen one, any new features I plan to add from that point on will not include explicit C++03 workarounds. Cromwell D. Enage