Token pasting and a little more

I'm taking a serious look at the Borland Compiler. I'm not that happy anymore with mingw as, it seems, its not entirely ANSI/ISO compliant. I may decide to buy BCB 6 Pro in a few days.

Anyway, while reading the documentation for the Borland compiler I came across the Token Pasting functionality and 3 questions came to my mind which had no answer over there.

1. Why exactly would I want to use Token Pasting. It seems rather confusing to me, especially the example they give:

From Borland Compiler documentation
#define VAR(i, j) (i##j)
the call VAR(x, 6) expands to (x6). This replaces the older nonportable method of using (i/**/j)

2. At which point during the parsing process does comment strip occur? Before or after preprocessor directives parsing.

3. Does Token Pasting have an ANSI/ISO definition or is it exclusive to Borland compiler?

The operators # and ## are ANSI-C (at least according to my book they are)

The # precedes a parameter name. It causes double quotes to be placed around the argument substituted for the parameter. For example

Code:

#define DUMPINT(x)    printf(#x "=%i\n", x)
becomes....
printf("x" "=%i\n", x)
so when you have
DUMPINT(mynumber)
you'll actually be saying
printf("mynumber" "=%i\n", mynumber)

The ## turns two tokens into a single token. For example:

Code:

#define DISPLAY(x, t)    print ## t (#x, x)
If you call this using
DISPLAY(i, int)
it first expands to
print ## int ("i", i)
then to 
printint("i",i)

In this example we have created a function name based on parameters to the macro.

I don't expect this type of code is used much at *newbie* level. It serves to confuse until you are comfortable with C in general (imho).

Originally posted by Hammer
I don't expect this type of code is used much at *newbie* level. It serves to confuse until you are comfortable with C in general (imho). [/B]

I agree. But you answered it in a way I could understand. That alone is good enough for me.

Just one thing though. More for curiosity than anything else. I understand the very first thing to occur at compile time is the parsing of preprocessor directives, then macros, then whitespaces, and so forth. But I couldn't locate any info on at which point does comment stripping occur. Just by looking, it seems to me it should occur before whitspaces parsing... is this correct?

Just by looking, it seems to me it should occur before whitspaces parsing... is this correct?

The quick answer is I don't know. But I'd hazard a guess by saying it's compiler dependant, and really doesn't make much difference to the programmer.

I can understand your curiosity, but try not to get bogged down in too much detail that isn't really related to C/C++ directly.

>I'm not that happy anymore with mingw as, it seems, its not entirely ANSI/ISO compliant.
None of them are, find the switch that turns on ANSI checking for your compiler and live with the fact that there is no such thing as a truly ANSI/ISO compliant compiler. I also recommend a flavor of Lint for further checking.

>2. At which point during the parsing process does comment strip
>occur? Before or after preprocessor directives parsing.
Before. It's much easier to parse a well formatted file than one littered with worthless comments, so most compilers will strip all comments from the source before doing any parsing. This drastically speeds up the parsing stage since the comments don't have to be ignored, they just aren't there. Of course, this is the most logical method but I can't tell you for sure whether or not all compilers use it.

>3. Does Token Pasting have an ANSI/ISO definition or is it exclusive to Borland compiler?
It is an ANSI/ISO feature.

-Prelude

Originally posted by Prelude
None of them are, find the switch that turns on ANSI checking for your compiler and live with the fact that there is no such thing as a truly ANSI/ISO compliant compiler. I also recommend a flavor of Lint for further checking.

Hehe... the eternal "f**k standards" by software companies... It's amazing.

Anyway, it's not that i'm a standards freak or something that is prepared to shell $1,000 just because you are allowed to declare an array dimensions with a variable, (like int array[myvar]), under mingw... although, I must say, it irritated me since i'm learning C++ and the last thing I need is a syntax prostitute compiler.

It's more that I'm a gadget freak (aka geek) and really need/want the extra features that RADs like BC or VC offer.

> I'm not that happy anymore with mingw as, it seems, its not entirely ANSI/ISO compliant
Try adding

-ansi -pedantic

to the command line
As far as I know, mingw is a derivative of the GNU compiler (which has these options).

The order of events is described here
5.1.1.2 Translation phases
in
http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/

Thanks Salem!

It took me a while to reply as I've been busy...

It didn't allow me to compile that array with those 2 parameters added. Complained as it should. It's funny being happy because it doesn't compile

But you want to know the irony of it all?
stdlib.h also poped up with errors... LOL

Also, thanks for the link. Bookmarked.

#define DISPLAY(x, t) print ## t (#x, x)
If you call this using
DISPLAY(i, int)
it first expands to
print ## int ("i", i)
then to
printint("i",i)

Wow! That is freaking amazing! How come I haven't read about it before? I've read a few books and NONE of them went over anything like that!

Are there any other uses for the # and ## operators? For example, some functionality I always looked for... turning a variable name into a string? Hmm, I doubt this would be possible, as variable names are lost when you compile.

Yep, the # operator.

int abc=4;
cout<<#abc;//outputs abc