31

I'm learning C and find someone defined a struct, its struct name has _ in front of it. This is my first time seen it, can someone tell me a little bit more about it? Why someone would use _aStructName instead of aStructName, what are the benefits?

struct _huffmanNode {
    int value;
    uint32_t frequency;

    int hasChild;
    struct _huffmanNode *child[2];

    struct _huffmanNode *next;
};

similarly I find someone using this kind of naming convention in the following code:

typedef struct HuffCode_ {

unsigned char      used;
unsigned short     code;
unsigned char      size;

} HuffCode;
Dori
  • 18,283
  • 17
  • 74
  • 116
Dean
  • 1,103
  • 4
  • 17
  • 29
  • 11
    Note that all identifiers that begin with an underscore are reserved for the implementation and should not be used for your own identifiers. – pmg Apr 05 '11 at 22:03
  • 11
    @pmg: All identifiers that begin with **two** underscores are reserved for implementation. All identifiers that begin with one underscore should not be visible outside the file scope (for example a static global or an internal struct) – Shahbaz Apr 13 '12 at 19:45

5 Answers5

21

There is no benefit in user code, it's just ugly. In the second example, the HuffCode_ isn't even necessary since the struct type is already named by the typedef.

The only places where this can be useful are:

  1. When StructName is already in use, StructName_ gives a different name (but you should really come up with a better name).
  2. Identifiers in the C standard library that are not defined by the standard shouldn't conflict with user code identifiers. Therefore, C library writers use the _ prefix in the hopes that users will not use that. Unfortunately, some users do.
  3. In very old compilers, it may be useful to give the struct a different name than is used in the typedef. You need both the typedef and the other name if you're building a linked structure (example).
Community
  • 1
  • 1
Fred Foo
  • 355,277
  • 75
  • 744
  • 836
9

I think this is done mostly because of the very mistaken idea that a struct and a type cannot have the same name. In other words, that somehow

struct MyStruct;
typedef struct MyStruct MyStruct;

will collide in strange ways because the struct and the typedef have the same name. This is wrong in C. The name of a struct is considered a tag, whereas a typedef creates a type name. These live in two different namespaces and will not collide. In my opinion, it makes a lot more sense for the tag of the struct to be the same as the typedef, assuming you use a typedef at all. In C, you must always reference a struct with the struct keyword. For example, if you define

struct MyStruct;

but do not make a typedef, then the following is invalid:

void myfunction()
{
  MyStruct var;   /* compiler error: MyStruct is not defined. */
  struct MyStruct var2; /* this is OK, MyStruct is a valid name for a struct. */
}

If you want to define variables (or arguments) of type MyStruct in C, you must provide a typedef:

typedef struct MyStruct MyStruct;

void myfunction2()
{
  MyStruct var;  /* this is ok now */
  struct MyStruct var2; /* this is still ok too */
}

In this second example, var, and var2 have the same type, although this isn't obvious. Indeed, if the typedef were changed, they would no longer have the same type. Beware of this! It can cause some interesting bugs if type definitions change.

In C++, a struct definition essentially creates an implicit typedef so that both of the above code snippets compile. There is, in C++, essentially no difference between a struct name (or tag) and a type name. Which is, in my opinion, another great reason to name the two the same way, especially if you anticipate that your C module might be used by some C++ code at some point.

Jeremy West
  • 11,495
  • 1
  • 18
  • 25
8

A lot of the time in straight C, people like to typedef their structs so that they don't look so ugly. So they name the struct itself something ugly, and the typedef something clean. Usually the convention I've seen in the GNU world is:

typedef struct mytype_t
{
    int field;
    char field2;
} mytype;
Chris Eberle
  • 47,994
  • 12
  • 82
  • 119
  • 14
    They should just omit the name, or give it the same name as the `typedef`. The `_t` convention isn't uglifying, it's to denote that something is a type. (I've seen `typedef struct foo {...} foo_t` much more often.) – Fred Foo Apr 05 '11 at 21:59
  • 3
    Maybe worth mentioning that POSIX claims to own types with suffix `*_t`. – Jeremy West May 02 '18 at 01:58
  • 3
    and also is worthy to mention that Linux kernel coding style tells that is a "mistake" to typedef structs and pointers just to hide their nature and it is far cleaner to avoid such typedef-ing. (source here, § 5: http://lxr.linux.no/linux+v4.15.14/Documentation/process/coding-style.rst) – MaxC May 04 '20 at 20:54
4

I use a variant of the second example:

typedef struct huffcode {
... } HuffCode;
Richard Schneider
  • 34,944
  • 9
  • 57
  • 73
2

Convention from school 42 (norminette)

typedef struct s_name
{
  ...
} t_name;
Mendes
  • 972
  • 9
  • 11