C Language, Structure Pointer Dereferencing

Rohi
#1 / 13

Structure Pointer Dereferencing

Dear All,

Is it a good practice to *strictly* avoid dereferencing of structure
pointers inside your code ?

I recently came across this neat trick to do the same.

To access the fields of structures, I use the following macros:

#define V(a) ((void)0,(a))
typedef struct foo_1 foo_1;

struct foo_1
{
type_1 f_1 ; // fields
type_2 f_2;
.
.

Quote:

};

#define dereferencer_1(a) (a)

// following macro used to set fields
#define x_f_1_foo_1(a) (dereferencer_1(a)->f_1)
.....
.....
.....
#define x_f_n_foo_1(a) (dereferencer_1(a)->f_n)

// to read a field
#define f_1_foo_1(a) V(x_f_1_foo_1(a))
.......
......
#define f_n_foo_1(a) V(x_f_n_foo_1(a))

Can any one point out the flaws in this approach? Any
ideas/alternatives to do the same?

Regards,
Rohit
--

Fri, 18 Feb 2005 11:40:43 GMT

Richard Heathfiel
#2 / 13

Structure Pointer Dereferencing

Quote:

> Dear All,

> Is it a good practice to *strictly* avoid dereferencing of structure
> pointers inside your code ?

Why should it be? I don't understand why you think this.

Quote:

> I recently came across this neat trick to do the same.

> To access the fields of structures, I use the following macros:

> #define V(a) ((void)0,(a))
> typedef struct foo_1 foo_1;

> struct foo_1
> {
> type_1 f_1 ; // fields
> type_2 f_2;
> .
> .

> };

> #define dereferencer_1(a) (a)

> // following macro used to set fields
> #define x_f_1_foo_1(a) (dereferencer_1(a)->f_1)
> .....
> .....
> .....
> #define x_f_n_foo_1(a) (dereferencer_1(a)->f_n)

> // to read a field
> #define f_1_foo_1(a) V(x_f_1_foo_1(a))
> .......
> ......
> #define f_n_foo_1(a) V(x_f_n_foo_1(a))

> Can any one point out the flaws in this approach?

All those macros, all those underscores, all that typing.

Quote:

> Any
> ideas/alternatives to do the same?

a->f_n seems to me to be a vast improvement over the other options you
present here.

--

"UsenX-Mozilla-Status: 0009" - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Fri, 18 Feb 2005 14:02:31 GMT

Gordon Burdi
#3 / 13

Structure Pointer Dereferencing

Quote:

>Is it a good practice to *strictly* avoid dereferencing of structure
>pointers inside your code ?

No. And what makes you think your approach avoids dereferencing
of structure pointers?

Quote:

>I recently came across this neat trick to do the same.

NEAT trick? I think it qualifies as a MESSY trick to the LONG_MAX
power.

Quote:

>To access the fields of structures, I use the following macros:

>#define V(a) ((void)0,(a))

Pointless macro.

Quote:

>typedef struct foo_1 foo_1;

>struct foo_1
>{
> type_1 f_1 ; // fields
> type_2 f_2;

This is an absolutely horrible and useless naming convention.

Quote:

> .
> .

>};

>#define dereferencer_1(a) (a)

Another pointless macro.

Quote:

>// following macro used to set fields
>#define x_f_1_foo_1(a) (dereferencer_1(a)->f_1)
>.....
>.....
>.....
>#define x_f_n_foo_1(a) (dereferencer_1(a)->f_n)

>// to read a field
>#define f_1_foo_1(a) V(x_f_1_foo_1(a))
>.......
>......
>#define f_n_foo_1(a) V(x_f_n_foo_1(a))

This naming convention is designed to make the code impossible to
read, right?

Quote:

>Can any one point out the flaws in this approach? Any
>ideas/alternatives to do the same?

Please explain what it is you are trying to accomplish, besides
obfuscation. If the point IS obfuscation, you have done a good job
accomplishing it.

Gordon L. Burditt

Fri, 18 Feb 2005 14:21:26 GMT

Ben Pfaf
#4 / 13

Structure Pointer Dereferencing

Quote:

> Is it a good practice to *strictly* avoid dereferencing of structure
> pointers inside your code ?

No. Who gave you that idea? There is nothing wrong with
dereferencing structure pointers.

Quote:

> I recently came across this neat trick to do the same.

> To access the fields of structures, I use the following macros:

> #define V(a) ((void)0,(a))

I suppose you're using this to transform an lvalue into an
rvalue? You might have noted so, because otherwise it's a
useless no-op.

Quote:

> #define dereferencer_1(a) (a)

