pointer of pointer

[qianz99]

Hi

I have a structure, B_t is another structure

typedef struct{
int len;
unsigned char code[12];
B_t *b;
}A_t

Now I need to pass A_t into a function to evaluate
I use pointer of pointer

void evaluate(A_t **a)

My question is how to evaluate the component of this structure

(*a)->b???

seems not right

Thanks a lot!

 

[Malcolm McLean]

Hi

I have a structure, B_t is another structure

typedef struct{
int len;
unsigned char code[12];
B_t *b;
}A_t

Now I need to pass A_t into a function to evaluate
I use pointer of pointer

void evaluate(A_t **a)

My question is how to evaluate the component of this structure

(*a)->b???

seems not right

It is right. It is ugly and so you might be better off with

A_t *aptr;
aptr = *a;

aptr->b;

Code that a machine can read correctly isn't necessarily easy for humans to
read. The extra variable will almost certainly be optimised away by the
compiler, so there is unlikely to be any efficiency penalty.

 

[jg]

My question is how to evaluate the component of this structure

(*a)->b???

It accesses member b of A_t, which a pointer to B_t. Whether
it is right or not depends upon what you mean by 'evaluate'.

JG

 

[Army1987]

It is right. It is ugly and so you might be better off with

A_t *aptr;
aptr = *a;

aptr->b;

Code that a machine can read correctly isn't necessarily easy for humans
to read. The extra variable will almost certainly be optimised away by the
compiler, so there is unlikely to be any efficiency penalty.

I can't see how that is so much clearer than (*a)->b than you
claim. I can't see any way fou a human to misinterpret such an
expression.

 

[Malcolm McLean]

I can't see how that is so much clearer than (*a)->b than you
claim. I can't see any way fou a human to misinterpret such an
expression.

By itself it is not too bad, as long as the reader is familiar with C.
The problem comes when it is incorporated into longer expressions. You can
very easily produce code which is perfectly machine parseable, but too hard
to read.

 

[Ian Collins]

By itself it is not too bad, as long as the reader is familiar with C.
The problem comes when it is incorporated into longer expressions. You
can very easily produce code which is perfectly machine parseable, but
too hard to read.

The problem is they are easy too write at the time. Too few developers
invest the time go back and refactor what they have written once it "works".

 

[Malcolm McLean]

The problem is they are easy too write at the time. Too few developers
invest the time go back and refactor what they have written once it
"works".

My current policy is to publicly release all reuseable code. So that forces
me to clean it up and modularise it. However it is easier said than done.
I've got an awful lot of stuff hanging around which for various reasons
hasn't made it onto the website.