On 8 February 2018 at 03:20, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

The same is possible with library components, although it may incur more overhead. In case of boost/std::function, I would use boost::function or even a custom function wrapper internally (the latter is useful to remove the dependency on Boost.Function). I don't see any advantage of using std::function.

Using std::function has one advantage, though, it's standardised. degski

On 8 February 2018 at 09:16, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

On 02/08/18 17:27, degski via Boost wrote:

...

On 8 February 2018 at 03:20, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

The same is possible with library components, although it may incur more

...

overhead. In case of boost/std::function, I would use boost::function or even a custom function wrapper internally (the latter is useful to remove the dependency on Boost.Function). I don't see any advantage of using std::function.

Using std::function has one advantage, though, it's standardised.

In the context of this discussion, it's irrelevant.

It seems only logical to me to decrease coupling with other boost libraries as time moves on, to use the std-equivalent of certain boost libraries... Subtle differences exist (between std- and boost-versions of certain libs), i.e. random, file-system and others... and this is a pita... IMHO, boost libs that state that they are let's say C++14, should use std::array, std::chrono, std::random (and std::function), etc... and decrease coupling with other parts of boost... degski

On 8 February 2018 at 13:25, Peter Dimov via Boost wrote:

degski wrote:

...

...

...

Using std::function has one advantage, though, it's standardised.

In the context of this discussion, it's irrelevant.

It seems only logical to me to decrease coupling with other boost libraries as time moves on, to use the std-equivalent of certain boost libraries...

This discussion is about link compatibility between code compiled with C++03 and code compiled with C++11. If your code uses std::function, it can't be compiled with C++03 and therefore this thread is simply not for you.

Yes, I get that, I'm stating the opposite, if it's compiled with C++11, it should use std::function. There's an interesting std::function replacement in Cometa https://github.com/kfrlib/cometa, btw. degski PS: I really don't understand the focus of boost to always want to compile stuff with the most archaic compilers possible. If your using an old compiler, just use a(n older) boost version that works with that specific compiler.

On 8 February 2018 at 13:54, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

... Those code bases are supposed to link with whatever Boost version

Why does this have to be the case, why does it "have" to be whatever version? degski

On 8 February 2018 at 14:42, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

Because otherwise such code base becomes unshippable with that distro (i.e. cannot be packaged for that distro).

Not everybody uses linux, in reality most people don't... degski

On 8 February 2018 at 16:35, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

Most people do, actually.

So linux is the prevailing OS? How do you measure this? If Google Inc. is using linux on 500'000 servers, that, to me, counts as 1 user. Some references (links) please. So you're suggesting what, exactly? Leaving Linux people out in the cold?

And, probably, every other UNIX-like system, too, since the poor distribution culture is mostly an unfortunate property of the Windows ecosystem.

" distribution culture" is (mostly, so far) a nix-concept. degski

On 8 February 2018 at 17:11, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

Given that those servers are used by millions of people, you may want to count again.

