By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,889 Members | 1,259 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,889 IT Pros & Developers. It's quick & easy.

Purpose of #define inside struct definition?

P: n/a

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;

May 8 '07 #1
Share this Question
Share on Google+
12 Replies


P: n/a
dj****@gmail.com wrote:
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.
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.
May 8 '07 #2

P: n/a
dj****@gmail.com wrote:
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.)

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
May 8 '07 #3

P: n/a
On 8 May, 15:45, Christopher Benson-Manica <a...@otaku.freeshell.org>
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.)
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.

May 8 '07 #4

P: n/a
Christopher Benson-Manica wrote:
dj****@gmail.com 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.
--
clvrmnky

Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.
May 8 '07 #5

P: n/a
On Tue, 8 May 2007 14:45:35 +0000 (UTC), Christopher Benson-Manica
<at***@otaku.freeshell.orgwrote:
>dj****@gmail.com wrote:
>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.)
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.

--
Al Balmer
Sun City, AZ
May 8 '07 #6

P: n/a
Al Balmer <al******@att.netwrote:
On Tue, 8 May 2007 14:45:35 +0000 (UTC), Christopher Benson-Manica

#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. */
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.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
May 8 '07 #7

P: n/a
Christopher Benson-Manica <at***@otaku.freeshell.orgwrote:
Al Balmer <al******@att.netwrote:
On Tue, 8 May 2007 14:45:35 +0000 (UTC), Christopher Benson-Manica
>
>#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. */
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.
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
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
May 8 '07 #8

P: n/a
In article <5a*************@mid.uni-berlin.de>,
Jens Thoms Toerring <jt@toerring.dewrote:
>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.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
May 8 '07 #9

P: n/a
On May 8, 9:53 am, mark_blue...@pobox.com wrote:
On 8 May, 15:45, Christopher Benson-Manica <a...@otaku.freeshell.org>
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

May 8 '07 #10

P: n/a
Dave Hansen <id**@hotmail.comwrote:
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".

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
May 8 '07 #11

P: n/a
Christopher Benson-Manica <at***@otaku.freeshell.orgwrites:
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.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
May 9 '07 #12

P: n/a
dj****@gmail.com wrote:
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.
--
pa at panix dot com
May 9 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.