C++03 / C++11 compatibility question for compiled libraries
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. Boost.test is compiled with b2. I believe if the user does not pass additional parameters to the build, the default is to use whatever is provided in the Jamfile, that compiles the static and shared libraries in C++03 mode. If the user of boost.test compiles in C++03, it is ok if the library is used in a C++11 project. The other way is obviously not true. Now, in the headers of boost.test, I can detect for the compiler version, and depending on the language settings, activate an API that is C++11. OTOH, if I do not want users to be confused, this API should be header only. But this hardly work in practice, as the C++03 and C++11 APIs are usually not separable. Say: struct test_case { // compiled member function test_case(boost::function<void ()> function_to_test); #if Cpp11 // std::function variant to ensure compatibility with std::bind test_case(std::function<void ()> function_to_test); #endif private: boost::function<void ()> m_function_to_test; }; This API is obviously not good at all, and for having the slightest chance to make this work, the 2 APIs C++11 vs C++03 should be mutually exclusive. This also produces 2 different incompatible shared/static libraries, which is even more confusing for the user as the compiler options should be transitively passed to the user's code, or the user should be aware of which library to link with. So, the questions are: * how do other boost developers deal with this? * what is your experience on users in terms of compilation+linking? are usually people aware of this problem and they compile in C++11 all the code including boost? * is there any better option? All the other options I see are even worse. Thanks, Raffi
On 02/08/18 11:50, Raffi Enficiaud via Boost wrote:
Say:
struct test_case {
// compiled member function test_case(boost::function<void ()> function_to_test);
#if Cpp11 // std::function variant to ensure compatibility with std::bind test_case(std::function<void ()> function_to_test); #endif
boost::function should already be compatible with std::bind.
private: boost::function<void ()> m_function_to_test; };
This API is obviously not good at all, and for having the slightest chance to make this work, the 2 APIs C++11 vs C++03 should be mutually exclusive. This also produces 2 different incompatible shared/static libraries, which is even more confusing for the user as the compiler options should be transitively passed to the user's code, or the user should be aware of which library to link with.
So, the questions are: * how do other boost developers deal with this?
In Boost.Log, I maintain linking ABI always compatible with C++03. For example, I convert rvalue references to lvalue references in the header and call a special internal function from the library that assumes move semantics. 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.
* what is your experience on users in terms of compilation+linking? are usually people aware of this problem and they compile in C++11 all the code including boost?
There is a large class of use cases where the user links against Boost that is built by someone else. In Linux, it is typical to rely on the Boost version shipped with distro. On Windows, I presume, some users prefer our pre-built binaries. So the use case when the headers and the library are used with different C++ version settings are real and a good library should account for that.
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 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.
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
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.
On 8 February 2018 at 13:25, Peter Dimov via Boost <boost@lists.boost.org> 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 02/08/18 22:36, degski via Boost wrote:
On 8 February 2018 at 13:25, Peter Dimov via Boost <boost@lists.boost.org> 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.
How does that solve the linking incompatibility problem?
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.
It's not just about older compilers. There are code bases that are not compatible with C++11, some of them using Boost. Given that the default in recent compilers is C++14, those code bases explicitly set C++03. Those code bases are supposed to link with whatever Boost version (which, of course, is compiled in the default C++14 mode) that is shipped by your distro. On older systems there is a reverse problem, when the system-supplied Boost is compiled in C++03 and you want to compile your code in C++11 or later.
On 02/08/18 23:23, degski via Boost wrote:
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?
Because otherwise such code base becomes unshippable with that distro (i.e. cannot be packaged for that distro). This includes both preparing the package for the distro, if you're the package maintainer from the distro, and public users' repositories (e.g. PPAs). If you're distributing software separately from the distro ecosystem, you have to build and package Boost yourself, which may in turn require re-packaging other components that depend on Boost or can be used with your software. This quickly increases the packaging burden on you.
On 02/09/18 01:09, degski via Boost wrote:
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...
(Most people do, actually.) 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.
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 02/09/18 01:47, degski via Boost wrote:
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.
Given that those servers are used by millions of people, you may want to count again.
Some references (links) please.
https://en.wikipedia.org/wiki/Usage_share_of_operating_systems In all segments except desktop/laptop, Linux or Android is in the lead. So one way or the other, most likely you're using Linux somehow. Anyway, this is going into offtopic/flamewar territory.
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
Although it is definitely off-topic, I'm with degski on this one. Shipping with distros is not a major concern, and distros that require an older version can use that as well as the most recent. Doing otherwise maintains status quo which leads to code bloat and buildup of less-efficient code for compatibility's sake. On 9/02/2018 12:22 p.m., degski via Boost wrote:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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.
On 8 February 2018 at 15:06, Peter Dimov via Boost <boost@lists.boost.org> wrote:
So mp11 and Beast need to be C++17 because those using C++11 can always use an earlier version of Boost.
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... (as boost::mp11 does, as far as I've seen, but you're far better placed to say something about that than me, I would say). Boost-1.66 source code plus the stuff that is generated building boost (just x64, debug, release) occupies very close to 5GB of disk-space, time to start cutting that down. But if your using gcc-3.3, clang-3.6 or vs2012, one cannot expect boost -1.67 to compile with it. On windows, I would say this is more of an issue as on linux, as you'd be obliged to use/install old crt's, that are known to have (publicized) vulnerabilities... I have an issue with boost looking backwards all the time. Clang and VC (we've got (experimentally) concepts!) both seem to have (nowadays) adopted very much a forward looking view, to be ahead of the standard. I would like boost to do the same. I'm talking about std::random (boost version deviates), std::chrono (not sure whether boost version deviates), std::file_system (boost version deviates), etc... degski
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.
On 8 February 2018 at 16:58, Peter Dimov via Boost <boost@lists.boost.org> wrote:
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.
But, do the libs you quoted use std::optional and std::string_view (instead of their boost impersonations) when compiled with C++17? That is core of the point I'm trying to make. boost::beast is committed to go exactly the road I'm advocating, once the Network TS (Vinnie will be happy) is standardized. It's not like we go out of our way to avoid using the available standard
facilities.
I never said, or intend to imply, that *you* do, I know you don't. degski
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?
On 8 February 2018 at 17:22, Peter Dimov via Boost <boost@lists.boost.org> wrote:
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?
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? degski
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:36, Peter Dimov via Boost <boost@lists.boost.org> 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)? degski
On 8 February 2018 at 17:42, degski <degski@gmail.com> wrote:
On 8 February 2018 at 17:36, Peter Dimov via Boost <boost@lists.boost.org> 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
degski 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)?
It applies to mostly everything, except perhaps pure implementation details of DLLs. 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.
On 8 February 2018 at 17:58, Peter Dimov via Boost <boost@lists.boost.org> 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
On 2/8/2018 3:50 AM, 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.
Boost.test is compiled with b2. I believe if the user does not pass additional parameters to the build, the default is to use whatever is provided in the Jamfile, that compiles the static and shared libraries in C++03 mode.
If the user of boost.test compiles in C++03, it is ok if the library is used in a C++11 project. The other way is obviously not true.
Now, in the headers of boost.test, I can detect for the compiler version, and depending on the language settings, activate an API that is C++11. OTOH, if I do not want users to be confused, this API should be header only. But this hardly work in practice, as the C++03 and C++11 APIs are usually not separable.
Say:
struct test_case {
// compiled member function test_case(boost::function<void ()> function_to_test);
#if Cpp11 // std::function variant to ensure compatibility with std::bind test_case(std::function<void ()> function_to_test); #endif
private: boost::function<void ()> m_function_to_test; };
This API is obviously not good at all, and for having the slightest chance to make this work, the 2 APIs C++11 vs C++03 should be mutually exclusive. This also produces 2 different incompatible shared/static libraries, which is even more confusing for the user as the compiler options should be transitively passed to the user's code, or the user should be aware of which library to link with.
So, the questions are: * how do other boost developers deal with this? * what is your experience on users in terms of compilation+linking? are usually people aware of this problem and they compile in C++11 all the code including boost? * is there any better option? All the other options I see are even worse.
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. But others did not like it preferring instead to roll their own solution or more simply to use Boost at all times because it is available. I naturally prefer my own solution but of course I am biased.
Thanks, Raffi
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<void()> 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 <system_error> 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.))
On 2/8/2018 9:20 AM, Peter Dimov via Boost wrote:
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<void()> 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 discuss a solution for this in the documentation topic "Use in a non-header only library".
I inadvertently introduced such a problem in Boost.System when I made the object layout dependent on whether <system_error> 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.
On 2/8/2018 10:48 AM, Peter Dimov via Boost wrote:
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.
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. Of course this assumes your non-header only library only supports compilers which in C++11 mode on up offers C++11 libraries for what you are using in your library. But how many modern compilers do not support C++11 libraries properly in C++11 mode on up, and would you really want to support such libraries that do not.
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 2/8/2018 12:21 PM, Peter Dimov via Boost wrote:
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.
Because most libraries are header-only. Because assuming that if a single CXXD mod xxx is std, all others are std is not what I would call good programming.
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. In the same way that someone building a modern army would not choose to equip his soldiers with swords and pikes, no sane project leader would choose to use c++03 in favour of c++17 today. New libraries should not pander to obsolete coding practices at all. People must simply keep up, otherwise we’re all stuck in the dark ages.
On 9 Feb 2018, at 09:13, Olaf van der Spek via Boost <boost@lists.boost.org> wrote:
On Thu, Feb 8, 2018 at 9:50 AM, Raffi Enficiaud via Boost <boost@lists.boost.org> 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?
-- Olaf
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 9. Feb 2018, at 10:31, Richard Hodges via Boost <boost@lists.boost.org> 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
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Hans Dembinski via Boost Sent: 09 February 2018 10:52 To: boost@lists.boost.org Cc: Hans Dembinski Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries
On 9. Feb 2018, at 10:31, Richard Hodges via Boost <boost@lists.boost.org> 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.
Upgrading other people's compilers may not be free and riskless? 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 ;-) (The recently reviewed Outcome looks like it may need C++20, for example). 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. 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). This clearly suits those that don't want to update compilers. 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. This policy puts pressure on people to upgrade compilers without 'holding a gun to their heads'. I think we should continue to follow this policy, allowing library authors to make the decisions as they see fit, but to loudly announce breaking changes like this well ahead so that people know what will happen (especially if they don't upgrade). My two (old) pence ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
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 <boost@lists.boost.org> 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
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. See https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-1..., where apparently very soon now one will be able to turn on their experimental C99 preprocessor implementation which surely will either make Edward very happy, or unhappy depending. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
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.
On 2/10/2018 10:20 PM, Niall Douglas via Boost 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.
See https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-1..., where apparently very soon now one will be able to turn on their experimental C99 preprocessor implementation which surely will either make Edward very happy, or unhappy depending.
If it actually existed, certainly happy rather than unhappy, but it is still just Microsoft promises, despite your "very soon".
Niall
El feb. 9, 2018, a las 08:15, Paul A. Bristow via Boost <boost@lists.boost.org <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
Jared Grubb wrote:
Is there an example of an existing library that ditched C++03 support?
Can't think of one, but C++03 becomes more and more of a burden for ASIO so it might do so.
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?
Yes.
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?
By virtue of depending on a C++11 library, they will effectively become C++11-only whether they "move" or not. The community plays no role.
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 <boost@lists.boost.org> 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?
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.
On 9 Feb 2018, at 09:45, Andrey Semashev via Boost <boost@lists.boost.org> 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 <boost@lists.boost.org> 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?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 <boost@lists.boost.org> 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 <boost@lists.boost.org> 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?
Am 09.02.2018 4:21 nachm. schrieb "Edward Diener via Boost" < boost@lists.boost.org>: 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. std::auto_ptr.
On 9 Feb 2018, at 09:45, Andrey Semashev via Boost <boost@lists.boost.org>
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 <boost@lists.boost.org> 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?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
On 02/09/18 19:07, Daniel James via Boost wrote:
On 9 February 2018 at 15:45, Thomas Heller via Boost <boost@lists.boost.org> wrote:
std::auto_ptr.
We've been fixing libraries that require auto_ptr, unary_function etc.
We've been fixing *our* code. But our users may not have been doing so with *their* code that uses Boost.
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. degski
On 9 February 2018 at 16:08, degski via Boost <boost@lists.boost.org> 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?
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 <boost@lists.boost.org> 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 9 February 2018 at 16:26, Thomas Heller via Boost <boost@lists.boost.org> wrote:
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 <boost@lists.boost.org> 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?
Unless I misunderstood it, the emails that this was in response to were about C++03 libraries "demanding" something of the user, and blocking people from using later language versions.
On 2/9/2018 11:08 AM, 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.
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
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... 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 <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. 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 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#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 <boost@lists.boost.org
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 2/11/2018 3:23 PM, degski via Boost wrote:
On 11 February 2018 at 13:36, Edward Diener via Boost <boost@lists.boost.org
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.
What exactly do you mean by C++03 is not supported ? 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 ?
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 <boost@lists.boost.org
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 2/11/2018 5:16 PM, degski via Boost wrote:
On 11 February 2018 at 15:55, Edward Diener via Boost <boost@lists.boost.org
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.
You are saying then that what you mean by "C++03 is not supported" is compiling in C++03 mode.
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.
I also think that Boost libraries should successfully compile in at least C++11 mode. 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.
degski
On 11 February 2018 at 17:01, Edward Diener via Boost <boost@lists.boost.org
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
On 2/11/2018 6:46 PM, degski via Boost wrote:
On 11 February 2018 at 17:01, Edward Diener via Boost <boost@lists.boost.org
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.
... 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).
Thanks for the CXXD support. If more people supported CXXD, and someone recommended it for review, and someone wanted to be the review manager, I certainly would like it be considered as a Boost library. 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.
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 <boost@lists.boost.org
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 12 February 2018 at 11:23, Paul A. Bristow via Boost < boost@lists.boost.org> wrote:
Some on this thread seem to view 'support' and 'validated' as binary features.
I still think they are. If you cannot use the tools created by the library author to validate that the library functions well over a set of tests deemed relevant by that library author, one has to conclude that that C++-Version is not supported.
Boost (and life in general) really isn't as simple as that.
Test coverage is not ever going to be 100%. In principle I couldn't care less as to what C++-standard a library is written in. I wouldn't even mind if boost had a number pure C-Libs. BUT, a library, f.e. not supporting C++11 moves, starts to violate the principle that "I don't pay for what I don't use.", because stuff gets copied, while it could be moved. Variadic templates is equally not to be sniffed upon. All this looking backwards, let's not disenchant those people who insist on using an old compiler, where does that come from. If and when you're not moving to C++11 you are living in the dark ages. Yes, at some point it was *new*, and there might be bugs (luckily there were no bugs in older boost versions). In the meanwhile C++11 is old news. One can only speculate as to why a number of people involved with boost are soooooooo stuck in the past, but as in many issues/problems in the world in general, the first thing to do is, IMHO, follow the money. That's an old lesson I learned, long time ago. degski
On February 11, 2018 11:27:00 PM EST, Edward Diener via Boost <boost@lists.boost.org> wrote:
On 2/11/2018 6:46 PM, degski via Boost wrote:
On 11 February 2018 at 17:01, Edward Diener via Boost <boost@lists.boost.org
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.)
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. R On 11 February 2018 at 19:36, Edward Diener via Boost <boost@lists.boost.org
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
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 <boost@lists.boost.org
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
On 11 February 2018 at 13:25, Paul A. Bristow via Boost <boost@lists.boost.org> wrote:
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
You should thank Louis Dionne, I just merged his changes to the beta site.
Paul A. Bristow wrote:
degski wrote:
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.
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.
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 > <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.
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.
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 > <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.
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.
Raffi Enficiaud wrote:
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.
I'm glad to hear it. I was responding to the hypothetical suggestion that Boost.Test be made C++11 only, by pointing out what the effects of that would be.
On 9 February 2018 at 14:48, Edward Diener via Boost <boost@lists.boost.org> 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 2/9/2018 10:45 AM, Thomas Heller via Boost wrote:
Am 09.02.2018 4:21 nachm. schrieb "Edward Diener via Boost" < boost@lists.boost.org>:
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.
std::auto_ptr.
OK, but That is a "library" rather than a language construct. 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. In general though, while I do encourage new library developers to use later versions of the C++ standard if they feel that it will make their library better, I do not see the purpose of dropping support for existing C++03 libraries that are successful in their goals. Nor do I see any purpose for mandating what level of C++ support any given library must meet to be part of Boost.
On 9 Feb 2018, at 09:45, Andrey Semashev via Boost <boost@lists.boost.org>
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 <boost@lists.boost.org> 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 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 <boost/shared_ptr.hpp> 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 <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>> +1-847-691-1404
On 2/9/2018 4:25 PM, Nevin Liber via Boost wrote:
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 <boost/shared_ptr.hpp> 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.
Please see https://github.com/eldiener/cxx_dual.
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...
On 9 February 2018 at 07:36, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Olaf van der Spek wrote:
Isn't it time to require C++11 to avoid spending / wasting time on these
issues?
No.
Wouldn't it be worthwhile to discuss this point in a separate thread? It seems to me that, as C++11 support in 2018 :-) is starting to get ubiquitous, boost could be losing a lot of old cruft. A number of libs can then also be simply removed boost::array etc... Testing cycles would be quicker etc etc... degski
On Fri, Feb 9, 2018 at 2:36 PM, Peter Dimov via Boost <boost@lists.boost.org> 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. -- Olaf
On Mon, Feb 12, 2018 at 9:58 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Fri, Feb 9, 2018 at 2:36 PM, Peter Dimov via Boost <boost@lists.boost.org> 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
Olaf van der Spek wrote:
Isn't it time to require C++11 to avoid spending / wasting time on these issues?
No. Any given Boost contributor or library author is free to spend as much of their time caring about C++03 as they want. Other Boost developers are free to not spend any time on these issues. (They only requirement regarding language standards in Boost is that new libraries should not fail to work in the latest C++ standard mode.)
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). Glen
On Sun, Feb 18, 2018 at 2:17 PM, Glen Fernandes via Boost <boost@lists.boost.org> 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
On 18 February 2018 at 07:29, Olaf van der Spek via Boost < boost@lists.boost.org> wrote:
Even VS 2010 knows some C++11 stuff.
But, if you inspect some of the Boost code base, you'll have to conclude that VS2010 is to be considered pretty recent (anything after VC6 is more or less supported). degski
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."
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<int ()> const& F ) = 0; virtual int operator()( std::function<int ()> 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? 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? I don't know enough about Boost.Tests internals to know the answer to any of these questions, but: * 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, * Somehow we need to find strategies for dealing with this. Not helping much, John. --- This email has been checked for viruses by AVG. http://www.avg.com
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<int ()> const& F ) = 0; virtual int operator()( std::function<int ()> 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
Le 09.02.18 à 20:08, Steven Watanabe via Boost a écrit :
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<int ()> const& F ) = 0; virtual int operator()( std::function<int ()> 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.
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... * 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.
- 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.
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 Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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.
Probably? Ai, ai ai... The real poison to take is move to Boost 2.0, being a C++11 (minimal) lib. degski
Le 10.02.18 à 21:42, degski via Boost a écrit :
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?
No.
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).
On Mon, Feb 12, 2018 at 9:45 AM, Raffi Enficiaud via Boost <boost@lists.boost.org> 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 -- Olaf
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 <boost@lists.boost.org> 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.
On Mon, Feb 12, 2018 at 10:17 AM, Raffi Enficiaud via Boost <boost@lists.boost.org> 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 <boost@lists.boost.org> 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++ ... -- Olaf
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 <boost@lists.boost.org> 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 <boost@lists.boost.org> 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?
On Mon, Feb 12, 2018 at 10:42 AM, Raffi Enficiaud via Boost <boost@lists.boost.org> 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)
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?
Sorry, I misunderstood your claim. I was thinking about a (user) program using different options then its dependencies. -- Olaf
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
On 17/02/2018 17:50, 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.
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. I think your survey results underestimate the numbers. No way of proving it, though. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 17/02/2018 18:02, Peter Dimov via Boost wrote:
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.
Sorry, I was thinking of C support regarding GCC 5. You're right, for C++ it's GCC 6. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
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 2/17/18 9:50 AM, 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 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. Currently boost only requires that libraries be consistent with the latest current standard - which would be C++17 now. So technically any library which doesn't compile with a standards conforming compiler would/should be considered broken. As it turns out, this doesn't isn't really much of a burden. The serialization library, first added to boost in (2004?) still functions with the latest standard with a little help from boost/config.hpp. Once in a while something breaks when a new compiler standard comes out. So far maintaining compatibility with the latest standard only requires an occasional trivial tweak to eliminate a a compile time error. C++ is good that way. Oh - and btw - still functions as well (or better) than it ever did with C++03. So from my standpoint the correct answer is c) And the current situation isn't broken and doesn't need any kind of fix. Robert Ramey
On Sat, Feb 17, 2018 at 10:55 AM, Robert Ramey via Boost <boost@lists.boost.org> 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.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vinnie Falco via Boost Sent: 18 February 2018 02:34 To: boost@lists.boost.org Cc: Vinnie Falco Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries
On Sat, Feb 17, 2018 at 10:55 AM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
What does "drop support" mean?
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. +1 Boost doesn't 'require' any compiler and Boost doesn't 'support' any compiler.
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.
That's *exactly* what is happening now! And some people are even writing libraries that require C++17 (Outcome?) and beyond (YAP?). We should only be cautious about accepting libraries requiring C++ standards that are in vaporware mode like C++23 ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
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 Sat, Feb 17, 2018 at 7:55 PM, Robert Ramey via Boost <boost@lists.boost.org> 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? -- Olaf
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 <boost@lists.boost.org> 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 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 <boost@lists.boost.org> 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. As you and others have mentioned, as long as a library, written for whatever standard(s) it has specified in its doc, builds and works properly with the latest C++ standards, why should anyone want to legislate against it as far as what C++ features it uses are does not. One can encourage the use of later C++ constructs and C++ compilation modes that may make it easier to create an effective library, but it is wrong to force on a library developer particular constructs for which he has no use. I understand that some programmers may want library interfaces to support C++11 versions of std libraries rather than the equivalent Boost versions of those same libraries, because people compiling in C++11 mode or above may be otherwise using the std versions of those libraries in their code. I wrote CXXD as an attempt to solve that problem. But that choice is up to the library developer and can't be legislated as a demand.
Robert Ramey.
On 18 Feb 2018, at 21:36, Edward Diener via Boost <boost@lists.boost.org> 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 <boost@lists.boost.org> 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/18 12:48 AM, Pete Bartlett via Boost wrote:
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.
OK - then help me out by stating your definition here. Robert Ramey
On 2/19/2018 3:48 AM, Pete Bartlett via Boost wrote:
On 18 Feb 2018, at 21:36, Edward Diener via Boost <boost@lists.boost.org> 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 <boost@lists.boost.org> 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.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener via Boost Sent: Montag, 19. Februar 2018 18:53 To: boost@lists.boost.org
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.
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. Especially the latter is something that IMO should be discussed, because it means that people who are using certain Boost libraries in a C++03 project may no longer be able to update to newer Boost versions. Regards, Paul
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 Mon, Feb 19, 2018 at 7:21 PM, Steven Watanabe via Boost <boost@lists.boost.org> wrote:
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.
Raffi started this thread with some questions concerning C++03 and C++11.. in Boost.Test. No C++03 supported was less than ideal according to some people. -- Olaf
On February 19, 2018 1:28:04 PM EST, Olaf van der Spek via Boost <boost@lists.boost.org> wrote:
On Mon, Feb 19, 2018 at 7:21 PM, Steven Watanabe via Boost <boost@lists.boost.org> wrote:
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.
Raffi started this thread with some questions concerning C++03 and C++11.. in Boost.Test. No C++03 supported was less than ideal according to some people.
I would think a Boost.Test 2, that includes breaking changes, would be easiest. So long as the original keeps working, existing libraries can be considered supported. Once testing no longer works, a library should be considered unsupported. That means Boost.Test 2 can use newer language constructs and library features with near impunity, and the original can remain as it is today. -- Rob (Sent from my portable computation device.)
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
On 2/19/2018 1:10 PM, Groke, Paul via Boost wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener via Boost Sent: Montag, 19. Februar 2018 18:53 To: boost@lists.boost.org
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.
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.
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 ?
Especially the latter is something that IMO should be discussed, because it means that people who are using certain Boost libraries in a C++03 project may no longer be able to update to newer Boost versions.
Regards, 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.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey via Boost Sent: 18 February 2018 20:45 To: Olaf van der Spek via Boost Cc: Robert Ramey Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries
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 <boost@lists.boost.org> 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.
The phrase "drop support" has *no meaning* in the context of Boost. Paul PS Remins me of a favorite https://en.wikipedia.org/wiki/Edsger_W._Dijkstra aphorism is this one: "The question of whether machines can think is about as relevant as the question of whether submarines can swim. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
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.)
Gavin Lambert wrote:
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.
See https://ci.appveyor.com/project/pdimov/system/build/1.0.97-develop/job/v6b2o... for an example of the Cygwin linker doing that. It's a warning, but better than nothing. MinGW too: https://ci.appveyor.com/project/pdimov/system/build/1.0.97-develop/job/8kum8...
On Tue, Feb 13, 2018 at 12:21 AM, Gavin Lambert via Boost <boost@lists.boost.org> 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
On 13/02/2018 21:05, Olaf van der Spek wrote:
On Tue, Feb 13, 2018 at 12:21 AM, Gavin Lambert 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?
They can, but it's a little trickier since you will only get the C++03 implementation if someone actually compiles a translation unit in C++03 mode. (Though that's not a bad thing.)
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<int ()> const& F ) = 0; virtual int operator()( std::function<int ()> 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
Raffi Enficiaud wrote:
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 :) ).
The Boost community is not equipped to handle an even simpler problem: issue a compile-time error (or more precisely, a link-time error) when the user mixes C++03 with C++11. (Or mixes different Boost versions.) As for your problem, as you pose it, it's inherently insoluble, so no community will be equipped to handle it.
* do you think we can set up mechanisms that checks we are doing it right?
The Boost.System tests link a C++03 exe and a C++11 exe with the default-built library, to check for this type of problem: https://github.com/boostorg/system/blob/develop/test/Jamfile.v2#L93
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<int ()> const& F ) = 0; virtual int operator()( std::function<int ()> 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<int ()> const& F ) = 0; virtual int f( std::function<int ()> const& F ) = 0; #else virtual int f( boost::function<int ()> const& F ) = 0; virtual int __f( std::function<int ()> 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.
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<int ()> const& F ) = 0; virtual int f( std::function<int ()> const& F ) = 0;
#else
virtual int f( boost::function<int ()> const& F ) = 0; virtual int __f( std::function<int ()> 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, 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. libstdc++, though, has the luxury of knowing the slot allocation algorithm, as well as binary layout of its own components (e.g. std::string vs. std::__cxx11::string), so it can do stuff like that and even better (e.g. it can actually transparently support both string types, where needed). In an external generic library like Boost, this is a pretty risky thing to do. Just always using ABI-stable types in the link interface seems more preferable.
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<int ()> const& F ) = 0; virtual int f( std::function<int ()> const& F ) = 0;
#else
virtual int f( boost::function<int ()> const& F ) = 0; virtual int __f( std::function<int ()> 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 02/10/18 20:13, Peter Dimov via Boost wrote:
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<int ()> const& F ) = 0; virtual int f( std::function<int ()> const& F ) = 0;
#else
virtual int f( boost::function<int ()> const& F ) = 0; virtual int __f( std::function<int ()> 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.
Well, yes, but that's not a problem for libstdc++, because, presumably, it is always compiled with the latest C++ supported by the compiler. So the std::function declaration is only replaced with a dummy when it cannot be called. 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.
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 02/10/18 23:23, degski via Boost wrote:
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.
I don't think this is necessary. And given that we don't normally do point releases, I don't think C++03 users would want to stick with an old Boost version.
participants (24)
-
Andrey Semashev -
Daniel James -
degski -
Edward Diener -
Gavin Lambert -
Glen Fernandes -
Groke, Paul -
Hans Dembinski -
Jared Grubb -
John Maddock -
Nevin Liber -
Niall Douglas -
Olaf van der Spek -
Paul A. Bristow -
Pete Bartlett -
Peter Dimov -
Raffi Enficiaud -
Richard Hodges -
Rob Stewart -
Robert Ramey -
Soul Studios -
Steven Watanabe -
Thomas Heller -
Vinnie Falco