usage of ## for macro string catenation

[ziyan]

Hello all,

I'm trying to write a macro that will let me access the fields of a
struct variable, given the field name as a parameter. I tried the
follwing which produces the desired result when run thru gnu cpp, but
it complains and stops.

#define ref(var,field) var. ## field

struct mystruct {
int i;
char c;
};

int main (void) {
struct mystruct aaa;
ref(aaa,i) = 1;
}

Any help is greatly appreciated.
___
Regards,
Ziyan Maraikar
Vrije Universiteit, Amsterdam.

 

[Walter Roberson]

I'm trying to write a macro that will let me access the fields of a
struct variable, given the field name as a parameter. I tried the
follwing which produces the desired result when run thru gnu cpp, but
it complains and stops.

#define ref(var,field) var. ## field

The gcc message is along the lines of,

pasting "." and "i" does not give a valid preprocessing token

which is accuate. ## is used to create new tokens, and period is
not a possible character in a preprocessor token.

For your purposes, just use

#define ref(var,field) var.field

 

[ziyan]

Hi Walter

Thanx for the tip.

For your purposes, just use

#define ref(var,field) var.field

Hmm...seems obvious enough. Guess I assumed macro replacement only
works on whitespace separated tokens.

BTW I came up with a nice hack for a hashtable I implemented using this
technique:

typedef struct {
enum {INT, FLOAT, STRING} type;
union {
int INT;
float FLOAT;
char *STRING;
} value;
} Hashobject;

typedef struct {
char *key;
Hashobject object;
short chain;
} Hashentry;

#define hash_add(_ht, _key, _value, _type){\
Hashentry _he; \
_he.key = _key; \
_he.object.type = _type; \
_he.object.value._type = _value;\
hash_addentry (_ht, _he); \
}

int hash_addentry (Hashtable *ht, Hashentry ent);

 

[Keith Thompson]

Hmm...seems obvious enough. Guess I assumed macro replacement only
works on whitespace separated tokens.

[snip]

As far as the compiler is concerned, tokens are tokens, and spaces
between them are often optional. Just as "x + y" and "x+y" are
equivalent, "var . field" is equivalent to "var.field". (As a matter
of style, of course, "var . field" is ugly.)

 

[Eric Sosman]

Hmm...seems obvious enough. Guess I assumed macro replacement only
works on whitespace separated tokens.

[snip]

As far as the compiler is concerned, tokens are tokens, and spaces
between them are often optional. Just as "x + y" and "x+y" are
equivalent, "var . field" is equivalent to "var.field". (As a matter
of style, of course, "var . field" is ugly.)

... which raises the question of why anyone would
want to write `ref(var,field)' instead of `var.field'.
Maybe I'm blind, but I don't see the attraction ...

 

[Keith Thompson]

For your purposes, just use

#define ref(var,field) var.field

Hmm...seems obvious enough. Guess I assumed macro replacement only
works on whitespace separated tokens.

[snip]

As far as the compiler is concerned, tokens are tokens, and spaces
between them are often optional. Just as "x + y" and "x+y" are
equivalent, "var . field" is equivalent to "var.field". (As a matter
of style, of course, "var . field" is ugly.)

... which raises the question of why anyone would
want to write `ref(var,field)' instead of `var.field'.
Maybe I'm blind, but I don't see the attraction ...

By itself, it doesn't make much sense, but if ziyan's article upthread
shows a hash table macro that uses it. The macro has several
arguments, and it's not obvious from a call that one of them happens
to be a member name