Well, no, there probably is for all those servers, just 1 compiled version (with distributed copies) of boost (or any library). In all segments except desktop/laptop, Linux or Android is in the lead. Again, Android for me counts as 1 user (apart from the fact we're not talking C or C++ anymore), as 99.99999999% of Android users wouldn't know what a software library is, they know what "like" means, though!

So one way or the other, most likely you're using Linux somehow.

Yes, in my router.

Anyway, this is going into offtopic/flamewar territory.

As long as it's civilized, it's like sitting in the pub, and discuss the issues of the world over a couple of beers (or vodkas, what you prefer), no harm in that... degski

degski wrote:

PS: I really don't understand the focus of boost to always want to compile stuff with the most archaic compilers possible. If your using an old compiler, just use a(n older) boost version that works with that specific compiler.

So mp11 and Beast need to be C++17 because those using C++11 can always use an earlier version of Boost. Except earlier versions of Boost have neither. Oops.

degski wrote:

No, no, no, f.e. boost::mp11, or boost::beast are to be compiled with C++11 and should therefor use std C++11 libraries instead of their equivalent boost version...

That's what they do; except Beast uses Boost.System because ASIO uses it, and it uses Boost.Optional and boost::string_view because std::optional and std::string_view are C++17, and so on. It's not like we go out of our way to avoid using the available standard facilities.

degski wrote:

But, do the libs you quoted use std::optional and std::string_view (instead of their boost impersonations) when compiled with C++17?

Assuming a non-header-only library for the sake of going back onto the topic, this would create exactly the problems we've been discussing, if you link your C++17 code to the C++14-built library, or vice versa. For what gainz?

degski wrote:

...

Assuming a non-header-only library for the sake of going back onto the topic, this would create exactly the problems we've been discussing, if you link your C++17 code to the C++14-built library, or vice versa. For what gainz?

I'm probably missing the point. If that C++17 (exe-code) and C++14 (library-code) are built with the same compiler (an unavoidable C++ problem, C is great in some sense!), unless the C++17 code is in the header, why would it cause problems?

Because if you have class X { private: beast::string_view sv_; public: // ... }; the class layout and size could change if you compile this in two translation units, one C++14 (uses boost::string_view), one C++17 (uses std::string_view). Same with optional.

On 8 February 2018 at 17:42, degski wrote:

On 8 February 2018 at 17:36, Peter Dimov via Boost wrote:

...

the class layout and size could change if you compile this in two translation units, one C++14 (uses boost::string_view), one C++17 (uses std::string_view).

Does this apply also when using static libs, each one statically linked to its' CRT (at the time of compilation)?

Just to be sure you take the above in the right way. I'm not trying to wind you up, I'm trying to learn something (from the experts). degski

On 8 February 2018 at 17:58, Peter Dimov via Boost wrote:

And, if we're talking about string_view in particular, it's often used in interfaces as a function parameter so it'd be pretty much guaranteed to blow up unless boost::string_view and std::string_view happen to share the same layout.

Again, this was my point from the start, if a standard lib provides a (std-)facility, that's the one that should be used, just to avoid that problem. boost::string_view is just impersonating std::string_view, no guarantee that they are the same, std::string_view should be used, also inside boost (if available). On STL-level, this happens as well of course, between different versions. Thanks, for the clarification... degski

Edward Diener wrote:

As far as which library to use, depending on the compiler/version available, either boost or std, of two very similar libraries, this is what my Cxx_dual library (https://github.com/eldiener/cxx_dual) is all about.

That's not going to work at all if link compatibility is desired. If you have class something { private: CXXD::function f_; public: // ... }; the layout of `something` changes between C++03 and C++11, which leads to incredibly nasty things at runtime as objects appear at the wrong address and the observed behavior makes no sense. I inadvertently introduced such a problem in Boost.System when I made the object layout dependent on whether was available, to enable conversions from/to std::error_code. It's not fun at all. (I have since fixed that, and added tests that link to the library from a forced-03 or forced-11 main.cpp. Incidentally, the layout of std::string also changes between 03 and 11, so if such compatibility is desired, you can't use that either.) (But there's absolutely no need to use std::function "for std::bind compatibility". boost::function can store std::bind just fine (and vice versa.))

Edward Diener wrote:

I discuss a solution for this in the documentation topic "Use in a non-header only library".

lib MyLib : MyHeader.cpp : <define>CXXD_ARRAY_USE_BOOST <define>CXXD_FUNCTION_USE_BOOST <define>CXXD_REGEX_USE_BOOST <define>CXXD_TUPLE_USE_BOOST <define>MYLIB_BEING_BUILT ; lib MyLib_std : MyHeader.cpp : <define>CXXD_ARRAY_USE_STD <define>CXXD_FUNCTION_USE_STD <define>CXXD_REGEX_USE_STD <define>CXXD_TUPLE_USE_STD <define>MYLIB_BEING_BUILT ; lib MyLib_ar_fn_rx : MyHeader.cpp : <define>CXXD_ARRAY_USE_STD <define>CXXD_FUNCTION_USE_STD <define>CXXD_REGEX_USE_STD <define>CXXD_TUPLE_USE_BOOST <define>MYLIB_BEING_BUILT ; lib MyLib_ar_fn_tp : MyHeader.cpp : <define>CXXD_ARRAY_USE_STD <define>CXXD_FUNCTION_USE_STD <define>CXXD_REGEX_USE_BOOST <define>CXXD_TUPLE_USE_STD <define>MYLIB_BEING_BUILT ; lib MyLib_ar_fn : MyHeader.cpp : <define>CXXD_ARRAY_USE_STD <define>CXXD_FUNCTION_USE_STD <define>CXXD_REGEX_USE_BOOST <define>CXXD_TUPLE_USE_BOOST <define>MYLIB_BEING_BUILT ; lib MyLib_ar_rx_tp : MyHeader.cpp : <define>CXXD_ARRAY_USE_STD <define>CXXD_FUNCTION_USE_BOOST <define>CXXD_REGEX_USE_STD <define>CXXD_TUPLE_USE_STD <define>MYLIB_BEING_BUILT ; lib MyLib_ar_rx : MyHeader.cpp : <define>CXXD_ARRAY_USE_STD <define>CXXD_FUNCTION_USE_BOOST <define>CXXD_REGEX_USE_STD <define>CXXD_TUPLE_USE_BOOST <define>MYLIB_BEING_BUILT ; lib MyLib_ar_tp : MyHeader.cpp : <define>CXXD_ARRAY_USE_STD <define>CXXD_FUNCTION_USE_BOOST <define>CXXD_REGEX_USE_BOOST <define>CXXD_TUPLE_USE_STD <define>MYLIB_BEING_BUILT ; lib MyLib_ar : MyHeader.cpp : <define>CXXD_ARRAY_USE_STD <define>CXXD_FUNCTION_USE_BOOST <define>CXXD_REGEX_USE_BOOST <define>CXXD_TUPLE_USE_BOOST <define>MYLIB_BEING_BUILT ; lib MyLib_fn_rx_tp : MyHeader.cpp : <define>CXXD_ARRAY_USE_BOOST <define>CXXD_FUNCTION_USE_STD <define>CXXD_REGEX_USE_STD <define>CXXD_TUPLE_USE_STD <define>MYLIB_BEING_BUILT ; lib MyLib_fn_rx : MyHeader.cpp : <define>CXXD_ARRAY_USE_BOOST <define>CXXD_FUNCTION_USE_STD <define>CXXD_REGEX_USE_STD <define>CXXD_TUPLE_USE_BOOST <define>MYLIB_BEING_BUILT ; lib MyLib_fn_tp : MyHeader.cpp : <define>CXXD_ARRAY_USE_BOOST <define>CXXD_FUNCTION_USE_STD <define>CXXD_REGEX_USE_BOOST <define>CXXD_TUPLE_USE_STD <define>MYLIB_BEING_BUILT ; lib MyLib_fn : MyHeader.cpp : <define>CXXD_ARRAY_USE_BOOST <define>CXXD_FUNCTION_USE_STD <define>CXXD_REGEX_USE_BOOST <define>CXXD_TUPLE_USE_BOOST <define>MYLIB_BEING_BUILT ; lib MyLib_rx_tp : MyHeader.cpp : <define>CXXD_ARRAY_USE_BOOST <define>CXXD_FUNCTION_USE_BOOST <define>CXXD_REGEX_USE_STD <define>CXXD_TUPLE_USE_STD <define>MYLIB_BEING_BUILT ; lib MyLib_rx : MyHeader.cpp : <define>CXXD_ARRAY_USE_BOOST <define>CXXD_FUNCTION_USE_BOOST <define>CXXD_REGEX_USE_STD <define>CXXD_TUPLE_USE_BOOST <define>MYLIB_BEING_BUILT ; lib MyLib_tp : MyHeader.cpp : <define>CXXD_ARRAY_USE_BOOST <define>CXXD_FUNCTION_USE_BOOST <define>CXXD_REGEX_USE_BOOST <define>CXXD_TUPLE_USE_STD <define>MYLIB_BEING_BUILT ; This probably gives you an idea why one might prefer to always use the Boost components instead.

Edward Diener wrote:

As discussed in the doc to the CXX Dual library you do not have to choose to allow all possible variations, depending on how many different CXXD mods you decide to use. You could decide that if C++11 on up is being used your name is some 'xxx_std' while if C++11 on up is not being used your name is 'xxx', and therefore you have two naming variants.

You could do that, and it simplifies things considerably (although it doesn't allow you to link 03 with 11.) But if you do that, what's the point of having separate CXXD macros per component then? You only need one, and the whole CXXD library collapses to a single `namespace cxxd = std|boost` directive.

On 9. Feb 2018, at 10:31, Richard Hodges via Boost wrote:

...

Isn't it time to require C++11 to avoid spending / wasting time on these issues?

+1

Upgrading one’s compiler to adopt the current standard is free and riskless.

tl;dr I know that this is not so simple, at least if you want your software to run on a large in-homogeneous ecosystem of computers. That being said, I see no problem requiring C++11 as the new lowest common denominator at this point. Theoretically, yes, it should be a problem to just require C++11, but I know from personal experience that there can be a lot of inertia involved in the switch from C++03 to C++11. I worked with the IceCube Neutrino Observatory for two years, and during that whole time the core developers (included me) wanted to move to C++11 and couldn't make the transition. There was no issue for people doing computing on their desktop at all, it was an issue when the software should run on computing clusters, which were invariably stuck with terribly old compilers. To understand that, you need to know that the computing clusters used in research are typically local clusters run independently by some universities. Naturally, such a disorganised ecosystem tends to be quite in-homogenous, so you have to accommodate the smallest common denominator. Now those of you in the industry probably laugh at this point and shout things like Docker and VMs, but scientists (perhaps surprisingly) are quite slow at adapting to these new technologies and tend to prefer "conservative" and "simple" solutions. I think this is mostly because administrators of said computing clusters are typically former scientists, not people from the industry, employed for life who tend to be overburdened with their daily work, so they don't find the extra time required to upgrade the software on a cluster. Just my two cents on the issue, Hans

On 9 February 2018 at 10:15, Paul A. Bristow via Boost < boost@lists.boost.org> wrote:

Historically Boost has always taken the line that *each library* is allowed to set its minimum compiler/standard level.

This is a slightly dis-ingenious statement, I think. Boost's first release dates from 1999, so after publication of C++98. C++03 was an bug fix release. Which means that, in case we are talking about going towards C++11, we can see that since its' inception boost has not encountered any (significant) new standard(s). So far, support for C++11 has not been ubiquitous, so historically it makes sense not to push for moving to C++11. In the meanwhile, the landscape looks different.

More complicated is if an existing library wants to up its requirements. Sometimes this can be achieved using macro tests - and Boost is massively complicated by doing this already.

And with new standards rolling in every three years, and (future) removal of deprecated features and more frequent fixes, this is only gonna get worse, i.e. Peter D. proposal to move to positive macros.

Many libraries author who want to make a big step like moving to C++11(++) may find it easier to have a separate new version 2 (3...) as this allows them to take full advantage of new features to do things better (and cut the crap).

Moving to using a C++11 compliant compiler is not a big step IMO, you don't need to use any C++11 feature iff you don't want to.

This clearly suits those that don't want to update compilers.

That is just mad cow disease !

Authors wanting to make a breaking change like requiring C++11(++) can also take the line that those who won't update Boost can only continue using C++03 by freezing at an old Boost version.

Exactly, if you don't want to upgrade compiler, it's better to use the old libs, they we're at the time well tested with the compilers of the day. degski

On 9 February 2018 at 11:18, Peter Dimov via Boost wrote:

degski wrote:

Moving to using a C++11 compliant compiler is not a big step IMO,

...

It is if you use MSVC because there isn't one yet. :-)

Clang snapshot build. If you don't want to use the C++11 features (in which context I said that), it doesn't matter whether it's fully C++11-compliant. degski

Niall Douglas wrote:

...

...

Moving to using a C++11 compliant compiler is not a big step IMO,

It is if you use MSVC because there isn't one yet. :-)

I've been deliberately adding nothing to this thread ... but this is unfair. VS2017.5 implements enough of C++ 14, let alone C++ 11, that little code not relying on the correctness of preprocessor would notice the deficiencies from the standard. Even two phase lookup mostly seems to work now.

It was a joke. But I actually had constexpr (the C++11 kind) in mind, not the preprocessor or C++03 things. I have admittedly not tested with 1912, but it didn't yet quite work with 1911.

El feb. 9, 2018, a las 08:15, Paul A. Bristow via Boost mailto:boost@lists.boost.org> escribió:

Historically Boost has always taken the line that *each library* is allowed to set its minimum compiler/standard level.

So if a library declares it needs C++11 (or indeed C++14, C++17, C++20 ...), then that’s fine. In fact, it's more than fine - it's excellent ;-)

Really? Your email lays out the obstacles nicely, but you're more optimistic than I am :) Is there an example of an existing library that ditched C++03 support? If a library with no dependents (say, boost::log or boost::process) declared they were going C++11-only in boost-1.70, would that really be allowed? Or would they be required to fork a v11 in order to avoid breaking compatibility? If a library with dependents (say, boost::date_time) wanted to go C++11, would the community rally to push its dependent libraries to move too? Boost serves two roles: (1) making cool things work on "all" compilers (even older/buggy ones); and (2) doing cool things that push the limits of the language but require newer support. The gulf between the two is growing and eventually the whole project will need to roll forward its minimum version to keep the surface area sane. I think we're nearing that inflection point, but I sure don't know how to break the stalemate. Jared

On 02/09/18 12:13, Olaf van der Spek via Boost wrote:

On Thu, Feb 8, 2018 at 9:50 AM, Raffi Enficiaud via Boost wrote:

...

* is there any better option? All the other options I see are even worse.

Isn't it time to require C++11 to avoid spending / wasting time on these issues?

What do you propose to do with libraries that want to keep C++03 compatibility and rely on Boost.Test in tests?

On 2/9/2018 4:49 AM, Richard Hodges via Boost wrote:

...

What do you propose to do with libraries that want to keep C++03 compatibility and rely on Boost.Test in tests?

Demand that they be upgraded or drop them in favour of better-behaved ones.

Only the future is ahead. The past is irrelevant.

A library that demands c++03 is not a c++ library. It’s merely a blocker to productivity. It must adapt or die.

Since C++03 is the lowest level of C++ standards compatibility, it can hardly "demand" anything. If you think it does please point out a C++03 construct which is not supported by later C++ standards.

...

On 9 Feb 2018, at 09:45, Andrey Semashev via Boost wrote:

On 02/09/18 12:13, Olaf van der Spek via Boost wrote:

...

On Thu, Feb 8, 2018 at 9:50 AM, Raffi Enficiaud via Boost wrote:

...

* is there any better option? All the other options I see are even worse. Isn't it time to require C++11 to avoid spending / wasting time on these issues?

What do you propose to do with libraries that want to keep C++03 compatibility and rely on Boost.Test in tests?

On 9 February 2018 at 15:45, Thomas Heller via Boost wrote:

std::auto_ptr.

We've been fixing libraries that require auto_ptr, unary_function etc.

On 9 February 2018 at 09:45, Thomas Heller via Boost wrote:

Since C++03 is the lowest level of C++ standards compatibility, it can hardly "demand" anything. If you think it does please point out a C++03 construct which is not supported by later C++ standards.

std::auto_ptr.

register keyword, trigraphs, operator++(bool), exception specifications. degski

Am 09.02.2018 5:18 nachm. schrieb "Daniel James via Boost" < boost@lists.boost.org>: On 9 February 2018 at 16:08, degski via Boost wrote:

On 9 February 2018 at 09:45, Thomas Heller via Boost < boost@lists.boost.org> wrote:

...

Since C++03 is the lowest level of C++ standards compatibility, it can hardly "demand" anything. If you think it does please point out a C++03 construct which is not supported by later C++ standards.

std::auto_ptr.

register keyword, trigraphs, operator++(bool), exception specifications.

Do any of our libraries use any of those? Is this really the topic of this thread? Isn't it more about code depending on boost libraries that might not be as easy to upgrade as one might think? Or distributed binaries compiled with a different flavor than you favor? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

On 2/9/2018 11:08 AM, degski via Boost wrote:

On 9 February 2018 at 09:45, Thomas Heller via Boost wrote:

...

Since C++03 is the lowest level of C++ standards compatibility, it can hardly "demand" anything. If you think it does please point out a C++03 construct which is not supported by later C++ standards.

std::auto_ptr.

register keyword, trigraphs, operator++(bool), exception specifications.

OK, but those are all pretty obscure constructs, even for C++03. I do not think that any Boost library uses any of the above but I do agree that if a C++03 library uses some language feature that is dropped in subsequent versions of the C++ standard it should at least consider upgrading itself to be usable by others compiling with that later version. However I am still against the notion that Boost is going to dictate a level of the C++ standard in which all libraries in Boost must be written. You can not force developers to use constructs and libraries which they do not find useful. I do agree with the idea that a Boost library should be usable when compiled with a later version of the C++ standard than that for which the library itself was written. The issue with Boost Test is that if it now requires a C++11 level compiler to use it, every library which tests itself using Boost Test now requires a C++11 level compiler to run its tests.

degski

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of degski via Boost Sent: 09 February 2018 20:56 To: boost Cc: degski Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries

On 9 February 2018 at 14:48, Edward Diener via Boost wrote:

...

The issue with Boost Test is that if it now requires a C++11 level compiler to use it, every library which tests itself using Boost Test now requires a C++11 level compiler to run its tests.

So, unless this requirement is lifted, the Rubicon has already been crossed...

In a sense, yes, but Boost.Test C++03 from release 1.66 still exists. So those who stay with C++03 won't be able to rely on the tester-runners to test updated libraries, but they can still use Boost.Test C++03 to run the test themselves - if they care. Or they can freeze their Boost version completely continuing with the bugs they know and love. I suspect the Laggards will just muddle on? Meanwhile the Modernizers can muddle forward - it clearly isn't straightforward. I think that the current process is working OK just as Daniel James's updated guidance (good - thanks) suggests https://beta.boost.org/development/requirements.html#Backwards_compatibility Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830 Paul

On 11 February 2018 at 13:36, Edward Diener via Boost

wrote:

I would find it a bit alarming if testing a Boost library, which uses Boost Test as its testing infrastructure, can no longer be done in C++03 mode for various compilers. Boost would basically be saying to end-users, if you are using such-and-such a library we can no longer test it in C++03 mode.

I would go further and state that it says that C++03 is not supported.

Since I offered my solution to this quandary with CXXD, and since I have seen no solution in this thread that is better than what I offered, it is useless for me to comment further about trying to solve the problem.

Bar Boost 2.0, CXXD is as close as we can get to a satisfying solution (iff it does what it says on the tin). Integrating CXXD in the basic infrastructure would be required, and a review, I guess. However, subtle differences between std:: and boost:: counterparts exist, which could be (is, actually) a deal-breaker. degski

On 11 February 2018 at 15:55, Edward Diener via Boost

wrote:

What exactly do you mean by C++03 is not supported ?

I mean that if testing of Boost is not supported for C++03, that effectively means that Boost does not support C++03.

In other words what do you think constitutes a C++03 library versus a C++11 library, such that a Boost C++03 library should not be supported ?

These things are obviously not necessarily mutually exclusive. A C++11 library is a lib that requires C++11 (be it libs a la std::array, or r-value references), a C++03-library is one that uses constructs not in the C++11 standard. Admittedly those constructs are only a handful. However, going forward, more and more constructs are being deprecated (and will subsequently be removed, cppreference.com tags quite some things deprecated). Then there are those libraries that don't support move semantics, while they could benefit from it. degski

On 11 February 2018 at 17:01, Edward Diener via Boost

wrote:

You are saying then that what you mean by "C++03 is not supported" is compiling in C++03 mode.

No, I mean that if the test suite (of a library) cannot compile with C++03, one has to qualify the library as non-C++03 (even if it might on the surface look as if the library (not the test-suite) *does* compile with C++03). If I cannot test it, it's not vali(date)d code.

... But I hope you realize that is different from saying that C++03 libraries, meaning libraries not using C++11or above constructs or libraries, should not be part of Boost.

I agree with you, I don't think they should not be part of boost. However, I do think that to at least support moves (not only the semantics) (for all libraries) when compiled with C++11 or above, should be on the road-map, and then of course CXXD (so I get the std::-equivalent of the library in the standard I'm compiling the library with). degski

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener via Boost Sent: 12 February 2018 04:27 To: boost@lists.boost.org Cc: Edward Diener Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries

On 2/11/2018 6:46 PM, degski via Boost wrote:

...

On 11 February 2018 at 17:01, Edward Diener via Boost

...

wrote:

OTOH I think you can encourage feature addition for a particular library but I do not think forcing some C++11 on up construct or library to be used is something that Boost ought to be doing.

+1 Some on this thread seem to view 'support' and 'validated' as binary features. Boost (and life in general) really isn't as simple as that. Have you looked at the test matrix recently - there is plenty of 'not-green'. Have you looked at the unfixed bugs'n'features list? There are plenty :-( Tests done are a small subset of possible tests (they tend to infinity - for example a loopback test of double to decimal digits string and back was found to take a lifetime for all possible 64-bit doubles). There are lots of tests that pass on one compiler and fail on others. So Boost (like everyone else) has always worked on a 'best-efforts' promise. The tests are a guide to what works, but every user must 'suck it and see' and do additional tests in their environment for their application for their risk tolerance. If a library author is willing to provide a workaround for a pre-C++latest compiler, then users of that library should consider themselves lucky. And if tests work with an obsolete compiler, then that's an ever bigger bonus too. But having said that, Raffi's move to need C++11 compilers for Boost.Test should certainly focus *users* minds on the benefits of upgrading. (And he is managing it 'by the book' by raising the issue here now). Getting all legalistic about what is 'supported' isn't going to help IMO. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

On February 11, 2018 11:27:00 PM EST, Edward Diener via Boost wrote:

On 2/11/2018 6:46 PM, degski via Boost wrote:

...

On 11 February 2018 at 17:01, Edward Diener via Boost

...

wrote:

...

You are saying then that what you mean by "C++03 is not supported" is compiling in C++03 mode.

No, I mean that if the test suite (of a library) cannot compile with C++03, one has to qualify the library as non-C++03 (even if it might on the surface look as if the library (not the test-suite) *does* compile with C++03). If I cannot test it, it's not vali(date)d code.

You are saying that any library which compiles in C++03 mode is not supported if uses Boost Test for its testing framework, otherwise it is still still supported.

Such a library would be known to compile on 03 mode, but templates would only undergo the first phase checking. If the library is not changed, that would be OK. The moment one makes a change, then there's no certainty of 03 compatibility. Non-template code is safer in this regard, but not completely safe. If Boost.Test were to have two different backend libraries for 03 and 11 support, the headers adjusted appropriately according to the language, and the right library were linked each time, both languages could be supported. The problem, as Raffi seems to be discussing, is whether and how to allow those using 11 to continue using boost::function. IOW, should testing in 11 mode require switching to std::function? -- Rob (Sent from my portable computation device.)

On 2/11/2018 3:32 PM, Richard Hodges via Boost wrote:

...

Boost would basically be saying to end-users, if you are using such-and-such a library we can no longer test it in C++03 mode.

Compiler vendors are not going to focus on improving legacy support for outdated standards. Why should boost? I don't see any new web programs being written in javascript version 3, on node v1, targeting an IE 5 client. Why should people who insist on doing that in c++ be supported? It just wastes everyone else's time.

The message should be, "upgrade your compiler, or get out of the way. You're holding everyone else up with your buggy old non-conforming compiler."

I have seen some lame excuses as to why people can't (won't) upgrade, and that's fine, if people are happy with legacy compilers then presumably they're happy with legacy versions of libraries. Let them remain on boost 1.66.

All this legacy support simply clutters up boost and makes it unnecessarily complicated.

Arguably, boost has more market penetration than any one compiler. If word gets around that a vendor's compiler is not compatible with boost, that vendor is at risk of people dropping their garbage compiler like a hot stone. This is in reality no different to being incompatible with the standard library. It would be commercial suicide. They will fix their compilers rather than lose market share.

c++ needs to move forward. Slavish devotion to backwards compatibility is a burden it can not afford.

Thee are two completely different things here when discussing C++03 versus C++11 on up. They are: 1) Should Boost support its libraries when end-users compile in C++03 mode ? 2) Should Boost libraries themselves be required to support C++11 in some way, although I am still waiting to understand what that way appears to be from you or others whose rhetoric isn't saying very much to me ? As far as 1) is concerned, I think Boost must consider that this may be disappointing to end-users who still work in applications which do not support C++11 on up compilation. I am not saying you are wrong in your opinion, I am just saying that Boost has to understand what this means to some number of end-users before deciding to go in this direction. As for 2) I see absolutely no practical difference between a library which compiles and works fine in C++11 on up mode, yet uses no construct or library which is part of the C++11 on up standard, and a library which uses some construct or library which is part of the C++11 on up standard, and also works fine when compiled in C++11 on up mode.

