Structure Pointer Dereferencing 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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.

<excellent discussion snipped reluctantly>

--

"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  
 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  
 
 [ 13 post ] 

 Relevant Pages 

1. Structure Pointer Dereferencing

2. dereferencing pointer to a structure containing a pointer to int

3. Pointers to structures & Dereferencing

4. Dereferencing f-pointers, arrays of f-pointers, pointers to f-pointers

5. Dereferencing pointer to incomplete type

6. Problem with: dereferencing pointer to incomplete type

7. dereferencing NULL pointers in AIX

8. Dereferencing pointers...?

9. dereferencing NULL pointers and string functions

10. "dereferencing pointer to incomplete type"

11. struct datatype scope (dereferencing pointer to incomplete type)

12. Function pointer dereferencing

 

 
Powered by phpBB® Forum Software