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]

<qi*****@gmail.comwrote in message
news:11**********************@y80g2000hsf.googlegr oups.com...

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.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[jg]

On May 11, 1:36 pm, [e-mail] wrote:

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]

"Malcolm McLean" <re*******@btinternet.comha scritto nel messaggio
news:g7******************************@bt.com...

>>

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]

"Army1987" <pl********@for.itwrote in message
news:f2**********@tdi.cu.mi.it...

>
"Malcolm McLean" <re*******@btinternet.comha scritto nel messaggio
news:g7******************************@bt.com...

>>>

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.

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.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ian Collins]

Malcolm McLean wrote:

>
"Army1987" <pl********@for.itwrote in message
news:f2**********@tdi.cu.mi.it...

>>
"Malcolm McLean" <re*******@btinternet.comha scritto nel messaggio
news:g7******************************@bt.com...

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

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

--
Ian Collins.

[Malcolm McLean]

"Ian Collins" <ia******@hotmail.comwrote in message
news:5a*************@mid.individual.net...

Malcolm McLean wrote:

>>
"Army1987" <pl********@for.itwrote in message
news:f2**********@tdi.cu.mi.it...

>>>
"Malcolm McLean" <re*******@btinternet.comha scritto nel messaggio
news:g7******************************@bt.com.. .
>
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.

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

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.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm