Libraries and C++ compliance

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Libraries and C++ compliance

Boost - Dev mailing list
I would like to ask people who present new libraries to Boost, in
whatever stages they are, to please specify in the documentation to the
library and/or in messages regarding the library, what level of C++
compliance is needed to use the functionality of that library. This plea
is not being directed at any particular current library being mentioned
by anyone on the mailing list, but is a general plea regarding
developers and their efforts.

I realize it is a real pain that C++ as a language, and as it continues
to evolve, has a number of popular levels of C++ compliance. This is
largely because C++ is offered by a number of different vendors in a
number of different supported releases, each particular implementation
supporting a number of levels of C++ compliance and sometimes only
partially supporting a particular level of C++ compliance. But given
this sometimes difficult situation I do not see it as enough for library
docs/information to simply say "this library supports
some-vendor/some-release" because this is actually fairly meaningless to
me when I know that "some-vendor/some-release" supports a number of
levels of C++ compliance through some compiler parameter ( often
-std=something ). Therefore docs/information of "the library supports
"some-implementation" or "the library is compliant with "more than one
level of C++ compliance" tells me as much as if some one told me that
the moon is yellow. So I am begging, pleading, entreating library
authors to be specific about the C++ features or the C++ level of
compliance needed to use their library, even if it is just a one-liner
that succinctly explains what the end-user needs to know.

Furthermore, for any given library could we please have specific
information about what will happen if I use the library, or some feature
of the library, without the desired minimum level of C++ compliance.
While I would assume compile-time compiler errors as the norm another
possibility, especially given the excellent support in Boost Config to
compiler conformance, are more readable preprocessor errors. Finally a
library might offer some level of advanced C++ compliance but fall back
to a lower level if possible.

Please, please library authors this is important. No end-user or tester
of your library wants to spend extended time trying to figure out why
some compile fails when the answer turns out simply to be one of
inadequate C++ conformance level for a particular compiler
implementation being used with a particular level of conformance.


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

Re: Libraries and C++ compliance

Boost - Dev mailing list
On 10/04/2017 03:24, Edward Diener via Boost wrote:

> Please, please library authors this is important. No end-user or tester
> of your library wants to spend extended time trying to figure out why
> some compile fails when the answer turns out simply to be one of
> inadequate C++ conformance level for a particular compiler
> implementation being used with a particular level of conformance.

Outcome is up for review here end of May.

Are you happy with its compiler support at
https://ned14.github.io/boost.outcome/prerequisites.html? To save people
clicking on the link:

"Outcome is a header only C++ 14 library known to work on these
compilers or better:

clang 3.5 (LLVM)
clang 3.7 (with Microsoft Codegen)
GCC 5.4
VS2015 Update 2
Xcode 7.3

*A copy of Boost is not required to use this library. You can simply
drop Outcome into your project and go.*

Warning: MSVC generates significant code bloat when using Outcome in
large code bases. If you can use VS2017 which implements C++ 14
constexpr and has a better optimiser for modern C++, you will see tigher
executables. Execution speed is not particularly different, though one
would have thought the extra cache load caused by code bloat might
affect some applications. In this situation, use LLVM clang targeting
the MSVC ABI."

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
|  
Report Content as Inappropriate

Re: Libraries and C++ compliance

Boost - Dev mailing list
> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Niall Douglas via Boost
> Sent: 10 April 2017 08:05
> To: [hidden email]
> Cc: Niall Douglas
> Subject: Re: [boost] Libraries and C++ compliance
>
> On 10/04/2017 03:24, Edward Diener via Boost wrote:
>
> > Please, please library authors this is important. No end-user or tester
> > of your library wants to spend extended time trying to figure out why
> > some compile fails when the answer turns out simply to be one of
> > inadequate C++ conformance level for a particular compiler
> > implementation being used with a particular level of conformance.

+1  - this IS really important to users.