R

On 11 February 2018 at 19:36, Edward Diener via Boost

...

wrote:

...

On 2/11/2018 8:25 AM, Paul A. Bristow via Boost wrote:

...

-----Original Message-----

...

From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of degski via Boost Sent: 09 February 2018 20:56 To: boost Cc: degski Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries

On 9 February 2018 at 14:48, Edward Diener via Boost < boost@lists.boost.org> wrote:

The issue with Boost Test is that if it now requires a C++11 level

...

compiler to use it, every library which tests itself using Boost Test now requires a C++11 level compiler to run its tests.

So, unless this requirement is lifted, the Rubicon has already been crossed...

In a sense, yes, but Boost.Test C++03 from release 1.66 still exists.

That does little good for testing latest changes.

...

So those who stay with C++03 won't be able to rely on the tester-runners to test updated libraries, but they can still use Boost.Test C++03 to run the test themselves - if they care.

I would find it a bit alarming if testing a Boost library, which uses Boost Test as its testing infrastructure, can no longer be done in C++03 mode for various compilers. Boost would basically be saying to end-users, if you are using such-and-such a library we can no longer test it in C++03 mode.

Since I offered my solution to this quandary with CXXD, and since I have seen no solution in this thread that is better than what I offered, it is useless for me to comment further about trying to solve the problem. But Boost should understand exactly what they are telling end-users if this change has been made or will be made to Boost Test.

