use pointer to struct or not when using typedef in C

Question

In order to define a new datatype in C for example a type for linked list
one can use one of the following definitions

struct list_node {
    int x;
    struct list_node * next;
};

//1
typedef struct list_node list1;
//2
typedef struct list_node *list2;

From what I have seen the common practice is the first definition.

The question is if the second definition is also an acceptable practice. In which cases if any should one prefer the second over the first? Provided that the variables that we use are pointers to struct list_node is it possible to do the same operations with both types? What are the advantages of the first?

Similar question: http://stackoverflow.com/questions/3781932/is-typedefing-a-pointer-type-considered-bad-practice — Blagovest Buyukliev, Feb 24 '11 at 00:03

score 6 · Accepted Answer · answered Feb 24 '11 at 01:10

I would require API users to type the "*", i.e. typedef the struct, not a pointer to the struct. This is the widely-used style in GLib, which is one of the more popular C stacks.

It works out well because it is important to know whether you have a pointer to a struct or the struct itself. For example, can you store NULL in a variable of the type? If you hide that an object is a pointer, you have to create a special NIL_NODE or other value to replace NULL. If you just make it a pointer, then people can treat it like one.

Another important benefit is the ability to put the actual struct definition somewhere private, i.e. in the .c file instead of in the header. You can put just the typedef in the header, while keeping the struct itself opaque to API users. This requires people to only use the exported methods that you provide to manipulate the struct. It also means you don't have to rebuild the world if you change the struct fields.

Yet another reason to take this path is that sometimes you do want a struct that can be copied, and you still want to typedef it. Take a thing like GdkPoint:

  typedef struct {
     int x, y;
  } GdkPoint;

Here it's useful to allow direct struct access, like:

 GdkPoint point = { 10, 10 };
 GdkPoint copy = point;
 do_stuff_with_point(&copy);

However, if your convention is that the "GdkPoint" typedef would be a pointer, you're going to have to be inconsistent.

Code is just clearer if you can tell what's a pointer and what isn't, and code is better encapsulated if you don't put struct definitions in the header (for structs that represent abstract, opaque data types, which is maybe the most common kind).

My default template for a C data type is something like this in the header:

typedef struct MyType MyType;
 MyType* my_type_new(void);
 void    my_type_unref(MyType *t);
 void    my_type_ref(MyType *t);

Then the actual "struct MyType" in the .c file, along with the new, the unref, and any operations on the type.

The exception would be for types such as Point, Rectangle, Color where it's "plain old data" and direct field access is desired; another variation is to have a my_type_free() instead of _unref() if you don't need refcounting.

Anyhow, this is one style, basically the GLib style, that's widely-used and is known to work well.

I completely agree. It's usually not a good idea to use `typedef` to hide whether a type is a pointer or a structure (unless you're using opaque pointers for a library interface). To be honest I usually prefer to call a `struct` a `struct` and avoid the `typedef` altogether but if you're going to `typedef` something, make it the structure and not the pointer. — bta, Feb 24 '11 at 01:25
glib style would use CamelCase for a struct typedef and lowercase for primitive type typedef, so that's what removes the need to type "struct" while keeping things clear. also preserves the ability to have opaque structs not in header — Havoc P, Feb 24 '11 at 15:45

score 1 · Answer 2 · answered Feb 24 '11 at 00:26

I prefer the first style, so it's clear which types are objects, and which types are pointers. But I find C pointers easy to understand / interpret, which (apparently) plenty of people don't. So if you think most of the people reading your code base won't understand pointers, use typedef STRUCT_FOO *PSTRUCT_FOO everywhere, like the Win32 API does.

score 0 · Answer 3 · answered Jun 27 '13 at 10:44

typedef int* ptr_int; ptr_int x,y,z;

Programmer may be confused that all three x, y, z are of int* type i.e. Pointers to int. But in Reality only x is of int* type y and z are simple int.

because ptr_int x, y, z; is equals to int* x, y, z; not int*x, *y, *z;

so, typedef also create confusion in programmers mind and may lead to bugs and errors.

score 0 · Answer 4 · answered Feb 24 '11 at 00:07

0

Consider using both of these:

typedef struct list_node Node;
typedef Node* ListHead;

answered Feb 24 '11 at 00:07

Jim Balter

16,163
3
43
66

score 0 · Answer 5 · answered Feb 24 '11 at 02:12

As long as the identifier makes it clear it's a pointer then there's no harm (I personally prefer a suffix ala _Pointer or _Ptr, but whatever suits the project). That said, for C-only code there's no actual benefit in avoiding the explicit *. For mixed C/C++ environments or pure C++, I've often seen use of typedefs to pointers rationalised/justified re facilitating transitioning to, use of, and switching between smart pointer types. There's probably some truth to this, though I've never found myself wanting to adopt the practice.

use pointer to struct or not when using typedef in C

5 Answers5