(and even info on what happens with older versions that the author cannot test, including any clues.  "Some parts will probably work
with C++ 2003 but no tested." are also useful).

Using BOOST_STATIC_ASSERT_MSG at the right places is really helpful too.
 

> Outcome is up for review here end of May.
>
> Are you happy with its compiler support at
> https://ned14.github.io/boost.outcome/prerequisites.html? To save people
> clicking on the link:
>
> "Outcome is a header only C++ 14 library known to work on these
> compilers or better:
>
> clang 3.5 (LLVM)
> clang 3.7 (with Microsoft Codegen)
> GCC 5.4
> VS2015 Update 2
> Xcode 7.3
<snip>

Yes - just right.

Paul

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




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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Apr 10, 2017 at 9:04 AM, Niall Douglas via Boost
<[hidden email]> wrote:
> Warning: MSVC generates significant code bloat when using Outcome in
> large code bases. If you can use VS2017 which implements C++ 14
> constexpr and has a better optimiser for modern C++, you will see tigher
> executables. Execution speed is not particularly different, though one
> would have thought the extra cache load caused by code bloat might
> affect some applications. In this situation, use LLVM clang targeting

What situation? VS2015?

> the MSVC ABI."



--
Olaf

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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Apr 9, 2017 at 10:24 PM, Edward Diener via Boost <
[hidden email]> wrote:

> I would like to ask people who present new libraries to Boost, in whatever
> stages they are, to please specify in the documentation to the library
> and/or in messages regarding the library, what level of C++ compliance is
> needed to use the functionality of that library. This plea is not being
> directed at any particular current library being mentioned by anyone on the
> mailing list, but is a general plea regarding developers and their efforts.
>
> I realize it is a real pain that C++ as a language, and as it continues to
> evolve, has a number of popular levels of C++ compliance. This is largely
> because C++ is offered by a number of different vendors in a number of
> different supported releases, each particular implementation supporting a
> number of levels of C++ compliance and sometimes only partially supporting
> a particular level of C++ compliance. But given this sometimes difficult
> situation I do not see it as enough for library docs/information to simply
> say "this library supports some-vendor/some-release" because this is
> actually fairly meaningless to me when I know that
> "some-vendor/some-release" supports a number of levels of C++ compliance
> through some compiler parameter ( often -std=something ). Therefore
> docs/information of "the library supports "some-implementation" or "the
> library is compliant with "more than one level of C++ compliance" tells me
> as much as if some one told me that the moon is yellow. So I am begging,
> pleading, entreating library authors to be specific about the C++ features
> or the C++ level of compliance needed to use their library, even if it is
> just a one-liner that succinctly explains what the end-user needs to know.
>
> Furthermore, for any given library could we please have specific
> information about what will happen if I use the library, or some feature of
> the library, without the desired minimum level of C++ compliance. While I
> would assume compile-time compiler errors as the norm another possibility,
> especially given the excellent support in Boost Config to compiler
> conformance, are more readable preprocessor errors. Finally a library might
> offer some level of advanced C++ compliance but fall back to a lower level
> if possible.
>
> Please, please library authors this is important. No end-user or tester of
> your library wants to spend extended time trying to figure out why some
> compile fails when the answer turns out simply to be one of inadequate C++
> conformance level for a particular compiler implementation being used with
> a particular level of conformance.
>
>
+1

The requirements described above need to be added to the
http://www.boost.org/development/requirements.html hierarchy, too.

--Beman

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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Apr 10, 2017 at 3:04 AM, Niall Douglas via Boost <
[hidden email]> wrote:

clang 3.5 (LLVM)
> clang 3.7 (with Microsoft Codegen)
> GCC 5.4
> VS2015 Update 2
> Xcode 7.3
>

That's good, but as Edward pointed out knowing what values of -std= (or
equivalent) are required is also needed. If the -std= default is
acceptable, that should be mentioned too.

Thanks,

--Beman

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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/04/2017 10:09, Olaf van der Spek wrote:

> On Mon, Apr 10, 2017 at 9:04 AM, Niall Douglas via Boost
> <[hidden email]> wrote:
>> Warning: MSVC generates significant code bloat when using Outcome in
>> large code bases. If you can use VS2017 which implements C++ 14
>> constexpr and has a better optimiser for modern C++, you will see tigher
>> executables. Execution speed is not particularly different, though one
>> would have thought the extra cache load caused by code bloat might
>> affect some applications. In this situation, use LLVM clang targeting
>
> What situation? VS2015?
>
>> the MSVC ABI."

Note the phrase "Warning: **MSVC** generates significant ..."

Note the earlier mention that VS2015 Update 2 or later is known to work.
This implies VS2015 Update 1 or earlier does not.

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
|  
Report Content as Inappropriate

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>     clang 3.5 (LLVM)
>     clang 3.7 (with Microsoft Codegen)
>     GCC 5.4
>     VS2015 Update 2
>     Xcode 7.3
>
> That's good, but as Edward pointed out knowing what values of -std= (or
> equivalent) are required is also needed. If the -std= default is
> acceptable, that should be mentioned too.

