4 ms·

The article doesn't say why they have this rule, but I would argue that if you use the tag sometimes, then you might as well use it consistently every time you

The article doesn't say why they have this rule, but I would argue that if you use the tag sometimes, then you might as well use it consistently every time you declare a struct. There is no harm in it. I think some of the contortions around this might come from people who are afraid of polluting global namespaces. But struct tags and other names live in different namespaces. Your second example could just as well (and without using a __ prefix, which is reserved for the implementation and therefore, strictly speaking, is undefined behavior in user code) be: typedef struct my_struct_t { struct my_struct_t* link; } my_struct_t; or even struct my_struct_t { struct my_struct_t* link; }; typedef struct my_struct_t my_struct_t; Arguably, if you "own" the my_struct_t type name, you also have a right to declare "struct my_struct_t".

deaddodo 7y ago
> but I would argue that if you use the tag sometimes, then you might as well use it consistently every time you declare a struct. There is no harm in it. Sure, but that's a preference. Which was my point. I'm not against people tagging structs, but I'm also not against typedef'd untagged structs. And clearly the C community at large isn't either. > But struct tags and other names live in different namespaces. I'm aware of where tags live, I just see no necessity in defining something that will never be used. > Your second example could just as well (and without using a __ prefix, which is reserved for the implementation and therefore, strictly speaking, is undefined behavior in user code) be: This is pedantry and off topic. Name it whatever you like. It can be zyzzyx, for all I care; it's an internal tag at this point. You're correct about the __, that was intended to be _; and is simply a preference on my part. I'm not evangelizing it's use. > Arguably, if you "own" the my_struct_t type name, you also have a right to declare "struct my_struct_t". That's not the point. I will never call "struct my_struct_t" outside of a self-referential context. So it's pointless. I could define a tag. I could not. My code will compile the same.

deaddodo 7y ago

> but I would argue that if you use the tag sometimes, then you might as well use it consistently every time you declare a struct. There is no harm in it. Sure, but that's a preference. Which was my point. I'm not against people tagging structs, but I'm also not against typedef'd untagged structs. And clearly the C community at large isn't either. > But struct tags and other names live in different namespaces. I'm aware of where tags live, I just see no necessity in defining something that will never be used. > Your second example could just as well (and without using a __ prefix, which is reserved for the implementation and therefore, strictly speaking, is undefined behavior in user code) be: This is pedantry and off topic. Name it whatever you like. It can be zyzzyx, for all I care; it's an internal tag at this point. You're correct about the __, that was intended to be _; and is simply a preference on my part. I'm not evangelizing it's use. > Arguably, if you "own" the my_struct_t type name, you also have a right to declare "struct my_struct_t". That's not the point. I will never call "struct my_struct_t" outside of a self-referential context. So it's pointless. I could define a tag. I could not. My code will compile the same.