uppercase typedef?

[Stefan Ram]

Is it acceptable to use uppercase typedef names, like

typedef struct alpha { int beta; } * ALPHA;

? After all, there is preceding practice in the standard,
where we have the uppercase name »FILE«, which - as I
understand it - might have been typedef'd (doesn't have
to be a macro). This also hides the implementation detail,
whether the type name is a macro or a typdef name.

I believe »_t« is more recent, so would this be better:

typedef struct alpha { int beta; } * alpha_t;

? What I actually did, was to use this in a class:

typedef struct alpha { int beta; } * alpha;

And later even:

void example( alpha const alpha )
{ /* Here, "alpha" always is the parameter name, not the type name. */ }

. I just wanted to show that this is /possible/, not that it
always is the best style, but the students seem to be (mildly)
confused by this, so I consider using other names than three
times »alpha« with three different meanings.

 

[Ben Pfaff]

Is it acceptable to use uppercase typedef names, like

typedef struct alpha { int beta; } * ALPHA;

I personally avoid typedefs, especially typedefs of pointers,
because I find them to make code harder to read.

 

[Stefan Ram]

I personally avoid typedefs, especially typedefs of pointers,
because I find them to make code harder to read.

I avoid them too, but I have a teaching assignment requiring
me to teach this. However, I told the students that I do not
use »typedef« myself. The fact that I do not use »typedef«
myself might also be the reason why I am a little less
secure regarding coding style of typedef.

 

[Ben Pfaff]

I avoid them too, but I have a teaching assignment requiring
me to teach this. However, I told the students that I do not
use »typedef« myself. The fact that I do not use »typedef«
myself might also be the reason why I am a little less
secure regarding coding style of typedef.

Sometimes it does make sense to use typedef. For example,
typedef is useful for defining function types, for use with
function pointers, and typedef is also useful for defining
abstract types that might be instantiated in different ways in
different circumstances. Is your teaching assignment flexible
enough that you could just teach more sensible ways to use
typedef?

 

[Stefan Ram]

Sometimes it does make sense to use typedef. For example,
typedef is useful for defining function types, for use with
function pointers, and typedef is also useful for defining
abstract types that might be instantiated in different ways in
different circumstances. Is your teaching assignment flexible
enough that you could just teach more sensible ways to use
typedef?

Yes, I believe that I have already taught this
(typedef for function pointer types and abstract data types).

 

[Eric Sosman]

Is it acceptable to use uppercase typedef names, like

typedef struct alpha { int beta; } * ALPHA;

"Acceptable" from the Standard's point of view, certainly.
From the standpoint of "Would you like to encounter this when
reading someone else's unfamiliar code?" -- well, beauty is in
the eye of the beholder, but my eye sees little beauty here.

My own preference is not to typedef data pointers (I do,
however, find function pointer typedefs helpful). If you like
pointer typedefs, at least put "ptr" or "p" or some such cue
in the name.

? After all, there is preceding practice in the standard,
where we have the uppercase name »FILE«, which - as I
understand it - might have been typedef'd (doesn't have
to be a macro). This also hides the implementation detail,
whether the type name is a macro or a typdef name.

Lots of the Standard codifies pre-existing practice, dating
from times before idioms were well-established. For example,
there are macros like `assert' and `complex' and `and' that
do not obey the usual convention of spelling macro names in
upper-case.

I believe »_t« is more recent, so would this be better:

typedef struct alpha { int beta; } * alpha_t;

Somewhere I have a vague memory that some other standard
(maybe one of the POSIX suite?) reserves all identifiers ending
in _t. This may or may not be a concern, depending on your
sphere of activity.

? What I actually did, was to use this in a class:

typedef struct alpha { int beta; } * alpha;

And later even:

void example( alpha const alpha )
{ /* Here, "alpha" always is the parameter name, not the type name. */ }

. I just wanted to show that this is /possible/, not that it
always is the best style, but the students seem to be (mildly)
confused by this, so I consider using other names than three
times »alpha« with three different meanings.

Some people find even a struct typedef displeasing. Myself,
I rather like them, but would use something like

typedef struct { int beta; } Alpha;
void example(Alpha const *alpha)

If a struct tag is needed, `alpha' would work but I usually use

typedef struct alpha_s {
int beta;
struct alpha_s *next;
} Alpha;

This habit's origins are in the pre-Standard days when compilers
didn't always implement separate name spaces for struct tags and
for other identifiers; still, the _s suffix seems to me to carry
some documentary weight. I suppose a C++ programmer writing C
might use

typedef struct alpha {
int beta;
struct alpha *next;
} alpha;

.... because in C++ a declaration of `struct alpha' also declares
`alpha' as a name for that struct type.

In an existing body of code, stick with existing practice.
In new code, use whatever you think will be clearest.

 

[Keith Thompson]

Some of the naming case conventions that the standard uses,
are opposite to the conventions that programmers usually use.

stdout, stderr, stdin are all macros.

Yes, but back in the day I suspect they were just object names.

Similarly, FILE might have originally been a macro (before typedefs
were introduced).

In modern C, it's rarely necessary to use a macro rather than a
typedef name. (bool, in C99's <stdbool.h>, is a macro rather than
a typedef; the point of that is to allow a program to undefine and
perhaps redefine it.)

 

[Keith Thompson]

My own preference is not to typedef data pointers (I do,
however, find function pointer typedefs helpful). If you like
pointer typedefs, at least put "ptr" or "p" or some such cue
in the name.

[...]

Another approach is to typedef the function type, and then use "*" on
the typedef name. For example:

typedef void signal_handler(int);

signal_handler *ptr = (cond ? this_function : that_function);

signal(SIGFOO, ptr);

 

[Nobody]

Is it acceptable to use uppercase typedef names,

It's legal. Whether or not it's a good idea is a different matter.

like

typedef struct alpha { int beta; } * ALPHA;

typedef'ing pointers is seldom a good idea.

The only time I do it is if the type is intentionally abstract (i.e. an
object declared using the typedef will never be the subject of "*" or "->").
In which case, I'll normally make the base type an unspecified structure,
ie.

struct foo;
typedef struct foo *handle_t;

with the actual definition of "struct foo" nowhere in sight, so the only
thing that you can do with a value of type handle_t is to assign it, pass
it as an argument to a function, etc.

If code is going to dereference the pointer, I wouldn't typedef either the
pointer or the structure, so the code would have to read:

struct alpha *a;

This makes it clear that "->" is an appropriate operation for "a".

 

[Nick]

It's legal. Whether or not it's a good idea is a different matter.


typedef'ing pointers is seldom a good idea.

The only time I do it is if the type is intentionally abstract (i.e. an
object declared using the typedef will never be the subject of "*" or "->").
In which case, I'll normally make the base type an unspecified structure,
ie.

struct foo;
typedef struct foo *handle_t;

with the actual definition of "struct foo" nowhere in sight, so the only
thing that you can do with a value of type handle_t is to assign it, pass
it as an argument to a function, etc.

If code is going to dereference the pointer, I wouldn't typedef either the
pointer or the structure, so the code would have to read:

struct alpha *a;

This makes it clear that "->" is an appropriate operation for "a".

I don't even do it in that case. I've pretty well given up typedefing
structs - it's not really a saving in either clarity or typing - but
even when I did, I go by the standards FILE example.