If a library clearly states at the top that it is a C++ 14 library, I'd
think it obvious to start with -std=c++14 for older compilers needing
that if you're manually configuring its usage. You've already documented
it's a C++ 14 library.

I don't think the documentation should suggest compiler flags as these
vary between compilers and platforms and versions of the compiler and
downstream use case. Besides, for anyone using cmake it is taken care
for you anyway as cmake abstracts that nitty gritty away.

BTW Outcome does compiler feature detection and complains loudly with
useful error messages if you try using it on a compiler without
sufficient C++ 14 features. Outcome also tells cmake what compiler
features it needs. If it is accepted, it will tell Boost.Build the
compiler features needed too.

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
|  
Report Content as Inappropriate

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 4/10/2017 7:15 AM, Beman Dawes via Boost wrote:

> On Mon, Apr 10, 2017 at 3:04 AM, Niall Douglas via Boost <
> [hidden email]> wrote:
>
> clang 3.5 (LLVM)
>> clang 3.7 (with Microsoft Codegen)
>> GCC 5.4
>> VS2015 Update 2
>> Xcode 7.3
>>
>
> That's good, but as Edward pointed out knowing what values of -std= (or
> equivalent) are required is also needed. If the -std= default is
> acceptable, that should be mentioned too.

The -std= default changes with each compiler/version so that is not
necessary IMO for library authors to know or say. Niall mentioned C++14
so that is what is useful when someone says what their library needs.
How C++14 translates to std= should be part of what the end-user should
know when he uses a library with different compiler/versions. For
instance my own particular setup for testing Boost libraries with Boost
Build translates "c14" at the end of my own toolset "names" to the
particular 'std=" switch for different compiler/versions I use for C++14
support. While this is usually "std=c++14" it does not have to be that,
as sometimes something else works instead, such as "std=c++1y". Of
course some compilers, aka VC++, can not be adjusted in such a way, so
that it is also important for the end-user himself to know what level of
compliance a particular compiler supports.

I am far more concerned that library authors just state clearly what
level of C++ compliance is needed to use their library and/or what level
of C++ compliance is needed to use certain features of their library if
those features differ from the general level. Of course stating what
particular C++ construct support is needed, over and above basic
C++1998/2003 support, also is helpful.

As a side note I would really like to see libraries, which are tailored
for Boost, use the Boost Config C++ feature testing macros to put out
preprocessor #error messages when a feature that it needs is not
supported during compilation, rather than letting the compiler simply
fail because the construct in code cannot be parsed at the C++
conformance level the code expects. I even note that a number of our
current libraries do not do this, but should. It is much more
understandable to get a preprocessor #error message specific to the C++
feature needed in such cases, than to get a nest of difficult to
decipher compile failures for particular constructs.


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

Re: Libraries and C++ compliance

Boost - Dev mailing list

> On Apr 10, 2017, at 9:05 AM, Edward Diener via Boost <[hidden email]> wrote:
>
>
> As a side note I would really like to see libraries, which are tailored for Boost, use the Boost Config C++ feature testing macros to put out preprocessor #error messages when a feature that it needs is not supported during compilation, rather than letting the compiler simply fail because the construct in code cannot be parsed at the C++ conformance level the code expects.

This should happen during configure step, so that the user gets an error before even building the library.

Paul


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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> course some compilers, aka VC++, can not be adjusted in such a way, so
> that it is also important for the end-user himself to know what level of
> compliance a particular compiler supports.

The newer MSVC's now have a /std: switch. You'll be glad to know it
doesn't follow the same semantics as -std= because well, it's Microsoft.

cmake 3.8 does not appear to understand the MSVC /std: switch yet
because if you ask it for the C++ 17 standard when targeting MSVC, it pukes.

> As a side note I would really like to see libraries, which are tailored
> for Boost, use the Boost Config C++ feature testing macros to put out
> preprocessor #error messages when a feature that it needs is not
> supported during compilation, rather than letting the compiler simply
> fail because the construct in code cannot be parsed at the C++
> conformance level the code expects. I even note that a number of our
> current libraries do not do this, but should. It is much more
> understandable to get a preprocessor #error message specific to the C++
> feature needed in such cases, than to get a nest of difficult to
> decipher compile failures for particular constructs.

Most of the compilers released during the last two years have varying
support for C++17 feature test macros (VS2017 is very compliant here
interestingly). If your library has no dependency on Boost, use those.

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
|  
Report Content as Inappropriate

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> As a side note I would really like to see libraries, which are
>> tailored for Boost, use the Boost Config C++ feature testing macros
>> to put out preprocessor #error messages when a feature that it
>> needs is not supported during compilation, rather than letting the
>> compiler simply fail because the construct in code cannot be parsed
>> at the C++ conformance level the code expects.
>
> This should happen during configure step, so that the user gets an
> error before even building the library.

A library's headers may have much lower demands on the C++ version than
the source code.

So your headers should still do feature checking and #error out.

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
|  
Report Content as Inappropriate

Re: Libraries and C++ compliance

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

On 04/10/2017 08:35 AM, Paul Fultz II via Boost wrote:
>
>> On Apr 10, 2017, at 9:05 AM, Edward Diener via Boost <[hidden email]> wrote:
>>
>>
>> As a side note I would really like to see libraries, which are tailored for Boost, use the Boost Config C++ feature testing macros to put out preprocessor #error messages when a feature that it needs is not supported during compilation, rather than letting the compiler simply fail because the construct in code cannot be parsed at the C++ conformance level the code expects.
>
> This should happen during configure step, so that the user gets an error before even building the library.
>

  That works for libraries that have a configure
step, which is not most Boost libraries.

In Christ,
Steven Watanabe


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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Apr 10, 2017 at 7:54 AM, Niall Douglas via Boost
<[hidden email]> wrote:
> So your headers should still do feature checking and #error out.

Beast is supposed to only require C++11. But I expect full support for
C++11. So Visual Studio 2015 with anything less than Update 3 is not
going to build correctly. I would love to check for specific updates,
but I cannot find any Microsoft documentation on _MSC_VER or
_MSC_FULL_VER that distinguishes between updates.

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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 4/10/2017 10:35 AM, Paul Fultz II via Boost wrote:
>
>> On Apr 10, 2017, at 9:05 AM, Edward Diener via Boost <[hidden email]> wrote:
>>
>>
>> As a side note I would really like to see libraries, which are tailored for Boost, use the Boost Config C++ feature testing macros to put out preprocessor #error messages when a feature that it needs is not supported during compilation, rather than letting the compiler simply fail because the construct in code cannot be parsed at the C++ conformance level the code expects.
>
> This should happen during configure step, so that the user gets an error before even building the library.

There is no "building the library" for header-only libraries in Boost.
For non-header only libraries it is possible to use Boost Config's Build
Time Configuration to determine whether or not the library can be built
at all.

I believe it should be possible to design a Boost Build jam file
configuration facility, based on the check-target-builds rule, so that a
Boost Build error is generated when the Boost Config C++ feature testing
macros indicate the level of C++ compliance needed by a library is not
met, but nobody has done that yet AFAIK.


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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 4/10/2017 10:53 AM, Niall Douglas via Boost wrote:
>> course some compilers, aka VC++, can not be adjusted in such a way, so
>> that it is also important for the end-user himself to know what level of
>> compliance a particular compiler supports.
>
> The newer MSVC's now have a /std: switch. You'll be glad to know it
> doesn't follow the same semantics as -std= because well, it's Microsoft.

The new MSVC remains completely undocumented more than one month after
it has been released, so whatever /std: switch it does have is guesswork
AFAICS. But yes, if the new MSVC has such a switch it is an advance over
the previous versions which just offered a single level of C++
compliance, whatever it was, which the end-user had to understand exactly.

>
> cmake 3.8 does not appear to understand the MSVC /std: switch yet
> because if you ask it for the C++ 17 standard when targeting MSVC, it pukes.
>
>> As a side note I would really like to see libraries, which are tailored
>> for Boost, use the Boost Config C++ feature testing macros to put out
>> preprocessor #error messages when a feature that it needs is not
>> supported during compilation, rather than letting the compiler simply
>> fail because the construct in code cannot be parsed at the C++
>> conformance level the code expects. I even note that a number of our
>> current libraries do not do this, but should. It is much more
>> understandable to get a preprocessor #error message specific to the C++
>> feature needed in such cases, than to get a nest of difficult to
>> decipher compile failures for particular constructs.
>
> Most of the compilers released during the last two years have varying
> support for C++17 feature test macros (VS2017 is very compliant here
> interestingly). If your library has no dependency on Boost, use those.
>
> Niall
>



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

