macros - C

borophyll wrote:
> Hi
>
> Can anyone explain why the output of the following code:
>
> #define A 1
> #define B 2
> A.B
>
> after preprocessing only, is:
>
> 1 . 2
>
> Why does the preprocessor put spaces between each character, when the
> macro invocation has none?

The preprocessor is often -- and incorrectly -- said to
operate on the text of the program's source code. In fact,
it operates on tokens (formally, "preprocessing tokens")
that have been derived from the text. These tokens simply
come one after another, pretty maids all in a row; they do
not need to be separated by spaces. Equally, though, they
do not magically combine with each other just because they
happen to be adjacent.

So: By the time the sample code reaches the preprocessor,
it has been divided into three tokens which we may represent as

A

borophyll wrote:
>
> Hi
>
> Can anyone explain why the output of the following code:
>
> #define A 1
> #define B 2
> A.B
>
> after preprocessing only, is:
>
> 1 . 2
>
> Why does the preprocessor put spaces between each character, when the
> macro invocation has none?

Why did you put a dot in between A and B?

What should AB mean?

--
pete

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> borophyll wrote:
>> Hi
>> Can anyone explain why the output of the following code:
>> #define A 1
>> #define B 2
>> A.B
>> after preprocessing only, is:
>> 1 . 2
>> Why does the preprocessor put spaces between each character, when the
>> macro invocation has none?
>
> The preprocessor is often -- and incorrectly -- said to
> operate on the text of the program's source code. In fact,
> it operates on tokens (formally, "preprocessing tokens")
> that have been derived from the text. These tokens simply
> come one after another, pretty maids all in a row; they do
> not need to be separated by spaces. Equally, though, they
> do not magically combine with each other just because they
> happen to be adjacent.
[...]

Quite correct.

However, some preprocessors are *implemented* as text-to-text
translators; they take input text, ****yze it as a sequence of
preprocessor tokens, and generate output text that is then ****yzed by
later compiler phases a a sequence of tokens.

In this case, the preprocessor implementation inserts blanks between
'1', '.', and '2' precisely so that the next phase will see them as
distinct tokens, rather than as a single token '1.2' (a floating
constant).

The fact that the preprocessor implementation allows you to see its
output is just an extra feature, not required by the language. It
could just as correctly have produced a sequence of tokens in some
binary form, as long as the next compilation phase is able to
interpret that form as tokens.

(Historically, of course, the preprocessor was a separate program that
did text processing, as it still is in some implementations. This
stuff about "preprocessor tokens" and "tokens" is a formalization of
what it does; text-to-text processing is now just one way to implement
that formalized process.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Aug 23, 12:01 pm, CBFalconer <cbfalco...@yahoo.com> wrote:

> Because that is specified by the C standard.

Care to quote which part?

regards, B

borophyll wrote:

> Hi
>
> Can anyone explain why the output of the following code:
>
> #define A 1
> #define B 2
> A.B
>
> after preprocessing only, is:
>
> 1 . 2
>
> Why does the preprocessor put spaces between each character, when the
> macro invocation has none?
>
> Regards, B
may be you want this:
A##.##B /* No dots will be */

On 23 août, 08:39, Ivan Gotovchits <ivan.gotovch...@auriga.ru> wrote:
> boroph... wrote:
> > Hi
>
> > Can anyone explain why the output of the following code:
>
> > #define A 1
> > #define B 2
> > A.B
>
> > after preprocessing only, is:
>
> > 1 . 2
>
> > Why does the preprocessor put spaces between each character, when the
> > macro invocation has none?
>
> > Regards, B
>
> may be you want this:
> A##.##B /* No dots will be */

This doesn't work and gives 1##.##2

#define AB(a,b) AB_(a,b)
#define AB_(a,b) a ## . ## b

AB(A,B) -> 1.2

a+, ld.

Are the # and ## operators only allowed within a macro definition?

B.

borophyll wrote:
>
> Hi
>
> Can anyone explain why the output of the following code:
>
> #define A 1
> #define B 2
> A.B
>
> after preprocessing only, is:
>
> 1 . 2
>
> Why does the preprocessor put spaces between each character, when the
> macro invocation has none?

Strange... My compiler's preprocessor outputs "1.B". (No spaces,
but it failed to expand "B".) Is it broken?

Note that it does replace "A->B" with "1->2", which is why I may not
have noticed this before. I do have code with macros for struct
entries, but they're probably all within pointers.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap>

Kenneth Brody <kenbrody@spamcop.net> writes:
> borophyll wrote:
>> Can anyone explain why the output of the following code:
>>
>> #define A 1
>> #define B 2
>> A.B
>>
>> after preprocessing only, is:
>>
>> 1 . 2
>>
>> Why does the preprocessor put spaces between each character, when the
>> macro invocation has none?
>
> Strange... My compiler's preprocessor outputs "1.B". (No spaces,
> but it failed to expand "B".) Is it broken?

Probably, but it's hard to be certain by looking at the output of the
preprocessor, which is normally internal to the compiler. The token
sequence 1 . 2 can't appear in a legal program; if the behavior
doesn't affect any legal programs, and doesn't cause the compiler to
fail to issue a diagnostic for some program with a syntax error or
constraint violation, then strictly speaking it's not a bug as far as
the C standard is concerned. (If your preprocessor has an additional
requirement to generate textual output, it may be a bug if it doesn't
meet that requirement correctly.)

Try the following program. It should print "ok".

#define A a
#define B b
int main(void)
{
struct { int b; } a;
a.b = 42;
if (A.B == 42) {
puts("ok");
}
else {
puts("bug");
}
return 0;
}

But here A and B expand to identifiers, not integer constants, so if
there is a bug this may not trigger it.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"