-std=c++17 vs -std=c++1y

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

-std=c++17 vs -std=c++1y

Andrew Brownsword
Hi,

Is there a way to get cmake 3.11 to emit 17 vs 1y when setting CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to use the value of the preprocessor define __cplusplus (which is a date), and the value differs depending on whether 17 or 1y is used (at least with CLang).  I haven’t figured out how to get cmake to emit -std=c++17, it always seems to use 1y, which is causing problems with code that assumes the __cplusplus date reflects the c++17 standardization date.

Thanks,
   Andrew

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: -std=c++17 vs -std=c++1y

Rolf Eike Beer
Am Sonntag, 6. Mai 2018, 08:00:14 schrieb Andrew Brownsword:
> Hi,
>
> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting
> CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to
> use the value of the preprocessor define __cplusplus (which is a date), and
> the value differs depending on whether 17 or 1y is used (at least with
> CLang).  I haven’t figured out how to get cmake to emit -std=c++17, it
> always seems to use 1y, which is causing problems with code that assumes
> the __cplusplus date reflects the c++17 standardization date.

My bet is: that code is wrong. For every compiler I have seen the rules have
been:

-std=c++AA is used as long as the standard is not fixed

-afterwards std=c++YY is introduced, and -std=c++AA is an alias for that

So it does not matter which flag you use when the compiler supports both, but
you can't of course properly test on the value of __cplusplus in older
compilers because you don't know in which year/month the standard will be
released.

Eike
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: -std=c++17 vs -std=c++1y

Jean-Michaël Celerier
In reply to this post by Andrew Brownsword
Note that c++17 is c++1z. c++1y was C++14.



-------
Jean-Michaël Celerier

On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword <[hidden email]> wrote:
Hi,

Is there a way to get cmake 3.11 to emit 17 vs 1y when setting CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to use the value of the preprocessor define __cplusplus (which is a date), and the value differs depending on whether 17 or 1y is used (at least with CLang).  I haven’t figured out how to get cmake to emit -std=c++17, it always seems to use 1y, which is causing problems with code that assumes the __cplusplus date reflects the c++17 standardization date.

Thanks,
   Andrew

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: -std=c++17 vs -std=c++1y

Andrew Brownsword
Well, I am specifying:

set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_EXTENSIONS ON)

and the compiler line contains “-std=gnu++1y”.  I’m using a very recent source build of CLang and libc++.  Any idea why cmake would fall back to 1y in this case?





On May 6, 2018, at 9:05 AM, Jean-Michaël Celerier <[hidden email]> wrote:

Note that c++17 is c++1z. c++1y was C++14.



-------
Jean-Michaël Celerier

On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword <[hidden email]> wrote:
Hi,

Is there a way to get cmake 3.11 to emit 17 vs 1y when setting CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to use the value of the preprocessor define __cplusplus (which is a date), and the value differs depending on whether 17 or 1y is used (at least with CLang).  I haven’t figured out how to get cmake to emit -std=c++17, it always seems to use 1y, which is causing problems with code that assumes the __cplusplus date reflects the c++17 standardization date.

Thanks,
   Andrew

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: -std=c++17 vs -std=c++1y

Robert Maynard
If you have standard required enabled the compiler version shouldn't decay
down to 14 when asking for 17.

I recommend having a small test repo and using cmake --trace/--trace-expand
to determine where the gnu++1y is coming from. It is not clear when looking
at Modules/Compiler/Clang-CXX.cmake how gnu++1y would be used unless CMake
is thinking you are asking for C++14 on clang 3.5.
On Sun, May 6, 2018 at 1:35 PM Andrew Brownsword <
[hidden email]> wrote:

> Well, I am specifying:

> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> set(CMAKE_CXX_STANDARD 17)
> set(CMAKE_CXX_EXTENSIONS ON)

> and the compiler line contains “-std=gnu++1y”.  I’m using a very recent
source build of CLang and libc++.  Any idea why cmake would fall back to 1y
in this case?





> On May 6, 2018, at 9:05 AM, Jean-Michaël Celerier <
[hidden email]> wrote:

> Note that c++17 is c++1z. c++1y was C++14.



> -------
> Jean-Michaël Celerier
> http://www.jcelerier.name

> On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword <
[hidden email]> wrote:

>> Hi,

>> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting
CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to
use the value of the preprocessor define __cplusplus (which is a date), and
the value differs depending on whether 17 or 1y is used (at least with
CLang).  I haven’t figured out how to get cmake to emit -std=c++17, it
always seems to use 1y, which is causing problems with code that assumes
the __cplusplus date reflects the c++17 standardization date.

>> Thanks,
>>     Andrew

>> --

>> Powered by www.kitware.com

>> Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

>> Kitware offers various services to support the CMake community. For more
information on each offering, please visit:

>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html

>> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake



> --

> Powered by www.kitware.com

> Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

> Kitware offers various services to support the CMake community. For more
information on each offering, please visit:

> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html

> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake