Can BOOST_PP_DEFINED be implemented?

Question

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.

Aman

Probably not possible in general case, but can be possible with limitations. Do you control how FOO is #define'd ? Is it you who #define it in various places? What type is FOO - does it define string, integer, empty definition or something else? – Dibasic

@Dibasic I do control how FOO is defined, and in my envisioned usage, I would be setting it on the compile line with -D when certain files are compiled. As such, I could set it to any of the choices you mention. – Aman

If you can choose the value of FOO, why not just do -DFOO=1, then add a little #ifndef FOO / #define FOO 0 / #endif and just use FOO. – Batish

This will break if #ifndef FOO / #define FOO 0 / #endif gets into precompiled header. – Dibasic

@Batish I added an example to help motivate why I need the contextual expansion, and why just defining and using #if will not work. – Aman

Answer 1

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)

Reduced

Very interesting, I will try this today and see if I can get it to work. – Aman

I think the limitation when XXX is defined with #define XXX 1 can be easily solved using BOOST_VMD_IS_NUMBER (analogous to your approach with BOOST_VMD_IS_EMPTY). Here is a possible example (not tested with VS). – Allantoid

@Aman Does it work for you? It's pretty interesting. I'm looking forward for your reply. – Reduced

I wasn't able to get it to work on my first try, but have not had much time to get back to this problem. I will definitely update when I have. – Aman

@Aman Let me help you a bit. I've used BOOST_VMD_IS_EMPTY in your API implementation. API_IMPL2 is also adjusted. Please check the results in the Edit section of my answer. – Reduced

Ahhh... I figured out what was going wrong. I think in your example you were #define'ing the value in the header. For me, it comes in via -D. A bare -D argument like -DFOO is the same as -DFOO=1 - meaning it isn't actually useable with BOOST_VMD_IS_EMPTY, per your mentioned "flaw" above. Passing -DFOO= defines it in such a way that BOOST_VMD_IS_EMPTY respects it. Neat! – Aman

@Aman As @jv_ mention to overcome this problem you can use BOOST_VMD_IS_NUMBER instead of BOOST_VMD_IS_EMPTY. I've checked it with -DFOO=1, it works as expected. I will update my answer. – Reduced

Yup, totally working wth BOOST_VMD_IS_NUMBER. I think this might be a better way of doing project wide visibility macros if you are willing to take the preprocessor metaprogramming hit. In projects made up of large number of libraries, it is no fun to need to make a separate config.h header for every library. This way, do it once and make the preprocessor do the heavy lifting. – Aman

BOOST_VMD_IS_NUMBER is also useful when you want to detect defines for SIG* macros such as whether SIGHUP exists in the current system. This and the rest of the answer saved my ass right now. Thank you. – Ketene

Answer 2

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

Kleenex

Answer 3

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.

Dibasic

I'm not sure I like the goal of the question, but this solution has the unfortunate property of pushing configuration that used to be in the program source code into the build system source (Makefile). – Nutpick

OP said he's going to use -D in his envisioned usage. – Dibasic

@Dibasic please see my updated question for details on why I need the macro to expand differently in different contexts within the same TU. – Aman