什么时候使用没有 typedef 的结构体有意义？

Question

Structs in C declare a data structure that associates different data types into a contiguous piece of memory.

Typedefs are a way to create user-defined data type names. This is useful for many applications including <stdint.h>

Structs seem to be exclusively used with typedefs. It seems like the default behaviour of defining a struct should also define a typedef .

Why would I ever want to define struct without also using a typedef ?

Answer 1

It's a matter of personal preference, possibly imposed onto other people working on the same project as a convention. For instance, the Linux kernel coding style guide discourages the introduction of new typedefs in no uncertain terms.

Though I don't necessarily agree with everything in that guide, some of which seems silly (for instance vps_t a; example could be virtual_container_t a; : the issue hinges on the cryptic name that is chosen for typedef more than the existence of the typedef), in my TXR language project, here are some raw stats:

txr$ git grep '^typedef struct' '*/*.[ch]' '*.[ch]' | wc
     25      91     839
txr$ git grep '^struct' '*/*.[ch]' '*.[ch]' | wc
    135     528    4710

Lines of code beginning with struct outnumber typedef struct lines by a factor of 5.4!

The union/tag namespace feature of C means that you can have a variable called foo in the same scope as a struct foo without a clash, which is useful. This extra namespace gives us an opportunity not to pollute the regular identifier namespace with user-defined type names, which improves hygiene.

The cost is that we have to type struct foo instead of just foo in declarations.

It makes particular sense if you have experience with languages in which class/type names do not intrude into the lexical variable namespace, like Common Lisp.

The above code base, though, compiles as C++, so that throws a bit of a monkey wrench into it. In C++, struct foo defines foo as a type, which can be referenced in the ordinary namespace.

Another reason is that there is some clarity. When we see a declaration like:

struct foo x;

we know that x is a structure, whereas

foo x;

could be anything; it could be typedef double foo . Sometimes we go for that kind of abstraction. When you want to hide how something is implemented, reach for typedef . However, typedef doesn't provide perfect abstraction.

Also, if we see:

struct foo f;
struct bar b;

we know that these are necessarily different, incompatible types. We do not know that given:

foo f;
bar b;

They could both be typedef s for the same structure or for int for all we know.

If you typedef pointer types, but the code dereferences them, it looks pretty silly:

foo x = get_foo();
char *fname = x->name; /* what? */

That kernel coding style document has this to say about the above: In general, a pointer, or a struct that has elements that can reasonably be directly accessed should never be a typedef.

Not using typedef for structures has as much to do with some of the hygiene of using the tag namespace, as it has to do with avoiding typedef as such: keeping the code explicit, and reserving typedef for situations in which we actually need a proper abstraction.

Answer 2

Structs seem to be exclusively used with typedefs.

This is a mistaken impression. Structs are frequently used without typedefs, and I personally prefer that. There are numerous struct types declared and used, without built-in typedefs, by the C standard library and POSIX standard library extension functions, for example.

It seems like the default behavior of defining a struct should also define a typedef.

In C++, it effectively does.

Why would I ever want to define struct without also using a typedef?

Why would you ever want to define a struct with a typedef ? Using a (tagged) structure type via the struct keyword and its tag clarifies what kind of type it is, and enables you to determine quickly by eye whether two types are the same. On the other hand, a typedef ed alias can represent any type at all, and there can be multiple such aliases for the same type.

There are some good and appropriate uses of typedef , but there are a lot of other uses whose propriety is a code style consideration. Myself, I strongly prefer styles that minimize use of typedef .

Answer 3

typedef is just a convenience to allow you to refer to your struct without explicitly stating struct MyStruct every time you refer to it.
Some actually prefer this explicitness, making it clear you're working with a user-defined type.

Answer 4

我从来没有对我的结构进行 typedef，这样它们就可以更容易地在其他头文件中声明为“extern”。

Answer 5

You ask: Why would I ever want to define struct without also using a typedef?

It depends what you mean by 'define a struct'. Not all uses of struct are to define named types.

For example you could define a variable via

struct  
{   double  a, b;
}   dbls = { -1.0, 1.0};

Then dbls.a etc makes sense, but there is no named type.

Similarly in an anonymous union you might have

struct  ructT
{   union
    {   struct { int a; int b; } ints;
        struct { float a; float b; } floats;
    };
};

Here one has defined a type struct ructT but the inner structs are unnamed.

In each of these cases if one was to insist on typedefs, there would be more names to dream up, and more code to type.

Answer 6

typedef isn't just about saving a few keystrokes - it's about abstracting away implementation details of the underlying type. IOW, if you provide a typedef name for a struct type, you should also provide a complete API for setting and accessing members, formatting for output, allocating, deallocating, etc. You're hiding the "struct"-ness of the type from whomever is using it. Think about the FILE type in the standard library - that's a typedef name, usually for some implementation-specific structure. However, you never access any element of a FILE type directly - you just pass FILE * objects to various functions ( fprintf , fread , feof , ferror , etc.) that hide the implementation from you.

If you're expecting the user of the type to explicitly access members with the . or -> operators, then don't create a typedef name for it - just leave it as struct whatever . Otherwise you create a "leaky" abstraction, which creates heartburn down the line.

Similar rule for pointer types - don't hide the "pointer"-ness of a type behind a typedef unless you're willing to create a full API to abstract away pointer operations as well.