Typdef pointers to structs or not?

[Johan Tibell]

Could someone outline the pros and cons of typedefing pointers to
structs like this?

typedef struct exp_ {
int val;
struct exp_ *child;
} *exp;

(This is straight from memory so it might not even compile.)

The use case is AST representation which makes heavy use of pointers to
structs (in fact IIRC it only uses pointers, never plain structs).
Right now I don't use typedefs since I read in the Linux kernel coding
guidelines that (the author believes) that it obfuscates what's really
going on. Note that pretty much every function in the compiler will
modify these structs so either the whole typedef will be in a .h file
or a bunch of access functions are needed.

[Bill Pursell]

Re: Typdef pointers to structs or not?


Johan Tibell wrote:

Could someone outline the pros and cons of typedefing pointers to
structs like this?
>
typedef struct exp_ {
int val;
struct exp_ *child;
} *exp;

pros:

allows a programmer that is writing code that uses
the structure to save a few keystrokes.

cons:

causes the maintenance programmer some
aggravation upon realization that an exp is a pointer,
which would have been obvious had the
objects been declared explictly.



Personally, I think the typedef is not helpful in these cases.

[Chris Dollin]

Re: Typdef pointers to structs or not?

Johan Tibell wrote:

Could someone outline the pros and cons of typedefing pointers to
structs like this?
>
typedef struct exp_ {
int val;
struct exp_ *child;
} *exp;
>
(This is straight from memory so it might not even compile.)
>
The use case is AST representation which makes heavy use of pointers to
structs (in fact IIRC it only uses pointers, never plain structs).
Right now I don't use typedefs since I read in the Linux kernel coding
guidelines that (the author believes) that it obfuscates what's really
going on. Note that pretty much every function in the compiler will
modify these structs so either the whole typedef will be in a .h file
or a bunch of access functions are needed.

Cons:
some C programmers don't like it
it's harder to tell whether something is a pointer or not

Pros:
easier to treat as a purely abstract type

For me, the (pro) is a no-brainer. Other programmers in other contexts
may reasonably feel differently.

In your particular circumstances -- expression trees -- I have in
fact "typedefed pointers", for exactly the abstract type reason:
I changed the representation later so that an Exp wasn't
a pointer (and, IIRC, changed it back later later). Having stray
*'s all over the place would have made that rather trickier.

