C++17 detection

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

C++17 detection

Boost - Dev mailing list
How do I get ready for C++17?

I have a piece of code which requires C++14.  I want to use something
from C++17 but I also want my code to work now.  So I have

#if C++14 being used
namespace std {
// implement C++ function
} // std

I've looked in the documentation for Boost.Config and can't find any
hints there.

What is the best way to do this?

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
On Sun, Sep 10, 2017 at 12:30 PM, Robert Ramey via Boost <
[hidden email]> wrote:
>
> How do I get ready for C++17?
>
> I have a piece of code which requires C++14.  I want to use something
from C++17 but I also want my code to work now.  So I have
>
> #if C++14 being used
> namespace std {
> // implement C++ function
> } // std
>
> I've looked in the documentation for Boost.Config and can't find any
hints there.
>
> What is the best way to do this?
>
> Robert Ramey
>

I like to configure on a per-feature basis, so I use these when boost
Boost.Config falls short:
http://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros

Barrett

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey via Boost wrote:
> How do I get ready for C++17?
>
> I have a piece of code which requires C++14.  I want to use something from
> C++17 but I also want my code to work now.  So I have
>
> #if C++14 being used
> namespace std {
> // implement C++ function
> }

Don't define those things inside namespace std. Instead:

  namespace boost {
  namespace yours {
  namespace detail {
#if /* C++17 thing available */
      using std::thing;
#else
      /* Define thing yourself */
#endif
  } } }

And then use boost::yours::detail::thing in your library.

Glen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

> Em 10 sept 2017, às 19:30, Robert Ramey via Boost <[hidden email]> escreveu:
>
> How do I get ready for C++17?
>
> I have a piece of code which requires C++14.  I want to use something from C++17 but I also want my code to work now.  So I have
>
> #if C++14 being used
> namespace std {
> // implement C++ function
> } // std
>
> I've looked in the documentation for Boost.Config and can't find any hints there.

You might find this technique useful:

http://bannalia.blogspot.com/2016/09/compile-time-checking-existence-of.html?m=1

The nice thing about it is you don't depend
on implementation macros that might or
might not be accurate.

Joaquín M López Muñoz

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/09/2017 20:07, Glen Fernandes via Boost wrote:

> On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey via Boost wrote:
>> How do I get ready for C++17?
>>
>> I have a piece of code which requires C++14.  I want to use something from
>> C++17 but I also want my code to work now.  So I have
>>
>> #if C++14 being used
>> namespace std {
>> // implement C++ function
>> }
>
> Don't define those things inside namespace std. Instead:
>
>   namespace boost {
>   namespace yours {
>   namespace detail {
> #if /* C++17 thing available */
>       using std::thing;
> #else
>       /* Define thing yourself */
> #endif
>   } } }
>
> And then use boost::yours::detail::thing in your library.

And here is an example of use of exactly that technique which uses
std::optional if available with the current compiler's configuration,
otherwise a conforming optional<T> implementation:

https://github.com/ned14/quickcpplib/blob/master/include/optional.hpp

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
I did the same thing with smart_ptr, allowing for a transition between
boost and std in the Apache Thrift project going from C++03 to C++11.
Unfortunately it was a bunch of trial and error as no macro seemed to cover
it completely.

https://github.com/apache/thrift/blob/master/lib/cpp/src/thrift/stdcxx.h

- Jim

On Sun, Sep 10, 2017 at 8:28 PM, Niall Douglas via Boost <
[hidden email]> wrote:

> On 10/09/2017 20:07, Glen Fernandes via Boost wrote:
> > On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey via Boost wrote:
> >> How do I get ready for C++17?
> >>
> >> I have a piece of code which requires C++14.  I want to use something
> from
> >> C++17 but I also want my code to work now.  So I have
> >>
> >> #if C++14 being used
> >> namespace std {
> >> // implement C++ function
> >> }
> >
> > Don't define those things inside namespace std. Instead:
> >
> >   namespace boost {
> >   namespace yours {
> >   namespace detail {
> > #if /* C++17 thing available */
> >       using std::thing;
> > #else
> >       /* Define thing yourself */
> > #endif
> >   } } }
> >
> > And then use boost::yours::detail::thing in your library.
>
> And here is an example of use of exactly that technique which uses
> std::optional if available with the current compiler's configuration,
> otherwise a conforming optional<T> implementation:
>
> https://github.com/ned14/quickcpplib/blob/master/include/optional.hpp
>
> Niall
>
> --
> ned Productions Limited Consulting
> http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
On 11/09/2017 13:11, James E. King, III wrote:
> I did the same thing with smart_ptr, allowing for a transition between
> boost and std in the Apache Thrift project going from C++03 to C++11.
> Unfortunately it was a bunch of trial and error as no macro seemed to cover
> it completely.
>
> https://github.com/apache/thrift/blob/master/lib/cpp/src/thrift/stdcxx.h

