Are there technical reasons to pick one struct coding style over the other?

Arguments in favour of "struct tag style":

• Less namespace clutter.

  C has a peculiar name space system where all identifiers belong to one of: labels, tags, members, ordinary. Struct tag style only occupies a name in the tag name space.

  Meaning that struct tags will not collide with everything else in the ordinary name space and so using that style means less naming collisions overall, if the structs are exposed to the whole program through a header file.

  (They may of course still collide with other structs, unions or enums however.)

  Similarly, self-referencing structs that use "typedef style" will occupy twice the amount of identifiers:

  typedef struct node { .... struct node* next; } node;

  This occupies the identifier node in both the tag and ordinary name spaces.

Arguments in favour of "typedef style":

• Type swapping/punning/serializing struct types with the help of unions.

  Suppose you have some struct

  struct s 
  { 
    uint16_t x; 
    uint16_t y; 
  };
  

  and later on realize that it would be handy to access this struct in more ways than one. With the nice little feature of C11 anonymous structs, we can rewrite this declaration into a union while remaining backwards-compatible:

  union s
  {
    struct
    { 
      uint16_t x; 
      uint16_t y; 
    };    
    struct
    {
      uint8_t x_lo; // assuming little endian & no padding
      uint8_t x_hi;
      uint8_t y_lo;
      uint8_t y_hi;
    };
  
    uint8_t raw_data [4];
  };
  

  You'll see unions like this all the time for embedded system MCU register maps, data protocol definitions and similar.

  Thanks to C11 anonymous structs we can rewrite the struct like this and not break any existing code already using it as obj.x.

  However, if we used "struct tag" style, we would have to rewrite all the code using what was once a struct and instead type union all over the place.

  Similarly, in case of the mentioned register maps, we may have all manner of hardware registers where some are declared as structs and some as union. It becomes an unholy mess for the user of the register map if they are to type out either struct or union depending on register. I've never seen a MCU vendor-provided register map using "struct tag style", likely for this very reason.

• Type-generic and/or macro trick programming.

  Type-generic programmming in old school C typically uses void pointers in combination with some enum to keep track of what type the data is. There may also be various macro tricks where you want to pass along a type as a pre-processor token, for whatever reason.

  In both of these cases, it is highly inconvenient to have types consisting of multiple words with white space in between them.

  Example - suppose we have a "X macro" listing all supported types by some program:

  #define SUPPORTED_TYPES(X) \
    X(int)                   \
    X(double)                \
  

  We might now use this for example to generate an enum, to get a unique integer value corresponding to each type supported:

  typedef enum
  {
    #define ENUM_NAME(type) SOMETHING_##type,
    SUPPORTED_TYPES(ENUM_NAME)
  } type_t;
  

  So far so good. Then I want to add a struct to the list:

  struct my_struct { int x; };
  
  #define SUPPORTED_TYPES(X) \
    X(int)                   \
    X(double)                \
    X(struct my_struct)      \ 
  

  And bam: syntax error upon token concatenation SOMETHING_##type, because we suddenly try to create an enumeration constant called SOMETHING_struct my_struct.

  Whereas typedef struct { int x; } my_struct; works seamlessly.

  Similarly, only using one single pre-processor token for the type might help with macro "stringification" using the # operator.

• Opaque types.

  Yes, that subjective Linux kernel document did manage to find a single non-subjective argument and ironically it was one against using "struct tag style".

  When declaring opaque types - see How to do private encapsulation in C? - the preferred forward declaration in the header is typedef struct my_struct my_struct;. Mainly because the user of the opaque type need not and should not worry about what type they are actually dealing with.

  But at the same time we cannot use typedef twice both for forward declaration and struct defintion. So the actual struct definition in the .c file would still have to be struct my_struct {...}; even if the API of our opaque type always uses my_struct* without the struct keyword everywhere else. It kind of ends up a combination of the two styles.

• C++ compatibility.

  In C++, structs are just a poor man's class and tags do not work quite the same - what you type after struct is the name of the type, period. You never type out struct my_type x; in C++. Or well, you can, but it looks quite alien and out of place among the rest of the language conventions.

posted 10 months ago

CC BY-SA 4.0

10mo ago

Lundin‭

9041 reputation 38 124 1039 167