From: H. H. <hen...@gm...> - 2008-08-24 01:26:18
|
On Sun, Aug 24, 2008 at 4:19 AM, Jason McKesson <ko...@gm...> wrote: > 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. > Well no, this is not true at all. The VC compiler issues is only about anonymous structures. For example, this generates a warning: typedef struct GLMvec2f_s { union { GLfloat v[2]; struct { GLfloat x, y; } }; } GLMvec2f; While this does not: typedef struct GLMvec2f_s { union { GLfloat v[2]; struct GLMvec2fcoords_s { GLfloat x, y; } }; } GLMvec2f; > > 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? > For obvious reasons. 1) function calls can be chained, 2) it is more convenient to set up the structure with one call than manually assigning values for each member. While we have the constructor function xxSet, this does not rule out the possibility of having an open struct. In some cases, the caller may want to access one member, while in another cases he wants to setup it one go. IMO, I see no trouble or complication at this point from having unions in our structs. They are an advantage, not a hindurance. > > > On Sun, Aug 24, 2008 at 1:43 AM, Henri Häkkinen <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. >> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > -- Henri 'henux' Häkkinen |