Problem with anonymous structs and unions

Problem with anonymous structs and unions

[mramirez]

Hi,

I am having problems to compile the following snippet of code:

struct Vector2
{
    union
    {
        struct
        {
            float x, y;
        };
        struct
        {
            float u, v;
        };
    };
};

int main( int argc, char** argv )
{

    Vector2 vertex;

    vertex.x = 100.0f;
    vertex.y = 50.0f;

    Vector2 texCoord;

    texCoord.u = 0.75f;
    texCoord.v = 0.025f;

    return 0;
}

g++-2.95 complains in the following manner:

mramirez@mtg100:~/anonymous$ g++ -o test test.cxx
test.cxx:11: anonymous class type not used to declare any objects
test.cxx:15: anonymous class type not used to declare any objects

Since this works fine under other compilers ( don't ask which ones ), I am
suspecting that that union-structtuple is violating either the standard or the gcc "way of doing things",
isn't it?
For the case above mentioned there's a simple workaround:

struct Vector2
{
    union
    {
        float x;
        float u;
    };

    union
    {
        float y;
        float v;
    };
};

So I can port most of these expressive vector types, except when
expressivity is further augmentedby providing a union with an array, for instance. I could relay on
returning a pointer to the first memberdeclared, but that's likely to provide interesting bugs when combined with
"exotic" alignments.
Any ideas?

Miguel Ramírez

Re: Problem with anonymous structs and unions

[Oscar Fuentes]

<mramirez@iua.upf.es> writes:

> Hi,
> 
> I am having problems to compile the following snippet of code:
> 
> struct Vector2
> {
>     union
>     {
>         struct
>         {
>             float x, y;
>         };
>         struct
>         {
>             float u, v;
>         };
>     };
> };
> 
> int main( int argc, char** argv )
> {
> 
>     Vector2 vertex;
> 
>     vertex.x = 100.0f;
>     vertex.y = 50.0f;
> 
>     Vector2 texCoord;
> 
>     texCoord.u = 0.75f;
>     texCoord.v = 0.025f;
> 
>     return 0;
> }
> 
> g++-2.95 complains in the following manner:
> 
> mramirez@mtg100:~/anonymous$ g++ -o test test.cxx
> test.cxx:11: anonymous class type not used to declare any objects
> test.cxx:15: anonymous class type not used to declare any objects
> 
> Since this works fine under other compilers ( don't ask which ones
> ), I am suspecting that that union-structtuple is violating either
> the standard or the gcc "way of doing things", isn't it?

Are those other compilers Windows compilers, by chance? They are
forced to be bug-compatible with MSVC++.

Anonymous structs must declare an object, as the error message says.

> For the case above mentioned there's a simple workaround:
> 
> struct Vector2
> {
>     union
>     {
>         float x;
>         float u;
>     };
> 
>     union
>     {
>         float y;
>         float v;
>     };
> };
> 
> So I can port most of these expressive vector types, except when
> expressivity is further augmentedby providing a union with an array,
> for instance. I could relay on returning a pointer to the first
> memberdeclared, but that's likely to provide interesting bugs when
> combined with "exotic" alignments.  Any ideas?

How about naming the structs?

-- 
Oscar

Re: Problem with anonymous structs and unions

[Eljay Love-Jensen]

Hi,

 >How about naming the structs?

I believe naming the structs isn't the problem.  The structs need to be 
"instantiated" (so to speak) by being given a variable name.  Otherwise 
they are just declarative, not definitive.

However, I would argue that the practice of using unions to form synonyms 
is, itself, suspect.  It looks like, to me, that at one point there was a 
(religous?) naming convention war, and unions were used as a 
compromise.  Do away with the synonyms.  (C/C++ unions themselves are often 
suspect, in my opinion.)

--Eljay

Re: Problem with anonymous structs and unions

[Miguel Ramírez]

> Hi,
>
>  >How about naming the structs?
>
> I believe naming the structs isn't the problem.  The structs need to be
> "instantiated" (so to speak) by being given a variable name.  Otherwise
> they are just declarative, not definitive.
>

Neither do I. Then it would be a nested type, thus being obliged by the
usual type rules.

> However, I would argue that the practice of using unions to form synonyms
> is, itself, suspect.  It looks like, to me, that at one point there was a
> (religous?) naming convention war, and unions were used as a
> compromise.  Do away with the synonyms.  (C/C++ unions themselves are
often
> suspect, in my opinion.)
>

I accept the point, but semantics are also important. Note that what I going
after is to provide a
comprenhensive interface, since conceptually both formulations, (x,y) or
(u,v), express the same concept,
a 2 dimensional vector... stuffing the 2d vector concept with context
meaning, such as the parametric nature
of texture coordinates, can be acceptable, but you must endure great pains
to avoid code duplication. However
it is true that it's not a very good practice to overload the union
mechanism, designed for saving memory, using
it to provide users with aliases that could make code more understandable in
a given context. Providing lots
of comments on the code could be another solution, but I prefer not to
comment too much, code should speak
for itself as much as possible.

Nonethless, an obvious refactoring  is to split that Vector2 into two types:

struct Vector2
{
    float x;
    float y;

    inline float x() { return x; }
    inline float y() { return y; }
};

struct TexCoords2
{
    float u;
    float v;

    inline float x() { return u; }
    inline float y() { return v; }
};

and then to use template binary operators for common ops like addition,
substraction, etc. But this
solution is relatively unsatisfactory since unary operators should be
duplicated in both types, which
is at least as suspect as using synonyms.

Or I could some Alexandrescu's magic to make my types derive from a base
template defining
the common ops, a thing that may compromise portability ( VC++ 6 has a
number of mysterious and not
fully documented issues regarding base templates ).

But these solutions don't  solve the issue about vector-like access, since I
fear that

struct Vector2
{
    float x;
    float y;

    inline float& operator[]( unsigned i ) { return *(&x + i); }
    inline const float& operator[]( unsigned i ) { return *(&x + i ); }

};

is not safe when exposing the structs to a particular alignment. Is there
any guarantee for this code
to work right when exposed above when aligning on, say, 16-byte boundaries?
( I could do the tests
myself but before wasting time I prefer to ask wether somebody has some
wisdom to share)

Thanks,

Miguel.

PS: I feel that this discussion is getting a bit off-topic for this list...
my apologies to those who feel that this
is adding noise to their mailbox.