Re: [boost] C++17 detection

Subject: Re: [boost] C++17 detection
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-09-11 15:37:31

On 9/11/17 8:20 AM, Glen Fernandes via Boost wrote:
> On Monday, September 11, 2017, Robert Ramey wrote:
> 
>> On 9/10/17 12:07 PM, Glen Fernandes via Boost wrote:
>>
>>> On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey wrote:
>>>
>>>> #if C++14 being used
>>>> namespace std {
>>>> // implement C++ function
>>>> }
>>>>
>>>
>>> Don't define those things inside namespace std. Instead:
>>>
>>
>> Hmmmm - I've done this from time to time.  Why would this be a bad thing?
> 
> 
> Because we only define things inside std that we are explicitly granted
> permission to (such as specializations of specific stand library types).

Right.  But why do "we" do this.  What problem might violating such a 
permission cause?

> Yes. You should add BOOST_NO_CXX17_STD_IS_DETECTED or similar to
> Boost.Config, just as we have added similar C++17 feature detection macros
> recently (e.g
> BOOST_NO_CXX17_FOLD_EXPRESSIONS, for Peter to use in Boost.Mp11).

Hmmmm - this would require more thought.  My actual interest is the 
usage o the "detection idiom".  So there should be a
BOOST_NO_CXX71_DECTECTION_IDIOM ?  Actually that would be ideal for my 
case.  But it would seem to me that that would be quite a narrow 
audience to justify the effort.  I'm willing to assume that any library 
which claims C++17 conformance would support the detection idiom, but I 
don't find a macro on Boost.Config which lets me know which version of 
the C++ standard library is supported.  It might be there but I haven't 
found it.

I guess I'm looking for

BOOST_C_PLUS_PLUS_LIBRARY_VERSION

or something like that.

> We want to have these detections handled in one place that all Boost
> libraries can benefit from. Implementation vendors don't always define
> __cplusplus to a value that sensibly or accurately reflect the state of
> their conformance. Then there could be defects in their implementations
> that otherwise invalidate what conformance they advertised. Boost.Config is
> the thing we rely on to tell us otherwise.

I get this. I'm a big user and promoter of Boost.Config.

Robert Ramey

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