feature for C++ standards compliance

Robert Ramey

25 Feb 2021 25 Feb '21

6:33 p.m.

The serialization library is compatible with C++03 (and likely 98). And is tested regularly with C++ compilers with the -std switch set to this mode. The recent changes to the math library have broken about 5 tests in the serialization library. Since this breakage is in a few tests only and not in the library itself, I'd like to suppress these tests when the being tested with a C++03 compiler. I've suppressed tests which are conditional on C++ features which are not supported and this has worked well for my purposes. I'd like to do the same for a couple of tests which are conditional on usage of the math library and standards versions < C++11. Any B2/CMake experts want to help an old guy out?

Show replies by date

Christopher Kormanyos

25 Feb 25 Feb

6:38 p.m.

...

...conditional on usage of the math library and standards versions This is probably too trivial, but I found myselfdoing this one in another project today.

#if defined(BOOST_VERSION) && (BOOST_VERSION <= 107500) #else #endif It works because Math decisively dumps 03 in 1.76. On Thursday, February 25, 2021, 7:34:37 PM GMT+1, Robert Ramey via Boost wrote: The serialization library is compatible with C++03 (and likely 98). And is tested regularly with C++ compilers with the -std switch set to this mode. The recent changes to the math library have broken about 5 tests in the serialization library. Since this breakage is in a few tests only and not in the library itself, I'd like to suppress these tests when the being tested with a C++03 compiler. I've suppressed tests which are conditional on C++ features which are not supported and this has worked well for my purposes. I'd like to do the same for a couple of tests which are conditional on usage of the math library and standards versions < C++11. Any B2/CMake experts want to help an old guy out? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

John Maddock

6:55 p.m.

On 25/02/2021 18:33, Robert Ramey via Boost wrote:

...

The serialization library is compatible with C++03 (and likely 98). And is tested regularly with C++ compilers with the -std switch set to this mode. The recent changes to the math library have broken about 5 tests in the serialization library. Since this breakage is in a few tests only and not in the library itself, I'd like to suppress these tests when the being tested with a C++03 compiler. I've suppressed tests which are conditional on C++ features which are not supported and this has worked well for my purposes. I'd like to do the same for a couple of tests which are conditional on usage of the math library and standards versions < C++11. Any B2/CMake experts want to help an old guy out?

There is no "only build this in C++X mode" for some value X, I was thinking about this the other day, and Boost.Config should probably add something that is the union of all our std-specific feature test macros that we could all use. In the mean time, adding: import ../../config/checks/config : requires ; To the top of the Jamfile and then to each target's requires clause add: [ requires cxx11_noexcept cxx11_rvalue_references sfinae_expr cxx11_auto_declarations cxx11_lambdas cxx11_unified_initialization_syntax cxx11_hdr_tuple cxx11_hdr_initializer_list cxx11_hdr_chrono cxx11_thread_local cxx11_constexpr cxx11_nullptr cxx11_numeric_limits cxx11_decltype cxx11_hdr_array cxx11_hdr_atomic cxx11_hdr_type_traits cxx11_allocator cxx11_explicit_conversion_operators ] And yes, this is over-verbose. I might see if I can file you a quick PR. Best, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Peter Dimov

7:04 p.m.

John Maddock wrote:

...

There is no "only build this in C++X mode" for some value X, I was thinking about this the other day, and Boost.Config should probably add something that is the union of all our std-specific feature test macros that we could all use.

In the mean time, adding:

import ../../config/checks/config : requires ;

To the top of the Jamfile and then to each target's requires clause add:

[ requires cxx11_noexcept cxx11_rvalue_references sfinae_expr cxx11_auto_declarations cxx11_lambdas cxx11_unified_initialization_syntax cxx11_hdr_tuple cxx11_hdr_initializer_list cxx11_hdr_chrono cxx11_thread_local cxx11_constexpr cxx11_nullptr cxx11_numeric_limits cxx11_decltype cxx11_hdr_array cxx11_hdr_atomic cxx11_hdr_type_traits cxx11_allocator cxx11_explicit_conversion_operators ]

And yes, this is over-verbose.

[ requires cxx11 ] would be a substantial improvement. :-)

John Maddock

7:13 p.m.

On 25/02/2021 18:33, Robert Ramey via Boost wrote:

...

