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

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

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

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.

This macro, however, seems truly pointless.

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

And this is an rvalue that cannot.  Very clever.

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

Yes, it seems completely insane.
--

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