Re: Libraries and C++ compliance

Boost - Dev mailing list
On 11/04/2017 04:57, Edward Diener via Boost wrote:
> On 4/10/2017 10:53 AM, Niall Douglas via Boost wrote:
>> The newer MSVC's now have a /std: switch. You'll be glad to know it
>> doesn't follow the same semantics as -std= because well, it's Microsoft.
>
> The new MSVC remains completely undocumented more than one month after
> it has been released, so whatever /std: switch it does have is guesswork
> AFAICS. But yes, if the new MSVC has such a switch it is an advance over
> the previous versions which just offered a single level of C++
> compliance, whatever it was, which the end-user had to understand exactly.

There's an official blog post about it:
 
https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/

And it's documented in the new doc wiki site (although the search is
atrociously bad, so you can't find it unless you already know what
you're looking for and even then have to navigate through several side
paths before you can get to it):
 
https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version



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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Apr 10, 2017 at 3:20 PM, Niall Douglas via Boost
<[hidden email]> wrote:

> On 10/04/2017 10:09, Olaf van der Spek wrote:
>> On Mon, Apr 10, 2017 at 9:04 AM, Niall Douglas via Boost
>> <[hidden email]> wrote:
>>> Warning: MSVC generates significant code bloat when using Outcome in
>>> large code bases. If you can use VS2017 which implements C++ 14
>>> constexpr and has a better optimiser for modern C++, you will see tigher
>>> executables. Execution speed is not particularly different, though one
>>> would have thought the extra cache load caused by code bloat might
>>> affect some applications. In this situation, use LLVM clang targeting
>>
>> What situation? VS2015?
>>
>>> the MSVC ABI."
>
> Note the phrase "Warning: **MSVC** generates significant ..."
>
> Note the earlier mention that VS2015 Update 2 or later is known to work.
> This implies VS2015 Update 1 or earlier does not.

Does it not work at all or does it do bloated code?

> VS2017 which implements C++ 14
> constexpr and has a better optimiser for modern C++, you will see tigher
> executables.

This bit makes it sound VS2017 is required to avoid the code bloat.


--
Olaf

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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 04/11/17 02:24, Gavin Lambert via Boost wrote:

> On 11/04/2017 04:57, Edward Diener via Boost wrote:
>> On 4/10/2017 10:53 AM, Niall Douglas via Boost wrote:
>>> The newer MSVC's now have a /std: switch. You'll be glad to know it
>>> doesn't follow the same semantics as -std= because well, it's Microsoft.
>>
>> The new MSVC remains completely undocumented more than one month after
>> it has been released, so whatever /std: switch it does have is guesswork
>> AFAICS. But yes, if the new MSVC has such a switch it is an advance over
>> the previous versions which just offered a single level of C++
>> compliance, whatever it was, which the end-user had to understand
>> exactly.
>
> There's an official blog post about it:
>
> https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/

Blog is not documentation. One should not be required to follow blogs or
other social media to know how to use a compiler.


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

Re: Libraries and C++ compliance

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 4/10/2017 7:24 PM, Gavin Lambert via Boost wrote:

> On 11/04/2017 04:57, Edward Diener via Boost wrote:
>> On 4/10/2017 10:53 AM, Niall Douglas via Boost wrote:
>>> The newer MSVC's now have a /std: switch. You'll be glad to know it
>>> doesn't follow the same semantics as -std= because well, it's Microsoft.
>>
>> The new MSVC remains completely undocumented more than one month after
>> it has been released, so whatever /std: switch it does have is guesswork
>> AFAICS. But yes, if the new MSVC has such a switch it is an advance over
>> the previous versions which just offered a single level of C++
>> compliance, whatever it was, which the end-user had to understand
>> exactly.
>
> There's an official blog post about it:
>
> https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/ 
>
>
> And it's documented in the new doc wiki site (although the search is
> atrociously bad, so you can't find it unless you already know what
> you're looking for and even then have to navigate through several side
> paths before you can get to it):
>
> https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version

It seems as if Microsoft has now decided to put their documentation
online, but not currently viewable locally as help topics. Thanks for
alerting me to this. Online docs are certainly better than no docs, even
if the TOC, Index and Search are much worse, if not non-existent, online.


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