This macro, however, seems truly pointless.

Quote:

> // following macro used to set fields
> #define x_f_1_foo_1(a) (dereferencer_1(a)->f_1)

So this is an lvalue that can be used to modify a member.

Quote:

> // to read a field
> #define f_1_foo_1(a) V(x_f_1_foo_1(a))

And this is an rvalue that cannot. Very clever.

Quote:

> Can any one point out the flaws in this approach? Any
> ideas/alternatives to do the same?

The main flaw is that in general the complication isn't worth
it. A secondary flaw is that the names are unreadable.
--
"It would be a much better example of undefined behavior
if the behavior were undefined."
--Michael Rubenstein
--

Sun, 20 Feb 2005 23:47:50 GMT

Douglas A. Gwy
#5 / 13

Structure Pointer Dereferencing

Quote:

> Can any one point out the flaws in this approach?

Yes, it seems completely insane.
--

Sun, 20 Feb 2005 23:47:55 GMT

Richard Heathfiel
#6 / 13

Structure Pointer Dereferencing

Quote:

> Dear All,

> Is it a good practice to *strictly* avoid dereferencing of structure
> pointers inside your code ?

Why should it be? I don't understand why you think this.

Quote:

> I recently came across this neat trick to do the same.

> To access the fields of structures, I use the following macros:

> #define V(a) ((void)0,(a))
> typedef struct foo_1 foo_1;

> struct foo_1
> {
> type_1 f_1 ; // fields
> type_2 f_2;
> .
> .

> };

> #define dereferencer_1(a) (a)

> // following macro used to set fields
> #define x_f_1_foo_1(a) (dereferencer_1(a)->f_1)
> .....
> .....
> .....
> #define x_f_n_foo_1(a) (dereferencer_1(a)->f_n)

> // to read a field
> #define f_1_foo_1(a) V(x_f_1_foo_1(a))
> .......
> ......
> #define f_n_foo_1(a) V(x_f_n_foo_1(a))

> Can any one point out the flaws in this approach?

All those macros, all those underscores, all that typing.

Quote:

> Any
> ideas/alternatives to do the same?

a->f_n seems to me to be a vast improvement over the other options you
present here.

--

"UsenX-Mozilla-Status: 0009" - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
--

Sun, 20 Feb 2005 23:47:57 GMT

Gordon Airpor
#7 / 13

Structure Pointer Dereferencing

The only thing you need to avoid when using struct pointers
is making assumptions about their alignment in memory.
Otherwise use
myStruct.item
or
ptr2mystruct->item
--

Sun, 20 Feb 2005 23:48:34 GMT

k..
#8 / 13

Structure Pointer Dereferencing

Quote:

>> Dear All,

>> Is it a good practice to *strictly* avoid dereferencing of structure
>> pointers inside your code ?

> Why should it be? I don't understand why you think this.

It's possible that some mangled description of opaque pointer types
for representation hiding was misexplained to him.

IE you may have a data type - let's say an applicative expression tree
for code - for which there are operators eg tagOf(tree), nargsOf(tree),
element(tree,n) and so on. You may wish to implement these by having
Tree be pointer-to-struct, but since you have in mind hacking this
deeply later, not allowing

tree->tag

all over your code - so you wrap it in a [-n inline would be nice] function,
or macro, outside the defining module.

I've done this; it made hacking the expression trees in my not-that-one
Spice compiler *much* easier.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

Mon, 21 Feb 2005 17:08:45 GMT

Richard Heathfiel
#9 / 13

Structure Pointer Dereferencing

Quote:

> Dear All,

> Is it a good practice to *strictly* avoid dereferencing of structure
> pointers inside your code ?

Why should it be? I don't understand why you think this.

Quote:

> I recently came across this neat trick to do the same.

> To access the fields of structures, I use the following macros:

> #define V(a) ((void)0,(a))
> typedef struct foo_1 foo_1;

> struct foo_1
> {
> type_1 f_1 ; // fields
> type_2 f_2;
> .
> .

> };

> #define dereferencer_1(a) (a)

> // following macro used to set fields
> #define x_f_1_foo_1(a) (dereferencer_1(a)->f_1)
> .....
> .....
> .....
> #define x_f_n_foo_1(a) (dereferencer_1(a)->f_n)

> // to read a field
> #define f_1_foo_1(a) V(x_f_1_foo_1(a))
> .......
> ......
> #define f_n_foo_1(a) V(x_f_n_foo_1(a))

> Can any one point out the flaws in this approach?

All those macros, all those underscores, all that typing.

Quote:

> Any
> ideas/alternatives to do the same?

a->f_n seems to me to be a vast improvement over the other options you
present here.

