typedefing a struct

[David Marsh]

Is there any functional difference (or any other reason to prefer
one over the other) between these two methods:

typedef struct mystruct {
int a;
int b;
} mystruct;

struct mystruct {
int a;
int b;
};
typedef struct mystruct mystruct;

 

[Richard Tobin]

Is there any functional difference (or any other reason to prefer
one over the other) between these two methods:

typedef struct mystruct {
int a;
int b;
} mystruct;

struct mystruct {
int a;
int b;
};
typedef struct mystruct mystruct;

No, but there is sometimes reason to do it the other way round:

typedef struct mystruct mystruct;

struct mystruct {
int a;
int b;
};

Because you can then use the type name "mystruct" in and before the
definition of the struct, which is useful if you have structures that
point to each other.

-- Richard

 

[Keith Thompson]

Is there any functional difference (or any other reason to prefer one
over the other) between these two methods:

typedef struct mystruct {
int a;
int b;
} mystruct;

struct mystruct {
int a;
int b;
};
typedef struct mystruct mystruct;

I don't believe there's any real difference. Note that in both cases,
any reference to the type within its own definition (say, if a
mystruct contains a pointer to a mystruct) has to use the name 'struct
mystruct', since the typedef name doesn't exist yet.

You could even drop the tag, and just declare

typedef struct {
int a;
int b;
} mystruct;

since you never use the struct tag name anyway. But you'll need the
tag if you ever add a mystruct pointer as a member.

Using the same name for the struct tag and for the typedef is
perfectly legal, but may cause problems in some IDEs. If this induces
you to use different names, pick a consistent convention to avoid
confusion.

Richard Heathfield has argued for the second form on stylistic
grounds, on the basis that since two names are being declared ('struct
mystruct' and 'mystruct'), there should be two declarations. I'll let
him refute my blatant misrepresentation of what he actually said. }

Others, myself included, have argued that in most cases typedefs for
strutures are superfluous. Your type already has a perfectly good
name, 'struct mystruct'; it doesn't need another. Using the 'struct'
keyword every time you refer to the type reminds the reader of the
relevant fact that the type is a structure type. If this fact is not
relevant, i.e., if you're creating an opaque type like FILE, then
using a typedef makes sense.

Plenty of very smart people disagree with me on this point, and
believe instead that having a one-word name for the type is
worthwhile.

 

[Keith Thompson]

No, but there is sometimes reason to do it the other way round:

typedef struct mystruct mystruct;

struct mystruct {
int a;
int b;
};

Because you can then use the type name "mystruct" in and before the
definition of the struct, which is useful if you have structures that
point to each other.

Note that this is vulnerable to typos. For example, this:

typedef struct my_struct mystruct;

struct mystruct {
int a;
int b;
mystruct *next;
};

compiles without error (but it will fail as soon as you try to declare
an object of type 'mystruct'). The problem is the added underscore in
the struct tag. 'struct my_struct' is an incomplete type, which is
legal in that context, even though you *meant* to use 'struct
mystruct'.

 

[Chris Thomasson]

Is there any functional difference (or any other reason to prefer one over
the other) between these two methods:

[...]

FWIW, here is how I personally do it:


typedef struct my_struct_s my_struct_t;

struct my_struct_s {
int a;
int b;
my_struct_t *c;
};


I postfix an '_s' for the struct name and a '_t' for the typedef name. It
seems to help me differentiate between the two quite easily.

 

[Richard Heathfield]

Keith Thompson said:

Using the same name for the struct tag and for the typedef is
perfectly legal, but may cause problems in some IDEs. If this induces
you to use different names, pick a consistent convention to avoid
confusion.

My preference: struct mystruct_, and typedef struct mystruct_ mystruct.

Richard Heathfield has argued for the second form on stylistic
grounds, on the basis that since two names are being declared ('struct
mystruct' and 'mystruct'), there should be two declarations. I'll let
him refute my blatant misrepresentation of what he actually said.

Ta Keith. Yeah, I think "should" is a bit strong. I have my own
preference, but C is flexible to cope with more than one preference!

I remember being confused by td s { foo } s; - by which I mean I thought
I knew what it meant, and was wrong, and did not discover this for some
years. On reflection, much of my coding style is based on the idea of
avoiding constructs that confused me in the past. This is probably why
I prefer sizeof x to sizeof(x), for example.

Others, myself included, have argued that in most cases typedefs for
strutures are superfluous. Your type already has a perfectly good
name, 'struct mystruct';

FCOV "perfectly good"

Plenty of very smart people disagree with me on this point, and
believe instead that having a one-word name for the type is
worthwhile.

It must, however, also be pointed out that plenty of very smart people
*agree* with you. (I am not one of them.)

 

[Richard Heathfield]

Chris Thomasson said:

I postfix an '_s' for the struct name and a '_t' for the typedef name.
It seems to help me differentiate between the two quite easily.

....and violates a POSIX rule, so keep your nose out of c.u.p.

 

[Chris Thomasson]

Chris Thomasson said:



...and violates a POSIX rule, so keep your nose out of c.u.p.

[...]

DAMN! I totally forgot about how the POSIX namespace reserves the '_t'
postfix; thank you for reminding me.

 

[jaysome]

Is there any functional difference (or any other reason to prefer
one over the other) between these two methods:

typedef struct mystruct {
int a;
int b;
} mystruct;

struct mystruct {
int a;
int b;
};
typedef struct mystruct mystruct;

Worth reading:

http://web.torek.net/torek/c/types2.html

 

[Army1987]

I postfix an '_s' for the struct name and a '_t' for the typedef name. It
seems to help me differentiate between the two quite easily.

What's the need for that? The former is always preceded by the
keyword struct and the latter is never.

(typedef struct foo foo; is one of the things I dislike without
being able to find any rational reasons whatever for doing so. But
I do agree that type names should be recognizable at a glance. I
still haven't found an alternative to the _t suffix which POSIX
reserves to implementations.)

 

[Richard Heathfield]

Army1987 said:

What's the need for that? The former is always preceded by the
keyword struct and the latter is never.

(typedef struct foo foo; is one of the things I dislike without
being able to find any rational reasons whatever for doing so.

Here's a rational reason for you (or, if you prefer, a
rationalisation!): it confuses Visual Studio's Intellisense "jump to
def" functionality, albeit not disablingly so.

But
I do agree that type names should be recognizable at a glance. I
still haven't found an alternative to the _t suffix which POSIX
reserves to implementations.)