...

Or they can freeze their Boost version completely continuing with the bugs they know and love.

I suspect the Laggards will just muddle on?

Meanwhile the Modernizers can muddle forward - it clearly isn't straightforward.

I think that the current process is working OK just as Daniel James's updated guidance (good - thanks) suggests

https://beta.boost.org/development/requirements.html#Backwar ds_compatibility

Paul

--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Paul

Paul A. Bristow wrote:

degski wrote:

...

On 9 February 2018 at 14:48, Edward Diener via Boost wrote:

...

The issue with Boost Test is that if it now requires a C++11 level compiler to use it, every library which tests itself using Boost Test now requires a C++11 level compiler to run its tests.

So, unless this requirement is lifted, the Rubicon has already been crossed...

In a sense, yes, but Boost.Test C++03 from release 1.66 still exists.

So those who stay with C++03 won't be able to rely on the tester-runners to test updated libraries, but they can still use Boost.Test C++03 to run the test themselves - if they care.

The practical effect of Boost.Test requiring C++11 will be that everything C++03 in the test matrix (using Boost.Test) will fail. We'll have to deal with that in some way. One option is to just stop testing C++03. Another is to migrate the libraries away from Boost.Test. Yet another is to do nothing and pay no attention to failures. Number two is the only option making any sense to me, but keep in mind that many of the affected libraries have no active maintainers, and the CMT is not terribly underworked.

