Purpose of #define inside struct definition?

[djhong]

Following is a snippet of a header file.
Here, #define are inside struct evConn{}

Any advantage of putting them inside struct block?
Looks like there is no diff in scoping of each identifier between
inside and outside struct block....

typedef struct evConn {
evConnFunc func;
void * uap;
int fd;
int flags;
#define EV_CONN_LISTEN 0x0001 /* Connection is a listener. */
#define EV_CONN_SELECTED 0x0002 /* evSelectFD(conn->file). */
#define EV_CONN_BLOCK 0x0004 /* Listener fd was blocking. */
evFileID file;
struct evConn * prev;
struct evConn * next;
} evConn;

 

[Ian Collins]

Following is a snippet of a header file.
Here, #define are inside struct evConn{}

Any advantage of putting them inside struct block?

Probably written this way to show the flags are associated with the
flags member of the struct.

 

[Christopher Benson-Manica]

Any advantage of putting them inside struct block?

What Ian said...

#define EV_CONN_LISTEN 0x0001 /* Connection is a listener. */
#define EV_CONN_SELECTED 0x0002 /* evSelectFD(conn->file). */
#define EV_CONN_BLOCK 0x0004 /* Listener fd was blocking. */

Just from a style perspective, I might personally prefer these to be

#define EV_CONN_LISTEN ( 0x0001 << 0 ) /* Connection is a listener. */
#define EV_CONN_SELECTED ( 0x0001 << 1 ) /* evSelectFD(conn->file). */
#define EV_CONN_BLOCK ( 0x0001 << 2 ) /* Listener fd was blocking. */

to clearly indicate that they are bitmask flags, but I imagine this
isn't your code anyway - just a thought. (And to see how silly an
idea others feel this is.)

 

[mark_bluemel]

Just from a style perspective, I might personally prefer these to be

#define EV_CONN_LISTEN ( 0x0001 << 0 ) /* Connection is a listener. */
#define EV_CONN_SELECTED ( 0x0001 << 1 ) /* evSelectFD(conn->file). */
#define EV_CONN_BLOCK ( 0x0001 << 2 ) /* Listener fd was blocking. */

to clearly indicate that they are bitmask flags, but I imagine this
isn't your code anyway - just a thought. (And to see how silly an
idea others feel this is.)

Hmmm. I'm not convinced ...

If you've got enough experience to recognize bitmask flags, you
probably recognize that powers of 2 map to them...

I find your shift-base values look a little "clunky", but that's just
my 2p worth.

 

[Clever Monkey]

(e-mail address removed) wrote: [...]

#define EV_CONN_LISTEN 0x0001 /* Connection is a listener. */
#define EV_CONN_SELECTED 0x0002 /* evSelectFD(conn->file). */
#define EV_CONN_BLOCK 0x0004 /* Listener fd was blocking. */

Just from a style perspective, I might personally prefer these to be

#define EV_CONN_LISTEN ( 0x0001 << 0 ) /* Connection is a listener. */
#define EV_CONN_SELECTED ( 0x0001 << 1 ) /* evSelectFD(conn->file). */
#define EV_CONN_BLOCK ( 0x0001 << 2 ) /* Listener fd was blocking. */

to clearly indicate that they are bitmask flags, but I imagine this
isn't your code anyway - just a thought. (And to see how silly an
idea others feel this is.)

Not silly at all! Very readable. Though, when I read "0x0004" I see
the binary value anyway, so it is less of a magic number for me. Must
have been all those base conversions I was forced to do by hand in school.

Since it is hidden behind a #define, one doesn't get the immediate sense
of "this bit over there" anyway, so I'd still have to read the
definition and remember that this define meant that bit pattern.

 

[Al Balmer]

What Ian said...


Just from a style perspective, I might personally prefer these to be

#define EV_CONN_LISTEN ( 0x0001 << 0 ) /* Connection is a listener. */
#define EV_CONN_SELECTED ( 0x0001 << 1 ) /* evSelectFD(conn->file). */
#define EV_CONN_BLOCK ( 0x0001 << 2 ) /* Listener fd was blocking. */

to clearly indicate that they are bitmask flags, but I imagine this
isn't your code anyway - just a thought. (And to see how silly an
idea others feel this is.)

I wouldn't call it silly, but I wouldn't do it. Anyone who works with
bitmasks has the patterns embedded in their brain anyway. I find your
version somewhat less readable.

 

