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]

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]

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

 

[Michael Wojcik]

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.

 

[Keith Thompson]

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

 

[SM Ryan]

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

 

[Jack Klein]

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.

 

[Herbert Rosenau]

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]

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]

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

[snip posturing]

Thanks for demonstrating my point.

Antistrephon cuts both ways.

 

[ena8t8si]

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]

Michael Wojcik wrote:
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?

 

[Joe Wright]

Michael Wojcik wrote:
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*phon\, n. [Gr. ? turned opposite ways.]
(Rhet.)
An argument retorted on an opponent. --Milton.
[1913 Webster]

 

[ena8t8si]

Michael Wojcik wrote:
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]

Michael Wojcik wrote:
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*phon\, 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
"antistrophon" 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 "antistrephon" (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 "antistrophe", 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 (e-mail address removed)

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

 

[ena8t8si]

Michael Wojcik wrote:
Michael Wojcik wrote:
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*phon\, 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
"antistrophon" 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 "antistrephon" (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 "antistrophe", 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.

Besides the OED, other dictionaries I've checked
list antistrophon but not antistrephon. I haven't
found any dictionary that lists antistrephon.

A Google search for antistrophon definition yields
over 600 hits; a search for antistrephon definition
yields only 30 hits, and a lot of those are in a
language other than English. None of the antistrephon
pages (at least the ones that I could read) distinguish
it from antistrophon.

And, the very page you cited says this:

What remains is a word which is one of the definitions in the
Century Dictionary and appears as a separate word, antistrophon,
in the OED. Lanham calls it antistrephon.

Of course it's possible that you're right and
the rest of the world is wrong. But it does
seem a little unfair to criticize the poster
for concluding that the word is misspelled.

 

[Michael Wojcik]

Michael Wojcik wrote:
Antistrephon cuts both ways.

Misspelled.

Wrong.

That is a different term. I wrote antistrephon, and I meant
antistrephon. Or more precisely, while some rhetoricians use
"antistrophon" 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_. [...]

Besides the OED, other dictionaries I've checked
list antistrophon but not antistrephon. I haven't
found any dictionary that lists antistrephon.

That's because they're nearly all copying the same source - the
_Century Dictionary_, which in turn is apparently just parrotting
Milton. (Long rightly criticizes the OED for this.) Milton is not
the supreme authority on rhetorical terms coined from Greek roots.

Dictionaries are rarely useful references for terms of art. They're
general reference works.

A Google search for antistrophon definition yields
over 600 hits; a search for antistrephon definition
yields only 30 hits, and a lot of those are in a
language other than English.

The web is even more general, and even less useful in this matter,
than dictionaries - with the exception of Long's helpful essay.

Of course it's possible that you're right and
the rest of the world is wrong.

Or that I can be right about this and "the rest of the world" not be
wrong, since we've not seen an opinion from the vast majority of the
world; 2) at least one reputable source (Lanham), presumably of this
world, agrees with me; and 3) the relative popularity of
"antistrophon" says absolutely nothing about the possible use of
"antistrephon".

They're derived from different - albeit cognate - roots:

strefw (sigma-tau-rho-epsilon-phi-omega): apparently strengthened
form of trepw, an early form of "to turn", also the root of trope
("turn")

-strofhv (sigma-tau-rho-omicron-phi-eta): root of various nouns
(anastrofe, etc) derived from strefw

The shift in the final vowel accomodates Ancient Greek's inflections
for declension. My guess is that the shift in the penultimate vowel
is either for euphony or simply the result of transposing the two
vowel sounds. But Greek isn't my field.

The difference between omicron and epsilon might seem slight, but
it is a real difference.[1]

But it does
seem a little unfair to criticize the poster
for concluding that the word is misspelled.

It seems perfectly fair to me, since it was correct - the word was
not misspelled, and his conclusion was wrong.

Now, Al Balmer posted the *suggestion* that the word was misspelled;
that's perfectly reasonable.

And I'll certainly grant that hoi polloi seem to have latched onto
antistrophon, despite its myriad and inconsistent employments. And
there is a school of thought that Lanham is rather too idiosyncratic.
So I might agree that others might use "antistrophon" as I used
"antistrephon" and garner no shame by it. But I can hardly stand
silently by and see my loyal "antistrephon" so vilely defamed, can I?


[1] Omicron is a circle, and epsilon is a semicircle plus a radius,
so their difference is pi minus 1, or about 2.14159.

--
Michael Wojcik (e-mail address removed)

Unfortunately, as a software professional, tradition requires me to spend New
Years Eve drinking alone, playing video games and sobbing uncontrollably.
-- Peter Johnson

 

[ena8t8si]

...
And I'll certainly grant that hoi polloi seem to have latched onto
antistrophon, despite its myriad and inconsistent employments. And
there is a school of thought that Lanham is rather too idiosyncratic.
So I might agree that others might use "antistrophon" as I used
"antistrephon" and garner no shame by it. But I can hardly stand
silently by and see my loyal "antistrephon" so vilely defamed, can I?

It's perfectly ok to give an expanded account of the two words.
But I didn't see any reason to jump on the guy for his "mistake",
since most people would have reached the same conclusion, and, as
you point out, even among the cognescenti there is a difference of
opinion about what usage is most appropriate.