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]

In article <11*********************@o13g2000cwo.googlegroups. com>,
ziyan <zi****@gmail.com> wrote:

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
--
Studies show that the average reader ignores 106% of all statistics
they see in .signatures.

[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]

"ziyan" <zi****@gmail.com> writes:

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.)

--
Keith Thompson (The_Other_Keith) ks***@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.

[Eric Sosman]

Keith Thompson wrote:

"ziyan" <zi****@gmail.com> writes:

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 ...

--
Er*********@sun.com

[Keith Thompson]

Eric Sosman <er*********@sun.com> writes:

Keith Thompson wrote:

"ziyan" <zi****@gmail.com> writes:

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

--
Keith Thompson (The_Other_Keith) ks***@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.