Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why use different a different tag and typedef for a struct?

Tags:

c

struct

typedef

In C code, I've seen the following:

typedef struct SomeStructTag {
    // struct members
} SomeStruct;

I'm not clear on why this is any different from:

typedef struct SomeStruct {
    // struct members
} SomeStruct;

What's the point of using a particular name for the type and typedefing it to a different type name?

like image 983
GarlicFries Avatar asked Dec 11 '13 23:12

GarlicFries


People also ask

Should you use typedef for structs?

In general, a pointer, or a struct that has elements that can reasonably be directly accessed should never be a typedef.

Why do you use typedef in a structure?

The C language contains the typedef keyword to allow users to provide alternative names for the primitive (e.g.,​ int) and user-defined​ (e.g struct) data types. Remember, this keyword adds a new name for some existing data type but does not create a new type.

What is the difference between a struct and a typedef struct?

Basically struct is used to define a structure. But when we want to use it we have to use the struct keyword in C. If we use the typedef keyword, then a new name, we can use the struct by that name, without writing the struct keyword.

Can typedef and struct have same name?

You can't "typedef a struct", that doesn't mean anything.


1 Answers

In most cases, one could use the same name for both purposes without any problem. The practice of people using different names in code probably stems from the days before ANSI standardization, when there were a lot of compilers that accepted mostly-compatible dialects of something resembling C. Some constructs and features would work on almost any compiler, others would work on most (but fail on a significant number), and others would only work on a few. Although the standard has for many years clearly mandated that there are different namespaces for types, structure tags, and for the members of each individual structure, some compilers from the early days didn't recognize all those namespaces as distinct, a fair amount of code was written which was supposed to work even with such compilers, and people tend to write code which resembles other code they've seen.

I think the strongest objection to using the same identifier given today's rules would be the principle that distinct identifiers should look distinct, and one should generally avoid using two semantically-equivalent identifiers for a given purpose. It's fine to use two distinct identifiers for some purpose if there's some clear semantic distinction between them (e.g. "the fastest type that's at least 32 bits" versus an "exactly 32 bits" type), but it's not good to have code use two different identifiers for the same purpose essentially at random. If one declares typedef struct FOO {...} FOO;, then struct FOO and FOO will be distinct identifiers that look as though they should be interchangeable. If there are particular cases where one is supposed to use one or the other and the names are distinct, then typing struct where one shouldn't, or vice versa, will cause a compilation error. If the names match, things would compile and there would be no warning that the usage of the name wasn't consistent with its usage elsewhere.

Incidentally, although struct tags are globally available, there often isn't any need to use any tag more than once. Even if a struct is supposed to contain self-referential pointers, one may, in ANSI C, declare it:

typedef struct NODE_S NODE;
struct NODE_S {
  NODE *parent,*left,*right;
};

without having to refer to the type as struct NODE_S anywhere except the particular line declaring the typedef name. Everywhere else, one may instead simply use the typedef name directly.

like image 88
supercat Avatar answered Nov 15 '22 18:11

supercat