The common idiom is using both:

typedef struct S { 
    int x; 
} S;

They are different definitions. To make the discussion clearer I will split the sentence:

struct S { 
    int x; 
};

typedef struct S S;

In the first line you are defining the identifier S within the struct name space (not in the C++ sense). You can use it and define variables or function arguments of the newly defined type by defining the type of the argument as struct S:

void f( struct S argument ); // struct is required here

The second line adds a type alias S in the global name space and thus allows you to just write:

void f( S argument ); // struct keyword no longer needed

Note that since both identifier name spaces are different, defining S both in the structs and global spaces is not an error, as it is not redefining the same identifier, but rather creating a different identifier in a different place.

To make the difference clearer:

typedef struct S { 
    int x; 
} T;

void S() { } // correct

//void T() {} // error: symbol T already defined as an alias to 'struct S'

You can define a function with the same name of the struct as the identifiers are kept in different spaces, but you cannot define a function with the same name as a typedef as those identifiers collide.

In C++, it is slightly different as the rules to locate a symbol have changed subtly. C++ still keeps the two different identifier spaces, but unlike in C, when you only define the symbol within the class identifier space, you are not required to provide the struct/class keyword:

 // C++
struct S { 
    int x; 
}; // S defined as a class

void f( S a ); // correct: struct is optional

What changes are the search rules, not where the identifiers are defined. The compiler will search the global identifier table and after S has not been found it will search for S within the class identifiers.

The code presented before behaves in the same way:

typedef struct S { 
    int x; 
} T;

void S() {} // correct [*]

//void T() {} // error: symbol T already defined as an alias to 'struct S'

After the definition of the S function in the second line, the struct S cannot be resolved automatically by the compiler, and to create an object or define an argument of that type you must fall back to including the struct keyword:

// previous code here...
int main() {
    S(); 
    struct S s;
}

There is no such thing as a "typedef struct".

Part the first: structure types

