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.