The comment header in that Smart Pointers block seems incorrect, BTW.

I assume you meant that BOOST_NO_CXX11_SMART_PTR was *not* defined in
VS2010 and VS2012 (since they do implement std::shared_ptr).

For the other part, perhaps you could have made use of
BOOST_NO_CXX11_TEMPLATE_ALIASES?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/10/17 1:00 PM, Joaquín M López Muñoz via Boost wrote:

>
>> Em 10 sept 2017, às 19:30, Robert Ramey via Boost <[hidden email]> escreveu:
>>
>> How do I get ready for C++17?
>>
>> I have a piece of code which requires C++14.  I want to use something from C++17 but I also want my code to work now.  So I have
>>
>> #if C++14 being used
>> namespace std {
>> // implement C++ function
>> } // std
>>
>> I've looked in the documentation for Boost.Config and can't find any hints there.
>
> You might find this technique useful:
>
> http://bannalia.blogspot.com/2016/09/compile-time-checking-existence-of.html?m=1
>
> The nice thing about it is you don't depend
> on implementation macros that might or
> might not be accurate.

A little background

I've been using the "detection idiom" which has worked well for my
purposes.  But this idiom is only found in C++17 libraries so I included
the code for it in my C++14 application.  But now I want to include my
local version of the idiom itself only if there isn't one included in
with the library so I can't depend upon it.

So your solution looks promising.

All this makes me wonder if the usage of Boost.Config might be
diminished by using such techniques.  Or perhaps, Boost.Config might be
broadened to make the usage of such techniques more accessible to the
"rest of us"

>
> Joaquín M López Muñoz
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/10/17 12:07 PM, Glen Fernandes via Boost wrote:

> On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey via Boost wrote:
>> How do I get ready for C++17?
>>
>> I have a piece of code which requires C++14.  I want to use something from
>> C++17 but I also want my code to work now.  So I have
>>
>> #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?

> #if /* C++17 thing available */

Actually, the question I meant to ask is what should go into the

/* C++17 thing available */

I was thinking of something from Boost.Config - which I use a lot.

Robert Ramey

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
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).


> #if /* C++17 thing available */
>>
>
> Actually, the question I meant to ask is what should go into the
>
> /* C++17 thing available */
>
> I was thinking of something from Boost.Config - which I use a lot.


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).

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.

Glen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
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
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 09/10/17 23:00, Joaquín M López Muñoz via Boost wrote:

>
>> Em 10 sept 2017, às 19:30, Robert Ramey via Boost <[hidden email]> escreveu:
>>
>> How do I get ready for C++17?
>>
>> I have a piece of code which requires C++14.  I want to use something from C++17 but I also want my code to work now.  So I have
>>
>> #if C++14 being used
>> namespace std {
>> // implement C++ function
>> } // std
>>
>> I've looked in the documentation for Boost.Config and can't find any hints there.
>
> You might find this technique useful:
>
> http://bannalia.blogspot.com/2016/09/compile-time-checking-existence-of.html?m=1
>
> The nice thing about it is you don't depend
> on implementation macros that might or
> might not be accurate.

This doesn't say if std::is_final is functional (i.e. not bugged). Also,
hijacking an unrelated class template for feature detection is kind of
hacky.

And I wonder how portable this is. std::is_final may actually be
std::some_internal_namespace::is_final; will it be found in this case?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Monday, September 11, 2017, Robert Ramey wrote:

> On 9/11/17 8:20 AM, Glen Fernandes via wrote:
>
>> 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.
>

No, something like that sounds much less useful to me. Imagine if 90% of
implementations had a correct and working std::is_detected but all of those
had a broken or non-existent... say... std::launder, and so the macro you
suggest would be defined. You don't care that those implementations don't
have std::launder. You just care that they have std::is_detected.

BOOST_NO_CXX71_DECTECTION_IDIOM sounds reasonable and still granular enough.

Glen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/09/2017 16:58, Robert Ramey via Boost wrote:

> On 9/10/17 12:07 PM, Glen Fernandes via Boost wrote:
>> On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey via Boost wrote:
>>> How do I get ready for C++17?
>>>
>>> I have a piece of code which requires C++14.  I want to use something
>>> from
>>> C++17 but I also want my code to work now.  So I have
>>>
>>> #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 it can fail. Newer stdlib implementations use inline namespaces
so you just can't forward declare things in namespace std. You need more
elaborated tricks:

http://www.boost.org/doc/libs/1_65_1/boost/move/detail/std_ns_begin.hpp

http://www.boost.org/doc/libs/1_65_1/boost/move/detail/std_ns_end.hpp

A Boost.Config or similar library that does this would be useful. That
way we could forward declare standard classes instead of pulling the
whole header.

Best,

Ion

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Sep 11, 2017 at 10:37 AM, Robert Ramey via Boost <
[hidden email]> wrote:

> 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.


Because the standard says so.  See [namespace.std].  When this is violated,
well, it's why we can't have nice things.  As a user, well, you've invoked
undefined behavior.

The standard needs a place where it owns all the names.


>   What problem might violating such a permission cause?


Ever wonder why there is no std::hash_map (with that spelling)?  Because
vendors used to put their hash_map into namespace std, neither of which was
quite compatible with the unordered_map eventually shipped in C++11.  It is
very deceiving to pretend you are part of the standard when you are not.
--
 Nevin ":-)" Liber  <mailto:[hidden email]>  +1-847-691-1404

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 12/09/2017 03:37, Robert Ramey wrote:
> On 9/11/17 8:20 AM, Glen Fernandes wrote:
>> 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?

You might cause the application to fail to compile correctly when used
with an unexpected (or newer or older) STL that defines a conflicting
symbol in that namespace.

If you're the application author, you can get away with that more often,
as you can change your offending code or perhaps use a different STL or
different STL version.  You don't have as much freedom as a library author.

>> 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'm a little surprised that there doesn't seem to be a Boost.Config
macro for std::void_t<>; but then there doesn't seem to be many C++17
macros yet at all.  Perhaps the maintainer is just waiting to see what
people want to test for, first.

> I guess I'm looking for
>
> BOOST_C_PLUS_PLUS_LIBRARY_VERSION
>
> or something like that.

__cplusplus gives you the claimed conformance level of the compiler,
which is usually (though not necessarily) in agreement with the STL.

But that doesn't do you a lot of good as it's a big catch-all (and at
least in the case of MSVC lags behind the actual individual feature
support).  So it's better to test for individual features that you need
rather than a conformance level as a whole.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
[Gavin Lambert]
> __cplusplus gives you the claimed conformance level of the compiler,
> which is usually (though not necessarily) in agreement with the STL.
> But that doesn't do you a lot of good as it's a big catch-all
> (and at least in the case of MSVC lags behind the actual individual feature support).

That's intentional. If we were to update __cplusplus's value before completing C++11 (not to mention C++14/17), the Internet would riot.

_MSVC_LANG reports the value that __cplusplus would have (in the recent versions that support /std:c++14, /std:c++latest, and now /std:c++17). Note that it isn't a claim to implement literally everything in the corresponding Standard.

STL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
On Tue, Sep 12, 2017 at 3:15 AM, Stephan T. Lavavej via Boost
<[hidden email]> wrote:
> [Gavin Lambert]
>> __cplusplus gives you the claimed conformance level of the compiler,
>> which is usually (though not necessarily) in agreement with the STL.
>> But that doesn't do you a lot of good as it's a big catch-all
>> (and at least in the case of MSVC lags behind the actual individual feature support).
>
> That's intentional. If we were to update __cplusplus's value before completing C++11 (not to mention C++14/17), the Internet would riot.

Well, MSVC never implemented C++98/03 completely, yet I think it
defined __cplusplus as if it did. I don't think __cplusplus ever did
provide any practical indication of the supported language and
therefore its value doesn't matter much.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/10/17 11:43 AM, Barrett Adair via Boost wrote:

> I like to configure on a per-feature basis, so I use these when boost
> Boost.Config falls short:
> http://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros

Looks like the best answer so far

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++17 detection

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 12/09/2017 12:15, Stephan T. Lavavej wrote:
> [Gavin Lambert]
>> __cplusplus gives you the claimed conformance level of the compiler,
>> which is usually (though not necessarily) in agreement with the STL.
>> But that doesn't do you a lot of good as it's a big catch-all
>> (and at least in the case of MSVC lags behind the actual individual feature support).
>
> That's intentional. If we were to update __cplusplus's value before
> completing C++11 (not to mention C++14/17), the Internet would riot.
I know it's intentional; that wasn't my point.  It wasn't intended as a
disparagement, just a statement of fact.

Although having said that, while I can understand the desire to not
update it until the standard is fully implemented, it does seem a bit
peculiar to do that -- and inconsistent with what GCC/Clang do (they
just indicate which version is requested on the command line), so I
don't know why you'd get a riot for doing the same as them.  In fact I
would think that would be a better thing to do, to improve consistency
between compilers.


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