Related
Take a look at this
#define getFourth( _1,_2,_3, _4,... ) _4 //select the 4th parameter
#define some_type(x) type, x
getFourth
( some_type(1),
some_type(2),
some_type(3)
)
I thought it expands to getFourth(type, 1, type, 2, type, 3) so we shall have 2 selected (since 2 is the 4th parameter). Instead, I got a warning "C4003 not enough actual parameters for macro 'getFourth". It appears that getFourth is treat some_type(1) as the first element, some_type(2) as the 2nd element, some_type(3) as the 3rd. Since it was expecting at least 4 parameters so we have the warning. Can someone please suggest how to fix it?
I thought it expands to getFourth(type, 1, type, 2, type, 3) so we shall have 2 selected (since 2 is the 4th parameter)
That's not how macros work. Macro expansion happens from the outside in. Furthermore, there are two opportunities for expansion: (1) during argument substitution, (2) with the resulting replacement list after that happens. Argument substitution expansion only occurs if the parameter in the macro corresponds to one in the replacement list (and that parameter isn't stringified with the # operator or participating in a paste (##)).
For example, if we had:
#define foo(b,c) b c
getFourth(some_type(1),some_type(2),some_type(3),foo(some_type,(4)),x)
Then getFourth now has 5 parameters, so it can be called. The first step in expansion would be argument substitution; getFourth's replacement list is _4, which only mentions one parameter. The corresponding argument is foo(some_type,(4)). Because _4 isn't being pasted or stringified, the processor can evaluate foo(some_type,(4)). That results in some_type (4), which further expands to type, 4. So now, type, 4 replaces _4. And we're done with argument substitution.
We're left with type, 4. There's one more rescan here, but nothing happens during this step. But note that some_type(1), some_type(2), and some_type(3) not only didn't get evaluated before getFourth, but they didn't get evaluated at all, because nothing in the replacement list mentions them.
Can someone please suggest how to fix it?
So long as the things you want to expand are arguments 1 through 3 of getFourth, they won't even evaluate. But you can make this just a parenthesized list, and then apply the macro, using a trick similar to what I did above:
#define CALL(a,b) a b
CALL(getFourth,(some_type(1),some_type(2),some_type(3))).
Now, getFourth and (some_type(1),some_type(2),some_type(3)) are just arguments to CALL, which mentions both parameters. So during argument substitution, getFourth itself "evaluates" (since this isn't enough to call the object-like macro, it's just left as is), and gets put into a. (some_type(1),some_type(2),some_type(3)) evaluates and gets put into b. That evaluation becomes (type, 1,type, 2,type, 3). So you wind up with getFourth (type, 1,type, 2,type, 3). Now rescan occurs, during which getFourth is called with the arguments you expect.
How should we interpret the following macro definition using the C++ standard? Notice the main issue is that replacement-list for AA contains embedded comma (for, S)
#define AA for, S //<---note the embedded comma
#define VALUE_TO_STRING(x) ^x!
#define VALUE(x) VALUE_TO_STRING(x)
int _tmain(int argc, _TCHAR* argv[])
{
VALUE(AA)
return 0;
}
I've done a test with VC++2010 and the final result of the above looks like the following without any error but I've problem interpreting the steps that it took to come up with the result using C++03 (or C++11) standard:
int wmain(int argc, _TCHAR* argv[])
{
^for, S!
return 0;
}
I've done some step by step tests with VC++2010. First I commented out the 2nd macro to see what was happening in the first step:
#define AA for, S
//#define VALUE_TO_STRING(x) ^x!
#define VALUE(x) VALUE_TO_STRING(x)
The macro replacement is straight forward and yielded a sequence that looks like another function-like macro having TWO arguments:
int wmain(int argc, _TCHAR* argv[])
{
VALUE_TO_STRING(for, S)
return 0;
}
According to [cpp.rescan] the next step is to re-scan this for more macro names. The question here is should this new macro be interpreted as a function-like macro with 2 arguments or 1 argument "for, S".
The normal interpretation is to consider VALUE_TO_STRING() is given 2 arguments which is invalid and hence a preprocessor error is resulted. But how come the VC++ came up with a result without any error? Obviously, the second step VC++ took was to consider the for, S as 1 single argument which doesn't make sense and isn't defined by the C++ standard.
I've done a test with VC++2010...
MS's preprocessor was never made standard. They phrase it this odd way:
C99 __func__ and Preprocessor Rules ... For C99 preprocessor rules, "Partial" is listed because variadic macros are supported.
In other words, "we support variadic macros; therefore we qualify as partially compliant". AFAIK standard compliance for the preprocessor is considered very low priority by the MS team. So I wouldn't tend to use VC or VC++ as a model of the standard preprocessor. gcc's a better model of the standard preprocessor here.
Since this is about the preprocessor I'm going to focus the story on just this snippet:
#define AA for, S
#define VALUE_TO_STRING(x) ^x!
#define VALUE(x) VALUE_TO_STRING(x)
VALUE(AA)
I'll be referencing ISO-14882 2011 here, which uses different numbers than 1998/2003. Using those numbers, here's what happens starting at the expansion step, step by step... except for steps not relevant here which I'll skip.
The preprocessor sees VALUE(AA), which is a function-like invocation of a previously defined function-like macro. So the first thing it does is argument identification, referencing 16.3 paragraph 4:
[if not variadic] the number of arguments (including those arguments consisting of no preprocessing tokens) in an invocation of a function-like macro shall equal the number of parameters in the macro definition
...and a portion of 16.3.1 paragraph 1:
After the arguments for the invocation of a function-like macro have been identified,
At this step, the preprocessor identifies that there is indeed one argument, that the macro was defined with one argument, and that the parameter x matches the invocation argument AA. So far, argument matching and x is AA is all that happened.
Then we get to the next step, which is argument expansion. With respect to this step, the only thing about the replacement list that really matters is where the parameters are in it, and whether or not the parameters are part of stringification (# x) or pasting (x ## ... or ... ## x). If there are arguments in the replacement list that are neither, then those arguments are expanded (stringified or pasted versions of the arguments don't count during this step). This expansion happens first, before anything else interesting goes on in the invocation, and it occurs just as if the preprocessor were only expanding the invocation parameter.
In this case, the replacement list is VALUE_TO_STRING(x). Again, VALUE_TO_STRING might be a function-like macro, but since we're doing argument expansion right now we really don't care. The only thing we care about is that x is there, and it's not being stringified or pasted. x is being invoked with AA, so the preprocessor evaluates AA as if AA were on a line instead of VALUE(AA). AA is an object-like macro that expands to for, S. So the replacement list transforms into VALUE_TO_STRING(for, S).
This is the rest of 16.3.1 paragraph 1 in action:
A parameter in the replacement list, unless [stringified or pasted] is replaced by the corresponding argument after all macros contained therein have been expanded [...] as if they formed the rest of the preprocessing file
So far so good. But now we reach the next part, in 16.3.4:
After all parameters in the replacement list have been substituted and [stuff not happening here] the resulting preprocessing token sequence
is rescanned, along with all subsequent preprocessing tokens of the source file, for more macro names to replace.
This part evaluates VALUE_TO_STRING(for, S), as if that were the preprocessing token set (except that it also temporarily forgets that VALUE is a macro per 16.3.4p2, but that doesn't come into play here). That evaluation recognizes VALUE_TO_STRING as a function-like macro, being invoked like one, so argument identification begins again. Only here, VALUE_TO_STRING was defined to take one argument, but is invoked with two. That fails 16.3 p 4.
I think the answer is in order of expanding.
Your simulation of preprocessor expanding, i.e. your choice of which macro to expand first, does in my opinion not match what the preprocessor does.
I, acting as a preprocessor (according to standard I believed at first; but a comment contradicts), would expand your code in this order:
VALUE(AA)
VALUE_TO_STRING(AA)
^AA!
^for, S!
This matches the result of the preprocessor for the original code.
Note that by this order it never sees the code VALUE_TO_STRING(for, S), the closest it gets is VALUE_TO_STRING(AA). That code does not cause the question concerning the number of arguments.
I did not quote anything from the standard, I think your quotes are sufficient.
As mentioned in a comment below, my answer is now an attempt how the result could be explained, without assuming conforming preprocessor. Any answer explaining with conforming behaviour is definitely better.
By the way, acting as a compiler, I would probably not understand the
^anything! as a way to make a string from a value either. But that is not the question and I assume that the meaning was lost, when you prepared the minimal example. That is of course perfectly allright. It might however influence the expansion, if it ever expands to a quoted macro name, e.g. "AA". That would stop expanding and the result could unveil what happened.
I am trying to write a program where the names of some functions are dependent on the value of a certain macro variable with a macro like this:
#define VARIABLE 3
#define NAME(fun) fun ## _ ## VARIABLE
int NAME(some_function)(int a);
Unfortunately, the macro NAME() turns that into
int some_function_VARIABLE(int a);
rather than
int some_function_3(int a);
so this is clearly the wrong way to go about it. Fortunately, the number of different possible values for VARIABLE is small, so I can simply do an #if VARIABLE == n and list all the cases separately, but is there is a clever way to do it?
Standard C Preprocessor
$ cat xx.c
#define VARIABLE 3
#define PASTER(x,y) x ## _ ## y
#define EVALUATOR(x,y) PASTER(x,y)
#define NAME(fun) EVALUATOR(fun, VARIABLE)
extern void NAME(mine)(char *x);
$ gcc -E xx.c
# 1 "xx.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "xx.c"
extern void mine_3(char *x);
$
Two levels of indirection
In a comment to another answer, Cade Roux asked why this needs two levels of indirection. The flippant answer is because that's how the standard requires it to work; you tend to find you need the equivalent trick with the stringizing operator too.
Section 6.10.3 of the C99 standard covers 'macro replacement', and 6.10.3.1 covers 'argument substitution'.
After the arguments for the invocation of a function-like macro have been identified,
argument substitution takes place. A parameter in the replacement list, unless preceded
by a # or ## preprocessing token or followed by a ## preprocessing token (see below), is
replaced by the corresponding argument after all macros contained therein have been
expanded. Before being substituted, each argument’s preprocessing tokens are
completely macro replaced as if they formed the rest of the preprocessing file; no other
preprocessing tokens are available.
In the invocation NAME(mine), the argument is 'mine'; it is fully expanded to 'mine'; it is then substituted into the replacement string:
EVALUATOR(mine, VARIABLE)
Now the macro EVALUATOR is discovered, and the arguments are isolated as 'mine' and 'VARIABLE'; the latter is then fully expanded to '3', and substituted into the replacement string:
PASTER(mine, 3)
The operation of this is covered by other rules (6.10.3.3 'The ## operator'):
If, in the replacement list of a function-like macro, a parameter is immediately preceded
or followed by a ## preprocessing token, the parameter is replaced by the corresponding
argument’s preprocessing token sequence; [...]
For both object-like and function-like macro invocations, before the replacement list is
reexamined for more macro names to replace, each instance of a ## preprocessing token
in the replacement list (not from an argument) is deleted and the preceding preprocessing
token is concatenated with the following preprocessing token.
So, the replacement list contains x followed by ## and also ## followed by y; so we have:
mine ## _ ## 3
and eliminating the ## tokens and concatenating the tokens on either side combines 'mine' with '_' and '3' to yield:
mine_3
This is the desired result.
If we look at the original question, the code was (adapted to use 'mine' instead of 'some_function'):
#define VARIABLE 3
#define NAME(fun) fun ## _ ## VARIABLE
NAME(mine)
The argument to NAME is clearly 'mine' and that is fully expanded.
Following the rules of 6.10.3.3, we find:
mine ## _ ## VARIABLE
which, when the ## operators are eliminated, maps to:
mine_VARIABLE
exactly as reported in the question.
Traditional C Preprocessor
Robert Rüger asks:
Is there any way do to this with the traditional C preprocessor which does not have the token pasting operator ##?
Maybe, and maybe not — it depends on the preprocessor. One of the advantages of the standard preprocessor is that it has this facility which works reliably, whereas there were different implementations for pre-standard preprocessors. One requirement is that when the preprocessor replaces a comment, it does not generate a space as the ANSI preprocessor is required to do. The GCC (6.3.0) C Preprocessor meets this requirement; the Clang preprocessor from XCode 8.2.1 does not.
When it works, this does the job (x-paste.c):
#define VARIABLE 3
#define PASTE2(x,y) x/**/y
#define EVALUATOR(x,y) PASTE2(PASTE2(x,_),y)
#define NAME(fun) EVALUATOR(fun,VARIABLE)
extern void NAME(mine)(char *x);
Note that there isn't a space between fun, and VARIABLE — that is important because if present, it is copied to the output, and you end up with mine_ 3 as the name, which is not syntactically valid, of course. (Now, please can I have my hair back?)
With GCC 6.3.0 (running cpp -traditional x-paste.c), I get:
# 1 "x-paste.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "x-paste.c"
extern void mine_3(char *x);
With Clang from XCode 8.2.1, I get:
# 1 "x-paste.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 329 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "x-paste.c" 2
extern void mine _ 3(char *x);
Those spaces spoil everything. I note that both preprocessors are correct; different pre-standard preprocessors exhibited both behaviours, which made token pasting an extremely annoying and unreliable process when trying to port code. The standard with the ## notation radically simplifies that.
There might be other ways to do this. However, this does not work:
#define VARIABLE 3
#define PASTER(x,y) x/**/_/**/y
#define EVALUATOR(x,y) PASTER(x,y)
#define NAME(fun) EVALUATOR(fun,VARIABLE)
extern void NAME(mine)(char *x);
GCC generates:
# 1 "x-paste.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "x-paste.c"
extern void mine_VARIABLE(char *x);
Close, but no dice. YMMV, of course, depending on the pre-standard preprocessor that you're using. Frankly, if you're stuck with a preprocessor that is not cooperating, it would probably be simpler to arrange to use a standard C preprocessor in place of the pre-standard one (there is usually a way to configure the compiler appropriately) than to spend much time trying to work out a way to do the job.
Use:
#define VARIABLE 3
#define NAME2(fun,suffix) fun ## _ ## suffix
#define NAME1(fun,suffix) NAME2(fun,suffix)
#define NAME(fun) NAME1(fun,VARIABLE)
int NAME(some_function)(int a);
Honestly, you don't want to know why this works. If you know why it works, you'll become that guy at work who knows this sort of thing, and everyone will come ask you questions. =)
Plain-English explanation of the EVALUATOR two-step pattern
I haven't fully understood every word of the C standard, but I think this is a reasonable working model for how the solution shown in Jonathan Leffler's answer works, explained a little more verbosely. Let me know if my understanding is incorrect, hopefully with a minimal example that breaks my theory.
For our purposes, we can think of macro expansion as happening in three steps:
(prescan) Macro arguments are replaced:
if they are part of concatenation or stringification, they are replaced exactly as the string given on the macro call, without being expanded
otherwise, they are first fully expanded, and only then replaced
Stringification and concatenation happen
All defined macros are expanded, including macros generated in stringification
Step-by-step example without indirection
main.c
#define CAT(x) pref_ ## x
#define Y a
CAT(Y)
and expand it with:
gcc -E main.c
we get:
pref_Y
because:
Step 1: Y is a the macro argument of CAT.
x appears in a stringification pref_ ## x. Therefore, Y gets pasted as is without expansion giving:
pref_ ## Y
Step 2: concatenation happens and we are left with:
pref_Y
Step 3: any further macro replacement happens. But pref_Y is not any known macro, so it is left alone.
We can confirm this theory by actually adding a definition to pref_Y:
#define CAT(x) pref_ ## x
#define Y a
#define pref_Y asdf
CAT(Y)
and now the result would be:
asdf
because on Step 3 above pref_Y is now defined as a macro, and therefore expands.
Step-by-step example with indirection
If we use the two step pattern however:
#define CAT2(x) pref_ ## x
#define CAT(x) CAT2(x)
#define Y a
CAT(Y)
we get:
pref_a
Step 1: CAT is evaluated.
CAT(x) is defined as CAT2(x), so argument x of CAT at the definition does not appear in a stringification: the stringification only happens after CAT2 is expanded, which is not seen in this step.
Therefore, Y is fully expanded before being replaced, going through steps 1, 2, and 3, which we omit here because it trivially expands to a. So we put a in CAT2(x) giving:
CAT2(a)
Step 2: there is no stringification to be done
Step 3: expand all existing macros. We have the macro CAT2(a) and so we go on to expand that.
Step 3.1: the argument x of CAT2 appears in a stringification pref_ ## x. Therefore, paste the input string a as is, giving:
pref_ ## a
Step 3.2: stringify:
pref_a
Step 3: expand any further macros. pref_a is not any macro, so we are done.
GCC argument prescan documentation
GCC's documentation on the matter is also worth a read: https://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html
Bonus: how those rules prevent nested calls from going infinite
Now consider:
#define f(x) (x + 1)
f(f(a))
which expands to:
((a + 1) + 1)
instead of going infinite.
Let's break it down:
Step 1: the outer f is called with argument x = f(a).
In the definition of f, the argument x is not part of a concatenation in the definition (x + 1) of f. Therefore it is first fully expanded before being replaced.
Step 1.1.: we fully expand the argument x = f(1) according to steps 1, 2, and 3, giving x = (a + 1).
Now back in Step 1, we take that fully expanded x argument equaling (a + 1), and put it inside the definition of f giving:
((a + 1) + 1)
Steps 2 and 3: not much happens, because we have no stringification and no more macros to expand.
#define NAME VALUE
I know whenever the compiler see this, it would replace NAME with VALUE. But I'm confused about the working of pre-processing directives such as :
#define CONFIG_VAR(name, type, value)
This does not tell the compiler to replace anything , but I could see statements like
CONFIG_VAR(rank, int, 100)
which would compile successfully. How does this work ?
In your example, that would simply do nothing at all. Any arguments, even those that seem like they should give compilation errors, are accepted and the whole macro call is replaced with an empty string.
If, however, you later replace the definition with something like:
#define CONFIG_VAR(name, type, value) add_config_var<type>(name, value)
it would suddenly do something useful. So, I'd guess that macro is a placeholder for functionality which is not (yet) implemented or not available in that part of the program.
When you say:
#define FOO BAR
what the preprocessor does is to replace each time after this it sees the text FOO by the text BAR, a macro definition. The process is called macro expansion. This is mostly used to define constants, like:
#define N 128
#define MASK (~(1 << 4))
It can be (ab)used to do very funky stuff, as it knows nothing of expressions, statements, or anything. So:
#define CONST (1 + 3 << (x))
is actually OK, and will expand to (1 + 3 << (x)) each time it is seen, using the current value of x each time. Also gunk like:
#define START 5 * (1 +
#define END + 5)
followed by START 2 + 3 + 4 END predictably gives 5 * (1 + 2 + 3 + 4 +5)`
There is also the option of defining macros with parameters, like:
#define BAD_SQUARE(x) x * x
which, if called as BAD_SQUARE(a) will expand to a * a. But BAD_SQUARE(a + b) expands to a + b * a + b, which isn't what was intended (presumably...).
This comes from the dark ages of C, today's C/C++ have safer/cleaner mechanisms to get the same result (use const in C++, in C it sadly defines a variable, not a real constant; use inline functions in C/C++ or templates in C++). There is too much code out there that uses this preprocessor usage (and too many fingers who write this way) so it is practically impossible to get rid of this. As a rule of thumb, learn to read code using macros, whiel learning to write code without them (as far as reasonable, there are times when they come mighty handy...).
This is a macro (more common in C than in C++). According to the definition you provided, the preprocessor will remove occurrences of that "function". A common use-case is usually for logging:
#ifdef DEBUG
#define dprintf(...) printf(...)
#else
#define dprintf(...) // This will remove dprintf lines
#endif
In C++, I believe the general convention is to use inline functions as they provide the same value performance-wise, but are also type checked.
If this really is the entire macro definition, then it simply defines this function-like macro to expand to nothing (an empty string). For example, in the source,
CONFIG_VAR(rank, int, 100);
will be transformed into
;
In this case pre-processor simply removes such strings (replaces with nothing). Widely enough used technique.
Here is example where it is important (actually only one of possible usages):
#if DEBUG_ON
#define LOG(level, string) SomeLogger(level, string)
#else
#define LOG(level, string)
#endif
Probably you should get more familiar with C preprocessor.
There is somewhat close technique (X macro) which builds code which handles repeating lists based on defined actions.
At: C++ FAQ - Miscellaneous technical issues - [39.6] What should be done with macros that need to paste two tokens together?
Could someone explain to me why? All I read is trust me, but I simply can't just trust on something because someone said so.
I tried the approach and I can't find any bugs appearing:
#define mymacro(a) int a ## __LINE__
mymacro(prefix) = 5;
mymacro(__LINE__) = 5;
int test = prefix__LINE__*__LINE____LINE__; // fine
So why do I need to do it like this instead (quote from the webpage):
However you need a double layer of indirection when you use ##.
Basically you need to create a special macro for "token pasting" such
as:
#define NAME2(a,b) NAME2_HIDDEN(a,b)
#define NAME2_HIDDEN(a,b) a ## b
Trust me on this — you really need to do
this! (And please nobody write me saying it sometimes works without
the second layer of indirection. Try concatenating a symbol with
__ LINE__ and see what happens then.)
Edit: Could someone also explain why he uses NAME2_HIDDEN before it's declared below? It seems more logical to define NAME2_HIDDEN macro before I use it. Is it some sort of trick here?
The relevant part of the C spec:
6.10.3.1 Argument substitution
After the arguments for the invocation of a function-like macro have been identified,
argument substitution takes place. A parameter in the replacement list, unless preceded
by a # or ## preprocessing token or followed by a ## preprocessing token (see below), is
replaced by the corresponding argument after all macros contained therein have been
expanded. Before being substituted, each argument’s preprocessing tokens are
completely macro replaced as if they formed the rest of the preprocessing file; no other
preprocessing tokens are available.
The key part that determines whether you want the double indirection or not is the second sentence and the exception in it -- if the parameter is involved in a # or ## operation (such as the params in mymacro and NAME2_HIDDEN), then any other macros in the argument are NOT expanded prior to doing the # or ##. If, on the other hand, there's no # or ## IMMEDIATELY in the macro body (as with NAME2), then other macros in the parameters ARE expanded.
So it comes down to what you want -- sometimes you want all macros expanded FIRST, and then do the # or ## (in which case you want the double layer indirection) and sometime you DO NOT want the macros expanded first (in which case you CAN'T HAVE double layer macros, you need to do it directly.)
__LINE__ is a special macro that is supposed to resolve to the current line number. When you do a token paste with __LINE__ directly, however, it doesn't get a chance to resolve, so you end up with the token prefix__LINE__ instead of, say, prefix23, like you would probably be expecting if you would write this code in the wild.
Chris Dodd has an excellent explanation for the first part of your question. As for the second part, about the definition sequence, the short version is that #define directives by themselves are not evaluated at all; they are only evaluated and expanded when the symbol is found elsewhere in the file. For example:
#define A a //adds A->a to the symbol table
#define B b //adds B->b to the symbol table
int A;
#undef A //removes A->a from the symbol table
#define A B //adds A->B to the symbol table
int A;
The first int A; becomes int a; because that is how A is defined at that point in the file. The second int A; becomes int b; after two expansions. It is first expanded to int B; because A is defined as B at that point in the file. The preprocessor then recognizes that B is a macro when it checks the symbol table. B is then expanded to b.
The only thing that matters is the definition of the symbol at the point of expansion, regardless of where the definition is.
The most non-technical answer, which I gathered from all links here, and link of links ;) is that, a single layer indirection macro(x) #x stringifies the inputted macro's name, but by using double layers, it will stringify the inputted macro's value.
#define valueOfPi 3
#define macroHlp(x) #x
#define macro(x) macroHlp(x)
#define myVarOneLayer "Apprx. value of pi = " macroHlp(valueOfPi)
#define myVarTwoLayers "Apprx. value of pi = " macro(valueOfPi)
printf(myVarOneLayer); // out: Apprx. value of pi = valueOfPi
printf(myVarOTwoLayers); // out: Apprx. value of pi = 3
What happens at printf(myVarOneLayer)
printf(myVarOneLayer) is expanded to printf("Apprx. value of pi = " macroHlp(valueOfPi))
macroHlp(valueOfPi) tries to stringify the input, the input itself is not evaluated. It's only purpose in life is to take an input and stringify. So it expands to "valueOfPi"
So, what happens at printf(myVarTwoLayers)
printf(myVarTwoLayers) is expanded to printf("Apprx. value of pi = " macro(valueOfPi)
macro(valueOfPi) has no stringification operation, i.e. there is no #x in it's expansion, but there is an x, so it has to evaluate x and input the value to macroHlp for stringification. It expands to macroHlp(3) which in turn will stringify the number 3, since it is using #x
The order in which macros are declared is not important, the order in which they are used is. If you were to actually use that macro before it was declared -- (in actual code that is, not in a macro which remains dormant until summoned) then you would get an error of sorts but since most sane people don't go around doing these kinds of things, writing a macro and then writing a function that uses a macro not yet defined further down, etc,etc... It seems your question isn't just one question but I'll just answer that one part. I think you should have broken this down a little more.