The serialization library is compatible with C++03 (and likely 98). And is tested regularly with C++ compilers with the -std switch set to this mode. The recent changes to the math library have broken about 5 tests in the serialization library. Since this breakage is in a few tests only and not in the library itself, I'd like to suppress these tests when the being tested with a C++03 compiler. I've suppressed tests which are conditional on C++ features which are not supported and this has worked well for my purposes. I'd like to do the same for a couple of tests which are conditional on usage of the math library and standards versions < C++11. Any B2/CMake experts want to help an old guy out?

I just looked at this, and I get 198 serialization lib test failures in C++03 mode currently :( The issue is that your tests are using Boost.Math, specifically float_distance, and this is now C++11 and later. It's used fairly ubiquitously in your tests as well. Given that we've signaled this change for over a year now, how do we handle this? Best, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Robert Ramey

7:58 p.m.

On 2/25/21 11:13 AM, John Maddock via Boost wrote:

...

I just looked at this, and I get 198 serialization lib test failures in C++03 mode currently :(

Its really only 5 tests. the tests are repeated for each archive. Also depending on the test setup more than one variant, or compiler or whatever may be tested - thus elevating the number.

...

The issue is that your tests are using Boost.Math, specifically float_distance, and this is now C++11 and later. It's used fairly ubiquitously in your tests as well.

Right. Still it's only 5 tests. After tracking this down - which took a surprising amount of time given branches, etc - I considered my options and the easiest and most future looking was to just suppress these tests for compilations with C++ version

...

Given that we've signaled this change for over a year now, how do we handle this?

I'm thinking the attribute list should include the standards version. But if that's too much work I totally understand and will work around it some other way. I don't know how many other libraries have this issue - it might well be none. I'll leave it totally up to you. Just post if you change anything. Robert Ramey

Gavin Lambert

8:48 p.m.

On 26/02/2021 8:58 am, Robert Ramey wrote:

...

Right. Still it's only 5 tests. After tracking this down - which took a surprising amount of time given branches, etc - I considered my options and the easiest and most future looking was to just suppress these tests for compilations with C++ version

Conditioning a boost test on boost version < N is equivalent to just unconditionally suppressing it, no? Isn't the goal to only suppress it when not compiling >= C++11? Shouldn't you just check __cplusplus >= 201103 for that?

Edward Diener

9:13 p.m.

On 2/25/2021 3:48 PM, Gavin Lambert via Boost wrote:

...

On 26/02/2021 8:58 am, Robert Ramey wrote:

...
Right. Still it's only 5 tests. After tracking this down - which took a surprising amount of time given branches, etc - I considered my options and the easiest and most future looking was to just suppress these tests for compilations with C++ version
Conditioning a boost test on boost version < N is equivalent to just unconditionally suppressing it, no?

Isn't the goal to only suppress it when not compiling >= C++11? Shouldn't you just check __cplusplus >= 201103 for that?

Unfortunately __cplusplus is not totally reliable in a number of compiler implementations.

Robert Ramey

9:15 p.m.

On 2/25/21 12:48 PM, Gavin Lambert via Boost wrote:

...

Conditioning a boost test on boost version < N is equivalent to just unconditionally suppressing it, no?

No - because boost version <= 1.75 math library supports C++03 while other versions don't/wont.

...

Isn't the goal to only suppress it when not compiling >= C++11?

yep

...

Shouldn't you just check __cplusplus >= 201103 for that?

Hmmm - is this portable on all compilers? Is this part of config.hpp?

...

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

Gavin Lambert

9:56 p.m.

On 26/02/2021 10:15 am, Robert Ramey wrote:

...

...
Conditioning a boost test on boost version < N is equivalent to just unconditionally suppressing it, no?

No - because boost version <= 1.75 math library supports C++03 while other versions don't/wont.

But for a library inside of Boost itself, as soon as you commit it, it will always remove the code. Any new Boost code cannot exist in Boost <= 1.75, by definition.

...

...
Shouldn't you just check __cplusplus >= 201103 for that?

Hmmm - is this portable on all compilers? Is this part of config.hpp?

There are some compilers that support only part of C++11 and they do not claim that compatibility level, but it is not unreasonable to suppress the tests under those conditions anyway. Certainly it will work in all of the major platforms and compilers.

Andrey Semashev

10:04 p.m.

On 2/26/21 12:15 AM, Robert Ramey via Boost wrote:

...

On 2/25/21 12:48 PM, Gavin Lambert via Boost wrote:

...
Conditioning a boost test on boost version < N is equivalent to just unconditionally suppressing it, no?

No - because boost version <= 1.75 math library supports C++03 while other versions don't/wont.

I think the point was that with the Boost version check you won't be running these tests *at all* in the current and future Boost.

...

...
Isn't the goal to only suppress it when not compiling >= C++11? yep

...
Shouldn't you just check __cplusplus >= 201103 for that?

Hmmm - is this portable on all compilers? Is this part of config.hpp?

__cplusplus is a standard C++ macro, but not all compilers consistently define it to >= 201103 in C++11 mode. Most notably, MSVC doesn't. If you want to check macros (which is what I'm doing in Boost.Integer to solve a similar problem with Boost.Multiprecision) then I'd suggest to check Boost.Config macros for the particular C++11 features that are required by Boost.Math. You may even peek in Boost.Math sources to see what these macros are, if they are checked there.

Edward Diener

10:22 p.m.

On 2/25/2021 5:04 PM, Andrey Semashev via Boost wrote:

...

On 2/26/21 12:15 AM, Robert Ramey via Boost wrote:

...
On 2/25/21 12:48 PM, Gavin Lambert via Boost wrote:

...
Conditioning a boost test on boost version < N is equivalent to just unconditionally suppressing it, no?

No - because boost version <= 1.75 math library supports C++03 while other versions don't/wont.

I think the point was that with the Boost version check you won't be running these tests *at all* in the current and future Boost.

...
...
Isn't the goal to only suppress it when not compiling >= C++11? yep

...
Shouldn't you just check __cplusplus >= 201103 for that?

Hmmm - is this portable on all compilers? Is this part of config.hpp?

__cplusplus is a standard C++ macro, but not all compilers consistently define it to >= 201103 in C++11 mode. Most notably, MSVC doesn't.

The compilers that emulate the msvc non-standard preprocessor, such as the VC++ based versions of Intel C++ and also NVCC I believe, report incorrect __cplusplus values. I also recall that some past versions of gcc reported an incorrect _cplusplus value, although I do not recall in which gcc version this was corrected. So unfortunately it is not completely reliable, even with major compilers. BTW the new C++ standard non-default preprocessor ( /Zc:preprocessor ) in VS2019 gets it right and is a very good C++ standard preprocessor.

...

If you want to check macros (which is what I'm doing in Boost.Integer to solve a similar problem with Boost.Multiprecision) then I'd suggest to check Boost.Config macros for the particular C++11 features that are required by Boost.Math. You may even peek in Boost.Math sources to see what these macros are, if they are checked there.

Yes, that is the only reliable solution right now.

Edward Diener

10:48 p.m.

On 2/25/2021 5:22 PM, Edward Diener via Boost wrote:

...

On 2/25/2021 5:04 PM, Andrey Semashev via Boost wrote:

...
On 2/26/21 12:15 AM, Robert Ramey via Boost wrote:

...
On 2/25/21 12:48 PM, Gavin Lambert via Boost wrote:

...
Conditioning a boost test on boost version < N is equivalent to just unconditionally suppressing it, no?

No - because boost version <= 1.75 math library supports C++03 while other versions don't/wont.

I think the point was that with the Boost version check you won't be running these tests *at all* in the current and future Boost.

...
...
Isn't the goal to only suppress it when not compiling >= C++11? yep

...
Shouldn't you just check __cplusplus >= 201103 for that?

Hmmm - is this portable on all compilers? Is this part of config.hpp?

__cplusplus is a standard C++ macro, but not all compilers consistently define it to >= 201103 in C++11 mode. Most notably, MSVC doesn't.

The compilers that emulate the msvc non-standard preprocessor, such as the VC++ based versions of Intel C++ and also NVCC I believe, report incorrect __cplusplus values. I also recall that some past versions of gcc reported an incorrect _cplusplus value, although I do not recall in which gcc version this was corrected.

gcc-4.6 and below had an incorrect value of '1' and it was fixed to be correct for gcc-4.7 on up. Not that I would bother worrying about such old compiler versions of gcc myself.

...

So unfortunately it is not completely reliable, even with major compilers. BTW the new C++ standard non-default preprocessor ( /Zc:preprocessor ) in VS2019 gets it right and is a very good C++ standard preprocessor.

...
If you want to check macros (which is what I'm doing in Boost.Integer to solve a similar problem with Boost.Multiprecision) then I'd suggest to check Boost.Config macros for the particular C++11 features that are required by Boost.Math. You may even peek in Boost.Math sources to see what these macros are, if they are checked there.

Yes, that is the only reliable solution right now.

Gavin Lambert

11:33 p.m.

On 26/02/2021 11:22 am, Edward Diener wrote:

...

Yes, that is the only reliable solution right now.

Well, the *correct* thing to do -- since this is due to a Boost.Math dependency -- is to look up whatever condition that Boost.Math itself uses (which may be a jamfile setting or a preprocessor check), and then use the identical one, whatever that may be.

Peter Dimov

10:21 p.m.

Robert Ramey wrote:

...

...
Shouldn't you just check __cplusplus >= 201103 for that?

Hmmm - is this portable on all compilers? Is this part of config.hpp?

Portable on everything except MSVC.

Peter Dimov

28 Feb 28 Feb

2:36 a.m.

John Maddock wrote:

...

I just looked at this, and I get 198 serialization lib test failures in C++03 mode currently :(

The issue is that your tests are using Boost.Math, specifically float_distance, and this is now C++11 and later. It's used fairly ubiquitously in your tests as well.

Sorry for hijacking the thread, but why does Math implement its own copy of parts of Mp11 in https://github.com/boostorg/math/blob/develop/include/boost/math/tools/mp.hp... ? :-)

Matt Borland

11 a.m.

On Sun, 2021-02-28 at 04:36 +0200, Peter Dimov via Boost wrote:

...

John Maddock wrote:

...
I just looked at this, and I get 198 serialization lib test failures in C++03 mode currently :(

The issue is that your tests are using Boost.Math, specifically float_distance, and this is now C++11 and later. It's used fairly ubiquitously in your tests as well.

Sorry for hijacking the thread, but why does Math implement its own copy of parts of Mp11

In release 1.75 Math had over 20 dependencies on other Boost libraries, primarily to support C++03. Now that C++11 is the minimum standard in Math it is possible to create a version that can be consumed in isolation. To this end a small subset of MP11 functionality was needed to break all the dependencies on MPL and MP11. Matt

Peter Dimov

2:47 p.m.

Matt Borland wrote:

...

On Sun, 2021-02-28 at 04:36 +0200, Peter Dimov via Boost wrote: ...

...
Sorry for hijacking the thread, but why does Math implement its own copy of parts of Mp11

In release 1.75 Math had over 20 dependencies on other Boost libraries, primarily to support C++03. Now that C++11 is the minimum standard in Math it is possible to create a version that can be consumed in isolation. To this end a small subset of MP11 functionality was needed to break all the dependencies on MPL and MP11.

I still count 18 dependencies on the current develop. Many of them can indeed be replaced with C++11 functionality, but I don't think that the zero-dependency Mp11 was your primary problem here.

John Maddock

2:58 p.m.

On 28/02/2021 14:47, Peter Dimov via Boost wrote:

...

Matt Borland wrote:

...
...
Sorry for hijacking the thread, but why does Math implement its own copy of parts of Mp11 In release 1.75 Math had over 20 dependencies on other Boost libraries,

On Sun, 2021-02-28 at 04:36 +0200, Peter Dimov via Boost wrote: ... primarily to support C++03. Now that C++11 is the minimum standard in Math it is possible to create a version that can be consumed in isolation. To this end a small subset of MP11 functionality was needed to break all the dependencies on MPL and MP11. I still count 18 dependencies on the current develop.

Many of them can indeed be replaced with C++11 functionality, but I don't think that the zero-dependency Mp11 was your primary problem here.

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

Matt Borland

3:05 p.m.

On Sun, 2021-02-28 at 16:47 +0200, Peter Dimov wrote:

...

I still count 18 dependencies on the current develop.

Many of them can indeed be replaced with C++11 functionality, but I don't think that the zero-dependency Mp11 was your primary problem here.

You are correct, and many of the remaining dependencies are trivial to replace. The diff stat to remove MPL and MP11 is going to be by far the largest to break a dependency; it also required changes in Multiprecision. (Un)fortunately I found myself in state ordered quarantine so I had nothing but time. Matt

1367

Age (days ago)

1370

Last active (days ago)

List overview

Download

19 comments

8 participants

participants (8)

Andrey Semashev
Christopher Kormanyos
Edward Diener
Gavin Lambert
John Maddock
Matt Borland
Peter Dimov
Robert Ramey