«

A question recently came up of late in some interviewing techniques
discussions and I vaguely remember this being an ANSI C++ related issue
but cannot remember the specifics. Basically if you have the following:

#define foo(x) x*x

..
..
..

foo(3+2);

Beside the obvious feau paux of not wrapping the macro parameter in
parens, the common misconception is the actual macro side affect - i.e.
the addition will take place before the substitution:

i.e. foo(3+2) = foo(5) = 5*5 = 25

Deeper insight believes that the substitution will take place first:

i.e. foo(3+2) = 3+2*3+2 = 3+(2*3)+2 = 11

However, it is my understanding the preprocessors can actually combine
literals (it's left to the implementation) giving a result of the
original first inclination:

i.e. foo(3+2) = foo(5) = 5*5 = 25

Now, in this case the point would be moot (and thuis the side affect
generated) if these were variables and not interger literals:

i.e.
int y= 3;
int z = 2;
foo(y+z) = y+z*y+z = y+(z*y)+z = (at run time) 3+(2*3)+2 = 11

Anyway, the question comes down to whether or not the preprocessor is
allowed to do mathematical calculations on integer literals. Anybody
know?

wrote:
> A question recently came up of late in some interviewing techniques
> discussions and I vaguely remember this being an ANSI C++ related
> issue but cannot remember the specifics. Basically if you have the
> following:
>
> #define foo(x) x*x
>
> .
> .
> .
>
> foo(3+2);
>
> Beside the obvious feau paux of not wrapping the macro parameter in
> parens, the common misconception is the actual macro side affect -
> i.e. the addition will take place before the substitution:
>
> i.e. foo(3+2) = foo(5) = 5*5 = 25
>
> Deeper insight believes that the substitution will take place first:
>
> i.e. foo(3+2) = 3+2*3+2 = 3+(2*3)+2 = 11
>
> However, it is my understanding the preprocessors can actually combine
> literals (it's left to the implementation) giving a result of the
> original first inclination:
>
> i.e. foo(3+2) = foo(5) = 5*5 = 25
>
> Now, in this case the point would be moot (and thuis the side affect
> generated) if these were variables and not interger literals:
>
> i.e.
> int y= 3;
> int z = 2;
> foo(y+z) = y+z*y+z = y+(z*y)+z = (at run time) 3+(2*3)+2 = 11
>
> Anyway, the question comes down to whether or not the preprocessor is
> allowed to do mathematical calculations on integer literals. Anybody
> know?

The Standard mandates the order of things happening in "2.1 Phases of
translation" which states that the source file is decomposed into
preprocessing tokens, then directives are executed and macros are
expanded. No tranlsation happens between decomposing into tokens (step
3) and substituting macros (step 4). All translation happens _after_
the processing steps 1 through 6 are done.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

OK - wish I had the standard to clarify as I don't quite understand
your response. The three items you state don't (seemingly) deal with
integer literas but "preprocessing tokens, then directives are executed
and macros are expanded". In this case are we talking the mathematical
work on integer literals are tokens or translations?

Victor Bazarov wrote:
> wrote:
> > A question recently came up of late in some interviewing techniques
> > discussions and I vaguely remember this being an ANSI C++ related
> > issue but cannot remember the specifics. Basically if you have the
> > following:
> >
> > #define foo(x) x*x
> >
> > .
> > .
> > .
> >
> > foo(3+2);
> >
> > Beside the obvious feau paux of not wrapping the macro parameter in
> > parens, the common misconception is the actual macro side affect -
> > i.e. the addition will take place before the substitution:
> >
> > i.e. foo(3+2) = foo(5) = 5*5 = 25
> >
> > Deeper insight believes that the substitution will take place first:
> >
> > i.e. foo(3+2) = 3+2*3+2 = 3+(2*3)+2 = 11
> >
> > However, it is my understanding the preprocessors can actually combine
> > literals (it's left to the implementation) giving a result of the
> > original first inclination:
> >
> > i.e. foo(3+2) = foo(5) = 5*5 = 25
> >
> > Now, in this case the point would be moot (and thuis the side affect
> > generated) if these were variables and not interger literals:
> >
> > i.e.
> > int y= 3;
> > int z = 2;
> > foo(y+z) = y+z*y+z = y+(z*y)+z = (at run time) 3+(2*3)+2 = 11
> >
> > Anyway, the question comes down to whether or not the preprocessor is
> > allowed to do mathematical calculations on integer literals. Anybody
> > know?
>
> The Standard mandates the order of things happening in "2.1 Phases of
> translation" which states that the source file is decomposed into
> preprocessing tokens, then directives are executed and macros are
> expanded. No tranlsation happens between decomposing into tokens (step
> 3) and substituting macros (step 4). All translation happens _after_
> the processing steps 1 through 6 are done.
>
> V
> --
> Please remove capital 'A's when replying by e-mail
> I do not respond to top-posted replies, please don't ask

wrote:
> Victor Bazarov wrote:
>> wrote:

[snipped question about whether arithmetic computations on literals are
performed before or after macro substitution]

>>
>>The Standard mandates the order of things happening in "2.1 Phases of
>>translation" which states that the source file is decomposed into
>>preprocessing tokens, then directives are executed and macros are
>>expanded. No tranlsation happens between decomposing into tokens (step
>>3) and substituting macros (step 4). All translation happens _after_
>>the processing steps 1 through 6 are done.

> OK - wish I had the standard to clarify as I don't quite understand
> your response. The three items you state don't (seemingly) deal with
> integer literas but "preprocessing tokens, then directives are
> executed
> and macros are expanded". In this case are we talking the mathematical
> work on integer literals are tokens or translations?

Mathematical computation is clearly not part of the tokenization
process, as tokenization means breaking a text into smaller tokens that
will be processed one at a time. The tokenizer doesn't know anything
about the semantics of the language constructs. Concerning your original
question I have to say that mathematical computations on literals are
performed _after_ the expansion of macros, thus it is non-conforming if
preprocessors do anything else but macro expansion or sources including.

>>
>>V
>>--
>>Please remove capital 'A's when replying by e-mail
>>I do not respond to top-posted replies, please don't ask

Had you not top-posted your reply, you may had got an answer from Victor
(who has certainly better knowledge of these issues than I).

Regards,
Stuart

* :
> Anyway, the question comes down to whether or not the preprocessor is
> allowed to do mathematical calculations on integer literals. Anybody
> know?

Not in ordinary macro expansion.

However, the controlling expression of an #if or #elif is an integral
constant expression, which is evaluated by the preprocessor.

So, the literal answer is "yes", but the answer in the context of
ordinary macro expansion is "no", except when the macro is used as a
controlling expression for an #if or #elif (in which case it's expanded
before the preprocessor evaluates the expression).

Hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Thanks y'all!

Alf P. Steinbach wrote:
> * :
> > Anyway, the question comes down to whether or not the preprocessor is
> > allowed to do mathematical calculations on integer literals. Anybody
> > know?
>
> Not in ordinary macro expansion.
>
> However, the controlling expression of an #if or #elif is an integral
> constant expression, which is evaluated by the preprocessor.
>
> So, the literal answer is "yes", but the answer in the context of
> ordinary macro expansion is "no", except when the macro is used as a
> controlling expression for an #if or #elif (in which case it's expanded
> before the preprocessor evaluates the expression).
>
> Hth.,
>
> - Alf
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is it such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?