In my Ubuntu Netbeans 7.3 installation, I have a C++ project with C++11 marked as the standard in the C++ Compiler Options. When I try to include <chrono> it does not seem to make the std::chrono namespace available. When I open up this file to see what's wrong, I see everything greyed out but his first section:
#ifndef _GLIBCXX_CHRONO
#define _GLIBCXX_CHRONO 1
#pragma GCC system_header
#if __cplusplus < 201103L
# include <bits/c++0x_warning.h>
#else
When I hover over the __cplusplus constant, to see how it was defined, it says it's defined as 199711L. Why is this? I clearly set the project C++ Standard to C++11.
Go to Tools->Options
Select C/C++ menu
Select Code Assistance tab
Select C++ Compiler tab
In Macro Definitions list view, locate __cplusplus and change its value to 201103L
Click OK button
Related
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
I am working on a plugin in which I need to #include a header file (let's say some_file.h) which in turn includes environ.h. Now, when I build my plugin, the build fails with some errors in the environ.h file and some other dependent files. Here's a code sample from environ.h where the error is occurring:
#ifndef PLATFORM
#ifdef WIN_ENV
#define PLATFORM "winpltfm.h"
#elif __OS2__
#define PLATFORM "os2pltfm.h"
#elif defined(unix) || defined(__unix)
#define PLATFORM "UnixPlatform.h"
#else
#error You must define the PLATFORM macro <------- Error-1
#endif
#endif
#include PLATFORM <------- Error-2
The Error-1 is: #error you must define the platform macro and Error-2 is easy to guess: Expected <filename> or "filename".
The strange thing is that some other plugin where some_file.h is included works fine i.e. builds successfully. This made me think that there must be some build settings which might be different.
Can anyone suggest what should be done in such a case to remove the errors from the environ.h header file?
Note: I am working on MAC OS X in Xcode.
I continued my comments to this answer so it's easier to explain...
First, instead of #elif __OS2__ it should be #elif defined(__OS2__) that's why during your test #define __OS2__ didn't work, but #define __OS2__ 1 did.
EDIT: From your comments you noted that environ.h is a standard file, but it seems odd how they are checking for the OS2 define. They are forcing it to be defined to a value rather than just being defined.
Second, as evident from your test, the compiler isn't defining __OS2__ for you, and there might be another header that is, but isn't currently included in the tranlation unit that picks up some_file.h. If you've confirmed that OS2 isn't defined by another header file in your project you can define a macro for the preprocessor by following these steps given by this SO answer:
The build setting you need to change is called 'Preprocessor Macros'
and it can be found in the 'Build Settings' tab of the Project
Settings pane (use the search box to find it). Select each target in
turn in the left-hand side of the Project Settings pane then modify
the Preprocessor Macros setting.
The setting is specified as a space-separated list of preprocessor
macros in the form 'foo' or 'foo=bar'.
Third, it seems your include path to os2pltfm.h is wrong or missing in your compiler settings.
You can include the file following the instructions given in this SO answer:
All you have to do is add the -I flag to your build setting under
"Other C Flags"
So in your target's build setting search for "Other C Flags" and add
-I/path-to-include/
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.
I am including a third party header and source file into my project.
At the top of the header there is this:
#if defined(WIN32) || defined(WIN16)
#ifndef MSDOS
#define MSDOS
#endif
#endif
#include <stdio.h>
#include <stdlib.h>
#ifndef MSDOS
#include <unistd.h>
#endif
#include "des.h"
The problem is that #if defined(WIN32) fails and the compilation fails when trying to #include unistd.h which I don't want to do.
I have third party project that works with this header file i.e. WIN32 is defined and it doesn't try to include In Visual Studio I did "Go To Definition" on "WIN32" and was taken to the following definition in WinDefs.h.
#define WIN32
I'm not sure this is where its getting WIN32 definition from, as the third party project does not appear to include "WinDefs.h".
So my problem is, how can I get WIN32 to be defined in my current new project?
Depends on your project setup. WIN32 is defined inside the windows header files, but you can pass it to the compiler as well ("-DWIN32" for gcc for example). Try it and see whether it compiles.
Visual Studio has the built-in define _WIN32. mingw-gcc has WIN32 and _WIN32 built-in so the project was likely tested using gcc. You might add
#if defined(_WIN32) && !defined(WIN32)
#define WIN32
#endif
or just add a -DWIN32 to the CFLAGS.
Check your includes. I am guessing that the third party header is included prior to the windows.h. So, in your main.cpp or equal it should be
#include <windows.h> // this will also include windefs.h
#include <thirdParty.h>
and not the other way around.
Hope that helps.
You can simply include the windows header files (windows.h) before including the third party header - as you already found out WIN32 is defined there but technicaly it could be defined anywhere (so if the third party project is not including the windows headers check if it's being defined in the compiler project settins directly).
BTW there is also a _WIN32 define that is set by the compiler, it's possibly a better idea to look for this define if checking if the code is being compiled under windows;
For those seeking answers to the
where is WIN32 defined
part of the questions, I've found it defined in:
minwindef.h
ole2.h
Note, I have no confidence that these are the only places it's defined. I expect there are probably other files where it's defined. Nevertheless, I thought this might help some people.
Some WIN32 defined in the compiler . Just like this，If you use the gcc for windows , WIN32 is defined . If you use the gcc for linux , WIN32 is not defined :)
So , the macros is a switch. You can define it to use somethine , and not define it to unuse something.
I'm building a commercial app, and we are using some GPL code to help us along.
How can I add #warning or #error statements so that when the code is built for debug, it warns, but when we build for release it throws errors?
I can do:
#warning this code is released under a CCL licensing scheme, see Source_Code_License.rtf
#warning this code is not LGPL-compliant
#warning this code was copied verbatim from a GP Licensed file
at the beginning of files, but can I do better? Is there a better way of tagging a file if it's included?
I'm using Objective-C++ with gcc or clang.
#ifdef SOME_SYMBOL
#error "foobar"
#else
#warning "foobar"
#endif
NDEBUG has a slightly different purpose (controlling assert) and may be #undef and re-defined selectively (reincluding assert.h to effect the change), so it probably wouldn't be the right symbol. But it is a standard macro and could be used.
Note that #error is standard, but #warning is an extension.
Use #pragma message instead.