Home » C++ » Why does C++ disallow anonymous structs and unions?

Why does C++ disallow anonymous structs and unions?

Posted by: admin November 29, 2017 Leave a comment

Questions:

Some C++ compilers permit anonymous unions and structs as an extension to standard C++. It’s a bit of syntactic sugar that’s occasionally very helpful.

What’s the rationale that prevents this from being part of the standard? Is there a technical roadblock? A philosophical one? Or just not enough of a need to justify it?

Here’s a sample of what I’m talking about:

struct vector3 {
  union {
    struct {
      float x;
      float y;
      float z;
    };
    float v[3];
  };
};

My compiler will accept this, but it warns that “nameless struct/union” is a non-standard extension to C++.

Answers:

As others have pointed out anonymous unions are permitted in standard C++, but anonymous structs are not.

The reason for this is that C supports anonymous unions but not anonymous structs*, so C++ supports the former for compatibility but not the latter because it’s not needed for compatibility.

Furthermore, there’s not much use to anonymous structs in C++. The use you demonstrate, to have a struct containing three floats which can be referred to either by .v[i], or .x, .y, and .z, I believe results in undefined behavior in C++. C++ does not allow you to write to one member of a union, say .v[1], and then read from another member, say .y. Although code that does this is not uncommon it is not actually well defined.

C++’s facilities for user-defined types provide alternative solutions. For example:

struct vector3 {
  float v[3];
  float &operator[] (int i) { return v[i]; }
  float &x() { return v[0]; }
  float &y() { return v[1]; }
  float &z() { return v[2]; }
};

* C11 apparently adds anonymous structs, so a future revision to C++ may add them.

Questions:
Answers:

I’ll say, you can clean up your vector3 declaration by just using a union

union vector3 {
  struct { float x, y, z; } ;
  float v[3] ;
} ;

Sure, anonymous structures was an MSVC extension. But ISO C11 permits it now, and gcc allows it, and so does Apple’s llvm compiler.

Why in C11 and not C++11? I’m not sure, but practically speaking most (gcc++, MSVC++ and Apple’s C++ compiler) C++ compilers support them.

Questions:
Answers:

Not sure what you mean. Section 9.5 of the C++ spec, clause 2:

A union of the form

union { member-specification } ;

is called an anonymous union; it defines an unnamed object of unnamed type.

You can do things like this too:

void foo()
{
  typedef
  struct { // unnamed, is that what you mean by anonymous?
    int a;
    char b;
  } MyStructType; // this is more of a "C" style, but valid C++ nonetheless

  struct { // an anonymous struct, not even typedef'd
    double x;
    double y;
  } point = { 1.0, 3.4 };
}

Not always very useful… although sometimes useful in nasty macro definitions.

Questions:
Answers:

Unions can be anonymous; see the Standard, 9.5 paragraph 2.

What purpose do you see an anonymous struct or class as fulfilling? Before speculating why something isn’t in the Standard, I’d like to have some idea why it should be, and I don’t see a use for an anonymous struct.

Questions:
Answers:

Based on the edit, the comments, and this MSDN article: Anonymous Structures, I’ll hazard a guess – it fits poorly with the concept of encapsulation. I wouldn’t expect a member of a class to mess with my class namespace beyond merely adding one member. Furthermore, changes to the anonymous structure can affect my class without permission.

Questions:
Answers:

Your code

union {
  struct {
    float x;
    float y;
    float z;
  };
  float v[3];
};

is like

union Foo {
   int;
   float v[3];
};

which is surely invalid (in C99 and before).

The reason is probably to simplify parsing (in C), because in that case you only need to check that the struct/union body has only “declarator statements” like

Type field;

That said, gcc and “other compilers” supports unnamed fields as an extension.

Edit: Anonymous structs are now officially supported in C11 (§6.7.2.1/13).