C++ 0x and C++

[max-divulskiy]

For c++ I can use

[bash]#ifdef _cplusplus
#endif[/bash]

Please tell me how to properly called directive for c++ 0x. Use this dirictive I want distinguish c++ code and c++ 0x.

[Aubrey_W_]

Hello muved,

I'll move this thread to the main Intel C++ Compiler forum where one of our Technical Consulting Engineers can answer it.

Best regards,

==
Aubrey W.
Intel Software Network Support

[Judith_W_Intel · Accepted solution]

__cplusplus

In C++0x the macro __cplusplus will be set to a value that differs from (is greater than) the current 199711L.

Since this value is not available yet, the Intel compiler and all other compilers still use 199711L even in c++0x mode.

[Marián__VooDooMan__M]

Judith Ward (Intel) wrote:

__cplusplus

In C++0x the macro __cplusplus will be set to a value that differs from (is greater than) the current 199711L.

Since this value is not available yet, the Intel compiler and all other compilers still use 199711L even in c++0x mode.

I am using MSVC 2013 and ICC 14 SP1 Update 2. I need to check for C++11. ICC should define macro __cplusplus to higher value than 199711L.

I'm stuck to code such as

#if defined(__INTEL_COMPILER) && (__INTEL_COMPILER >= 1400)

in order to use code for c++11 which (partially) ICC exploits.

Take this as a suggestion to future ICC. It is my wish. I don't mind for compatibility with MSVC, IMHO ICC should be more featured of contemporary standards than MSVC 2013, as an extension to MSVC, but with incompatibility with MSVC. C++10 features are for me more important than compatibility with MSVC. And I don't think I'm the only one.

[TimP]

The typical problem is that setting the newer date in the macro implies full compliance with the new standard, but there is no recognized way to signal an intermediate version.  I'll admit that the configure hackery (e.g. autoconfig) used to overcome this is not friendly to application development or something I have the motivation to begin to understand.

icc has the dilemma of needing to incorporate both partial c++11 implementations from Microsoft and from g++, and working with major linux distros which choose various versions of the latter.

I was a little surprised by the answer about attempting to support -std=c++0x when I thought icc had followed the lead taken by g++ to use -std=c++11 in current releases (requiring, on linux, a g++ new enough to reflect that change, and also with issues on Windows regarding various Visual Studio versions).

[Marián__VooDooMan__M]

Tim Prince wrote:

The typical problem is that setting the newer date in the macro implies full compliance with the new standard, but there is no recognized way to signal an intermediate version.  I'll admit that the configure hackery (e.g. autoconfig) used to overcome this is not friendly to application development or something I have the motivation to begin to understand.

icc has the dilemma of needing to incorporate both partial c++11 implementations from Microsoft and from g++, and working with major linux distros which choose various versions of the latter.

I was a little surprised by the answer about attempting to support -std=c++0x when I thought icc had followed the lead taken by g++ to use -std=c++11 in current releases (requiring, on linux, a g++ new enough to reflect that change, and also with issues on Windows regarding various Visual Studio versions).

I absolutely agree. Incomplete implementation of C++11 cannot modify __cplusplus value of this built-in macro. But there should be some way to check by compile-time awareness of supported functionality like "constexpr" or "= delete" or "final" new keywords in C++11.

I cannot use "autoconf" Unices tool, since I am working on MSVC (2013) project only.

[Judith_W_Intel]

>> But there should be some way to check by compile-time awareness of supported functionality like "constexpr" or "= delete" or "final" new >> keywords in C++11.

This is when the proposed feature macros will come in handy, see:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3694.htm

Unfortunately these are still a work in progress.