--

"UsenX-Mozilla-Status: 0009" - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
--

Sat, 23 Apr 2005 12:20:23 GMT

Allin Cottrel
#10 / 13

Structure Pointer Dereferencing

Quote:

>>Is it a good practice to *strictly* avoid dereferencing of structure
>>pointers inside your code ?

> Why should it be? I don't understand why you think this.

Agreed. We seem to have had a rash of this nonsense on c.l.c. lately.
Is it something in the water?

Allin Cottrell.

Sat, 23 Apr 2005 12:27:15 GMT

k..
#11 / 13

Structure Pointer Dereferencing

Quote:

>> Dear All,

>> Is it a good practice to *strictly* avoid dereferencing of structure
>> pointers inside your code ?

> Why should it be? I don't understand why you think this.

I think I know why.

Sometimes - quite often, in the kind of code I've written, but "sometimes"
is good enough - you know in advance that you *don't* know in advance what
the most effective layout for your structures is; but you *do* know what
the abstract operations you want to perform are. For example, you may wish
to represent an expression tree with operations like

smint n make me a tree representing the "small" integer n
id s make me a tree representing the identifier s
infix x op y make me a tree representing op(x,y)

left x get me the left operand of an infix node
right x ditto, right

Although `left` and `right` might well end up being implemented as

x->leftOperand [etc]

they might also be implemented as

(BASE(t)[ARG_left].vim)

with further clever (or not) thinks happening in `BASE`. To allow the
representation to change without requiring grungy hacking of the dependant
code, we wrap the accesses in macros or functions, so that the user code
never gets to use -> on trees.

As usual, a powerful tactic in the hands of the experienced can be
converted, by a kind of tutorial decay, into a Rule Without Exceptions.
Look! If you never write x->f in your code, always writing f'(x) [where
the ' of f' is there to sort out the scoping issues], then you will
never have to change the code if you change the use of ->!

Well, yes. But there's little point in avoiding the -> in the code
that *implements* trees, and there's little point in avoiding the ->
for which -> is the obvious and natural long-term answer.

Quote:

>> To access the fields of structures, I use the following macros:

And there's *no* point in just systematically replacing the ->s with
macros - the whole point of the abstraction layer is not to hide the
-> operation, but to wrap up an entire "abstract" operation.

Quote:

> All those macros, all those underscores, all that typing.

With *no payback*. Abstract datatypes are useful and powerful and
elegant, and one can wish for more support for them in C - without
going down the C++ road - but one doesn't get them by just hiding
->; it needs *thought*.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

Sat, 23 Apr 2005 17:46:28 GMT

Richard Heathfiel
#12 / 13

Structure Pointer Dereferencing

Quote:

> >> Dear All,

> >> Is it a good practice to *strictly* avoid dereferencing of structure
> >> pointers inside your code ?

> > Why should it be? I don't understand why you think this.

> I think I know why.

> Sometimes

STOP RIGHT THERE! I GOTTA KNOW RIGHT NOW! BEFORE WE GO ANY FURTHER...
er, excuse me a moment...

[switches off Meat Loaf CD, adjusts precariously-balanced coffee-mug,
coughs attentively]

Chris, before we go any further, I have no problem with "sometimes", or
even "often". It's this "strictly" that I'm objecting to.

--

"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Sat, 23 Apr 2005 18:03:27 GMT

k..
#13 / 13

Structure Pointer Dereferencing

Quote:

>> >> Dear All,

>> >> Is it a good practice to *strictly* avoid dereferencing of structure
>> >> pointers inside your code ?

>> > Why should it be? I don't understand why you think this.

>> I think I know why.

>> Sometimes

> STOP RIGHT THERE! I GOTTA KNOW RIGHT NOW! BEFORE WE GO ANY FURTHER...
> er, excuse me a moment...

> [switches off Meat Loaf CD, adjusts precariously-balanced coffee-mug,
> coughs attentively]

You swine. Here I am at work, with most of my mod cons at home. (I can't
get much music into the Jornada.) At least I haven't got a cough.

Quote:

> Chris, before we go any further, I have no problem with "sometimes", or
> even "often". It's this "strictly" that I'm objecting to.

Yes, I understand ...

Quote:

> <excellent discussion snipped reluctantly>

... the "strictly" comes from Tutorial Decay. In other words, people
go for the "strictly" because of a good practice with choices decaying
into a Rule Without Exceptions.

The same effect is observable in discussions on the writing of fiction,
as meta-discussed in rec.arts.sf.composition, for example.

--
Chris "blushing" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

Sat, 23 Apr 2005 20:22:48 GMT