On 2/12/2018 2:32 AM, Raffi Enficiaud via Boost wrote:

Le 12.02.18 à 02:17, Peter Dimov via Boost a écrit :

...

Paul A. Bristow wrote:

...

degski wrote:

...

On 9 February 2018 at 14:48, Edward Diener via Boost > wrote:

...

The issue with Boost Test is that if it now requires a C++11 level compiler to use it, every library which tests itself using Boost Test > > now requires a C++11 level compiler to run its tests.

So, unless this requirement is lifted, the Rubicon has already been crossed...

In a sense, yes, but Boost.Test C++03 from release 1.66 still exists.

So those who stay with C++03 won't be able to rely on the tester-runners to test updated libraries, but they can still use Boost.Test C++03 to run the test themselves - if they care.

The practical effect of Boost.Test requiring C++11 will be that everything C++03 in the test matrix (using Boost.Test) will fail.

We'll have to deal with that in some way. One option is to just stop testing C++03. Another is to migrate the libraries away from Boost.Test. Yet another is to do nothing and pay no attention to failures.

Number two is the only option making any sense to me,

Are you serious? I committed to maintain Boost.Test, not to burry it. Boost.Test **does** support C++03 and C++11. Boost.Test has values in the C++ testing ecosystem, there is no point in killing it.

The initial question was a technical one, something that did not appear obvious to me about mixed APIs spanning several dialects. I am not asking for people to tell what the fate of Boost.Test should be: I am well aware that Boost.Test needs to continue supporting C++03, I am taking care of that. And yes, Boost.Test is used by people outside the Boost community.

That is good to hear. Thanks !

...

but keep in mind that many of the affected libraries have no active maintainers, and the CMT is not terribly underworked.

On 9 February 2018 at 14:48, Edward Diener via Boost wrote:

However I am still against the notion that Boost is going to dictate a level of the C++ standard in which all libraries in Boost must be written.

That's not what I've been trying to put across, though... Apart from the constructs put forward in this thread (and there are probably some more), one can write perfectly fine C++11 without using any feature introduced in that particular standard.

You can not force developers to use constructs and libraries which they do not find useful.

No, no need for that, see above.

I do agree with the idea that a Boost library should be usable when compiled with a later version of the C++ standard than that for which the library itself was written.

Exactly...

The issue with Boost Test is that if it now requires a C++11 level compiler to use it, every library which tests itself using Boost Test now requires a C++11 level compiler to run its tests.

Rubicon crossed... degski

On Fri, Feb 9, 2018 at 2:26 PM, Edward Diener via Boost < boost@lists.boost.org> wrote:

I am all for C++03 libraries upgrading their implementation if a later version of C++ drops support for a previously supported standard library. I was one of the many people who worked to change a number of Boost libraries from using std::auto_ptr to using std::unique_ptr when it was appropriate.

I'm not. For instance: if the library author wishes to make an improvement to their library that they may eventually propose to the committee, they can modify their Boost library and and get user experience. What someone could do is something like (caution: pseudocode): #if c++03 or earlier #include namespace boost { namespace stl { using boost::shared_ptr; using boost::weak_ptr; using boost::enabled_shared_from_this; // ... }} #else #include <memory> namespace boost { namespace stl { using std::shared_ptr; using std::weak_ptr; using std::enabled_shared_from_this; // ... }} While that certainly doesn't solve all issues, it might help. If it is something we wanted, we could either encourage library maintainers to do so when their library gets standardized or someone could propose it as a separate library. Anyway, just a thought... -- Nevin ":-)" Liber > +1-847-691-1404

Olaf van der Spek wrote:

Isn't it time to require C++11 to avoid spending / wasting time on these issues?

No.

On Fri, Feb 9, 2018 at 2:36 PM, Peter Dimov via Boost wrote:

Olaf van der Spek wrote:

...

Isn't it time to require C++11 to avoid spending / wasting time on these issues?

No.

You're proposing C++14 instead? ;) -- Olaf

On Mon, Feb 12, 2018 at 9:58 AM, Olaf van der Spek wrote:

On Fri, Feb 9, 2018 at 2:36 PM, Peter Dimov via Boost wrote:

...

Olaf van der Spek wrote:

...

Isn't it time to require C++11 to avoid spending / wasting time on these issues?

No.

Why not, where's the demand for C++03 support coming from?

It might be nice to have some understanding / documentation about what language standards, compilers and compiler versions are expected to be supported and why.

Peter? -- Olaf

On Sun, Feb 18, 2018 at 2:17 PM, Glen Fernandes via Boost wrote:

Olaf van der Spek wrote:

...

Why not, where's the demand for C++03 support coming from?

Users of Boost that care about C++03.

Before I became a contributor to Boost, and before I became a Boost library author, I was a user of Boost at Microsoft. Even as late as 2014 when I left the company, those projects depended on Boost for C++03 support. (In fact, at least one of the projects only dropped C++03 support as late as 2016).

It's 2018 now.. Where did the C++03 support requirement come from though, an old compiler? Even VS 2010 knows some C++11 stuff. -- Olaf

degski wrote:

(anything after VC6 is more or less supported).

No, it isn't. VC8 is the earliest that will work, somewhat. VC7.1 is tested in the matrix but nobody pays any attention to it and not much works.

Olaf van der Spek wrote:

...

...

...

Isn't it time to require C++11 to avoid spending / wasting time on these issues?

No.

Why not, where's the demand for C++03 support coming from?

My answer here isn't really about demand for C++03. Expanded, it's "I don't know what specifically you're proposing, and I don't know who is supposed to require C++11 from whom, but I don't think we should pursue it in any case because I've run some of the possible answers in my head and none of them are worth pursuing in my opinion."

AMDG On 02/09/2018 11:45 AM, John Maddock via Boost wrote:

On 08/02/2018 08:50, Raffi Enficiaud via Boost wrote:

...

Dear list,

I have a technical question I do not know how to address, and I would like to know how people deal with this.

To put things in the background: boost.test uses heavily boost::function and boost::bind, however I would like to use in some circumstances std::function and std::bind, which are, for instance, variadic.

Trying to get back to the case in point... is there any reason not to support both in the binary library?

ie

virtual int operator()( boost::function const& F ) = 0; virtual int operator()( std::function const& F ) = 0;

One of these can presumably simply call the other internally since a boost::function should be storable in a std::function and vice versa?

In this particular case, there shouldn't be any need to provide both explicitly as boost::function and std::function are convertible to each other. In general, I think that: - interfaces that take boost/std::xxx as a parameter should accept both. - interfaces that return boost/std::xxx are hard and I don't know how to handle them. - The internal implementation can pick one or the other. If you want ABI compatibility between C++03 and C++11, and the object crosses an ABI boundary, that means always using boost::xxx. For Boost.Test my overall recommendation is: always use boost::function, but use std::bind when it is available. In Christ, Steven Watanabe

AMDG On 02/10/2018 03:32 AM, Raffi Enficiaud via Boost wrote:

Le 09.02.18 à 20:08, Steven Watanabe via Boost a écrit :

...

<snip> In general, I think that: - interfaces that take boost/std::xxx as a parameter should accept both.> - interfaces that return boost/std::xxx are hard and I don't know how to handle them.

Yes. You are starting/proposing a recipe for ABI compatibility, which is the target of my concerns. Now:

* do you think we can elaborate more on this? For instance, same type of problem should apply to template parameters as well, exceptions, new keywords...

template parameters are not a major issue, as you can just accept whatever the user gives you. If you're explicitly instantiating the template in the separately compiled library, it should be safe to instantiate both versions, and the one that isn't used will just be ignored. It's probably okay to throw different exceptions as the default assumption in C++ is that any function can throw any exception. A function that has the same mangled name in different standards and is defined in multiple translation units (i.e. inline functions or function templates) must be identical regardless of the standard. Note that to be strictly correct it is not enough for the function to have the same effective behavior, as the optimizer is permitted to make assumptions based on the actual implementation. Also note that this is the hardest thing to get right and most code that tries to be ABI compatible across multiple standards tends to fudge it and hope for the best. If a function takes different parameters depending on the language standard, then it is a different function and both versions can coexist.

