Re: Typdef pointers to structs or not?

Chris Dollin <chris.dollin@xxxxxx> writes:
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_Keith) kst-u@xxxxxxx <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.
.

Relevant Pages

  • Re: WIN32_FIND_DATA and gigantic file sizes
    ... in structs that are persisted to disk, you can't just change the typedef to all of a sudden be a 64-bit quantity, or it will invalidate all those data files where it is still 32-bit. ... What you are looking for is DWORD_PTR (the size of a pointer to a DWORD); since pointers are 64-bits wide in x64 and 32-bits wide in x32. ...
    (microsoft.public.vc.mfc)
  • Re: Variadic functions calling variadic functions with the argument list, HLL bit shifts on LE proce
    ... then I get to thinking about memory and memory allocation. ... typedef unsigned int fc_ptr_int_t; ... /** This is the static cast for void pointer to typed pointer, ...
    (comp.lang.c)
  • Re: RE:How to realize the OOP in C?
    ... > int n; ... be a pointer to a standard structure like: ... typedef struct object_of_fubar * ObjectOfFubarP; ... Note that the class structure is allocated only ...
    (comp.lang.c)
  • Re: Naming typedefs
    ... gave reasons why I prefer not to use unnecessary typedefs. ... should I not typedef structs?": it is true that on this point I ... Yes, absolutely, it's a cultural question - a question of taste, ...
    (comp.unix.programmer)
  • Re: Developing/compiling software
    ... Memories of legacy 8051 hw platforms, multiple code banks, not enough common area and hard work trying to ensure that all the correct data appeared in the selected bank at the right time suggests that there must be a better way. ... You only need to use such tricks for braindead architectures like the 8051, where you have a hopeless stack and almost no registers, and thus need to pass data via globals or extra structs. ... What I said about pointers to structs is that the AVR has two pointer registers that work well with structs - Y and Z. ...
    (comp.arch.embedded)