Re: #define and (brackets)

Tech-Archive recommends: Fix windows errors by optimizing your registry

"Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote in message
news:ug9Hi0WUJHA.592@xxxxxxxxxxxxxxxxxxxxxxx
That's what I have warned against. That separate preprocessing and
compilation is NOT the same as one-shot preprocessing and compilation.

Per ANSI C standard, there is NO re-pre-process (NO re-tokenization).

So then you would characterize such behaviour as "a bug".

The compiler doesn't second-guess. It just follows the standard. May not
always be doing that, but in these cases it does.

Let me show you again:
cl /E test.cpp :

line0: int main(int,...) {
line1: printf("%d", --10);
line2: return 0;
line3: }

Please explain why line1 compiles under the current standard. Is it
compliant, compileable standard ANSI C code?

By the way, I don't see what's the point in your stringizing example.
Operator # replaces the whole proprocessing token sequence for an argument
with a string.

You don't see the point? I was trying to show that the preprocessor
evaluates MACRO arguments during the process of preprocessing. If a macro
argument is not re-used as an argument (or otherwise) in another macro then
it is NOT evaluated. That's why STRIZE(NUM) --> "NUM" and _STRIZE(NUM)_ -->
"-10". NUM gets evaluated (dereferenced) during preprocessing in the second
case, but NOT the first.

Know what I mean? If NUM appears in a macro it becomes -10, if it doesn't it
remains as NUM. Don't you think that might have some RELEVANCE here when

#define X -1
int main(int,...)
{
return -X;
}

compiles fine, but

#define X -1
#define Y -X

int main(int,....)
{
return Y;
}

doesn't?

- Alan Carre


.

Relevant Pages

  • Standards question regarding intrinsics with complex arguments
    ... these arguments) is not permitted by the Fortran 95 standard. ... 1501-510 Compilation successful for file test_cmplx.f90. ... I believe the code in question is standard Fortran95 and that the compiler is ... A kind type parameter ...
    (comp.lang.fortran)
  • Re: C# -- Good or Bad?
    ... ECMA standard. ... These implementations use JIT compilation, ... > need languages which allow to work close to the hardware, ... Finally, I'd note that in some cases, interpretation can actually ...
    (comp.lang.cpp)
  • Re: Separating evaluation and compilation environments.
    ... compilation and evaluation environments long before that. ... a baz definition and expanding out the foo macro forces you to recompile ... that definition if you redefine foo but intend to use baz again. ...
    (comp.lang.lisp)
  • Re: Inconsistent Program Results
    ... including one of them might trivially slow down compilation, ... I wrote the above (starting with "The standard headers"). ... return void, but there's no advantage in using that. ... You're cheating yourself by ignoring warning messages. ...
    (comp.lang.c)
  • Re: Question about compilation/evaluation environments
    ... I guess it depends on what you mean by evaluating some code. ... In this case, the form is the macro function, aka macro ... >> expander, aka expansion function... ... compilation of function and macro definitions. ...
    (comp.lang.lisp)