* do you think we can set up mechanisms that checks we are doing it right? (apart from trial and error, which has an exponential complexity in the number of types). I am just unaware of any tool or methodology that may help me doing it right.

Just build the library and test case with different standards. If it works, it's probably good enough.

...

- The internal implementation can pick one or the other. If you want ABI compatibility between C++03 and C++11, and the object crosses an ABI boundary, that means always using boost::xxx.

I was hoping for another solution ... To me, that means that long run, boost is implementing a side, non-compatible, C++ standard.

Pick your poison. It's impossible to use only std::xxx in the ABI while still being link-compatible with C++03. Personally, I can live with requiring a consistent std version, in which case, this is not a problem.

...

For Boost.Test my overall recommendation is: always use boost::function, but use std::bind when it is available.

The little story behind boost::bind was that, I believe around ~1.60, I encountered issues between std::bind and boost::function for moveable parameters. Maybe I was doing it wrong at that time, now it seems to be fixed (I tested). But I think the problem remains.

In the worst case, you can use std::bind -> std::function -> boost::function. In Christ, Steven Watanabe

On 10 February 2018 at 12:09, Steven Watanabe via Boost < boost@lists.boost.org> wrote:

Just build the library and test case with different standards. If it works, it's probably good enough.

Didn't Boost.Test require C++11 now? degski

Le 10.02.18 à 19:09, Steven Watanabe via Boost a écrit :

AMDG

On 02/10/2018 03:32 AM, Raffi Enficiaud via Boost wrote:

...

Le 09.02.18 à 20:08, Steven Watanabe via Boost a écrit :

...

<snip> In general, I think that: - interfaces that take boost/std::xxx as a parameter should accept both.> - interfaces that return boost/std::xxx are hard and I don't know how to handle them.

Yes. You are starting/proposing a recipe for ABI compatibility, which is the target of my concerns. Now:

* do you think we can elaborate more on this? For instance, same type of problem should apply to template parameters as well, exceptions, new keywords...

template parameters are not a major issue, as you can just accept whatever the user gives you. If you're explicitly instantiating the template in the separately compiled library, it should be safe to instantiate both versions, and the one that isn't used will just be ignored template <class some_struct> class my_template;

If some_struct is a class, it should be the same in every translation units, isn't it. Same more or less for my_template. By induction, everything that is pulled by those 2 entities should have the same implementation if they have exposed/public symbol and they land in different compilation units. In the case where this template + template parameter is seen in two different shared or static libraries, I believe they share the same symbol, while maybe implementing something different. That means * enforcing the use of the same language variant for the compilation of a library and all its dependencies. I believe this is what is done in the Debian community (please correct me if needed) * or enforce the ABI compatibility, which is difficult for developers, as the language does not provide enough semantics on this, and a lot of know-how seems to be compiler or platform specific. * or carefully crafting the visibility of each of those symbols, to lower the risk of having the same symbol with different definitions, which let the problem of static libraries the same

It's probably okay to throw different exceptions as the default assumption in C++ is that any function can throw any exception.

Exceptions or return type, the problem isn't it the same? the exception thrown should be ABI compatible, isn't it? Moreover, exceptions should have public visibility I believe.

A function that has the same mangled name in different standards and is defined in multiple translation units (i.e. inline functions or function templates) must be identical regardless of the standard.

Do you know if at least the linker emits an error or a warning if, same symbol exists but with different definition? I really have not a single clue, but it seems that this is a grey area where people just "hope" as you said and have little control.

Note that to be strictly correct it is not enough for the function to have the same effective behavior, as the optimizer is permitted to make assumptions based on the actual implementation. Also note that this is the hardest thing to get right and most code that tries to be ABI compatible across multiple standards tends to fudge it and hope for the best.

...

If a function takes different parameters depending on the language standard, then it is a different function and both versions can coexist.

...

* do you think we can set up mechanisms that checks we are doing it right? (apart from trial and error, which has an exponential complexity in the number of types). I am just unaware of any tool or methodology that may help me doing it right.

Just build the library and test case with different standards. If it works, it's probably good enough.

Well, the second best to hope for is a compiler or a linker error. The worse is exactly something that presumably "works" with silent problems that, for instance, corrupt a stack. I was hoping for the second best.

...

...

- The internal implementation can pick one or the other. If you want ABI compatibility between C++03 and C++11, and the object crosses an ABI boundary, that means always using boost::xxx.

I was hoping for another solution ... To me, that means that long run, boost is implementing a side, non-compatible, C++ standard.

Pick your poison. It's impossible to use only std::xxx in the ABI while still being link-compatible with C++03. Personally, I can live with requiring a consistent std version, in which case, this is not a problem.

From all this conversation, I learned at least

* that there is a real problem that is not just between the keyboard and the chair (that is good for my ego ...) * cross dialect APIs should be avoided, which was not obvious * having API on different dialect is ok as long as it is a partition of the API, * that static or shared libraries naming conventions might help the user avoiding mistakes, but means that all dialect variant should appear in the name This is what I think is a partition: /////// class helper_cpp03 { void somemethod(boost::function< void () > f); }; #if CPP11 class cpp11 { template <class T> void somemethod2(T&& v) { helper_cpp03 inst; // bind can talk to boost::function inst.somemethod( std::bind(&X::C, std::forward(v)) ); } }; #endif /////// The two APIs can talk together, no symbol is modified depending on the dialect. The API in the C++11 case is a superset of the one in C++03, I can only add symbols, not modify C++03 existing ones. This is not a partition: /////// class helper { #if CPP11 void somemethod(std::function< void () > f); #else void somemethod(boost::function< void () > f); #endif }; class myclass { template <class T> #if CPP11 void somemethod2(T && v) { inst.somemethod( std::bind(&X::C, std::forward(v)) ); } #else void somemethod2(T const & v) { inst.somemethod( boost::bind(&X::C, v) ); } #endif }; /////// While this is a bit exaggerated in the example, I think this type of code might happen: code is changed depending on the dialect: * the interface is changed * the way those two entities exchange data is changed (boost::bind vs std::bind) Does this make sense?

...

...

For Boost.Test my overall recommendation is: always use boost::function, but use std::bind when it is available.

The little story behind boost::bind was that, I believe around ~1.60, I encountered issues between std::bind and boost::function for moveable parameters. Maybe I was doing it wrong at that time, now it seems to be fixed (I tested). But I think the problem remains.

In the worst case, you can use std::bind -> std::function -> boost::function.

This initial problem is fine now, it works as many other mentioned, std::bind being fully compatible with boost::function (which I was not aware of).

Le 12.02.18 à 10:14, Olaf van der Spek via Boost a écrit :

On Mon, Feb 12, 2018 at 9:45 AM, Raffi Enficiaud via Boost wrote:

...

* enforcing the use of the same language variant for the compilation of a library and all its dependencies. I believe this is what is done in the Debian community (please correct me if needed)

Is it? If I as a user build my app, I can pick the language variant I want. And AFAIK there's only one variant of the .so available:

lrwxrwxrwx 1 root root 34 Nov 12 2016 libboost_program_options.so -> libboost_program_options.so.1.62.0 -rw-r--r-- 1 root root 520672 Nov 12 2016 libboost_program_options.so.1.62.0

I was referring to the Debian provided packages, obviously not the ones compiled by someone or in a PPA. But I do not have any reference that clearly states this, maybe this is part of the debian package tools.

Le 12.02.18 à 10:23, Olaf van der Spek via Boost a écrit :

On Mon, Feb 12, 2018 at 10:17 AM, Raffi Enficiaud via Boost wrote:

...

Le 12.02.18 à 10:14, Olaf van der Spek via Boost a écrit :

...

On Mon, Feb 12, 2018 at 9:45 AM, Raffi Enficiaud via Boost wrote:

...

* enforcing the use of the same language variant for the compilation of a library and all its dependencies. I believe this is what is done in the Debian community (please correct me if needed)

Is it? If I as a user build my app, I can pick the language variant I want. And AFAIK there's only one variant of the .so available:

lrwxrwxrwx 1 root root 34 Nov 12 2016 libboost_program_options.so -> libboost_program_options.so.1.62.0 -rw-r--r-- 1 root root 520672 Nov 12 2016 libboost_program_options.so.1.62.0

I was referring to the Debian provided packages, obviously not the ones compiled by someone or in a PPA. But I do not have any reference that clearly states this, maybe this is part of the debian package tools.

Those are from Debian..

$ dpkg -l|grep boost ... ii libboost-program-options-dev:amd64 1.62.0.1 amd64 program options library for C++ (default version) ii libboost-program-options1.62-dev:amd64 1.62.0+dfsg-4 amd64 program options library for C++ ii libboost-program-options1.62.0:amd64 1.62.0+dfsg-4 amd64 program options library for C++

Yes, and I do not get your point. Do you have access to the compilation options? Is there any mixed C++03/C++11 API in program option?

Coming into this thread late, but this is of relevance: https://www.jetbrains.com/research/devecosystem-2017/cpp/ https://blog.jetbrains.com/clion/2017/10/jb-cpp-at-cppcon-2017/ 66% regularly use C++11 46% don't plan to upgrade to a new C++ standard 21% regularly use C++03 41% mostly use C++11 <5% mostly use C++03 <3% mostly use C++98 I think investment in C++03 yields significantly diminished returns. And C++11 is simply the most popular version. In light of this information, I would drop support for C++03 and require C++11 going forward. Thanks

Niall Douglas wrote:

A significant proportion of newer Visual Studio users are on C++ 11 or even 14 without realising it. Same goes for GCC 5 (or later) users.

6 ior later. 5 is still C++98 by default. 6 is C++14. No GCC version is C++11 by default.

On 2/17/2018 12:50 PM, Vinnie Falco via Boost wrote:

Coming into this thread late, but this is of relevance:

https://www.jetbrains.com/research/devecosystem-2017/cpp/ https://blog.jetbrains.com/clion/2017/10/jb-cpp-at-cppcon-2017/

66% regularly use C++11 46% don't plan to upgrade to a new C++ standard 21% regularly use C++03

41% mostly use C++11 <5% mostly use C++03 <3% mostly use C++98

I think investment in C++03 yields significantly diminished returns. And C++11 is simply the most popular version. In light of this information, I would drop support for C++03 and require C++11 going forward.

What do you mean by "require C++11" ? People keep repeating this but everyone seems to have a different meaning. To me it actually means absolutely nothing.

Thanks

On Sat, Feb 17, 2018 at 10:55 AM, Robert Ramey via Boost wrote:

What does "drop support" mean?

It means I would not invest any energy in C++03 compatibility. If it happens to be compatible, that's fine. But I wouldn't go out of my way to make it so. And where possible I would use C++11 features and idioms since they improve both the interface and the implementation.

And some people are even writing libraries that require C++17 (Outcome?) and beyond (YAP?).

Outcome merely requires a highly conforming C++ 14 implementation. It will make good use of C++ 20 if you can give it that though. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 2/18/18 2:12 AM, Olaf van der Spek via Boost wrote:

On Sat, Feb 17, 2018 at 7:55 PM, Robert Ramey via Boost wrote:

...

What does "drop support" mean?

a) libraries should fail to compile with C++03? Any library which does so should be considered "broken" in some sense?

b) libraries should/must be implemented in C++11(+?)? Any library which isn't should/would be considered "broken"

c) libraries should/must be compilable with C++11(+?)? Any libraries which don't would be considered broken.

None of the above, but you already knew that, didn't you?

No. It's a serious question. The phrase "drop support" is confusing to me in the context of Boost. Robert Ramey.

On 18 Feb 2018, at 21:36, Edward Diener via Boost wrote:

...

On 2/18/2018 3:44 PM, Robert Ramey via Boost wrote:

...

On 2/18/18 2:12 AM, Olaf van der Spek via Boost wrote: On Sat, Feb 17, 2018 at 7:55 PM, Robert Ramey via Boost wrote:

...

What does "drop support" mean?

a) libraries should fail to compile with C++03? Any library which does so should be considered "broken" in some sense?

b) libraries should/must be implemented in C++11(+?)? Any library which isn't should/would be considered "broken"

c) libraries should/must be compilable with C++11(+?)? Any libraries which don't would be considered broken.

None of the above, but you already knew that, didn't you? No. It's a serious question. The phrase "drop support" is confusing to me in the context of Boost.

Exactly ! There has been lots of noise about "dropping c++03" support but very little substance which explains what it means.

To speak frankly, only you and Robert are being pedantic on the issue. The rest of the thread’s contributors seem to have a common understanding of what “dropping support” is whether you are talking about new or existing libraries. Unfortunately the meta-problem is that the API compatibility issue is extremely bikeshedable, as this thread shows. There’s no definitive answer as different maintainers will attach different value to a library working with a particular compiler. To continue the bikeshed analogy, the nuclear power power plant bit is the ABI problem. As someone (Peter?) said quite a few messages ago now, there isn’t a good solution within Boost, so we talk about a different problem.

On 2/19/2018 3:48 AM, Pete Bartlett via Boost wrote:

...

On 18 Feb 2018, at 21:36, Edward Diener via Boost wrote:

...

On 2/18/2018 3:44 PM, Robert Ramey via Boost wrote:

...

On 2/18/18 2:12 AM, Olaf van der Spek via Boost wrote: On Sat, Feb 17, 2018 at 7:55 PM, Robert Ramey via Boost wrote:

...

What does "drop support" mean?

a) libraries should fail to compile with C++03? Any library which does so should be considered "broken" in some sense?

b) libraries should/must be implemented in C++11(+?)? Any library which isn't should/would be considered "broken"

c) libraries should/must be compilable with C++11(+?)? Any libraries which don't would be considered broken.

None of the above, but you already knew that, didn't you? No. It's a serious question. The phrase "drop support" is confusing to me in the context of Boost.

Exactly ! There has been lots of noise about "dropping c++03" support but very little substance which explains what it means.

To speak frankly, only you and Robert are being pedantic on the issue. The rest of the thread’s contributors seem to have a common understanding of what “dropping support” is whether you are talking about new or existing > > libraries.

Care to tell me what that "common understanding" is ? I truly have no idea what people mean by it in relation to Boost libraries that can be built and used in C++03 mode. Do you really mean that if a library can be built and used in C++03 mode it should be dropped from Boost, even if it works fine when built and used in the latest C++ mode supported by compilers ? Inquiring minds actually want to know what is meant by "dropping c++03" support. This is not pedantic issue. It is an attempt to understand what "dropping c++03" support actually means to the people who keep mentioning it.

Unfortunately the meta-problem is that the API compatibility issue is extremely bikeshedable, as this thread shows. There’s no definitive answer as different maintainers will attach different value to a library working with a particular compiler.

To continue the bikeshed analogy, the nuclear power power plant bit is the ABI problem. As someone (Peter?) said quite a few messages ago now, there isn’t a good solution within Boost, so we talk about a different problem.

AMDG On 02/19/2018 11:10 AM, Groke, Paul via Boost wrote:

...

-----Original Message----- Care to tell me what that "common understanding" is ? <snip>

My naive understanding of dropping support for C++03 would be to stop putting any effort into making new stuff compatible with C++03 or into keeping existing stuff compatible with C++03.

To whom does this apply? Boost as a whole has no policy requiring this in the first place. In Christ, Steven Watanabe

On 19 February 2018 at 12:28, Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

No C++03 supported was less than ideal according to some people.

Yes, correct, but I still didn't hear (from those people) a single rationale as to why that should be so. degski

From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe via Boost Sent: Montag, 19. Februar 2018 19:21

AMDG

Please keep that to yourself.

...

...

-----Original Message----- Care to tell me what that "common understanding" is ? <snip>

My naive understanding of dropping support for C++03 would be to stop

On 02/19/2018 11:10 AM, Groke, Paul via Boost wrote: putting any effort into making new stuff compatible with C++03 or into keeping existing stuff compatible with C++03.

