Can __cplusplus ever be defined and equal to zero? [duplicate] - c++

This question already has answers here:
How are the __cplusplus directive defined in various compilers?
(4 answers)
Closed 5 years ago.
The question came up of whether one should wrap extern "C" using #if or #ifdef. i.e.:
#if __cplusplus
extern "C" {
#endif
or
#ifdef __cplusplus
extern "C" {
#endif
Which begs the question: is there ever a situation where __cplusplus is defined to be equal to zero?

According to the standard, the __cplusplus macro must be defined, the exact definition depends on the C++ standard being used but it will not be zero.
For example, for C++11 it must be 201103L, with the note "It is intended that future versions of this standard will replace the value of this macro with a greater value."
Historically, in some ancient non-conforming compilers you could probably dig up, __cplusplus was defined to 0 to indicate non-conformance with the standard. This is only of historical interest.
See: How are the __cplusplus directive defined in various compilers?

Related

__cplusplus expanded minimum values

Am I right to understand that these are the minimum values of __cplusplus and that C++98 has the same value has C++03?
// C++ 98
#define __cplusplus 199711L
// C++ 03
#define __cplusplus 199711L
// C++ 11
#define __cplusplus 201103L
// C++ 14
#define __cplusplus 201402L
// C++ 17
#define __cplusplus 201500L
// C++ 20
#define __cplusplus 201704L
// looks like the format is YEAR*100+something
Also, does C++20 have an official value now that the standard is released?
Also, does C++20 have an official value now that the standard is released?
It does: 202002L. The format here is a date: YYYYMM (C++20 was made official in February 2020). The value for C++17 was 201703L, not 201500. All the rest are correct (C++03 did not change the __cplusplus macro).
However, this macro is far too coarse to be generally useful. Implementations don't just add every feature in one go, they get added as time progresses. So you're better off using feature-test macros to test for what you actually need.

undefine and redefine the __cplusplus macro

I want to undefine and redefine the __cplusplus macro am getting however compilation error:__cplusplus was not declared in this scope
#define TEMP_VERSION __cplusplus // temporary macro to hold the __cplusplus containt
#undef __cplusplus
#define __cplusplus TEMP_VERSION // redefine __cplusplus
#define AA 111
#undef AA
#define AA 111
int main()
{
cout << "__cplusplus = "<<__cplusplus<<endl; // It doesn't work
cout << "AA = "<<AA<<endl; // It works
return 0;
}
Question 1: Why it is not working with the __cplusplus but works with AA
I know that this is really ugly but the reason why am undefining the macro is that I am using a third party Software where they are missusing the #ifdef __cplusplus, I mean the content of the #ifdef __cplusplus ... #endif is wrong. So instead of changing their software I choosed to do the following
#define TEMP_VERSION __cplusplus
#undef __cplusplus
#include <third_party_sw.h>
#define __cplusplus TEMP_VERSION
Question 2: What do you think is it a good approach ?
From the C++ standard ([cpp.predefined, 3-4]):
The values of the predefined macros (except for __FILE__ and __LINE__)
remain constant throughout the translation unit. If any of the
pre-defined macro names in this subclause, or the identifier defined,
is the subject of a #define or a #undef preprocessing directive, the
behavior is undefined.
In other words, the __cplusplus macro isn't just something that the compiler starts out by defining before handing control over to you; it is an immutable constant, which cannot be changed and is an error to attempt to change.
As for whether it would be a good approach if it were possible: Depends on the context, but probably not. These sorts of "fool the header" hacks (#define private public, anyone?) are seldom effective and never safe.
EDIT: Oh, also incidentally, even if you did have a macro it was legal to save/restore, that wouldn't be the right way to do it. See Can I redefine a C++ macro then define it back?.
Question 1: Why it is not working with the __cplusplus but works with AA
Because __cplusplus is a pre-defined macro, and behaviour of (un-)defining it is undefined:
stadard draft [cpp.predefined]
If any of the pre-defined macro names in this subclause, or the identifier defined, is the subject of a #define or a #undef preprocessing directive, the behavior is undefined. ...
AA is not a pre-defined macro, nor is the indentifier reserved. It is OK to (re-)define it.
Question 2: What do you think is it a good approach ?
(Re-)defining reserved identifiers is never a good approach. Even redefining user defined macros is a dubious proposition.
Ideal approach might be to fix the third party software, if possible. Alternatively, you could write a custom header for the software which doesn't have the problem.
It's because __cplusplus is pre-defined by the compiler.
Technically, it's the pre-processor that defines them, but depending on which compiler invokes the pre-processor, the output may differ. Try running this:
$ g++ -dM -E - </dev/null
The output is all the pre-processor defines that (in this case) the pre-processor run by this command produces.
Mind you __cplusplus does not appear there. It's built-in for every C++ compilation unit.
(The same works when substituting clang++ for g++.)

What does the "__cplusplus" macro expand to?

What does the C++ macro __cplusplus contain and expand to?
Does the macro __cplusplus always, even in oldest C++ implementation, contain and expand to a numeric value?
Is it safe to use #if __cplusplus
or should we use instead of that #ifdef __cplusplus?
Conclusion (added later)
From comments and accepted answer:
__cplusplus expands to a number representing the standard's version, except pre-standard C++ in the early 90s (which simply expanded to 1).
Yes, even in oldest C++ implementation (expands to a numeric value).
No, #ifdef should be used when header is shared with C-language (because some C-compilers will warn when #if checks undefined macro).
Yes, it always does expand to numeric value and its meaning is the version of C++ standard that is being used. According to cppreference page, __cplusplus macro should expand to:
199711L (until C++11),
201103L (C++11),
201402L (C++14),
201703L (C++17),
202002L (C++20)
The difference between #if and #ifdef directives is that #ifdef should be used to check whether given macro has been defined to allow a section of code to be compiled.
On the other hand #if (#else, #elif) directives can be used to check whether specified condition is met (just like typical if-condition).
__cplusplus is required to be defined by the C++ standard. For C++11 or higher __cplusplus > 199711L should hold true.
Does the macro __cplusplus always, even in oldest C++ implementation,
contain and expand to a numeric value?
Yes it does.
19.8 C++11
__cplusplus
The integer literal 201703L. [ Note: It is intended that future
versions of this International Standard will replace the value of this
macro with a greater value. — end note  ]
C++98
__cplusplus The name
_
_cplusplus is defined to the value 199711L when compiling a C
++ translation unit. 143)
Unfortunately, the __cplusplus macro has the value 199711 in MS Visual Studio 2022, regardless of the specified C++ standard. Use _MSVC_LANG instead. See VS comment.
This seems to work:
#if defined(_MSVC_LANG) // MS compiler has different __cplusplus value.
# if _MSVC_LANG < 201703
# error Please compile for C++17 or higher
# endif
#else // All other compilers.
# if __cplusplus < 201703
# error Please compile for C++17 or higher
# endif
#endif

extern "C", what is it useful for? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Combining C++ and C - how does #ifdef __cplusplus work?
I come across the following lines in many libraries; what are they good for? When/where is __cplusplus defined?
#ifdef __cplusplus
extern "C" {
#endif
//...
#ifdef __cplusplus
}
#endif
__cplusplus is defined for C++ code. It happens sometimes that you have to mix C code, and C++ code. There can be many reasons for that, e.g. you have a driver written long ago in C that you want to use in your brand new C++0x project.
Every function type and name has a language linkage. There's a difference between C adn C++ functions, since C does not have function names overloading, a function name can serve as a unique identifier in C, but can not in C++. This is called function mangling.
Since you don't need to mangle the name in C, using extern "C" will make the compiler omit adding the parameter information for linkage.
The C++ standard explicitly states in 7.5 para 3:
Every implementation shall provide for linkage to functions written in
the C programming language, "C", and linkage to C++ functions, "C++".
complex sqrt(complex); //C++ linkage by default
extern "C" {
double sqrt(double);//C linkage
}

How to trigger the __cplusplus (C++) #ifdef?

#ifdef __cplusplus
// C++ code
#else
// C code
#endif
The structure is this.
My question is, how to actually trigger the #ifdef on?
I mean, in program? What code I write can turn #ifdef on?
For example, in this case.
is that
#define __cplusplus
will turn it on?
"#define __cplusplus"
will let it on?
Yes, it will "let it on".
__cplusplus should be automatically defined by C++ compiler. C++ uses different name mangling and the macro often used to make C headers compatible with C++:
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
Just compile it with a C++ compiler and __cplusplus is defined automatically in that case.
The C++ Standard enforces that __cplusplus will always be defined in C++ programs. The C Standard obviously does not. This means that the user need go to no effort to enable this machinery.
A C++ compiler defines this automatically.
Since this starts with two consecutive underscores, it is reserved. You are not allowed to define it yourself (i.e., attempting to do so gives undefined behavior).