I have two versions of a c++ compiler installed on my computer. One of them recognizes the __COUNTER__ macro and the other does not. After doing some research to make the program compile in both I have yet to come across the Macro definition for __COUNTER__. Is this some special Macro done by the compiler or can I copy the definition for __COUNTER__ into my source code, if I can copy it what is the code I need.
__COUNTER__ is a built-in in several common compilers. It is not possible to define manually. If you're stuck with a compiler that doesn't support it, your best option might be to run your code through a preprocessor that does support it before feeding it into the compiler.
It's a special macro which has been introduced by Visual Studio and I think is now supported by GCC too.
It basically provides a unique counter over integral numbers which can be used to generate unique identifiers.
From GCC release notes:
A new predefined macro __COUNTER__ has been added. It expands to sequential integral values starting from 0. In conjunction with the ## operator, this provides a convenient means to generate unique identifiers.
If you don't have it available to a compiler you can easily mimic the behavior with a static variable. But I'm not sure what you are compiling so I'm not sure how this counter is used in the code you have available.
Related
I am using GCC and my compiler defines those macros : __FLT_RADIX__, __FLT_MANT_DIG__, __FLT_MAX_EXP__, __FLT_HAS_INFINITY__, __FLT_HAS_QUIET_NAN__, __FLT_HAS_DENORM__, ... Are they specific to GCC or are they in the C++ standard ? I mean wether they are defined or not, I know their values are implementation-specific. If they are not in the standard, where can I find their equivalent for all compilers ?
Are they ... in the C++ standard ?
No.
Are they specific to GCC
They are not in GCC documentation, so they are not guaranteed to be in (future releases of) GCC either. They are for internal use (probably for portable implementation of the standard macros and std::numeric_limits).
where can I find their equivalent for all compilers ?
There are corresponding standard macros for most of these in the C standard library. Simply remove the underscores from beginning and end; for example FLT_RADIX. An exception is FLT_HAS_SUBNORM which is named differently as you can see. See the standard for full list of macros.
There are no standard macros for __FLT_HAS_QUIET_NAN__ or __FLT_HAS_INFINITY__. But the information (including the others) is in std::numeric_limits template.
I need to use those values in the preprocessor
It there a ways of using std::numiric_limits constants in the preprocessor
You could use metaprogramming. Write a program that generates a header file with custom macro definitions. Something like
std::cout << "#define MY_CUSTOM_FLT_HAS_QUIET_NAN "
<< std::numeric_limits<float>::has_quiet_NaN();
Then compile and run that meta program on the target system to generate the header to use to compile the main program.
I know that excessive use of inline functions could affect binary upgradeability. This is must be avoided when upgradeability is important. But, I can't figure out how inlining could affect binary compatibility. Please, could someone illustrate that.
When declaring your functions, variables, and types (aka, your "symbols"), you should also declare them as exported. Different compilers achieve this in different ways (Visual Studio uses __declspec(dllexport) (and some other methods which I'm too lazy to google for you) while GCC uses various Visibility switches. I believe clang uses GCC semantics (or is relatively compatible) and am unfamiliar with other compilers' methods for exporting symbols.
If you inline your function and it actually gets inlined (which, if you declared it as an exportable symbol, I would argue that to be a compiler bug) then how do you call it from outside of your library? As part of the inlining process for functions the compiler will often remove or rework prologue and epilogue instructions since they're no longer needed (for example, no more need to retn on x86 -- just store the return value in the register it's going to be used).
Now suppose that on one early version of your library you had used some function which was declared inline but did not actually get inline (for example, a recursive function). Someone else comes along and starts using your library. In a later version, you rework your code to remove the recursion; suddenly the compiler can inline the function and opts to, therefore hiding the export. Now your existing customers (whoever's using your library) have missing symbols. You've broken binary compatibility.
When we look at STL header files, we see many macros used where we could instead write single lines, or sometimes single word, directly. I don't understand why people use so many macros. e.g.
_STD_BEGIN
using ::type_info;
_STD_END
#if defined(__cplusplus)
#define _STD_BEGIN namespace std {
#define _STD_END }
#define _STD ::std::
Library providers have to cope with a wide range of implementations and use case. I can see two reasons for use of macros in this case (and there are probably others I'm not thinking about now):
the need to support compilers which don't support namespace. I'm not sure if it would be a concern for a recent implementation, but most of them have a long history and removing such macros even if compilers which don't support namespaces are no more supported (the not protected using ::type_info; hints that it is the case) would have a low priority.
the desire to allow customers to use their implementation of the standard library in addition to the one provided by the compiler provider without replacing it. Configuring of the library would then allow to substitute another name for std.
That
#if defined(__cplusplus)
in your sample is the key. Further down in your source I would expect to see alternative definitions for the macros. Depending on compilation environment, some constructs may require different syntax or not be supported at all; so we write code once, using macros for such constructs, and arrange for the macros to be defined appropriately depending on what is supported.
Macros vs variables : macros can run faster in this case because they are actually made constants after pre-processing.(Operations on constants are faster than that on variables).
Macros vs functions : Using macros avoids the overhead compared to that when using functions requires pushing parameters to stack, pushing return address and then popping from stack....
Macros : Faster execution but requires more memory space.
Function : Slower execution but less memory space.
After browsing some old code, I noticed that some classes are defined in this manner:
MIDL_INTERFACE("XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX")
Classname: public IUnknown {
/* classmembers ... */
};
However, the macro MIDL_INTERFACE is defined as:
#define MIDL_INTERFACE(x) struct
in C:/MinGW/include/rpcndr.h (somewhere around line 17). The macro itself is rather obviously entirely pointless, so what's the true purpose of this macro?
In the Windows SDK version that macro expands to
struct __declspec(uuid(x)) __declspec(novtable)
The first one allows use of the __uuidof keyword which is a nice way to get the guid of an interface from the typename. The second one suppresses the generation of the v-table, one that is never used for an interface. A space optimization.
This is because MinGW does not support COM (or rather, supports it extremely poorly). MIDL_INTERFACE is used when defining a COM component, and it is generated by the IDL compiler, which generates COM type libraries and class definitions for you.
On MSVC, this macro typically expands to more complicated initialization and annotations to expose the given C++ class to COM.
If I had to guess, it's for one of two use cases:
It's possible that there's an external tool that parses the files looking for declarations like these. The idea is that by having the macro evaluate to something harmless, the code itself compiles just fine, but the external tool can still look at the source code and extract information out of it.
Another option might be that the code uses something like the X Macro Trick to selectively redefine what this preprocessor directive means so that some other piece of the code can interpret the data in some other way. Depending on where the #define is this may or may not be possible, but it seems reasonable that this might be the use case. This is essentially a special-case of the first option.
which compiling a multithreaded program we use gcc like below:
gcc -lpthread -D_REENTRANT -o someprogram someprogram.c
what exactly is the flag -D_REENTRANT doing over here?
Defining _REENTRANT causes the compiler to use thread safe (i.e. re-entrant) versions of several functions in the C library.
You can search your header files to see what happens when it's defined.
Excerpt from the libc 8.2 manual:
Macro: _REENTRANT
Macro: _THREAD_SAFE
These macros are obsolete. They have the same effect as defining
_POSIX_C_SOURCE with the value 199506L.
Some very old C libraries required one of these macros to be defined
for basic functionality (e.g. getchar) to be thread-safe.
We recommend you use _GNU_SOURCE in new programs. If you don’t specify
the ‘-ansi’ option to GCC, or other conformance options such as
-std=c99, and don’t define any of these macros explicitly, the effect is the same as defining _DEFAULT_SOURCE to 1.
When you define a feature test macro to request a larger class of
features, it is harmless to define in addition a feature test macro
for a subset of those features. For example, if you define
_POSIX_C_SOURCE, then defining _POSIX_SOURCE as well has no effect. Likewise, if you define _GNU_SOURCE, then defining either
_POSIX_SOURCE or _POSIX_C_SOURCE as well has no effect.
JayM replied:
Defining _REENTRANT causes the compiler to use thread safe (i.e. re-entrant) versions of several functions in the C library.
You can search your header files to see what happens when it's defined.
Since OP and I were both interested in the question, I decided to actually post the answer. :) The following things happen with _REENTRANT on Mac OS X 10.11.6:
<math.h> gains declarations for lgammaf_r, lgamma_r, and lgammal_r.
On Linux (Red Hat Enterprise Server 5.10), I see the following changes:
<unistd.h> gains a declaration for the POSIX 1995 function getlogin_r.
So it seems like _REENTRANT is mostly a no-op, these days. It might once have declared a lot of new functions, such as strtok_r; but these days those functions are mostly mandated by various decades-old standards (C99, POSIX 95, POSIX.1-2001, etc.) and so they're just always enabled.
I have no idea why the two systems I checked avoid declaring lgamma_r resp. getlogin_r when _REENTRANT is not #defined. My wild guess is that this is just historical cruft that nobody ever bothered to go through and clean up.
Of course my observations on these two systems might not generalize to all systems your code might ever encounter. You should definitely still pass -pthread to the compiler (or, less good but okay, -lpthread -D_REENTRANT) whenever your program requires pthreads.
In multithreaded programs, you tell the compiler that you need this feature by defining the _REENTRANT macro before any #include lines in your program. This does three things, and does them so elegantly that usually you don’t even need to know what was done:
Some functions get prototypes for a re-entrant safe equivalent.
These are normally the same function name, but with _r appended so
that, for example, gethostbyname is changed to gethostbyname_r.
Some stdio.h functions that are normally implemented as macros
become proper re-entrant safe functions.
The variable errno, from errno.h, is changed to call a function,
which can determine the real errno value in a multithread safe way.
Taken from Beginning Linux Programming
It simply defined _REENTRANT for the preprocessor. Somewhere in the associated code, you'll probably find #ifdef _REENTRANT or #if defined(_REENTRANT) in at least a few places.
Also note that the name "_REENTRANT: is in the implementer's name space (any name starting with an underscore followed by another underscore or a capital letter is), so defining it means you've stepped outside what the standard defines (at least the C or C++ standards).