Re: [Glsdk-devel] The use of anonymous structures

[Jason M. <ko...@gm...>]

Henri Häkkinen wrote:
> Does anyone have anything to say on this, please? I am currently 
> working hard on the GLM and I think we should resolve the issue of how 
> we actually define the math types.
Well, the VC++ compiler issue pretty much ends #2 as a possibility. If 
#1 doesn't work for you, that leaves #3.

BTW, the whole point of having accessor functions like glmVecSet2f is 
that there is no alternative way to set them. If you do have an 
alternative (directly setting the fields in the struct), why bother with 
a function?

> On Sun, Aug 24, 2008 at 1:43 AM, Henri Häkkinen <hen...@gm... 
> <mailto:hen...@gm...>> wrote:
>
>     Okay, lets discuss on this matter. I have written the library with
>     the implementation of using struct/union approach as I thought
>     this was the implementation we decided on in the forums.
>
>     We have multiple approaches:
>
>     Proposal #1: the array approach
>
>     typedef GLfloat GLMvec2f[2];
>
>     void glmVecSet2f (GLMvec2f out, GLfloat x, GLfloat y);
>     void glmVecAdd2f (GLMvec2f out, const GLMvec2f v1, const GLMvec2f v2);
>
>     This allows the user code to call like this:
>
>     GLMvec2f a, b, c;
>     glmVecSet2f (a, 1.0f, 1.0f);
>     glmVecSet2f (b, 2.0f, 2.0f);
>     glmVecAdd2f (c, a, b);
>
>     However GCC will generate warnings on args 2 and 3 for glmVecAdd2f.
>
>     We cannot define glmVecSet2f like this:
>
>     GLMvec2f glmVecSet2f (GLMvec2f out, GLfloat x, GLfloat y);
>
>     This is impossible because functions cannot return arrays. The bad
>     side of this approach is that function calls cannot be nested like
>     this:
>
>     glmVecAdd2f (c, glmVecSet2f (a, 1.0f, 1.0f), glmVecSet2f (b, 2.0f,
>     2.0f));
>
>
>     Proposal #2: struct/union approach (the current implementation)
>
>     typedef struct GLMvec2f_s {
>       union {
>         GLfloat v[2];
>         struct GLMvec2f_data_s {
>           GLfloat x, y;
>         };
>       };
>     } GLMvec2f;
>
>     GLMvec2f *glmVecSet2f (GLMvec2f *out, GLfloat x, GLfloat y);
>     GLMvec2f *glmVecAdd2f (GLMvec2f *out, const GLMvec2f *v1, const
>     GLMvec2f *v2);
>
>     This allows function calls to be nested:
>
>     GLMvec2f a, b, c;
>     glmVecAdd2f (&c, glmVecSet2f (&a, 1.0f, 1.0f), glmVecSet2f (&b,
>     2.0f, 2.0f));
>
>     Data can be also passed directly to OpenGL functions:
>
>     GLMmat4f mat;
>     glmMatIdentity4f (&mat);
>     glLoadMatrixf (mat.m);
>     (or some equivalent GL3 API call)
>
>     Member can also be accessed by a moniker:
>
>     mat.m11 = 1.0f;
>     vec.x = 2.0f;
>     col.r = 0.5f;
>
>     As a sidenote, this is also how they do this in D3DX (the util
>     library of D3D).
>
>     The only con is the use of union, but I don't see this as a
>     problem. They are not particularly complicated either IMO.
>
>
>     Proposal #3: the struct-only approach
>
>     struct GLMvec2f_s {
>       GLfloat x, y;
>     } GLMvec2f;
>
>     GLMvec2f *glmVecSet2f (GLMvec2f *out, GLfloat x, GLfloat y);
>     GLMvec2f *glmVecAdd2f (GLMvec2f *out, const GLMvec2f *v1, const
>     GLMvec2f *v2);
>
>     This is almost the same as #2 except that avoidance of unions.
>
>     I would go with the struct/union.
>