Related
I can find other questions on the site about using #if and #ifdef inside macros, and ways to get around the restriction to achieve various things, but none of them or their answers seem to match my use-case, which seems like an obvious one to me:
// the system flags are defined as object-like macros in this header...
#include <sys/stat.h>
// naive attempt at function-like macro that of course cannot work
#define MAYBE_EXPORT_FLAG(flag) \
#if defined(flag). \
exports.Set(Napi::String::New(env, #flag), \
Napi::Number::New(env, flag)); \
#endif
Napi::Object Init(Napi::Env env, Napi::Object exports) {
MAYBE_EXPORT_FLAG(UF_NODUMP)
MAYBE_EXPORT_FLAG(UF_IMMUTABLE)
MAYBE_EXPORT_FLAG(UF_APPEND)
return exports;
}
For instance, this previous question seems similar and a workaround is provided, but I couldn't adapt that set of macros to my case, or if it is adaptable I'm not understanding something there. In any case it doesn't use the macro's parameter in the generated code.
I did find that there were some tricks around to do what some of the other questions wanted but I couldn't find a way to adapt any of them to this case. But they are quite tricky. So is there some trick or is it simply impossible?
What you end up needing to do is define a macro for every symbol of interest that expands based on whether the symbol is defined:
#include <sys/stat.h>
#ifdef UF_NODUMP
#define IFDEF_UF_NODUMP(...) __VA_ARGS__
#else
#define IFDEF_UF_NODUMP(...)
#endif
#ifdef UF_IMMUTABLE
#define IFDEF_UF_IMMUTABLE(...) __VA_ARGS__
#else
#define IFDEF_UF_IMMUTABLE(...)
#endif
#ifdef UF_APPEND
#define IFDEF_UF_APPEND(...) __VA_ARGS__
#else
#define IFDEF_UF_APPEND(...)
#endif
#define MAYBE_EXPORT_FLAG(flag) \
IFDEF_ ## flag( \
exports.Set(Napi::String::New(env, #flag), \
Napi::Number::New(env, flag)); \
)
Napi::Object Init(Napi::Env env, Napi::Object exports) {
MAYBE_EXPORT_FLAG(UF_NODUMP)
MAYBE_EXPORT_FLAG(UF_IMMUTABLE)
MAYBE_EXPORT_FLAG(UF_APPEND)
return exports;
}
This is somewhat painful and repetitive, but you can put all the repeated stuff in its own header file somewhere that you don't need to refer to much. Depending on what you are are trying to do, you might find it useful to define IFNDEF_ macros for each symbol as well.
Here's an alternate approach, for interest (with a caveat--see bolded list entry). This doesn't use your MAYBE_EXPORT_FLAG skeleton, but:
It's a bit more generic (based on pattern matching)
Usage is less verbose than giant chains of conditional directives (detects undefined flags using pattern matching)
Works with identifier-like flags (anything right-pasteable to an identifier; includes positive decimals, octals, hex numbers)
Works with parenthetical flags
WILL NOT WORK for (non-parenthetical) "negative" flags (e.g., if your system defines a flag as #define FLAG -1)
Base macros
#define SECOND(...) SECOND_I(__VA_ARGS__,,)
#define SECOND_I(A,B,...) B
#define GLUE(A,B) GLUE_I(A,B)
#define GLUE_I(A,B) A##B
#define EAT(...)
#define IF_NMATCHES_USEABLE(P_, F_, M_) M_
#define IF_NMATCHES_P(...) , IF_NMATCHES_USEABLE
#define IF_NMATCHES_CALL(P_,F_,M_) \
SECOND(IF_NMATCHES_P F_, IF_NMATCHES_D2)(P_, F_, M_)
#define IF_NMATCHES_D2(P_,F_,M_) \
SECOND(GLUE(P_, F_), IF_NMATCHES_USEABLE)(P_, F_, M_)
#define MATCHED_PATTERN(P_, F_, M_) EAT
Usage
#include <sys/stat.h>
// Match macros (prefix plus flag)
#define STAT_FLAG_UF_NODUMP ,MATCHED_PATTERN
#define STAT_FLAG_UF_IMMUTABLE ,MATCHED_PATTERN
#define STAT_FLAG_UF_APPEND ,MATCHED_PATTERN
// Apply
#define EXPORT_FLAG(FLAG_) \
exports.Set(Napi::String::New(env, #FLAG_), \
Napi::Number::New(env, FLAG_));
Napi::Object Init(Napi::Env env, Napi::Object exports) {
IF_NMATCHES_CALL(STAT_FLAG_,UF_NODUMP,EXPORT_FLAG)(UF_NODUMP)
IF_NMATCHES_CALL(STAT_FLAG_,UF_IMMUTABLE,EXPORT_FLAG)(UF_IMMUTABLE)
IF_NMATCHES_CALL(STAT_FLAG_,UF_APPEND,EXPORT_FLAG)(UF_APPEND)
return exports;
}
Semantically, IF_NMATCHES_CALL takes as arguments a prefix, a flag, and the name of a function-like macro. It will expand to EAT if the pattern matches, or your function-like macro's name if it doesn't. Then you add call arguments; EAT is a variadic macro that swallows those arguments and expands to nothing... your macro does what you want.
A pattern is matched if there is a "pattern-match" macro; the pattern match macro has a name equivalent to the prefix and the flag you're checking, and a replacement list of ,MATCHED_PATTERN (comma is significant, see below).
Mechanism
The core here uses C preprocessor pattern matching via an indirect SECOND macro. By default this macro expands to its second argument; when used as a pattern matcher, you would arrange the first argument to produce a token to be matched; for match cases you define a macro with that name and put a comma in that macro's replacement list, which shifts in a non-default macro.
The top level macro first applies a pattern matcher on parenthesized flag replacement lists; in such cases, IF_NMATCHES_P will expand, shifting IF_NMATCHES_USEABLE. If the flag doesn't expand to a parenthesized list, the second level IF_NMATCHES_D2 is called. This call matches on the prefix/suffix combination (the GLUE here is what would fail if your system defined the flag as a negative literal, as e.g. -1 is not right-pasteable); if your flag is not defined, the result of this would be your match macro, which will shift in MATCHED_PATTERN resulting in the EAT. If your flag is defined, the argument is ignored by the SECOND macro resulting in IF_NMATCHES_USEABLE. IF_NMATCHES_USEABLE is what expands to M_.
Demo
http://coliru.stacked-crooked.com/a/d151d475f2736141
I'm writing a library that uses the preprocessor meta-programming Boost.Preprocessor. One macro looks kind of like this:
#define MY_MACRO(my_type) return some_function<my_type>()
Now, the problem is that I need to remove the return if my_type is void. I checked Boost.Preprocessor, but I didn't see anything that could help me. How do I accomplish this? Something like:
#define MY_MACRO(my_type) BOOST_PP_IF(\
TYPE_EQUALS(my_type,void),return,BOOST_PP_EMPTY()) some_function<my_type>()
Unfortunately, boost preprocessor doesn't have an easy way to compare two tokens. Of course for your case you may just need to use some simple detection. This should work on C99 preprocessors:
#define CHECK_N(x, n, ...) n
#define CHECK(...) CHECK_N(__VA_ARGS__, 0,)
#define PROBE(x) x, 1,
#define IS_VOID(x) CHECK(BOOST_PP_CAT(IS_VOID_, x))
#define IS_VOID_void PROBE(~)
However, this won't work for parenthesis, for varidiac data(such as types with commas in them), or pointers. So here are the ones that work and don't work:
IS_VOID(int) // 0
IS_VOID(void) // 1
IS_VOID((void)) // Compile error
IS_VOID(std::map<int, int>) // Compile error
IS_VOID(void*) // Returns 1, but should return 0
You could try to work around all these cases or you could use a more general comparison macro(like the one here):
#define IS_PAREN(x) CHECK(IS_PAREN_PROBE x)
#define IS_PAREN_PROBE(...) PROBE(~)
#define IS_COMPARABLE(x) IS_PAREN( CAT(COMPARE_, x) (()) )
#define NOT_EQUAL(x, y) \
IIF(BITAND(IS_COMPARABLE(x))(IS_COMPARABLE(y)) ) \
( \
PRIMITIVE_COMPARE, \
1 EAT \
))(x, y)
#define EQUAL(x, y) COMPL(NOT_EQUAL(x, y))
#define COMPARE_void(x) x
#define IS_VOID(x) EQUAL(x, void)
Which could be updated to use boost preprocessor components. This should work for more cases, but still won't work with parenthesis(which may not be a problem).
Finally, this is just a comparison on the textual level, so if the user has typedefed void, it will incorrectly return false:
typedef void my_void;
IS_VOID(my_void) // Returns 0
If you are using the detection technique, you could allow the user to extend it for user-defined voids, like so:
#define IS_VOID(x) CHECK(BOOST_PP_CAT(IS_VOID_, x))
#define IS_VOID_void PROBE(~)
// User-defined void
#define IS_VOID_my_void PROBE(~)
I have seen this question:
How to generate random variable names in C++ using macros?
with the following answer: https://stackoverflow.com/a/1675203/551045
And I've tried to implement it in clang.
Here is my declaration:
#define TRACE(stream) FuncTrace x#__COUNTER__ (llvm::errs(), "hallo", 1)
I tried all variations x##__COUNTER__; x ## __COUNTER__ and so on but none seem to work.
Could this be a clang bug? The clang help page says it has the __COUNTER__ macro.
In the end the macro I need something like this:
#define TRACE(stream) FuncTrace x#__COUNTER__ (stream, __FUNCTION__, __LINE__)
To concatenate two tokens into one you use the ## operator. The # operator is used to turn a token into a string.
x ## __COUNTER__ will just produce x__COUNTER__. You need to fully expand __COUNTER__ first. One possible method is add a few more indirections, e.g.
#define YTRACE(x, y) FuncTrace x##y (llvm::errs(), __FUNCTION__, __LINE__)
#define XTRACE(x, y) YTRACE(x, y)
#define TRACE(x) XTRACE(x, __COUNTER__)
I want to know if we can have recursive macros in C/C++? If yes, please provide a sample example.
Second thing: why am I not able to execute the below code? What is the mistake I am doing? Is it because of recursive macros?
# define pr(n) ((n==1)? 1 : pr(n-1))
void main ()
{
int a=5;
cout<<"result: "<< pr(5) <<endl;
getch();
}
Macros don't directly expand recursively, but there are workarounds. When the preprocessor scans and expands pr(5):
pr(5)
^
it creates a disabling context, so that when it sees pr again:
((5==1)? 1 : pr(5-1))
^
it becomes painted blue, and can no longer expand, no matter what we try. But we can prevent our macro from becoming painted blue by using deferred expressions and some indirection:
# define EMPTY(...)
# define DEFER(...) __VA_ARGS__ EMPTY()
# define OBSTRUCT(...) __VA_ARGS__ DEFER(EMPTY)()
# define EXPAND(...) __VA_ARGS__
# define pr_id() pr
# define pr(n) ((n==1)? 1 : DEFER(pr_id)()(n-1))
So now it will expand like this:
pr(5) // Expands to ((5==1)? 1 : pr_id ()(5 -1))
Which is perfect, because pr was never painted blue. We just need to apply another scan to make it expand further:
EXPAND(pr(5)) // Expands to ((5==1)? 1 : ((5 -1==1)? 1 : pr_id ()(5 -1 -1)))
We can apply two scans to make it expand further:
EXPAND(EXPAND(pr(5))) // Expands to ((5==1)? 1 : ((5 -1==1)? 1 : ((5 -1 -1==1)? 1 : pr_id ()(5 -1 -1 -1))))
However, since there is no termination condition, we can never apply enough scans. I'm not sure what you want to accomplish, but if you are curious on how to create recursive macros, here is an example of how to create a recursive repeat macro.
First a macro to apply a lot of scans:
#define EVAL(...) EVAL1(EVAL1(EVAL1(__VA_ARGS__)))
#define EVAL1(...) EVAL2(EVAL2(EVAL2(__VA_ARGS__)))
#define EVAL2(...) EVAL3(EVAL3(EVAL3(__VA_ARGS__)))
#define EVAL3(...) EVAL4(EVAL4(EVAL4(__VA_ARGS__)))
#define EVAL4(...) EVAL5(EVAL5(EVAL5(__VA_ARGS__)))
#define EVAL5(...) __VA_ARGS__
Next, a concat macro which is useful for pattern matching:
#define CAT(a, ...) PRIMITIVE_CAT(a, __VA_ARGS__)
#define PRIMITIVE_CAT(a, ...) a ## __VA_ARGS__
Increment and decrement counters:
#define INC(x) PRIMITIVE_CAT(INC_, x)
#define INC_0 1
#define INC_1 2
#define INC_2 3
#define INC_3 4
#define INC_4 5
#define INC_5 6
#define INC_6 7
#define INC_7 8
#define INC_8 9
#define INC_9 9
#define DEC(x) PRIMITIVE_CAT(DEC_, x)
#define DEC_0 0
#define DEC_1 0
#define DEC_2 1
#define DEC_3 2
#define DEC_4 3
#define DEC_5 4
#define DEC_6 5
#define DEC_7 6
#define DEC_8 7
#define DEC_9 8
Some macros useful for conditionals:
#define CHECK_N(x, n, ...) n
#define CHECK(...) CHECK_N(__VA_ARGS__, 0,)
#define NOT(x) CHECK(PRIMITIVE_CAT(NOT_, x))
#define NOT_0 ~, 1,
#define COMPL(b) PRIMITIVE_CAT(COMPL_, b)
#define COMPL_0 1
#define COMPL_1 0
#define BOOL(x) COMPL(NOT(x))
#define IIF(c) PRIMITIVE_CAT(IIF_, c)
#define IIF_0(t, ...) __VA_ARGS__
#define IIF_1(t, ...) t
#define IF(c) IIF(BOOL(c))
#define EAT(...)
#define EXPAND(...) __VA_ARGS__
#define WHEN(c) IF(c)(EXPAND, EAT)
Putting it all together we can create a repeat macro:
#define REPEAT(count, macro, ...) \
WHEN(count) \
( \
OBSTRUCT(REPEAT_INDIRECT) () \
( \
DEC(count), macro, __VA_ARGS__ \
) \
OBSTRUCT(macro) \
( \
DEC(count), __VA_ARGS__ \
) \
)
#define REPEAT_INDIRECT() REPEAT
//An example of using this macro
#define M(i, _) i
EVAL(REPEAT(8, M, ~)) // 0 1 2 3 4 5 6 7
So, yes with some workarounds you can have recursive macros in C/C++.
Your compiler probably provides an option to only pre-process, not actually compile. This is useful if you are trying to find a problem in a macro. For example using g++ -E:
> g++ -E recursiveMacro.c
# 1 "recursiveMacro.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "recursiveMacro.c"
void main ()
{
int a=5;
cout<<"result: "<< ((5==1)? 1 : pr(5 -1)) <<endl;
getch();
}
As you can see, it is not recursive. pr(x) is only replaced once during pre-processing. The important thing to remember is that all the pre-processor does is blindly replace one text string with another, it doesn't actually evaluate expressions like (x == 1).
The reason your code will not compile is that pr(5 -1) was not replaced by the pre-processor, so it ends up in the source as a call to an undefined function.
You're not supposed to have recursive macros in C or C++.
The relevant language from the C++ standard, section 16.3.4 paragraph 2:
If the name of the macro being replaced is found during this scan of the replacement list (not including the rest of the source file’s preprocessing tokens), it is not replaced. Furthermore, if any nested replacements encounter the name of the macro being replaced, it is not replaced. These nonreplaced macro name preprocessing tokens are no longer available for further replacement even if they are later (re)examined in contexts in which that macro name preprocessing token would otherwise have been replaced.
There's some wiggle room in this language. With multiple macros that invoke one another, there's a grey area where that wording doesn't quite say what should be done. There is an active issue against the C++ standard regarding this language lawyer problem; see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#268 .
Ignoring that language lawyer issue, every compiler vendor understands the intent:
Recursive macros are not allowed in C or in C++.
Most likely you are not able to execute it because you can't compile it. Also if it would compile correctly, it would always return 1. Did you mean (n==1)? 1 : n * pr(n-1).
Macros can't be recursive. According to chapter 16.3.4.2 (thanks Loki Astari), if the current macro is found in the replacement list, it is left as is, thus your pr in the definition will not be changed:
If the name of the macro being replaced is found during this scan of
the replacement list (not including the rest of the source file's pre-
processing tokens), it is not replaced. Further, if any nested
replacements encounter the name of the macro being replaced, it is not
replaced. These nonreplaced macro name preprocessing tokens are no
longer available for further replacement even if they are later
(re)examined in contexts in which that macro name preprocessing token
would otherwise have been replaced.
Your call:
cout<<"result: "<< pr(5) <<endl;
was converted by preprocessor into:
cout<<"result: "<< (5==1)? 1 : pr(5-1) <<endl;
During this, the definition of pr macro is 'lost', and compiler shows an error like "‘pr’ was not declared in this scope (fact)" because there is no function named pr.
Use of macros is not encouraged in C++. Why don't you just write a function?
In this case you could even write a template function so it will be resolved in compile time, and will behave as a constant value:
template <int n>
int pr() { pr<n-1>(); }
template <>
int pr<1>() { return 1; }
TLDR.
True recursion itself is easy done by duplicating macros in two names, with each referencing other. But usefulness of this feature is doubtful, because this requires nested conditional macro to make recursion finite. All conditional macro-operators are essentially multiline, because #else and #endif lines must be separate lines (serious cpp limitation), which means, that conditional macro-definitions are impossible by design (thus, recusion itself would be useless).
You can't have recursive macros in C or C++.
I want to create a recursive Macro the will create the "next" class.
Example:
#define PRINTME(indexNum) class m_##(indexNum+1) { }
The indexNum + 1 is evaluated as an int, and won't concatenate to the class name.
How can I cause the compiler to evaluate that, before concatenating?
If you want to generate unique class names every time the PRINTME is invoked then, following is one way:
#define CONCATE1(X,Y) X##Y
#define CONCATE(X,Y) CONCATE1(X,Y)
#define PRINTME class CONCATE(m_,__COUNTER__) {}
__COUNTER__ is an extension in gcc and I am not sure if it's present in other compilers. It's guaranteed that compiler will add 1 every time this macro is invoked.
(In this case, you cannot use __LINE__ or __FILE__ effectively.)
Demo.
The simple answer is that you can't. The preprocessor generally deals in text and tokens; the only place arithmetic is carried out in in #if and #elif directives.
Also, macro expansion isn't recursive. During expansion, the macro being expanded is disabled, and is not available for further substitution.
Well it is doable, based on your motivation and ability to endure ugly code. First off define increment macro:
#define PLUS_ONE(x) PLUS_ONE_##x
#define PLUS_ONE_0 1
#define PLUS_ONE_1 2
#define PLUS_ONE_2 3
#define PLUS_ONE_3 4
#define PLUS_ONE_4 5
#define PLUS_ONE_5 6
#define PLUS_ONE_7 8
#define PLUS_ONE_8 9
#define PLUS_ONE_9 10
// and so on...
You can't just use PLUS_ONE(x) in concatenation operation, since preprocessor won't expand it. There is a way, however - you can abuse the fact that the preprocessor expands variadic arguments.
// pass to variadic macro to expand an argument
#define PRINTME(indexNum) PRINTME_PRIMITIVE(PLUS_ONE(indexNum))
// do concatenation
#define PRINTME_PRIMITIVE(...) class m_ ## __VA_ARGS__ { }
Done!
PRINTME(1); // expands to class m_2 { };
Have you considered using templates instead?