To whom does this apply? Boost as a whole has no policy requiring this in the first place.

Since it is my understanding it obviously applies to me.

In Christ, Steven Watanabe

In Reason, Paul

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener via Boost Sent: Montag, 19. Februar 2018 22:40

...

My naive understanding of dropping support for C++03 would be to stop

On 2/19/2018 1:10 PM, Groke, Paul via Boost wrote: putting any effort into making new stuff compatible with C++03 or into keeping existing stuff compatible with C++03.

Why would you want to drop a library from Boost that is compatible with C++03 but also works fine when built with later C++ standards ?

I never said I would.

On 12/02/2018 21:45, Raffi Enficiaud wrote:

...

A function that has the same mangled name in different standards and is defined in multiple translation units (i.e. inline functions or function templates) must be identical regardless of the standard.

Do you know if at least the linker emits an error or a warning if, same symbol exists but with different definition? I really have not a single clue, but it seems that this is a grey area where people just "hope" as you said and have little control.

No. If two things with different definitions resolve to different mangled names, then the linker can detect that as a missing reference and will report it as such (which is why most attempts to keep these sorts of things sane rely on inline namespaces, where the "real" name visible to the linker has extra decoration that the programmer doesn't see. Inline namespaces themselves aren't a thing in C++03, but you can still do the equivalent). Two symbols with the same mangled name are typically treated as identical by the linker regardless of anything else, and it's free to match them up and throw away multiple definitions without any diagnostic at all. Hence why ODR violations can be a significant problem, and one that is hard to track down. (Header-only and highly templated libraries can be the worst offenders in this regard: it only takes one translation unit compiled with slightly different settings to break seemingly unrelated code, sometimes apparently at random if the linker picks different ones to keep each time. Compiled libraries at least have the option of supplying both C++03 and C++11 implementations in separate namespaces, though it can become a game of whack-a-mole to enumerate all the different ABI-breaking settings that you want to concurrently support.) In an ideal world, the linker would compare the *size* of the symbols and issue a diagnostic if they don't match, as this is highly suspicious of an ODR issue. However I've yet to encounter one in the wild that actually does this. (And there are certain kinds of problems it wouldn't detect, but it would help with the majority of ODR violations.)

On Tue, Feb 13, 2018 at 12:21 AM, Gavin Lambert via Boost wrote:

(Header-only and highly templated libraries can be the worst offenders in this regard: it only takes one translation unit compiled with slightly different settings to break seemingly unrelated code, sometimes apparently at random if the linker picks different ones to keep each time. Compiled libraries at least have the option of supplying both C++03 and C++11 implementations in separate namespaces, though it can become a game of whack-a-mole to enumerate all the different ABI-breaking settings that you want to concurrently support.)

Why can header-only libs not use different namespaces for 03 and 11? -- Olaf

Le 09.02.18 à 19:45, John Maddock via Boost a écrit :

On 08/02/2018 08:50, Raffi Enficiaud via Boost wrote:

...

Dear list,

I have a technical question I do not know how to address, and I would like to know how people deal with this.

To put things in the background: boost.test uses heavily boost::function and boost::bind, however I would like to use in some circumstances std::function and std::bind, which are, for instance, variadic.

Trying to get back to the case in point... is there any reason not to support both in the binary library?

ie

virtual int operator()( boost::function const& F ) = 0; virtual int operator()( std::function const& F ) = 0;

One of these can presumably simply call the other internally since a boost::function should be storable in a std::function and vice versa?

I agree. However I have several doubts that this might work in the long term. One problem I see is that, if those types are somehow "equivalent" (purposely not defining what it means), then I believe that it may happen that we have type ambiguity at compilation time. The other concern I have is more about strategic. Since C++11, std::function is for me - de facto - the **upstream**, and whatever boost::function does: * should follow the standard for compatibility and feature set * is more or less disallowed to provide any type of extensions to this standard as it may confuse users. So, again, I do not see any superior solution, but betting that boost::function will handle smells like the wrong choice somehow. Also, I believe that all those compatibility issues between different implementations of say std::whatever (ABI differences between C++11, C++42 etc), are already - or should be - handled by library implementers much better than what boost developers can provide: those people know their compiler and library best. Looking only at this thread shows how much boost developers' community is not equipped to handled this problem (no offense, just a cold factual sum up :) ).

Except we can't make the std::function variant virtual as disabling it in C++03 mode would change the vtable layout... or can we just make sure it's the last virtual function declared?  Or else maybe only one of these needs to be virtual and the other can be a one line forwarder?

Yes, and all this renders the API very hard to manage for the users (and I am not mentioning the developer in this case).

I don't know enough about Boost.Tests internals to know the answer to any of these questions, but:

So far, I purposely discarded the implementation. My only concern is the API and the compatibility of the produced libraries.

* This topic is going to keep coming up - it may be 03 vs 11 or 14 today, but next week/year it'll be 14 vs 17 or 17 vs 20.  And,

Indeed. Having say, boost.test-C++03 and boost.test-C++11 is a possibility. But where does this end? What is a good partition wrt. compiler set? Coming back to boost.test, I believe that I may loose a lot of my clients splitting up, OTOH I may gain new people: I simply do not know today which strategy is good for the library itself.

* Somehow we need to find strategies for dealing with this.

Not helping much, John.

Not true :) Hand to hand, Raffi

John Maddock wrote:

Trying to get back to the case in point... is there any reason not to support both in the binary library?

ie

virtual int operator()( boost::function const& F ) = 0; virtual int operator()( std::function const& F ) = 0;

If you make the function virtual that just makes the problem worse. A non-virtual function will fail to link if you pass boost::function from one side but take std::function from the other. A virtual will silently call the std::function-taking override, passing it a boost::function. Much joy results. All this really makes no sense at all; boost::function should be used. But, if you really wanted to know, libstdc++ in a situation like the above (when the function has to be virtual because it's f.ex. specified that way by the standard) does something like the following: #if cpp11 virtual int __f( boost::function const& F ) = 0; virtual int f( std::function const& F ) = 0; #else virtual int f( boost::function const& F ) = 0; virtual int __f( std::function const& F ) = 0; #endif except of course we don't have std::function in C++03 mode, so even declaring __f will be a problem. If you run the variants in your head, C++03 exe with C++11 lib works, but C++11 exe with C++03 lib cannot. The best you can do in __f is crash.

Andrey Semashev wrote:

On 02/10/18 18:43, Peter Dimov via Boost wrote:

...

But, if you really wanted to know, libstdc++ in a situation like the above (when the function has to be virtual because it's f.ex. specified that way by the standard) does something like the following:

#if cpp11

virtual int __f( boost::function const& F ) = 0; virtual int f( std::function const& F ) = 0;

#else

virtual int f( boost::function const& F ) = 0; virtual int __f( std::function const& F ) = 0;

#endif

except of course we don't have std::function in C++03 mode, so even declaring __f will be a problem.

If you rely on the particular algorithm of vftable slot allocation,

I've never heard of a vtable slot allocation algorithm that is not the particular one that everyone uses.

declaring is not a problem - you can declare pretty much whatever virtual function. It's not going to be called anyway and its sole purpose is to reserve a particular slot.

It is going to be called, when a C++11 exe calls a C++03 library. It's true that you can declare whatever you want (within limits - the calling convention must stay the same), but you can't use it because it's not going to be whatever you declared, it's going to be std::function.

On 10 February 2018 at 11:25, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

Well, yes, but that's not a problem for libstdc++, because, presumably, it is always compiled with the latest C++ supported by the compiler.

Yeah, that is probably true, let's go with that! Maybe a similar convention is possible for Boost as well, i.e. we support

linking executables compiled only for C++ <= N, where N is the version that Boost was compiled for. It's difficult to enforce, though.

It would be better to up the minimum required version of C++ (to C++11), and let those who don't want to move (pun intended), to stick with their old copy (pun intended) of Boost. degski

On 10 February 2018 at 11:13, Peter Dimov via Boost wrote:

I've never heard of a vtable slot allocation algorithm that is not the particular one that everyone uses.

Right, It's ok, then! degski