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 typedef
ing it to a different type name?
In general, a pointer, or a struct that has elements that can reasonably be directly accessed should never be a typedef.
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.
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.
You can't "typedef a struct", that doesn't mean anything.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With