Is it possible to write a function-like C preprocessor macro that returns 1 if its argument is defined, and 0 otherwise? Lets call it BOOST_PP_DEFINED by analogy with the other boost preprocessor macros, which we can assume are also in play:
#define BOOST_PP_DEFINED(VAR) ???
#define XXX
BOOST_PP_DEFINED(XXX) // expands to 1
#undef XXX
BOOST_PP_DEFINED(XXX) // expands to 0
I'm expecting to use the result of BOOST_PP_DEFINED with BOOST_PP_IIF:
#define MAGIC(ARG) BOOST_PP_IIF(BOOST_PP_DEFINED(ARG), CHOICE1, CHOICE2)
In other words, I want the expansion of MAGIC(ARG) to vary based on whether ARG is defined or not at the time that MAGIC is expanded:
#define FOO
MAGIC(FOO) // expands to CHOICE1 (or the expansion of CHOICE1)
#undef FOO
MAGIC(FOO) // expands to CHOICE2 (or the expansion of CHOICE2)
I also found it interesting (and somewhat surprising) that the following doesn't work:
#define MAGIC(ARG) BOOST_PP_IIF(defined(arg), CHOICE1, CHOICE2)
Because apparently defined is only valid in the preprocessor when used as part of an #if expression.
I somewhat suspect that the fact that boost preprocessor doesn't already offer BOOST_PP_DEFINED is evidence for its impossibility, but it can't hurt to ask. Or, am I missing something really obvious about how to achieve this.
EDIT: To add some motivation, here is why I want this. The traditional way to do "API" macros to control import/export is to declare a new set of macros for every library, which means a new header, etc. So if we have class Base in libbase and class Derived in libderived, then we have something like the following:
// base_config.hpp
#if LIBBASE_COMPILING
#define LIBBASE_API __declspec(dllexport)
#else
#define LIBBASE_API __declspec(dllimport)
// base.hpp
#include "base_config.hpp"
class LIBBASE_API base {
public:
base();
};
// base.cpp
#include "base.hpp"
base::base() = default;
// derived_config.hpp
#if LIBDERIVED_COMPILING
#define LIBDERIVED_API __declspec(dllexport)
#else
#define LIBDERIVED_API __declspec(dllimport)
// derived.hpp
#include "derived_config.hpp"
#include "base.hpp"
class LIBDERIVED_API derived : public base {
public:
derived();
};
// derived.cpp
#include "derived.hpp"
derived::derived() = default;
Now, obviously, each of the _config.hpp header would really be a lot more complex, defining several macros. We could probably pull out some of the commonalities into a generic config_support.hpp file, but not all. So, in an effort to simplify this mess, I wondered if it would be possible make this generic, so that one set of macros could be used, but that would expand differently based on which _COMPILING macros were in play:
// config.hpp
#define EXPORT __declspec(dllexport)
#define IMPORT __declspec(dllimport)
#define API_IMPL2(COND) BOOST_PP_IIF(COND, EXPORT, IMPORT)()
#define API_IMPL(ARG) API_IMPL2(BOOST_PP_DEFINED(ARG))
#define API(LIB) API_IMPL(LIB ## _COMPILING)
// base.hpp
#include "config.hpp"
class API(LIBBASE) base {
public:
base();
};
// base.cpp
#include "base.hpp"
base::base() = default;
// derived.hpp
#include "config.hpp"
#include "base.hpp"
class API(LIBDERIVED) derived : public base {
public:
derived();
};
// derived.cpp
#include "derived.hpp"
derived::derived() = default;
In other words, when compiling base.cpp, API(LIBBASE) would expand to __declspec(dllexport) because LIBBASE_COMPILING was defined on the command line, but when compiling derived.cpp API(LIBBASE) would expand to __declspec(dllimport) because LIBBASE_COMPILING was not defined on the command line, but API(LIBDERIVED) would now expand to __declspec(dllexport) since LIBDERIVED_COMPILING would be. But for this to work it is critical that the API macro expand contextually.
It looks like you could use BOOST_VMD_IS_EMPTY to implement the required behavior. This macro returns 1 if its input is empty or 0 if its input is not empty.
Trick based on the observation that when XXX is defined by #define XXX, empty parameter list passed to BOOST_VMD_IS_EMPTY(XXX) during expansion.
Sample implementation of MAGIC macro:
#ifndef BOOST_PP_VARIADICS
#define BOOST_PP_VARIADICS
#endif
#include <boost/vmd/is_empty.hpp>
#include <boost/preprocessor/control/iif.hpp>
#define MAGIC(XXX) BOOST_PP_IIF(BOOST_VMD_IS_EMPTY(XXX), 3, 4)
#define XXX
int x = MAGIC(XXX);
#undef XXX
int p = MAGIC(XXX);
For Boost 1.62 and VS2015 preprocessor output will be:
int x = 3;
int p = 4;
This approach has a number of flaws, e.g. it's not working if XXX defined with #define XXX 1. BOOST_VMD_IS_EMPTY itself has limitations.
EDIT:
Here is the implementation of the required API macros based on BOOST_VMD_IS_EMPTY:
// config.hpp
#ifndef BOOST_PP_VARIADICS
#define BOOST_PP_VARIADICS
#endif
#include <boost/vmd/is_empty.hpp>
#include <boost/preprocessor/control/iif.hpp>
#define EXPORT __declspec(dllexport)
#define IMPORT __declspec(dllimport)
#define API_IMPL2(COND) BOOST_PP_IIF(COND, EXPORT, IMPORT)
#define API_IMPL(ARG) API_IMPL2(BOOST_VMD_IS_EMPTY(ARG))
#define API(LIB) API_IMPL(LIB ## _COMPILING)
Let's see what preprocessor will output for:
// base.hpp
#include "config.hpp"
class API(LIBBASE) base {
public:
base();
};
When LIBBASE_COMPILING defined, GCC output:
class __attribute__((dllexport)) Base
{
public:
Base();
};
When LIBBASE_COMPILING is not defined, GCC output:
class __attribute__((dllimport)) Base
{
public:
Base();
};
Tested with VS2015 and GCC 5.4 (Cygwin)
EDIT 2:
As #acm mentioned when parameter defined with -DFOO it's same as -DFOO=1 or #define FOO 1. In this case approach based on BOOST_VMD_IS_EMPTY is not working. To overcome it you can use BOOST_VMD_IS_NUMBER (thnx to #jv_ for the idea). Implementation:
#ifndef BOOST_PP_VARIADICS
#define BOOST_PP_VARIADICS
#endif
#include <boost/vmd/is_number.hpp>
#include <boost/preprocessor/control/iif.hpp>
#define EXPORT __declspec(dllexport)
#define IMPORT __declspec(dllimport)
#define API_IMPL2(COND) BOOST_PP_IIF(COND, EXPORT, IMPORT)
#define API_IMPL(ARG) API_IMPL2(BOOST_VMD_IS_NUMBER(ARG))
#define API(LIB) API_IMPL(LIB ## _COMPILING)
It's not a pure is defined check, but we can get all the way to checking for a particular token name.
Annotating a first principles solution based on Cloak from Paul Fultz II:
First provide the ability to conditionally choose text based on macro expansion to 0 or 1
#define IIF(bit) PRIMITIVE_CAT(IIF_, bit)
#define IIF_0(t, f) f
#define IIF_1(t, f) t
Basic concatenation
#define CAT(a, ...) PRIMITIVE_CAT(a, __VA_ARGS__)
#define PRIMITIVE_CAT(a, ...) a##__VA_ARGS__
Logical operators (compliment and and)
#define COMPL(b) PRIMITIVE_CAT(COMPL_, b)
#define COMPL_0 1
#define COMPL_1 0
#define BITAND(x) PRIMITIVE_CAT(BITAND_, x)
#define BITAND_0(y) 0
#define BITAND_1(y) y
A method to see whether a token is or is not parens "()"
#define CHECK_N(x, n, ...) n
#define CHECK(...) CHECK_N(__VA_ARGS__, 0, )
#define PROBE(x) x, 1,
#define IS_PAREN(x) CHECK(IS_PAREN_PROBE x)
#define IS_PAREN_PROBE(...) PROBE(~)
Note IS_PAREN works because "IS_PAREN_PROBE X" turns in to one arg in CHECK(), where as "IS_PAREN_PROBE ()" turns into PROBE(~) which turns into ~, 1. At which point we can pick up the 1 from CHECK
Another utility to eat some macro arguments as needed
#define EAT(...)
Here, we take advantage of blue painting (the thing which prevents naively recursive macros) to check whether or not two tokens are the same. If they are this collapses to (). Otherwise not, which we can detect via IS_PAREN.
This relies on COMPARE_XXX identity macros existing for any given symbol
#define PRIMITIVE_COMPARE(x, y) IS_PAREN(COMPARE_##x(COMPARE_##y)(()))
We add an IS_COMPARABLE trait for that helper
#define IS_COMPARABLE(x) IS_PAREN(CAT(COMPARE_, x)(()))
We work backwards to EQUAL by checking if both args are comparable, then converting to primitive_compare if they are. If not, we're not equal and eat the following args.
#define NOT_EQUAL(x, y) \
IIF(BITAND(IS_COMPARABLE(x))(IS_COMPARABLE(y))) \
(PRIMITIVE_COMPARE, 1 EAT)(x, y)
EQUAL is the compliment
#define EQUAL(x, y) COMPL(NOT_EQUAL(x, y))
And finally, the macro we actually want.
First we enable compare for "BUILDING_LIB"
#define COMPARE_BUILDING_LIB(x) x
Then our actual deciding macro, which is an integer if on whether a symbol resolves to "BUILDING_LIB"
#define YES_IF_BUILDING_LIB(name) IIF(EQUAL(name, BUILDING_LIB))("yes", "no")
#include <iostream>
#define FOO BUILDING_LIB
int main(int, char**) {
std::cout << YES_IF_BUILDING_LIB(FOO) << "\n";
std::cout << YES_IF_BUILDING_LIB(BAR) << "\n";
}
Which outputs:
yes
no
See his great blogpost (that I cribbed from): C Preprocessor tricks, tips, and idioms
Since you intend to use FOO as file-level switch that you control, I suggest that you use a simpler solution. The suggested solution is easier to read, less surprising, requires no dirty magic.
Instead of #define MAGIC(ARG) BOOST_PP_IIF(BOOST_PP_DEFINED(ARG), CHOICE1, CHOICE2) you simply -D with MAGIC=CHOICE1 or MAGIC=CHOICE2 per file.
You don't have to do it for all files. The compiler will tell you when you used MAGIC in a file, but did not make a choice.
If CHOICE1 or CHOICE2 is a major default you don't wish to specify, you can use -D to set default for all files and -U + -D to change your decision per file.
If CHOICE1 or CHOICE2 is lengthy, you can #define CHOICE1_TAG actual_contents in your header file where you originally intended to define MAGIC and then -D with MAGIC=CHOICE1_TAG, because CHOICE1_TAG will be automatically expanded into actual_contents.
For example assert.h:
...
#ifdef NDEBUG
#define assert(_Expression) ((void)0)
#else /* NDEBUG */
...
This area isn't surrendered by #ifdef, #define, #endif or having #pragma once.
I want to define my own assert function, so I #undef it and creates it, but then when a file includes anything after that includes assert.h it overrides my assert function I made before that include...
For example:
#include "my_assert.hpp"
#include <iostream.h>
My my_assert will lose effect and use assert.h's define.
I have a problem where I can't seem to get conditional #define preprocessors to work correctly. For example:
#define WIN32_BUILD
#ifdef WIN32_BUILD
#define PCH "stdafx.h"
#else
#define PCH "xyz.h"
#endif
#include PCH
If I use this form, the compiler tells me that it can't find 'stdafx.h'. OK, that seems odd, so if I change the code to....
#define WIN32_BUILD
#ifdef WIN32_BUILD
#define PCH "xyz.h"
#else
#define PCH "stdafx.h"
#endif
#include PCH
Then the file defined in PCH gets picked up and everything compiles fine. This seems odd to me, almost like the preprocessor is ignoring the #if directives and just using all the #defines that it encounters.
Obviously I am doing something wrong, and I was hoping that someone could help me understand this.
When a project has the precompiled header feature turned on the preprocessor ignores everything that comes before #include "stdafx.h"
So your #define statements are ignored.
TL:DR; #define defines the symbol, #ifdef tests if the symbol is defined not whether it has a value.
#define WIN32_BUILD
This defines a pre-processor token, WIN32_BUILD. The token has no value. Anywhere you use the token 'WIN32_BUILD' the pre-processor will substitute the empty string, i.e. nothing.
#ifdef WIN32_BUILD
This checks if the pre-processor token WIN32_BUILD is defined. It is, you just defined it.
#ifdef WIN32_BUILD
// true - this code is included.
#define PCH "stdafx.h"
This defines the pre-processor token, PCH, and assigns it the value "stdafx.h"
#else
#define PCH "xyz.h"
#endif
This code is ignored, because WIN32_BUILD was defined.
It looks as though you were expecting 'ifdef' to only evaluate to true if the expression was not defined /to/ something.
#define a
#define b SOMETHING
#ifdef a
// you are expecting this to be ignored
#endif
#ifdef b
// and expecting this not to be ignored
#endif
#ifdef and #if defined(...) do the same thing.
#define a
#define b SOMETHING
#if defined(a) && defined(b)
// this code will be evaluated, both tokens are defined.
#endif
This feature of pre-processor tokens is often used to support conditional functionality:
#if HAVE_CPP11_OVERRIDE_KEYWORD
#define OVERRIDE_FN override
#else
#define OVERRIDE_FN
#endif
struct A {
virtual void foo() {}
};
struct B : public A {
void foo() OVERRIDE_FN {}
};
In the above code, the override keyword is only added if the system supports it (determined outside of the code).
So a compiler with override sees
struct B : public A {
void foo() override {}
};
a compiler without it sees
struct B : public A {
void foo() {}
};
Note: The opposite of "ifdef" is "ifndef":
#define a
#define b SOMETHING
#undef c
//#define d // << we didn't define it.
int main() {
#ifdef a
#pramga message("a is defined")
#else
#pramga message("a is UNdefined")
#endif
#ifdef b
#pragma message("b is defined")
#else
#pramga message("b is UNdefined")
#endif
#ifdef c
#pramga message("c is defined")
#endif
#else
#pramga message("c is UNdefined")
#endif
#ifdef d
#pramga message("d is defined")
#endif
#else
#pramga message("d is UNdefined")
#endif
#ifndef d
#pragma message("d is not defined")
#endif
#ifndef a
#pragma message("a is not defined")
#endif
return 0;
}
You can assign a pre-processor token numeric values and test them with #if
#if _MSC_VER
#define WIN32_BUILD 1
#else
#define WIN32_BUILD 0
#endif
#if WIN32_BUILD
#include <Windows.h>
#endif
But, especially when doing cross-platform programming, people tend to use ifdef variants rather than numeric checks, because the value checks require you to explicitly ensure all of the tokens are defined with a value. It's a lot easier just to only define them when you need them.
Maybe I'm missing something, but could some please explain the "logic" behind the following code?
#ifndef _PTRDIFF_T
#ifndef _T_PTRDIFF_
#ifndef _T_PTRDIFF
#ifndef __PTRDIFF_T
#ifndef _PTRDIFF_T_
#ifndef _BSD_PTRDIFF_T_
#ifndef ___int_ptrdiff_t_h
#ifndef _GCC_PTRDIFF_T
#define _PTRDIFF_T
#define _T_PTRDIFF_
#define _T_PTRDIFF
#define __PTRDIFF_T
#define _PTRDIFF_T_
#define _BSD_PTRDIFF_T_
#define ___int_ptrdiff_t_h
#define _GCC_PTRDIFF_T
#ifndef __PTRDIFF_TYPE__
#define __PTRDIFF_TYPE__ long int
#endif
typedef __PTRDIFF_TYPE__ ptrdiff_t;
#endif /* _GCC_PTRDIFF_T */
#endif /* ___int_ptrdiff_t_h */
#endif /* _BSD_PTRDIFF_T_ */
#endif /* _PTRDIFF_T_ */
#endif /* __PTRDIFF_T */
#endif /* _T_PTRDIFF */
#endif /* _T_PTRDIFF_ */
#endif /* _PTRDIFF_T */
Why is this preferred over a simple:
#ifndef xyz
#define xyz
#endif
???
I can see they are nested, but it is very confusing. ...and btw, just what are they defining, as there are no values after the identifiers???
The logic is to only define the macros if none of them is defiend. However, I would certainly refactor it into:
#if !defined(_PTRDIFF_T) && !defined(_T_PTRDIFF_) && //... well, you get the idea
#define _PTRDIFF_T
#define _T_PTRDIFF_
//...
#ifndef __PTRDIFF_TYPE__
#define __PTRDIFF_TYPE__ long int
#endif
typedef __PTRDIFF_TYPE__ ptrdiff_t;
#endif
As to the second question: you can define a macro without a replacement text (it would just expand to nothing if used). Such macros are often used for conditional inclusion of code based on #ifdef or #ifndef.
They're checking that all these identifiers have been defined which would be in other already included headers. If they're all defined then we define a few new identifiers.
You don't need to give a value to the identifier, for example you wouldn't give a value to your #include guards.
How should I write the below piece of code using macro function?
#ifdef LOG_ENABLED
m_logger->Log(szType,szMessage);
#endif
I have done something like mentioned below and it resulted in error:-
#define _LOG_MSG_CND_BEGIN_ #ifdef LOG_ENABLED
#define _LOG_MSG_CND_END_ #endif
#define WriteLogMessage(szType,szMessage) \
{\
_LOG_MSG_CND_BEGIN_\
m_logger->Log(szType,szMessage);\
_LOG_MSG_CND_END_\
}
Please let me know how to write macro function for the above three piece of code without any errors.
I have used inline function for the same piece of code but while debugging i saw that the inline function was not getting treated as inline function and so i want to use macro function in this case.
Inline function which i used was as mentioned below:-
inline void WriteLogMessage(LOG_LEVEL szType, LPCTSTR szMessage){
#ifdef LOG_ENABLED
m_logger->Log(szType,szMessage);
#endif
}
The standard C preprocessor is a bit of an idiot and doesn't understand much at all. You want something like this:
#if defined LOG_ENABLED
#define WriteLogMessage(szType,szMessage) m_logger->Log(szType,szMessage)
#else
#define WriteLogMessage(szType,szMessage)
#endif
Preprocessor directives need to be the first thing in a line:
#define _LOG_MSG_CND_BEGIN_
#ifdef LOG_ENABLED
#define _LOG_MSG_CND_END_
#endif
#define WriteLogMessage(szType,szMessage) \
{\
_LOG_MSG_CND_BEGIN_\
m_logger->Log(szType,szMessage);\
_LOG_MSG_CND_END_\
}
EDIT: If you want macros to be expanded to other macros, that's not possible.