I'd rewritten a simple C++ program using unix as a variable name. But the program compilation failed.
#include <iostream>
int main() {
int unix = 1;
return 0;
}
After searching a lot on the internet I got to this website which helped me by saying that unix is predefined macro equal to 1.
I want to know list of all such predefined macros.
You can list all the predefined macros by using the GNU preprocessor cpp as:
cpp -dM file.cpp
Also note that macros such as unix, linux are non standard and you can disable them by using the -ansi compilation flag as:
g++ -ansi file.cpp
And you can use the -ansi flag with cpp also to get the list of all standard predefined macros:
cpp -dM -ansi file.cpp
touch mysymdef.h; g++ -dM mysymdef.h
It will generate a file mysymdef.h.gch which will have all predefined symbols/macros for you system. File is binary but with some edit it will work out.
for details refer to
http://gcc.gnu.org/onlinedocs/cpp/Invocation.html#Invocation
http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html
I don't think there's such a list as you are asking for that's available across every potential platform. You may want to see Pre-defined macros for more information. The 'gcc -dM' will work on Linux.
$ uname
Linux
$ cpp -dM <<<'' | grep unix
#define __unix__ 1
#define __unix 1
#define unix 1
Related
I am using the __int128 extension of g++. The problem with -std=c++17 is that some of the C++ library does not have all the support for that extension (i.e. std::make_unsigned<> fails). When using -std=gnu++17 it works fine.
I've added a header file that allows for the <limit> to work with __int128 when using -std=c++17 and I'd like to keep it for now, but when using -std=gnu++17 it breaks (because it is already defined). So I was thinking to add a condition like so:
#if !(<something>)
...
#endif
if the compiler already supports the limits with __int128.
My question is: what is that <something> I could check to distinguish between the standard and the GNU c++17 libraries?
I did this:
$ diff <(g++-11 -std=c++17 -E -dM -x c++ /dev/null|LC_ALL=C sort) \
<(g++-11 -std=gnu++17 -E -dM -x c++ /dev/null|LC_ALL=C sort)
And the output was:
180a181,182
> #define __GLIBCXX_BITSIZE_INT_N_0 128
> #define __GLIBCXX_TYPE_INT_N_0 __int128
315d316
< #define __STRICT_ANSI__ 1
424a426,427
> #define linux 1
> #define unix 1
That's not definitive, of course, but it's maybe a start.
So you could check for __STRICT_ANSI__ (indicating that there are no Gnu extensions), but perhaps the undocumentable __GLIBCXX_BITSIZE_INT_N_0 is more direct.
I use Xcode 11 and need to replicate this compiler command:
cc -g -Wall -Wall -Wextra -std=c99 -pedantic \
-DOBJC_OLD_DISPATCH_PROTOTYPES -c -o example.o example.c
Adding OBJC_OLD_DISPATCH_PROTOTYPES as a user defined macro with no value to the Build Settings doesn't help. Also defining it in the source fails by telling me it already got defined by Xcode via the command line. Despite setting a few suspicious flags to No, it seems Xcode keeps executing #define OBJC_OLD_DISPATCH_PROTOTYPES 1. How can I disable that?
I don't know how Xcode works but I see two points.
In the image you post you ask for a define like DOBJC_OLD_DISPATCH_PROTOTYPES, but in the command line you show it is OBJC_OLD_DISPATCH_PROTOTYPES. Which one you want to define? (Note the first D in the image: it isn't in the command line.)
With the first D the command line parameter would be:
-DDOBJC_OLD_DISPATCH_PROTOTYPES
(The -D is to define, the rest is what is defined.)
Normally that define should be made in the preprocessor options, not the compiler. You can see an example here although I don't know if the example is outdated. (There should be an option somewhere to set preprocessor defines though.)
If Xcode, no matter what, defines that as 1, you can redefine it whenever you need it:
#ifdef OBJC_OLD_DISPATCH_PROTOTYPES
#undef OBJC_OLD_DISPATCH_PROTOTYPES
#define OBJC_OLD_DISPATCH_PROTOTYPES
#endif
(Or DOBJC_OLD_DISPATCH_PROTOTYPES.)
That will get rid of the 1.
You have more information here.
If the following code is compiled with gcc lfs.c -o lfs, it prints nothing. However, if it is compiled with g++ lfs.c -o lfs, it prints "_LARGEFILE_SOURCE defined by stdio.h!".
#ifdef _LARGEFILE_SOURCE
int largefile_defined_at_start = 1;
#else
int largefile_defined_at_start = 0;
#endif
// This defines _LARGEFILE_SOURCE, but only in C++!
#include <stdio.h>
int main(void) {
#ifdef _LARGEFILE_SOURCE
if (!largefile_defined_at_start)
printf("_LARGEFILE_SOURCE defined by stdio.h!");
#endif
return 0;
}
In either case, _LARGEFILE_SOURCE is not defined by the compiler:
gcc -dM -E - < /dev/null |grep _LARGEFILE_SOURCE |wc -l
0
g++ -dM -E - < /dev/null |grep _LARGEFILE_SOURCE |wc -l
0
Why is stdio.h defining _LARGEFILE_SOURCE when GCC is invoked via the g++ frontend?
Because g++ defines _GNU_SOURCE, which basically implies all other feature macros, such as _LARGEFILE_SOURCE. These additional macros are defined when the <features.h> header is included, and most system header files include <features.h> very early in the file. The fact that _GNU_SOURCE is predefined is a continual source of frustration for people who want to write portable C++ code.
I believe you can simply:
#undef _GNU_SOURCE
However, this will break libstdc++. Ouch! What a pain! This all stems from one of the biggest design flaws in C++, which is the fact that #include is basically textual inclusion. Since most of libstdc++ is defined (not just declared!) in header files, this means that they contaminate your program with _GNU_SOURCE.
If you need to access an interface hidden by _GNU_SOURCE (such as strerror_r, for example, which is completely broken by _GNU_SOURCE) then you can access those interfaces only from files which don't use any libstdc++ headers.
This is only a problem with libstdc++ as far as I know, so I think you can also avoid the problem by using libc++ or something else like that.
I'm working on an existing C++ codebase that happens to use SIZE_MAX in a couple of places. I did some refactoring and now SIZE_MAX is not defined in one of the modules. This problem appeared when Travis-CI attempted to build the project on Linux. It worked fine before I refactored stuff, but tracing which exact header files were included is difficult.
In an attempt to replicate the problem locally, I installed an Ubuntu VM with the default gcc and was able to reproduce it. Here's the relevant source:
#include <stddef.h>
int main()
{
size_t a = SIZE_MAX;
}
The command line is simply:
g++ a.cpp
The error is:
a.cpp: In function ‘int main()’:
a.cpp:5:16: error: ‘SIZE_MAX’ was not declared in this scope
System info:
$ uname -a
Linux quartz 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
I have tried including cstdint, stdint.h, limits.h, inttypes.h, stdio.h, stdlib.h, and probably some others, and I can't figure out which specific header file I need for SIZE_MAX.
It is important to note that the program I'm working on compiled fine, with SIZE_MAX used in various places, before I made some changes. The changes I made caused it to become undefined in one .cpp source file where it was used (the others continue to be fine). So there exists some header file on my system where it is correctly defined.
It's likely that some header defined __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS before stdint.h was included.
Compiling on Linux with g++ -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS a.cpp should fix this issue on the older compilers.
If you'd like to learn more about these macros...
18.4.1 Header <cstdint> synopsis
The header also defines numerous macros of the form:
INT_[FAST LEAST]{8 16 32 64}_MIN
[U]INT_[FAST LEAST]{8 16 32 64}_MAX
INT{MAX PTR}_MIN
[U]INT{MAX PTR}_MAX
{PTRDIFF SIG_ATOMIC WCHAR WINT}{_MAX _MIN}
SIZE_MAX
EDIT
In the current C++11/14 standard, SIZE_MAX is introduced and mentioned only in <cstdint>. It is also part of C99, of which specification C++11 fully includes via the <cxxx> headers. So it seems it was not defined prior to C++11.
Which C++ standard header defines SIZE_MAX?
Its supposed to be defined in <cstdint>, but its optional.
Here are the results on Fedora 22 with GCC 5.1:
#include <cstdint>
// use SIZE_MAX
Results in:
g++ -DNDEBUG -g -O2 -fPIC -march=native -pipe -c filters.cpp
In file included from /usr/include/c++/5.1.1/cstdint:35:0,
from filters.cpp:14:
/usr/include/c++/5.1.1/bits/c++0x_warning.h:32:2: error: #error This file requires
compiler and library support for the ISO C++ 2011 standard. This support is currently
experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
filters.cpp: In constructor ‘Filter::Filter(BufferedTransformation*)’:
filters.cpp:305:36: error: ‘SIZE_MAX’ was not declared in this scope
: Filter(attachment), m_firstSize(SIZE_MAX), m_blockSize(0), m_lastSize(SIZE_M
^
It was simply easier to do the following, and stop worrying about non-portable optional-ness that still causes problems in 2015.
#include <limits>
#ifndef SIZE_MAX
# ifdef __SIZE_MAX__
# define SIZE_MAX __SIZE_MAX__
# else
# define SIZE_MAX std::numeric_limits<size_t>::max()
# endif
#endif
Trying __SIZE_MAX__ gets you back to the compile time constant that you probably crave. You can see if its defined in the preprocessor with cpp -dM < /dev/null | grep __SIZE_MAX__.
(And how/why numeric_limits<size_t>::max() is not a compile time constant is another C++ mystery, but that's a different problem).
If I compile with -fPIC on x86 Linux with gcc 4.1, then the definition __PIC__ is set to 1 and the preprocessor can act on that at compile time. However, on OS/X under gcc 4.01 that is not the case. Is there some other way to determine the setting of -fPIC at compile time on OS/X?
A general facility for querying compilation flags at the preprocessor level under OS/X would be even more helpful, but I wasn't able to find anything like that.
-fPIC is the default on OS X. gcc 4.0.1 on my crufty old OS X 10.4 machine does define __PIC__; or, when it is explicitly turned off with -fno-PIC, it does not.
The settings of compilation flags are not in general exported to the preprocessor, except for certain special cases, which may vary across different GCC targets.
But you can see the effects of changing flags on the predefined preprocessor definitions, on any platform, using the -dM option to gcc, which dumps the preprocessor definitions after preprocessing is complete.
e.g. from a terminal window:
$ gcc -xc++ -dM -E /dev/null | sort > /tmp/defaults.txt
$ gcc -fno-PIC -xc++ -dM -E /dev/null | sort > /tmp/nopic.txt
$ diff /tmp/defaults.txt /tmp/nopic.txt
65d64
< #define __PIC__ 1
$
(I've specified -xc++ there because I'm preprocessing /dev/null rather than a file with an extension that indicates the language variant. That could also be -xc, -xobjective-c or -xobjective-c++.)