[Christopher Benson-Manica]

I wouldn't call it silly, but I wouldn't do it. Anyone who works with
bitmasks has the patterns embedded in their brain anyway. I find your
version somewhat less readable.

At a place I used to work, the left-shift-X metaphor was widespread,
so I suppose I simply got used to the style. Judging by the other
responses, it seems that style was more idiosyncratic than I realized
at the time.

 

[Jens Thoms Toerring]

At a place I used to work, the left-shift-X metaphor was widespread,
so I suppose I simply got used to the style. Judging by the other
responses, it seems that style was more idiosyncratic than I realized
at the time.

But there are also cases were the left-shift-X way can help avoid
mistakes. If you have e.g. a 32-but wide hardware register which
says "Bit 23: set this bit to enable interrupts" then it tends to
be simpler to just use the number from the documentation and write

#define IRQ_ENABLE ( 1 << 23 )

than to calculate which hex number that corresponds to.

Regards, Jens

 

[Walter Roberson]

But there are also cases were the left-shift-X way can help avoid
mistakes. If you have e.g. a 32-but wide hardware register which
says "Bit 23: set this bit to enable interrupts" then it tends to
be simpler to just use the number from the documentation and write

#define IRQ_ENABLE ( 1 << 23 )

than to calculate which hex number that corresponds to.

True -- but still error prone if the bits are numbered the other way,
or there are padding bits to worry about.

 

[Dave Hansen]

On 8 May, 15:45, Christopher Benson-Manica <[email protected]>
wrote: [...]

Just from a style perspective, I might personally prefer these to be

#define EV_CONN_LISTEN ( 0x0001 << 0 ) /* Connection is a listener. */
#define EV_CONN_SELECTED ( 0x0001 << 1 ) /* evSelectFD(conn->file). */
#define EV_CONN_BLOCK ( 0x0001 << 2 ) /* Listener fd was blocking. */

to clearly indicate that they are bitmask flags, but I imagine this
isn't your code anyway - just a thought. (And to see how silly an
idea others feel this is.)

Hmmm. I'm not convinced ...

If you've got enough experience to recognize bitmask flags, you
probably recognize that powers of 2 map to them...

I find your shift-base values look a little "clunky", but that's just
my 2p worth.

I have a utility macro that I use in several projects that looks
something like this:

#define mBit(b) (1U<<(b))

So the above would become

#define EV_CONN_LISTEN mBit(0)) /* Connection is a
listener. */
#define EV_CONN_SELECTED mBit(1)) /* evSelectFD(conn-

file). */

#define EV_CONN_BLOCK mBit(2) /* Listener fd was
blocking. */

Fairly self-documenting, and a little less clunky-looking. IMHO,
anyway.

Regards,

-=Dave

 

[Christopher Benson-Manica]

I have a utility macro that I use in several projects that looks
something like this:

#define mBit(b) (1U<<(b))

So the above would become

#define EV_CONN_LISTEN mBit(0))

^

#define EV_CONN_SELECTED mBit(1))

^

#define EV_CONN_BLOCK mBit(2)

Nothing's quite as clunky as "wrong" Seriously, I rather agree
with your assessment (oops, snipped it - sorry) that this is less
clunky, although I'm not especially enamored with the name "mBit".

 

[Michal Nazarewicz]

Just from a style perspective, I might personally prefer these to be

#define EV_CONN_LISTEN ( 0x0001 << 0 ) /* Connection is a listener. */
#define EV_CONN_SELECTED ( 0x0001 << 1 ) /* evSelectFD(conn->file). */
#define EV_CONN_BLOCK ( 0x0001 << 2 ) /* Listener fd was blocking. */

to clearly indicate that they are bitmask flags, but I imagine this
isn't your code anyway - just a thought. (And to see how silly an
idea others feel this is.)

Personally, I find this method easier to edit. If I have like 20
masks it's easier to delete one from the middle or rearrange them when
they are written using (1 << n) idiom.

 

[Pierre Asselin]

Following is a snippet of a header file.
Here, #define are inside struct evConn{}

Any advantage of putting them inside struct block?
Documentation.


Looks like there is no diff in scoping of each identifier between
inside and outside struct block....

Yes, but in your snippet the #define'd constants occurred right after
the "int flags" member, so their purpose is obvious.