From: H. H. <hen...@gm...> - 2008-08-24 02:25:31
|
On Sun, Aug 24, 2008 at 5:14 AM, Stefanos A. <sta...@gm...> wrote: > Την Sun, 24 Aug 2008 04:05:06 +0300,ο(η) Henri Häkkinen > <hen...@gm...> έγραψε: > > > 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. > > > > I'd go for #2 (struct/union), just slightly modified. > > Why use a struct? Because typing vec.x is cleaner than vec[0]. > > Why have a union? So you can pass the struct to OpenGL without a cast. > Compare: > > foo(vec.data); // approach #2 (struct/union) > vs > foo((GLfloat*)vec); // approach #3 (struct) > vs > foo(&vec.x); // approach #3 (struct) > > To that end, it might be better to define structs like this: > > typedef struct GLMFoo_t > { > union GLMFoo_data > { > GLfloat data[2]; // Instead of v[] or m[] > struct GLMFoo_fields > { > GLfloat x, y; > } > } > } GLMFoo; > > This makes clear that the "data" field provides the storage for the vector > data - v or m might be somewhat cryptic at first glance. > I agree that we should go with the struct-union combination. However, I have discovered a problem: typedef struct FOO_s { union { int di; struct BAS_s { int do; }; }; } FOO; FOO f; f.di = 1; f.do = 2; This fails on GCC; f.do is not accessible (try it). I am not sure is this a bug in GCC or is this standard conforming behaviour. So therefore, we cannot go with the non-anonymous inner struct. I recommend that we go with struct-union, and with anonymous inner struct, and just use compiler #pragma (disable : warning) on Windows platform to drop the warning it produces. What do you think? > > ------------------------------------------------------------------------- > 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 |