I use typedef struct foo_ foo, on the grounds that I'll hardly ever see
the struct tag, but I'll see the synonym a lot.

 

[Richard]

Army1987 said:


Here's a rational reason for you (or, if you prefer, a
rationalisation!): it confuses Visual Studio's Intellisense "jump to
def" functionality, albeit not disablingly so.

And, if it confuses that (and tags and cscope) then it will confuse
people. It confuses me. I dont want to "think" when looking at a
declaration. It should be obvious. I like to see "struct" there in the
variable declaration. I then know it's a struct ....

 

[Charlie Gordon]

What's the need for that? The former is always preceded by the
keyword struct and the latter is never.

(typedef struct foo foo; is one of the things I dislike without
being able to find any rational reasons whatever for doing so. But
I do agree that type names should be recognizable at a glance. I
still haven't found an alternative to the _t suffix which POSIX
reserves to implementations.)

I don't see the point of inventing 2 different identifiers for the same
purpose. Indeed the definition `typedef struct foo foo;' is implicit in C++
for all struct foo declared or defined.
The consequence of the typedef is that you can no longer use `foo' to name
struct foo instances or any variables. But that is not really an
inconvenient as it would be quite confusing anyway.

I guess the real question is what convention to follow for naming structures
and other types.
The _t suffix is in wide use and recognized by editors, but it violates
POSIX constraints.
Using an initial capital is also in wide use in OOP but give C code a bad
smell of java.
Using all caps would be consistent with FILE and Microsoft C based APIs but
looks ugly.
I cannot settle for one over the others...

 

[Tor Rustad]

Is there any functional difference (or any other reason to prefer one
over the other) between these two methods:

[...]

FWIW, here is how I personally do it:


typedef struct my_struct_s my_struct_t;

struct my_struct_s {
int a;
int b;
my_struct_t *c;
};


I postfix an '_s' for the struct name and a '_t' for the typedef name.
It seems to help me differentiate between the two quite easily.

To typedef, or not to typedef, that's a question I have never agreed
with myself on. For low-level work, I prefer little obfuscation, and
aliasing by typedef's, but for high-level API's, those typedef's tend to
sneak in.


My naming convention is similar to yours, but with an important difference:

typedef struct my_struct MY_STRUCT_T;

struct my_struct
{
int a;
int b;
MY_STRUCT_T *c;
};

the "_T" suffix and uppercase, rarely pollute the name space.

 

[Keith Thompson]

I guess the real question is what convention to follow for naming
structures and other types. The _t suffix is in wide use and
recognized by editors, but it violates POSIX constraints. Using an
initial capital is also in wide use in OOP but give C code a bad smell
of java. Using all caps would be consistent with FILE and Microsoft C
based APIs but looks ugly. I cannot settle for one over the others...

A digression:

I suspect the reason FILE is in all-caps is that it was invented
before typedefs were introduced to the language, and thus must have
originally been a macro. When typedefs were invented, it was too late
to change it.

The definition might have been something like:

struct file { /* ... */ };
#define FILE struct file

 

[pete]

I still haven't found an alternative to the _t suffix
which POSIX reserves to implementations.

I use _type.

http://www.mindspring.com/~pfilandr/C/e_driver/e_driver.h

#define STRUCTURES 0 /* 0 or 1, This is the line to change */

#if STRUCTURES == 0 /* Not this one */

#define E_TYPE long unsigned
#define D_TYPE E_TYPE
#define GT(A, B) (*(A) > *(B))

#else

#define E_TYPE struct {/**/char array[20];/**/d_type data;}
#define D_TYPE long unsigned /* unsigned, double */
#define GT(A, B) ((A) -> data > (B) -> data)

#endif

typedef D_TYPE d_type;
typedef E_TYPE e_type;