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

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

Henri Häkkinen wrote:
> No no... We had this conversation already in the forums few days ago.
>
> The struct approach is superior over typedef GLfloat GLMmat2f[4]; for 
> the following reason:
>
> - it allows matrix data to be accessed as either using index or 
> members. You can see the memory layout of the matrix from the ordering 
> of the mXX members.
>
> - the following piece of code:
>
> typedef float FOO[2];
>
> FOO *test (FOO *out, const FOO *f)
> {
>   (*out)[0] = (*f)[0];
>   (*out)[1] = (*f)[1];
>   return out;
> }
The function "test" should not take pointers. Objects of type "FOO" 
already are pointers, so it does not need to take FOO*'s.
> int main ()
> {
>   FOO a, b;
>   test (&a, &b);
>   return 0;
> }
>
> Produces the following warning on GCC 4.2.3:
> warning: passing argument 2 of 'test' from incompatible pointer type
Which is why virtually every book on programming tells you /not/ to 
define multiple variables on the same line.
> Compare this:
>
> typedef struct {
>   union {
>     float f[2];
>     struct {
>       float x, y;
>     };
>   };
> } FOO;
>
> FOO *test (FOO *out, const FOO *f)
> {
>   out->x = f->x;
>   out->y = f->y;
>   return out;
> }
I don't like the idea of these functions all taking pointers to the 
types rather than the types themselves. I know C doesn't have an 
equivalent to the & reference in C++, but the user code would be a lot 
cleaner if you only passed pointers for parameters that are outputs (or 
large objects). That's the general convention for most C libraries I've 
seen.
> This code is a lot more clear and usable than the previous one. Also:
>
> vec[0] = -vec[0];
>
> You cannot be sure if this vec is an array of vectors or are you 
> accessing the first element of a 2D vector.
>
> Implementing math datatypes as structure is a lot more cleaner 
> approach than the array approach. Perhaps we should think if the union 
> there is redundant but typedef GLfloat GLMvec2f[2]; is not a good 
> idea. And I don't think we should hinder our design by the assumed 
> ignorance of the afromentioned newbies. Besides, I have already 
> implemented the library by the struct approach design. See the OpenGL 
> forums for the discussion we underwent there fore more points.
If you feel that the math types should be structs, then let them be 
struct. But they should /not/ be structs containing a union of an array 
and a struct. That violates principle #2: simplicity. A principle you 
agreed on, as you previously stated. Simplicity means you pick one side: 
struct or array.