Are there preprocessor macros defined in the gcc and g++ compilers so that if I want to make my C code link to the C standard library or the C++ standard library? Something like:
someFile.c
#ifdef __CPP__
#include <c++ library include>
#else
#include <c library include>
I'm sure there are but a quick Google search didn't point me to right away and I'm sure someone is going to just post duplicate question, but in any case, please point me in the right direction.
In c++ you can you
#ifdef __cplusplus
eg if c++ code you want certain piece of code to be handled by compiler as c code you need to put that block in
#ifdef __cplusplus
extern "C" {
#endif
#ifdef __cplusplus
}
#endif
I'm not sure if there are #defines specific to GCC, but the C++ standard defines the symbol __cplusplus. If that exists, then you are on a C++ compiler.
As pointed out by the other answers, testing for the definition of the __cplusplus predefined macro will work:
__cplusplus denotes the version of C++ standard that is being used, expands to
value 199711L (until C++11), 201103L (C++11), 201402L (C++14), or
201703L (C++17).
There is also a GCC specific macro which may be useful to you, __GNUG__. As outlined in the GCC documentation:
__GNUG__
The GNU C++ compiler defines this. Testing it is equivalent to testing
(__GNUC__ && __cplusplus).
The linked GCC documentation also lists other macros defined by the different GNU compilers.
In 6.10.8 Predefined macro names the C11 standard says (emphasis mine)
The implementation shall not predefine the macro __cplusplus, nor shall it define it in any standard header.
I believe C++ mandates a conforming implementation to define that name, so you can use it to differentiate languages
#ifdef __cplusplus
/* c++ code */
#else
/* c code */
#endif
Related
I've got a .h file that is included by both C and C++ source files. Its contents is wrapped in
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
Yet, when I include it in a .cpp file, clang-tidy issues C++-specific messages, like
warning: including 'stdbool.h' has no effect in C++; consider removing it [hicpp-deprecated-headers,modernize-deprecated-headers]
warning: inclusion of deprecated C++ header 'stdlib.h'; consider using 'cstdlib' instead [hicpp-deprecated-headers,modernize-deprecated-headers]
warning: use 'using' instead of 'typedef' [modernize-use-using]
I like these checks and I want to keep them active in my clang-tidy configuration, but of course for C++ code only. I can't change the header file to use using instead of typedef or <cstdlib> instead of <stdlib.h> because it's also included by C sources, hence the extern "C".
Is there any way to tell clang-tidy to treat code in extern "C" as C instead of C++, even if included from a .cpp file?
The clang-tidy version is 12.0.0.
Clang-Tidy can make use of the special NOLINT or NOLINTNEXTLINE comments to suppress warning of specific lines. It is intended exactly for your use case:
some lines contains legacy or not stricly nice C++ code
there is a good reason to do so - here the code has to be parseable by a C compiler.
The higher risk when using that is to abuse it and silence warnings where it would have be possible to improve the coding. But when you need a header to be used form both C and C++ sources, and you have carefully twice read the NOLINTed line, it is perfectly fine, at least IMHO. Furthermore, it is even possible to indicate the warnings to silence:
#ifdef __cplusplus
extern "C" {
#endif
// NOLINTNEXTLINE(hicpp-deprecated-headers,modernize-deprecated-headers) C compatible code
#include <stdbool.h>
#include <stdlib.h> // NOLINT C code requires that header
...
#ifdef __cplusplus
}
#endif
Those C and C++ headers strictly aren't equivalent for C++. Those warninggs are legal and indication of code non-compliant to C++ standard.
extern "C" only declares linkage type of declared functions and variables as global and without mangling, names are used in C format. It cannot affect object and functions that are declared with C++ features use. It have nothing to do with language's ecosystem. More of, if a C++ header appear inside those brackets, there may appear linking errors if a function declared there was originally in C++ linkage.
For C++ you have to use #ifdef __cplusplus to include C++ alternatives, including C ones otherwise.
Instead of:
#ifdef __cplusplus
extern "C" {
#endif
#include <stdbool.h>
#include <stdlib.h>
// your declarations
#ifdef __cplusplus
}
#endif
You would have a header with following structure
// headers that are universally compatible (3rd party)
#ifdef __cplusplus
# include <cstdlib>
// other C++ headers
// Your C++ - only declarations (incompatible with C rules)
extern "C" {
#else
# include <stdbool.h>
# include <stdlib.h>
// other C headers
// C-only declarations (incompatible with C++ rules)
#endif
// your compatible declarations available for both
#ifdef __cplusplus
} // extern "C"
#endif
In some cases this structure would need to be adjusted because of required order of header inclusion or declarations's dependency. Blindly changing linkage of declarations in library headers you didn't write and you cannot guarantee what naming conventions and linkage type those use is a faux pas that can result in ODR breach or linking failures.
The typedef issue is annoying and you can use NOLINT or command-line option to suppress modernize-use-using as an interim measure. In general for portable header this would be done by macro-definitions at least for struct types. There is a problem where typedef and alias declaration aren't convertible in some case by standard means, e.g. consider a declaration of function pointer type.
c++ compiler could compile code like this, and it executed correctly
#include <stdio.h>
int main() {
printf("test...\n");
return 0;
}
I think printf.c will be compiled to printf.o with c compiler, I just checked the stdio.h, there is no extern "C" keyword, then how could c++ linker link printf in printf.o which is compiled with c compiler?(By the way, my platform is ubuntu 14.04, compiler is gcc 4.8.4)
printf is part of the C++ standard library.
The <stdio.h> header that you include in the C++ source, belongs to the C++ standard library, and is not necessarily the same contents as a C compiler will include.
How the C++ implementation leverages the corresponding C implementation (if at all) is an implementation detail.
When C++ was originally made it was effectively a superset of C. That is to say, you can code perfectly good C in the C++ environment, just by ignoring all of the features that C++ adds. That, and because nowadays most C compilers are C++ compilers in which you can code C, is why you can use printf.
Secondly, no object code is generated for stdio because it is already a library, and so you are linking your own .o code against the already compiled stdio library code, which will be located somewhere in your compilers directory.
Nobody can give you a definitive answer without knowing what implementation you're using.
Cheers and hth. - Alf gave one possibility, which is that the stdio.h that is included by a C++ program may not be the same as the stdio.h that is included by a C program. Another possibility is that it is the same header, and there is an extern "C" block, and you just can't see it. For example, I use gcc, and my /usr/include/stdio.h contains a __BEGIN_DECLS macro, which expands to extern "C" { when compiled as C++. See Do I need an extern "C" block to include standard C headers?
You may not see an explicit extern "C" in stdio.h, but it is there. It's just hiding.
For example, on Linux, in stdio.h we see this:
#include <features.h>
__BEGIN_DECLS
In <features.h> you will find the following:
# ifndef _SYS_CDEFS_H
# include <sys/cdefs.h>
# endif
And in <sys/cdefs.h> you finally see:
#ifdef __cplusplus
# define __BEGIN_DECLS extern "C" {
# define __END_DECLS }
#else
# define __BEGIN_DECLS
# define __END_DECLS
#endif
So, via a fairly roundabout path, Linux header files have a __BEGIN_DECLS/__END_DECLS wrapper which, when compiled by a C++ compiler, end up wrapping the whole thing inside extern "C".
My question is mainly about the fact that a C++ toolchain "understands" both C and C++, so if I feed some code with an extern "C" to a c++ toolchain I assume it can understand what to do with that; but what if I feed code with extern "C++" to a C toolchain ?
What is the expected behaviour ?
If the compiler ALSO understands C++, it may accept it. If it's a pure C compiler it will object (just like it will on extern "C" as that syntax is not valid C - this is why it's typically enclosed with #ifdef __cplusplus or some such)
It is supposed to not compile, it is not valid C syntax.
The standard approach to make C declarations in a header file work both in a C and C++ compiler is to rely on a preprocessor symbol that's only defined in a C++ compiler. Like this:
#ifdef __cplusplus
extern "C" {
#endif
// C declarations here
// ...
#ifdef __cplusplus
}
#endif
Every C++ compiler defines __cplusplus.
extern "C++" is not valid C code, so a conforming C compiler must issue a diagnostic. There is no requirement that it not compile the code. Having issued a diagnostic, the compiler is free to do whatever its implementor decided was appropriate.
If you wrote some other compiler with such option you can do this.
As answered by #Mats we have another procedure to achieve this is #ifdef __cplusplus.
Moreover what you are trying is error only.
How do I use FTGL's C API from C++ code in Visual Studio 2010?
FTGL uses #ifdef __cplusplus checks to export C and C++ APIs from the same header files.
I tried this:
#ifdef __cplusplus
#undef __cplusplus
#include <FTGL/ftgl.h>
#define __cplusplus
#else
#include <FTGL/ftgl.h>
#endif
But VS2010 isn't having it:
warning C4117: macro name '__cplusplus' is reserved, '#undef' ignored
warning C4117: macro name '__cplusplus' is reserved, '#define' ignored
The macro __cplusplus is a reserved macro, and should be defined automatically by your compiler if you're compiling as C++ code (and not defined otherwise). You shouldn't have to #define it manually, and that's why your compiler throws an error.
How do I use FTGL's C API from C++ code in Visual Studio 2010?
You don't.
The makers of FTGL apparently don't want C++ users to use the C API. So they don't let them.
The __cplusplus macro is a part of the C++ language; it cannot be undefined. Or defined. Or redefined. And since that's what FTGL keys off of, there's no way to trick it into compliance.
The only way to avoid this is to edit FTGL itself.
Just a small question:
Can C++ use C header files in a program?
This might be a weird question, basically I need to use the source code from other program (made in C language) in a C++ one. Is there any difference between both header files in general? Maybe if I change some libraries...
I hope you can help me.
Yes, you can include C headers in C++ code. It's normal to add this:
#ifdef __cplusplus
extern "C"
{
#endif
// C header here
#ifdef __cplusplus
}
#endif
so that the C++ compiler knows that function declarations etc. should be treated as C and not C++.
If you are compiling the C code together, as part of your project, with your C++ code, you should just need to include the header files as per usual, and use the C++ compiler mode to compile the code - however, some C code won't compile "cleanly" with a C++ compiler (e.g. use of malloc will need casting).
If on, the other hand, you have a library or some other code that isn't part of your project, then you do need to make sure the headers are marked as extern "C", otherwise C++ naming convention for the compiled names of functions will apply, which won't match the naming convention used by the C compiler.
There are two options here, either you edit the header file itself, adding
#ifdef __cplusplus
extern "C" {
#endif
... original content of headerfile goes here.
#ifdef __cplusplus
}
#endif
Or, if you haven't got the possibility to edit those headers, you can use this form:
#ifdef __cplusplus
extern "C" {
#endif
#include <c_header.h>
#ifdef __cplusplus
}
#endif
Yes, but you need to tell the C++ compiler that the declarations from the header are C:
extern "C" {
#include "c-header.h"
}
Many C headers have these included already, wrapped in #if defined __cplusplus. That is arguably a bit weird (C++ syntax in a C header) but it's often done for convenience.