[Access to the fields was in any case via functions-which-might-be-macros,
so -vs . vs getWossname wasn't an issue.]

--
Chris "seeker" Dollin
A rock is not a fact. A rock is a rock.

[Michael Wojcik]

Re: Typdef pointers to structs or not?


In article <1154001469.978 557.270070@h48g 2000cwc.googleg roups.com>, "Johan Tibell" <johan.tibell@g mail.comwrites:

Could someone outline the pros and cons of typedefing pointers to
structs like this?
>
typedef struct exp_ {
int val;
struct exp_ *child;
} *exp;

This is a religious issue which has been hotly debated a number of
times on comp.lang.c. GIYF; for example:

http://groups.google.com/group/comp.lang.c/browse_frm/thread/341cf36d2ef82b01/3c5d2682bb789321

or
http://tinyurl.com/kauj6

(I suggest beginning with the first message from pete, which is
the start of the discussion of the style issue.)

http://groups.google.com/group/comp.lang.c/browse_frm/thread/63acfd89ded4f18b/860c9baab59f2511

or
http://tinyurl.com/ky7st

(The style discussion begins with the first message from Keith.)


Personally, I dislike typedef except when it is necessary (to extract
certain types of argument from a variadic argument list; I can't
think of any other cases offhand). I think they serve no useful
purpose and encourage certain poor practices that are prevented by
using "struct", which is C's actual facility for creating new types,
both visible and abstract. And typedefs which disguise pointer-
nature are even worse, as far as I'm concerned.

In this opinion I am joined, to some degree, by Keith Thompson and
Chris Torek. But others disagree, as you can see in the discussions
I cited.

--
Michael Wojcik michael.wojcik@ microfocus.com

Do not "test" parts, as this may compromise sensitive joinery. Those who
suffer difficulty should abandon the enterprise immediately. -- Chris Ware

[Keith Thompson]

Re: Typdef pointers to structs or not?

Chris Dollin <chris.dollin@h p.comwrites:

Johan Tibell wrote:

>Could someone outline the pros and cons of typedefing pointers to
>structs like this?
>>
>typedef struct exp_ {
> int val;
> struct exp_ *child;
>} *exp;
>>
>(This is straight from memory so it might not even compile.)
>>
>The use case is AST representation which makes heavy use of pointers to
>structs (in fact IIRC it only uses pointers, never plain structs).
>Right now I don't use typedefs since I read in the Linux kernel coding
>guidelines that (the author believes) that it obfuscates what's really
>going on. Note that pretty much every function in the compiler will
>modify these structs so either the whole typedef will be in a .h file
>or a bunch of access functions are needed.

>
Cons:
some C programmers don't like it
it's harder to tell whether something is a pointer or not
>
Pros:
easier to treat as a purely abstract type
>
For me, the (pro) is a no-brainer. Other programmers in other contexts
may reasonably feel differently.
>
In your particular circumstances -- expression trees -- I have in
fact "typedefed pointers", for exactly the abstract type reason:
I changed the representation later so that an Exp wasn't
a pointer (and, IIRC, changed it back later later). Having stray
*'s all over the place would have made that rather trickier.
>
[Access to the fields was in any case via functions-which-might-be-macros,
so -vs . vs getWossname wasn't an issue.]

IMHO, typedefing a pointer makes sense if and only if it's really to
be treated as a purely abstract type. This means that if you're
writing code that uses it, you don't, and shouldn't, even know that
it's a pointer. You never dereference it or perform arithmetic on it,
except through functions provided as part of the abstract type's
interface.

In the example above, if client code, having declared
exp x;
will ever refer to x->val or x->child, or do "x = malloc(sizeof *x);"
or "free(x)", then the type should visibley be a pointer type.

If, on the other hand, the interface is restricted to things like
x = new_exp();
set_val(x, 42);
then it could make sense to hide the pointer-ness behind a typedef.

If the interface could be re-written to make exp a structure rather
than a pointer, with no required changes in the client code, then it's
purely abstract.

<OT>
Some languages encourage a different style. For example, in some
languages most or all declarations that create new types create a
single-identifier name for them. In such a language, I'd feel more
comfortable about hiding a type's nature behind a single identifier.
But in C, most code that uses a type depends intimately on the nature
of the type; completely hiding the nature of a type is more difficult,
and partially hiding it is likely to be futile.
</OT>

(Incidentally, I'd call it "expr" rather than "exp"; "exp" is a
function declared in <math.h>.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[SM Ryan]

Re: Typdef pointers to structs or not?

"Johan Tibell" <johan.tibell@g mail.comwrote:
# Could someone outline the pros and cons of typedefing pointers to
# structs like this?

In the dark days before Unix, there used to be this thing called
a cross reference table. The premise was the compiler had to
match up declarations and references and determine the type of
identifiers, so why not print that out so programmers could use it
as reference? Of course Unix went beyond all that nonsense, instead
depending on grep and tags and programmer memory. (You already know
that the reason for the style of putting function type on one line
and function name on the the next was solely to make it easier
to write the tags program and to make /^functionname work in vi?)

A throwback to the dark days before Unix might suggest once again
making the compiler symbol table available to other programs, and
even to modify state of the art edittors like vi so that say when
the mouse moves over an identifier it can show you where it was
declared, its type and storage and other properties, etc? Or is
such an old fashionned concept of letting the computer do all the
hard work for you just too primitive a concept?

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Elvis was an artist. But that didn't stop him from joining the service
in time of war. That's why he is the king, and you're a shmuck.

[Jack Klein]

Re: Typdef pointers to structs or not?

On 27 Jul 2006 04:57:50 -0700, "Johan Tibell" <johan.tibell@g mail.com>
wrote in comp.lang.c:

Could someone outline the pros and cons of typedefing pointers to
structs like this?
>
typedef struct exp_ {
int val;
struct exp_ *child;
} *exp;
>
(This is straight from memory so it might not even compile.)
>
The use case is AST representation which makes heavy use of pointers to
structs (in fact IIRC it only uses pointers, never plain structs).
Right now I don't use typedefs since I read in the Linux kernel coding
guidelines that (the author believes) that it obfuscates what's really
going on. Note that pretty much every function in the compiler will
modify these structs so either the whole typedef will be in a .h file
or a bunch of access functions are needed.

NOT!!!

I am truly against typedefs for pointers to objects, except in a few
special cases. The potential confusion outweighs the gain. Note that
the one truly opaque ADT in the C standard, namely FILE, is still
defined as an object, and one defines objects of type FILE * to use
it.

But there are special cases. The double pointer ** notation itself
can cause confusion, or at best require the reader to slow down and
take care.

So I have some implementations where a typedef is used for an object
pointer type, generally a pointer to void. But this is used in
interfaces only. The typedef is only used in client code if it is
never dereferenced as such.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

[Herbert Rosenau]

Re: Typdef pointers to structs or not?

On Thu, 27 Jul 2006 11:57:50 UTC, "Johan Tibell"
<johan.tibell@g mail.comwrote:

Could someone outline the pros and cons of typedefing pointers to
structs like this?
>
typedef struct exp_ {
int val;
struct exp_ *child;
} *exp;

I would use always pure uppercase for self defined names. This flags
the reader of the source that it is truly not a variable name but a
type as it is positionished were a macro would commonly not possible.

To distinguish between a type representing a variable and a type
representing a pointer to a variable I'm trained since 16 years by the
defaults my OS uses:

- a receeding P that can not easy interpreted as member of the type
name presents a _p_ointer name.
So

typedef struct exp {
int val;
struct exp_ *child;
} EXP, *PEXP;

defines 2 different types:

A variable of struct exp

EXP exp;
PEXP head = &exp;

and a ponter to a struct exp;



--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[ena8t8si@yahoo.com]

Re: Typdef pointers to structs or not?


Michael Wojcik wrote:

In article <1154001469.978 557.270070@h48g 2000cwc.googleg roups.com>, "Johan Tibell" <johan.tibell@g mail.comwrites:

Could someone outline the pros and cons of typedefing pointers to
structs like this?

typedef struct exp_ {
int val;
struct exp_ *child;
} *exp;

>
This is a religious issue which has been hotly debated a number of
times on comp.lang.c.

It's a religious issue for some people. Other people
see that there are reasonable arguments both for and
against, and don't mind reading either style despite
whatever they may believe personally.

[Michael Wojcik]

Re: Typdef pointers to structs or not?


In article <1154325063.745 288.63320@75g20 00cwc.googlegro ups.com>, ena8t8si@yahoo. com writes:

Michael Wojcik wrote:

In article <1154001469.978 557.270070@h48g 2000cwc.googleg roups.com>, "Johan Tibell" <johan.tibell@g mail.comwrites:

Could someone outline the pros and cons of typedefing pointers to
structs like this?

This is a religious issue which has been hotly debated a number of
times on comp.lang.c.

>
It's a religious issue for some people. Other people

[snip posturing]

Thanks for demonstrating my point.

Antistrephon cuts both ways.

--
Michael Wojcik michael.wojcik@ microfocus.com

Proverbs for Paranoids, 2: The innocence of the creatures is in inverse
proportion to the immorality of the Master. -- Thomas Pynchon

[ena8t8si@yahoo.com]

Re: Typdef pointers to structs or not?


Michael Wojcik wrote:

In article <1154325063.745 288.63320@75g20 00cwc.googlegro ups.com>, ena8t8si@yahoo. com writes:

Michael Wojcik wrote:

In article <1154001469.978 557.270070@h48g 2000cwc.googleg roups.com>, "Johan Tibell" <johan.tibell@g mail.comwrites:
Could someone outline the pros and cons of typedefing pointers to
structs like this?
>
This is a religious issue which has been hotly debated a number of
times on comp.lang.c.

It's a religious issue for some people. Other people

[snip posturing]
>
Thanks for demonstrating my point.
>
Antistrephon cuts both ways.

If you want to see the question as being a religious
issue, that's okay with me.

Cool word by the way.

[Al Balmer]

Re: Typdef pointers to structs or not?

On 7 Aug 2006 15:07:35 -0700, ena8t8si@yahoo. com wrote:

>
>Michael Wojcik wrote:

>In article <1154325063.745 288.63320@75g20 00cwc.googlegro ups.com>, ena8t8si@yahoo. com writes:

Michael Wojcik wrote:
In article <1154001469.978 557.270070@h48g 2000cwc.googleg roups.com>, "Johan Tibell" <johan.tibell@g mail.comwrites:
Could someone outline the pros and cons of typedefing pointers to
structs like this?
>
This is a religious issue which has been hotly debated a number of
times on comp.lang.c.
>
It's a religious issue for some people. Other people

>[snip posturing]
>>
>Thanks for demonstrating my point.
>>
>Antistrephon cuts both ways.

>
>If you want to see the question as being a religious
>issue, that's okay with me.
>
>Cool word by the way.

Antistrophon, maybe?

--
Al Balmer
Sun City, AZ

[Joe Wright]

Re: Typdef pointers to structs or not?

ena8t8si@yahoo. com wrote:

Michael Wojcik wrote:

>In article <1154325063.745 288.63320@75g20 00cwc.googlegro ups.com>, ena8t8si@yahoo. com writes:

>>Michael Wojcik wrote:
>>>In article <1154001469.978 557.270070@h48g 2000cwc.googleg roups.com>, "Johan Tibell" <johan.tibell@g mail.comwrites:
>>>>Could someone outline the pros and cons of typedefing pointers to
>>>>structs like this?
>>>This is a religious issue which has been hotly debated a number of
>>>times on comp.lang.c.
>>It's a religious issue for some people. Other people

>[snip posturing]
>>
>Thanks for demonstrating my point.
>>
>Antistrephon cuts both ways.

>
If you want to see the question as being a religious
issue, that's okay with me.
>
Cool word by the way.
>

Misspelled.

Antistrophon \An*tis"tro*pho n\, n. [Gr. ? turned opposite ways.]
(Rhet.)
An argument retorted on an opponent. --Milton.
[1913 Webster]

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[ena8t8si@yahoo.com]

Re: Typdef pointers to structs or not?


Al Balmer wrote:

On 7 Aug 2006 15:07:35 -0700, ena8t8si@yahoo. com wrote:
>

Michael Wojcik wrote:

In article <1154325063.745 288.63320@75g20 00cwc.googlegro ups.com>, ena8t8si@yahoo. com writes:
Michael Wojcik wrote:
In article <1154001469.978 557.270070@h48g 2000cwc.googleg roups.com>, "Johan Tibell" <johan.tibell@g mail.comwrites:
Could someone outline the pros and cons of typedefing pointers to
structs like this?
>
This is a religious issue which has been hotly debated a number of
times on comp.lang.c.

It's a religious issue for some people. Other people
[snip posturing]
>
Thanks for demonstrating my point.
>
Antistrephon cuts both ways.

If you want to see the question as being a religious
issue, that's okay with me.

Cool word by the way.

>
Antistrophon, maybe?

I believe that's the OED spelling, yes.

[Michael Wojcik]

Re: Typdef pointers to structs or not?


In article <tOOdnSKWwrx8IE rZnZ2dnUVZ_vSdn Z2d@comcast.com >, Joe Wright <joewwright@com cast.netwrites:

ena8t8si@yahoo. com wrote:

Michael Wojcik wrote:

In article <1154325063.745 288.63320@75g20 00cwc.googlegro ups.com>, ena8t8si@yahoo. com writes:
>Michael Wojcik wrote:
>>In article <1154001469.978 557.270070@h48g 2000cwc.googleg roups.com>, "Johan Tibell" <johan.tibell@g mail.comwrites:
>>>Could someone outline the pros and cons of typedefing pointers to
>>>structs like this?
>>This is a religious issue which has been hotly debated a number of
>>times on comp.lang.c.
>It's a religious issue for some people. Other people
[snip posturing]
>
Thanks for demonstrating my point.
>
Antistrephon cuts both ways.

If you want to see the question as being a religious
issue, that's okay with me.

Cool word by the way.

Misspelled.

Wrong.

Antistrophon \An*tis"tro*pho n\, n. [Gr. ? turned opposite ways.]
(Rhet.)
An argument retorted on an opponent. --Milton.
[1913 Webster]

That is a different term. I wrote antistrephon, and I meant
antistrephon. Or more precisely, while some rhetoricians use
"antistroph on" for both, and the OED (incorrectly, IMO) cites only
the latter as a separate entry, other rhetoricians use both terms
distinctly. See for example Lanham's _A Handlist of Rhetorical
Terms_.

The two words come from similar, but distinct, classical Greek roots;
and while they are etymologically related, they refer to two very
different tropes. Lanham et al use "antistreph on" (literally,
"turning to the opposite side") for the technique of argument where
an opponent's argument is turned against his claim, and "anti-
strophon" (Lanham actually uses "antistroph e", literally "turning
about") for repetition at the end of successive clauses (a
"returning" ) and other forms of repetition. Some use it for the
syntactic inversion of normal word order; this is among the
definitions given by the OED.

William R Long has a short discussion on the topic at
http://www.drbilllong.com/MoreWords/RhetDevIII.html.

I will suggest, metastatically, that when flatly declaring someone
wrong on a point of technical obscurity such as this one, you use
a more reliable reference than one nearly a century out of date,
and of questionable authority even then.

--
Michael Wojcik michael.wojcik@ microfocus.com

Be sure to push the button of the bottom, and push the button of the
settlement page indicated next only once, there is fear of the bottom
rhinoceros multiplex lesson money. -- Sukebe Net