struct introduces a structure, which is an aggregate datatype consisting of a set of named members. (Arrays are also aggregates, but they consist of a number of identical members which are indexed. Unions have a set of member names, but can only contain one member at a time, so they are not aggregates. You probably didn't need to know that.)

Structure types usually have tags, so the actual typename will be something like struct Triangle. The tag (Triangle) is not in the same namespace as identifiers, so there is no problem using a tag which is also used for another purpose. Some people like to append tags with _s and _u, indicating that they are structure or union tags respectively, but that's not my style; I prefer to name types in CamelCase, and for me a structure or union tag is standing in for a typename. But of course you are free to use your own conventions.

If you use struct SomeTag in a program, you are effectively declaring that there is a structure whose tag is SomeTag. You're not required to fill in the declaration by naming or describing the structure's members, unless you need to refer to them in your code. A structure whose members have not (yet) been declared is called incomplete, but it can still be used as part of a pointer type because the C standard guarantees that all structure pointers have the same format, regardless of the contents of the structure. (That doesn't make them interchangeable, but it does mean that the compiler knows how big the pointers are.) A structure which never has its members defined and which is used only as the the target of a pointer type is called opaque.

You can complete the declaration of a structure by adding a block of member declarations. So

Copystruct Triangle {
    int a,b,c;
};

first declares that there is a structure whose name is struct Triangle, and then fills in the definition of that structure by declaring three named members which are all ints.

Union declarations and definitions are all very similar, by the way.

A structure definition can be used in a declaration as though it were a type name. Or to put it another way, you can declare the tag for a structure type, immediately fill in the fields, and then declare one or more variables of that type:

Copystruct Triangle { int a, b, c; } aTriangle, anotherTriangle;

That's not a very common style, but it's important to know that the syntax is possible.

Finally, it is legal define a structure without giving it a tag. Tagless structure types have a quirk: normally no two structure types can have the same tag, but all tagless structures are distinct. That means that you can declare a structure type which effectively has no name, and which is different from any other structure type, even a structure type with exactly the same members. That can be slightly useful if you have an aggregate which will only ever have one instance (a "singleton"), although I wouldn't really ever use this style myself. But after a small detour, we'll see another use for this feature.

Part the second: type aliases

C type names can be quite complicated, since they can be built up out of pieces. For example, const struct Triangle*[8] is an array of eight members, each of which is a pointer to an unmodifiable struct Triangle. double (*)(const struct Triangle*[8]) is a function which accepts one such array as an argument (or, more accurately, which accepts a pointer to the first element of such an array, because of array-to-pointer decay. But that's not relevant here.)

To make complex types a bit easier to use, C allows you to declare an alias name for a type. Aliases are declared with typedef and otherwise look exactly like the declaration of a variable. So, for example, you can declare a variable of type int with

Copyint someNumber;

and thus you can declare an alias for the type int with

Copytypedef int someType;

Similarly, you could declare an array of eight pointers to const Triangle elements with

Copyconst Triangle* eightSlices[8];

In exactly the same way, you can declare a name for the type of such an array with:

Copytypedef const Triangle* EightSlices[8];

Note that the name of the type goes exactly where the name of the object would go, which can be somewhere in the middle of the declaration.

Part the third: both of the above in one statement

As a simple example of declaring type aliases, here's how you declare an alias for a structure type:

An incomplete structure definition:

Copytypedef struct Triangle Triangle;

Or a complete structure definition:

Copytypedef struct Triangle {
   int a, b, c;
} Triangle;

Or both, separately (and these could go in either order):

Copytypedef struct Triangle Triangle;
struct Triangle {
    int a, b, c;
};

Remember that structure tags and other identifiers (such as type aliases) are in different namespaces, so there is no conflict between the two uses of Triangle above. Some programmers feel that it is necessary to distinguish between them, even though one of them can only be used immediately after the word struct and the other one cannot be used following the word struct. Others -- and I think you can guess that I fall into this crowd -- find it convenient to deliberately use the same name for both, relying on the presence or absence of the word struct to let us know whether it is a type alias or a tag. (And, more commonly, to indicate that we have no intention of ever again using the tag.)

So, back to my opening comment:

There is no such thing as a "typedef struct".

And there isn't. What we have here is a very ordinary struct, declared and defined. And we have a very ordinary type alias which gives an alternate name for that struct. And that's it.

Note that you can give an alias to an anonymous type (such as a tagless structure type), after which the type is no longer anonymous. So there are some people who would leave out the tag in the above definition:

Copytypedef struct {
    int a, b, c;
} Triangle;

That looks a lot like the singleton structure type mentioned above, but since it is a type it can be used to declare multiple instances. But I don't actually recommend this style.

To each their own: an ignorable appendix

Everyone has their own style preferences, and most of these preferences are valid. Most of us have worked on more than one project, and since every project tends to develop its own style guide, we need to learn how to accept and use different styles in different projects. But I think most of us have some style with which we feel most comfortable, which we will revert to when we're writing code just for ourselves (or when we're starting a project with the intention of attracting colleagues prepared to conform to our style). And what I've used above is my style.

In fact, I try to avoid the condensed declaration+definition+alias syntax, preferring the two-declaration version shown above:

Copytypedef struct Triangle Triangle; /* type alias */
struct Triangle {
  int a, b, c;
};                                /* type definition */

The reason I prefer that is that it lets me define types with self-referring members, such as linked lists and trees:

Copytypedef struct TriangleList TriangleList;
struct TriangleList {
    Triangle      slice;
    TriangleList* next;
};

(If I hadn't forward-aliased the type, I would have had to declare the member as struct TriangleList* next; which makes for even uglier alignment.)

Sometimes I end up with mutually referring types, and in that case, I need to gather the aliases together before any of the structure definitions. That also can be advantageous, because the alias definitions allow for opaque use of pointers to the type and can therefore be placed into a public header which does not include the type definitions at all.

But that's all just me. Feel free to ignore it.

In C++, there is only a subtle difference. It's a holdover from C, in which it makes a difference.

The C language standard (C89 §3.1.2.3, C99 §6.2.3, and C11 §6.2.3) mandates separate namespaces for different categories of identifiers, including tag identifiers (for struct/union/enum) and ordinary identifiers (for typedef and other identifiers).

If you just said:

struct Foo { ... };
Foo x;

you would get a compiler error, because Foo is only defined in the tag namespace.

You'd have to declare it as:

struct Foo x;

Any time you want to refer to a Foo, you'd always have to call it a struct Foo. This gets annoying fast, so you can add a typedef:

struct Foo { ... };
typedef struct Foo Foo;

Now struct Foo (in the tag namespace) and just plain Foo (in the ordinary identifier namespace) both refer to the same thing, and you can freely declare objects of type Foo without the struct keyword.

The construct:

typedef struct Foo { ... } Foo;

is just an abbreviation for the declaration and typedef.

Finally,

typedef struct { ... } Foo;

declares an anonymous structure and creates a typedef for it. Thus, with this construct, it doesn't have a name in the tag namespace, only a name in the typedef namespace. This means it also cannot be forward-declared. If you want to make a forward declaration, you have to give it a name in the tag namespace.

In C++, all struct/union/enum/class declarations act like they are implicitly typedef'ed, as long as the name is not hidden by another declaration with the same name. See Michael Burr's answer for the full details.

The second option cannot reference itself. For example:

// Works:
struct LinkedListNode_ {
    void *value;
    struct LinkedListNode_ *next;
};

// Does not work:
typedef struct {
    void *value;
    LinkedListNode *next;
} LinkedListNode;

// Also Works:
typedef struct LinkedListNode_ {
    void *value;
    struct LinkedListNode_ *next;
} LinkedListNode;

My question is why typedef needs flight to be written a second time at the end of a block?

When you declare:

typedef struct flight{
    int number;
    int capacity;
    int passengers;
 }flight;

you actually declare two things:

• a new structure type struct flight
• a type alias name flight for struct flight.

The reason why the type alias name with typedef appears at the end of the declaration like for any ordinary declaration is because for historical reasons typedef was put in the same specifiers category as storage-class specifiers (like static or auto).

Note that you can just declare:

typedef struct {
    int number;
    int capacity;
    int passengers;
}flight;

without the tag name if you intend to only use the type identifier flight.

As Greg Hewgill said, the typedef means you no longer have to write struct all over the place. That not only saves keystrokes, it also can make the code cleaner since it provides a smidgen more abstraction.

Stuff like

typedef struct {
  int x, y;
} Point;

Point point_new(int x, int y)
{
  Point a;
  a.x = x;
  a.y = y;
  return a;
}

becomes cleaner when you don't need to see the "struct" keyword all over the place, it looks more as if there really is a type called "Point" in your language. Which, after the typedef, is the case I guess.

Also note that while your example (and mine) omitted naming the struct itself, actually naming it is also useful for when you want to provide an opaque type. Then you'd have code like this in the header, for instance:

typedef struct Point Point;

Point * point_new(int x, int y);

and then provide the struct definition in the implementation file:

struct Point
{
  int x, y;
};

Point * point_new(int x, int y)
{
  Point *p;
  if((p = malloc(sizeof *p)) != NULL)
  {
    p->x = x;
    p->y = y;
  }
  return p;
}

In this latter case, you cannot return the Point by value, since its definition is hidden from users of the header file. This is a technique used widely in GTK+, for instance.

UPDATE Note that there are also highly-regarded C projects where this use of typedef to hide struct is considered a bad idea, the Linux kernel is probably the most well-known such project. See Chapter 5 of The Linux Kernel CodingStyle document for Linus' angry words. :) My point is that the "should" in the question is perhaps not set in stone, after all.

There are several things going on here. First, as others have said, the compiler's complaint about unknown type may be because you need to declare the types before using them. More important though is to understand the syntax of 3 things:

1. definition of struct type,
2. definition and declaration of struct variable, and
3. typedef

(Note that in the C-programming language, definition and declaration usually happen at the same time, and thus are essentially the same. This is not the case in many other languages. See footnote below for further details.)

When defining a struct, the struct can be tagged (named), or untagged (if untagged, then the struct must be used immediately (will explain what this means further below)).

struct Name {
   ...
};

This defines a type called "struct Name" which then can be used to define a struct variable/instance:

struct Name myNameStruct;

This defines a variable called myNameStruct which is a struct of type struct Name.

You can also define a struct, and declare/define a struct variable at the same time:

struct Name {
   ...
} myNameStruct;

As before, this defines a variable called myNameStruct which is an instance of type struct Name ... But it does it at the same time it defines the type struct Name.
The type can then be used again to declare and define another variable:

struct Name myOtherNameStruct;

Now typedef is just a way to alias a type with a specific name:

typedef OldTypeName NewTypeName;

Given the above typedef, any time you use NewTypeName it is the same as using OldTypeName. In the C programming language this is particularly useful with structs, because it gives you the ability to leave off the word "struct" when declaring and defining variables of that type and to treat the struct's name simply as a type on its own (as we do in C++). Here is an example that first defines the struct, and then typedefs the struct:

struct Name {
   ...
};

typedef struct Name Name_t;

In the above OldTypeName is struct Name and NewTypeName is Name_t. So now, to define a variable of type struct Name, instead of writing:

struct Name myNameStruct;

I can simple write:

Name_t myNameStruct;

NOTE ALSO, the typedef CAN BE COMBINED with the struct definition, and this is what you are doing in your code:

typedef struct {
   ...
} Name_t;

This can also be done while tagging (naming) the struct. This is useful for self-referential structs (for example linked-list nodes), but is otherwise superfluous. None-the-less, many follow the practice of always tagging structs, as in this example:

typedef struct Name {
   ...
} Name_t;

NOTE WELL: In the syntax above, since you have started with "typedef" then the whole statement is a typedef statement, in which the OldTypeName happens to be a struct definition. Therefore the compiler interprets the name coming after the right curly brace } as the NewTypeName ... it is NOT the variable name (as it would be in the syntax without typedef, in which case you would be defining the struct and declaring/defining a struct variable at the same time).

Furthermore, if you state typedef, but leave off the Name_t at then end, then you have effectively created an INCOMPLETE typedef statement, because the compiler considers everything within "struct Name { ... }" as OldTypeName, and you are not providing a NewTypeName for the typedef. This is why the compiler is not happy with the code as you have written it (although the compiler's messages are rather cryptic because it's not quite sure what you did wrong).

Now, as I noted above, if you do not tag (name) the struct type at the time you define it, then you must use it immediately, either to define a variable:

struct {
   ...
} myNameStruct;  // defines myNameStruct as a variable with this struct
                 // definition, but the struct definition cannot be re-used.

Or you can use an untagged struct type inside a typedef:

typedef struct {
   ...
} Name_t;

This final syntax is what you actually did when you wrote:

typedef struct{
   char firstName[56];
   char lastName[56];
} Author;

And the compiler was happy. HTH.

Regarding the comment/question about the _t suffix:

_t suffix is a convention, to indicate to people reading the code that the symbolic name with the _t is a Type name (as opposed to a variable name). The compiler does not parse, nor is it aware of, the _t.

The C89, and particularly the C99, standard libraries defined many types AND CHOSE TO USE the _t for the names of those types. For example C89 standard defines wchar_t, off_t, ptrdiff_t. The C99 standard defines a lot of extra types, such as uintptr_t, intmax_t, int8_t, uint_least16_t, uint_fast32_t, etc. But _t is not reserved, nor specially parsed, nor noticed by the compiler, it is merely a convention that is good to follow when you are defining new types (via typedef) in C. In C++ many people use the convention to start type names with an uppercase, for example, MyNewType ( as opposed to the C convention my_new_type_t ). HTH

Footnote about the differences between declaring and defining: First a special thanks to @CJM for suggesting clarifying edits, particularly in relation to the use of these terms. The following items are typically declared and defined: types, variables, and functions.

• Declaring gives the compiler only a symbolic name and a "type" for that symbolic name.
  • For example, declaring a variable tells the compiler the name of that variable, and its type.
• Defining gives the complier the full details of an item:
  • In the case of a type, defining gives the compiler both a name, and the detailed structure for that type.
  • In the case of a variable, defining tells the compiler to allocate memory (where and how much) to create an instance of that variable.

Generally speaking, in a program made up of multiple files, the variables, types and functions may be declared in many files, but each may have only one definition.

In many programming languages (for example C++) declaration and definition are easily separated. This permits "forward declaration" of types, variables, and functions, which can allow files to compile without the need for these items to be defined until later. In the C programming language however declaration and definition of variables are one and the same. (The only exception, that I know of, in the C programming language, is the use of keyword extern to allow a variable to be declared without being defined.) It is for this reason that in a previous edit of this answer I referred to "definition of structs" and "declaration of struct [variables]," where the meaning of "declaration of a struct [variable]" was understood to be creating an instance (variable) of that struct.

What this does:

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

Is define an anonymous struct and give it the alias ab_t. For this case there's no problem as you can always use the alias. It would however be a problem if one of the members was a pointer to this type.

If for example you tried to do something like this:

typedef struct {
    int count;
    TNODE *left, *right;
} TNODE;

This wouldn't work because the type TNODE is not yet defined at the point it is used, and you can't use the tag of the struct (i.e. the name that comes after the struct keyword) because it doesn't have one.

typedef struct THIS_IS_A_TAG
{
    int a;
    int b;
} THIS_IS_A_TYPEDEF;

THIS_IS_A_TYPEDEF object1;     // declare an object.       C:Ok,     C++:Ok
struct THIS_IS_A_TAG object2;  // declare another object.  C:Ok,     C++:Ok
THIS_IS_A_TAG object3;         // declare another object.  C:Not Ok, C++:Ok

The reason for the typedef is because C programmers would like to be able to do that third thing, but they can't.

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 typedefed 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.

There are actually four name-spaces in C (although this depends on a particular way of counting, and some include macro names as a fifth space, which I think is a valid way to think about them):

• goto labels
• tags (struct, union, and enum)
• the actual members of a struct or union type (one per type, hence you could count this as "many" instead of "one" name space)
• all other ("ordinary") identifiers, such as function and variable names and the names made to be synonyms for other types via typedef.

While it should (in theory) be possible to have separate spaces for struct vs union, for instance, C does not, so:

struct foo; union foo; /* ERROR */

is invalid. Yet:

struct foo { int a, b; };
struct bar { char b; double a; };

is just fine, showing that the members of the two different struct types are in different name-spaces (so again this makes the count of "4 name-spaces" above suspect :-) ).

All that aside, C has some moderately (and in some ways unnecessarily) complicated, but quite workable in practice, rules for how struct types work.

Each struct creates a new type unless it refers back to an existing type. The struct keyword may be followed by an identifier, or just an open brace {. If there is just an open brace, the struct creates a new type:

struct { ... } X; /* variable X has a unique type */

If there is an identifier, the compiler must look at the (single) tag name-space to see if that name is already defined. If not, the struct defines a new type:

struct blart { ... } X; /* variable X has type <struct newname>, a new type */

If the identifier is already present, generally this refers back to the existing type:

struct blart Y; /* variable Y has the same type as variable X */

There is one special exception, though. If you're in a new scope (such as at the beginning of a function), a "vacuous declaration"—the struct keyword, followed by an identifier, followed by a semicolon—"clears out" the previous visible type:

void func(void) {
    struct blart; /* get rid of any existing "struct blart" */
    struct blart { char *a; int b; } v;

Here v has a new type, even if struct blart was already defined outside func.

(This "vacuous declaration" trick is mostly useful in obfuscated code contests. :-) )

If you're not at a new scope, a vacuous declaration serves the purpose of declaring that the type exists. This is mainly useful to work around a different issue, which I will cover in a moment.

struct blart;

Here struct blart alerts you (and the compiler) that there is now a type named "struct blart". This type is merely declared, meaning that the struct type is "incomplete", if struct blart has not yet been defined. This type is defined (and "complete") if struct blart has been defined. So:

struct blart { double blartness; };

defines it, and then any earlier or later struct blarts refer to the same type.

Here's why this sort of declaration is useful. In C, any declaration of an identifier has scope. There are four possible scopes: "file", "block", "prototype", and "function". The last one (function scope) is exclusively for goto labels, so we can ignore it from here on. That leaves file, block, and prototype scopes. File scope is a technical term for what most people think of as "global", in contrast with "block scope" which is "local":

struct blart { double blartness } X; /* file scope */
void func(void) {
    struct slart { int i; } v; /* block scope */
    ...
}

Here struct blart has file scope (as does "global" variable X), and struct slart has block scope (as does "local" variable v).

When the block ends, struct slart goes away. You can no longer refer to it by name; a later struct slart creates a new and different type, in exactly the same way that a later int v; creates a new v, and does not refer to the v within the block scope inside function func.

Alas, the committee that designed the original C standard included (for good reason) one more scope, inside the function prototype, in a way that interacts rather badly with these rules. If you write a function prototype:

void proto(char *name, int value);

the identifiers (name and value) disappear after the closing parenthesis, just as you'd expect—you wouldn't want this to create a block-scope variable called name. Unfortunately, the same happens with struct:

void proto2(struct ziggy *stardust);

The name stardust goes away, but so does struct ziggy. If struct ziggy did not appear earlier, that new, incomplete type that is created inside the prototype, has now been removed from all human reach. It can never be completed. Good C compilers print a warning here.

The solution is to declare the struct—whether complete or not [*]—before writing the prototype:

struct ziggy; /* hey compiler: "struct ziggy" has file scope */
void proto2(struct ziggy *stardust);

This time, struct ziggy has an already-existing, visible declaration to refer back to, so it uses the existing type.

[* In header files, for instance, you often don't know if the header that defines the struct has been included, but you can declare the struct yourself, and then define protoypes that use pointers to it.]

Now, as to typedef...

The typedef keyword is syntactically a storage-class specifier, like register and auto, but it acts quite weird. It sets a flag in the compiler that says: "change variable declarations into type-name aliases".

If you write:

typedef int TX, TY[3], *TZ;

the way that you (and the compiler) can understand this is to start by removing the typedef keyword. The result needs to be syntactically valid, and it is:

int TX, TY[3], *TZ;

This would declare three variables:

• TX has type int
• TY has type "array 3 of int"
• TZ has type "pointer to int"

Now you (and the compiler) put the typedef back in, and change "has" to "is another name for":

• TX is another name for type int
• TY is another name for "array 3 of int"
• TZ is another name for "pointer to int"

The typedef keyword works with struct types in exactly the same way. It's the struct keyword that creates the new type; then typedef changes the variable declaration(s) from "has type ..." to "is another name for type ...". So:

typedef struct ca ca_t;

starts by either creating new type, or referring back to existing type, struct ca as usual. Then, instead of declaring a variable ca_t as having type struct ca, it declares the name as another name for the type struct ca.

If you omit the struct tag name, you are left with only two valid syntactic patterns:

typedef struct; /* note: this is pointless */

or:

typedef struct { char *top_coat; int top_hat; } zz_t, *zz_p_t;

Here, struct { creates a new type (remember, we said this way back at the beginning!), and then after the closing }, the identifiers that would have declared variables, now make type-aliases. Again, the type was actually created by the struct keyword (although it hardly matters this time; the typedef-names are now the only ways to refer to the type).

(The reason the first pointless pattern is the way it is, is that without the braces, the first identifier you stick in is the struct-tag:

typedef struct tag; /* (still pointless) */

and thus you haven't omitted the tag after all!)

As for the last question, about the syntax error, the problem here is that C is designed as a "single pass" language, where you (and the compiler) never have to look very far forward to find out what something is. When you attempt something like this:

typedef struct list {
    ...
    List *next; /* ERROR */
} List;

you've given the compiler too much to digest at once. It starts by (in effect) ignoring the typedef keyword except to set the flag that changes the way variables will be declared. This leaves you with:

struct list {
    ...
    List *next; /* ERROR */
}

The name List is simply not yet available. The attempt to use List *next; does not work. Eventually the compiler would reach the "variable declaration" (and because the flag is set, change it to a type-alias instead), but it's too late by then; the error has already occurred.

The solution is the same as with function prototypes: you need a "forward declaration". The forward declaration will give you an incomplete type, until you finish defining the struct list part, but that's OK: C lets you use incomplete types in a number of positions, including when you want to declare a pointer, and including with typedef alias-creation. So:

typedef struct list List; /* incomplete type "struct list" */

struct list { /* begin completing "struct list" */
    ...
    List *next; /* use incomplete "struct list", through the type-alias */
}; /* this "}" completes the type "struct list" */

This gains relatively little over just writing struct list everywhere (it saves a bit of typing, but so what? well, OK, some of us suffer a bit of carpal tunnel / RSI issues :-) ).

[Note: this last segment is going to cause controversy... it always does.]

In fact, if you mentally replace struct with type, C code becomes a whole lot nicer to "strongly typed language" fans. Instead of the terrible [%], weak-sauce:

typedef int distance; /* distance is measured in discrete units */
typedef double temperature; /* temperatures are fractional */

they can write:

#define TYPE struct

TYPE distance;
TYPE temperature;

These, being incomplete types, are truly opaque. To create or destroy or indeed do anything with a distance value you must call a function (and—for most variables anyway; there are some exceptions for external identifiers—use pointers, alas):

TYPE distance *x = new_distance(initial_value);

increase_distance(x, increment);
use_distance(x);
destroy_distance(x);

Nobody can write:

*x += 14; /* 3 inches in a dram, 14 ounces in a foot */

It simply won't compile.

Those who are a bit less bondage-and-discipline with their type systems can relax the constraints by completing the type:

TYPE distance { int v; };
TYPE temperature { double v; };

Of course, now "cheaters" can do:

TYPE distance x = { 0 };
x.v += 14; /* 735.5 watts in a horsepower */

(well, at least that last comment is correct).

[% Not really that terrible, I think. Some seem to disagree.]

In your first case, you are creating an object of type struct books named book.

In the second, you are defining an alias book for the type struct books. Thus book is not an object but a type name.

Update: please see comments attached to answer for clarification.

Original post.

Besides having to write "struct" everywhere, something else of note is that using a typedef will allow you to avoid subtle syntax errors when working with pointers:

Quote:

Typedefs can also simplify declarations for pointer types. Consider this:

struct Node {
    int data;
    struct Node *nextptr;
};

Using typedef, the above code can be rewritten like this:

typedef struct Node Node;
struct Node {
    int data;
    Node *nextptr;
};

In C, one can declare multiple variables of the same type in a single statement, even mixing pointer and non-pointers. However, one would need to prefix an asterisk to each variable to designate it as a pointer. In the following, a programmer might assume that errptr was indeed a Node *, but a typographical error means that errptr is a Node. This can lead to subtle syntax errors.

struct Node *startptr, *endptr, *curptr, *prevptr, errptr, *refptr;

By defining a Node * typedef, it is assured that all the variables will be pointer types.

typedef struct Node *NodePtr;
...
NodePtr startptr, endptr, curptr, prevptr, errptr, refptr;

I worked on a large project that extensively used typedef'd structs. We did so for a couple of reasons. Please keep in mind that this was pre-C99 and namespace segregation.

1. It was easier to type my_buffer_type *buffer instead of struct tag_buffer_type *buffer, and for the size of the codebase (1M+ loc) that made a big difference.

2. It abstracts the structure into an object. Rather than focus on every individual variable within the struct, we would focus on the data object that it represented. This abstraction led to generally more useful and easier to write code.

   • I think this is in direct contradiction to the quote attributed to Greg Kroah-Hartman that you provided. FWIW, that project was a client / server application and not a kernel so there's definitely some different considerations to take into account.

3. Treating the structure as an object also enabled us to better encapsulate the information. Code review caught quite a few situations where a newer developer would violate the principles of encapsulation we had put in place. Using typedef'd structs really made those violations obvious.

4. Portability was a concern as we wrote for a half-dozen platforms with the server and quite a few more with the client.

You can forward declare a struct without typedef too - the only distinctions are:

• whether the interface looks cleaner with or without the keyword struct
• whether the interface looks cleaner with or without the explicit pointer *

Eg.

struct S1;
typedef struct S2 S2;
typedef struct S3_s *S3;

void foo1(struct S1 *arg);
void foo2(S2 *arg);
void foo3(S3);

Obviously this only applies for forward-declared structures in an interface header.

If you're not hiding the structure implementation in the first place, choosing between S1 and S2 is a matter of preference (or consistency). I wouldn't use S3 unless it's a really opaque/hidden type.

Personal preference would be to use S1 (explicit struct keyword) for big/complex aggregates, and S2 for small structs you might treat like values and not always pass by pointer. YMMV.

Yes. The first version

typedef struct
{
    // members    
} Point;

defines an anonymous struct (i.e., a struct that doesn't have a name) and gives it a type name (i.e., Point). Unfortunately, if you decide to have a pointer to a recursive member inside your struct this way, you won't be able to do that because as long as you're before the semicolon that ends the typedef statement, you won't be able to use the type name Point.

On the other hand,

typedef struct Point
{
    // members
} Point;

defines a struct named struct Point and gives it a type name Point. Both struct Point and Point can be used interchangeably. You'll also be able to create a recursive member inside your struct as follows

struct Point *pp;

Hope that helps!

Let's analyse your code a bit:

typedef struct nodes
{
    int data;
    struct node *next;
}node;

This declares and defines struct nodes, a type with two members, and declares a type alias so we can refer to it only as node.

Now, in C++, the member declaration struct node *next automatically forward-declares a type called node. That then conflicts with your typedef target node: it's as if you're trying to give two types the same name.

In C, there is no conflict, because the type called node can in fact only be referred to as struct node.

The second snippet worked because, since during parsing of the member declaration struct node already exists, no new type is forward-declared there … and since all you're then doing is renaming it in the same typedef statement, C++ doesn't really care, knowing that it's all the same type (struct T is T; the difference is in syntax, not in name).

[C++11: 7.1.3/3]: In a given non-class scope, a typedef specifier can be used to redefine the name of any type declared in that scope to refer to the type to which it already refers. [ Example:

typedef struct s { / ... / } s;
typedef int I;
typedef int I;
typedef I I;

—end example ]

[C++11: 7.1.3/6]: In a given scope, a typedef specifier shall not be used to redefine the name of any type declared in that scope to refer to a different type. [ Example:

class complex { / ... / };
typedef int complex; // error: redefinition

—end example ]

Of course, in C++, this is all moot and you should just write:

struct node
{
   int data;
   node* next;
};

You do not need to typedef-away the elaborated-type-specifier struct.