glsdk-devel

[Glsdk-devel] The use of anonymous structures

[H. H. <hen...@gm...>]

Somebody mentioned in the OpenGL forums that we should avoid the use of
anonymous structures. Is this worth the concern?

For example, compare these:

typedef struct GLMmat2f_s {
  union {
    GLfloat m[4];
    struct GLMmat2fdata_s {
      GLfloat m00, m01, m10, m11;
    };
  };
} GLMmat2f;

vs.

typedef struct {
  union {
    GLfloat m[4];
    struct {
      GLfloat m00, m01, m10, m11;
    };
  };
} GLMmat2f;

We need to enclose the mXX variables into a struct in order for the union to
take them as a whole.

-- 
Henri 'henux' Häkkinen

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

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

Henri Häkkinen wrote:
> Somebody mentioned in the OpenGL forums that we should avoid the use 
> of anonymous structures. Is this worth the concern?
>
> For example, compare these:
>
> typedef struct GLMmat2f_s {
>   union {
>     GLfloat m[4];
>     struct GLMmat2fdata_s {
>       GLfloat m00, m01, m10, m11;
>     };
>   };
> } GLMmat2f;
>
> vs.
>
> typedef struct {
>   union {
>     GLfloat m[4];
>     struct {
>       GLfloat m00, m01, m10, m11;
>     };
>   };
> } GLMmat2f;
>
> We need to enclose the mXX variables into a struct in order for the 
> union to take them as a whole.
>
> -- 
> Henri 'henux' Häkkinen
I would suggest that those struct definitions violate the design 
principle of /simplicity/. You need to pick one: either a matrix is an 
array of floats or it is a struct with member fields. It should not be 
both. If you're having to use a /union/, you've already done something 
wrong. Unions are confusing and scary to neophyte programmers.

I'd prefer that a matrix were defined as:

typedef GLfloat[4] GLMmat2f;

It's simpler and gets the job done without being confusing to a 
programmer as to what is going on. Yes, it will need to have conventions 
associated with it, but that's a small price to pay for the obviousness 
of what the matrix is doing.

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

[H. H. <hen...@gm...>]

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;
}

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

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;
}

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.


On Sun, Aug 24, 2008 at 12:04 AM, Jason McKesson <ko...@gm...> wrote:

>  Henri Häkkinen wrote:
>
> Somebody mentioned in the OpenGL forums that we should avoid the use of
> anonymous structures. Is this worth the concern?
>
> For example, compare these:
>
> typedef struct GLMmat2f_s {
>   union {
>     GLfloat m[4];
>     struct GLMmat2fdata_s {
>       GLfloat m00, m01, m10, m11;
>     };
>   };
> } GLMmat2f;
>
> vs.
>
> typedef struct {
>   union {
>     GLfloat m[4];
>     struct {
>       GLfloat m00, m01, m10, m11;
>     };
>   };
> } GLMmat2f;
>
> We need to enclose the mXX variables into a struct in order for the union
> to take them as a whole.
>
> --
> Henri 'henux' Häkkinen
>
> I would suggest that those struct definitions violate the design principle
> of *simplicity*. You need to pick one: either a matrix is an array of
> floats or it is a struct with member fields. It should not be both. If
> you're having to use a *union*, you've already done something wrong.
> Unions are confusing and scary to neophyte programmers.
>
> I'd prefer that a matrix were defined as:
>
> typedef GLfloat[4] GLMmat2f;
>
> It's simpler and gets the job done without being confusing to a programmer
> as to what is going on. Yes, it will need to have conventions associated
> with it, but that's a small price to pay for the obviousness of what the
> matrix is doing.
>
> -------------------------------------------------------------------------
> 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

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

[Branan R. <br...@gm...>]

I don't think the problem is in structs, it's in a union of
struct/array that makes things complicated.

Having mat2f defined as:

typedef struct GLMmat2f_t
{
float m00, m01, m10, m11;
} GLMmat2f;

is perfectly fine. It's the union that's complicated and confusing.

Branan

On Sat, Aug 23, 2008 at 2:32 PM, Henri Häkkinen <hen...@gm...> 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;
> }
>
> 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
>
> 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;
> }
>
> 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.
>
>
> On Sun, Aug 24, 2008 at 12:04 AM, Jason McKesson <ko...@gm...> wrote:
>>
>> Henri Häkkinen wrote:
>>
>> Somebody mentioned in the OpenGL forums that we should avoid the use of
>> anonymous structures. Is this worth the concern?
>>
>> For example, compare these:
>>
>> typedef struct GLMmat2f_s {
>>   union {
>>     GLfloat m[4];
>>     struct GLMmat2fdata_s {
>>       GLfloat m00, m01, m10, m11;
>>     };
>>   };
>> } GLMmat2f;
>>
>> vs.
>>
>> typedef struct {
>>   union {
>>     GLfloat m[4];
>>     struct {
>>       GLfloat m00, m01, m10, m11;
>>     };
>>   };
>> } GLMmat2f;
>>
>> We need to enclose the mXX variables into a struct in order for the union
>> to take them as a whole.
>>
>> --
>> Henri 'henux' Häkkinen
>>
>> I would suggest that those struct definitions violate the design principle
>> of simplicity. You need to pick one: either a matrix is an array of floats
>> or it is a struct with member fields. It should not be both. If you're
>> having to use a union, you've already done something wrong. Unions are
>> confusing and scary to neophyte programmers.
>>
>> I'd prefer that a matrix were defined as:
>>
>> typedef GLfloat[4] GLMmat2f;
>>
>> It's simpler and gets the job done without being confusing to a programmer
>> as to what is going on. Yes, it will need to have conventions associated
>> with it, but that's a small price to pay for the obviousness of what the
>> matrix is doing.
>>
>> -------------------------------------------------------------------------
>> 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
>
>
> -------------------------------------------------------------------------
> 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
>
>

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.

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

[Orhun B. <orh...@gm...>]

Hi,

I just wanted to note that anonymous unions generate the following warning
in Visual C++ (9.0) at warning level 4.

glsdk\trunk\inc\GLSDK/glm.h(19) : warning C4201: nonstandard extension used
: nameless struct/union


It might be early to report such problems but I had to make several changes
to make glm.c compile with Visual C++.

- windows.h has to be included before glm.h.
- I had to define _USE_MATH_DEFINES to have M_PI defined.
 . From MSDN
> The "Math Constants" are not defined in Standard C/C++. Therefore, in
order to use them, you have to first define _USE_MATH_DEFINES and then
include cmath or math.h as below.

-- 
Orhun Birsoy

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

[H. H. <hen...@gm...>]

Thanks for this info. As you can see, the exact mathlib interface is still
in a state of flux.

On Sun, Aug 24, 2008 at 1:24 AM, Orhun Birsoy <orh...@gm...> wrote:

> Hi,
>
> I just wanted to note that anonymous unions generate the following warning
> in Visual C++ (9.0) at warning level 4.
>
> glsdk\trunk\inc\GLSDK/glm.h(19) : warning C4201: nonstandard extension used
> : nameless struct/union
>
>
> It might be early to report such problems but I had to make several changes
> to make glm.c compile with Visual C++.
>
> - windows.h has to be included before glm.h.
> - I had to define _USE_MATH_DEFINES to have M_PI defined.
>  . From MSDN
> > The "Math Constants" are not defined in Standard C/C++. Therefore, in
> order to use them, you have to first define _USE_MATH_DEFINES and then
> include cmath or math.h as below.
>
> --
> Orhun Birsoy
>
> -------------------------------------------------------------------------
> 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

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

[H. H. <hen...@gm...>]

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.



On Sun, Aug 24, 2008 at 1:22 AM, Jason McKesson <ko...@gm...> wrote:

>  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.
>


This has nothing to do how the variables are declared, but how the function
test is called.



>
>  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.
>


But it is also a lot more efficient to pass them as pointers.



>
>  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.
>
> -------------------------------------------------------------------------
> 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

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

[H. H. <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.

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.
>
>
>
> On Sun, Aug 24, 2008 at 1:22 AM, Jason McKesson <ko...@gm...> wrote:
>
>>  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.
>>
>
>
> This has nothing to do how the variables are declared, but how the function
> test is called.
>
>
>
>>
>>  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.
>>
>
>
> But it is also a lot more efficient to pass them as pointers.
>
>
>
>>
>>  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.
>>
>> -------------------------------------------------------------------------
>> 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
>
>


-- 
Henri 'henux' Häkkinen

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.
>

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

[H. H. <hen...@gm...>]

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

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

[Stefanos A. <sta...@gm...>]

Την 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.

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

[H. H. <hen...@gm...>]

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

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

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

Henri Häkkinen wrote:
>
>
> On Sun, Aug 24, 2008 at 5:14 AM, Stefanos A. <sta...@gm... 
> <mailto:sta...@gm...>> wrote:
>
>     Την Sun, 24 Aug 2008 04:05:06 +0300,ο(η) Henri Häkkinen
>     <hen...@gm... <mailto: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?
As you pointed out, D3DX defines a matrix thusly:

typedef struct _D3DMATRIX {
    union {
        struct {
            float        _11, _12, _13, _14;
            float        _21, _22, _23, _24;
            float        _31, _32, _33, _34;
            float        _41, _42, _43, _44;

        };
        float m[4][4];
    };
} D3DMATRIX;


Anonymous inner struct and all. It doesn't produce warnings or anything. 
Maybe you just need to have the struct come first in the union.

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

[H. H. <hen...@gm...>]

Indeed. At the moment, I don't have an access to a Windows box, but could
somebody who has, kindly test out the possibility of this.

Does the MSVC produce warnings, when you try to compile something like this:

typedef struct FOO_s {
  union {
    struct {
      int di;
    };
    in do;
  };
} FOO;

int main()
{
  FOO f;
  f.di = 1;
  f.do = 2;
  return 0;
}


On Sun, Aug 24, 2008 at 5:55 AM, Jason McKesson <ko...@gm...> wrote:

>  Henri Häkkinen wrote:
>
>
>
> 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?
>
> As you pointed out, D3DX defines a matrix thusly:
>
> typedef struct _D3DMATRIX {
>     union {
>         struct {
>             float        _11, _12, _13, _14;
>             float        _21, _22, _23, _24;
>             float        _31, _32, _33, _34;
>             float        _41, _42, _43, _44;
>
>         };
>         float m[4][4];
>     };
> } D3DMATRIX;
>
>
> Anonymous inner struct and all. It doesn't produce warnings or anything.
> Maybe you just need to have the struct come first in the 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

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

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

Henri Häkkinen wrote:
> Indeed. At the moment, I don't have an access to a Windows box, but 
> could somebody who has, kindly test out the possibility of this.
>
> Does the MSVC produce warnings, when you try to compile something like 
> this:
>
> typedef struct FOO_s {
>   union {
>     struct {
>       int di;
>     };
>     in do;
>   };
> } FOO;
>
> int main()
> {
>   FOO f;
>   f.di = 1;
>   f.do = 2;
>   return 0;
> }
No, but I can't imagine GCC does. That's because "do" is a C keyword ;)

When you change it to be a regular identifier, it compiles fine. I even 
switched the order of the struct and the int, and it still works.

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

[H. H. <hen...@gm...>]

Right :)

Hmm, someone reported that MSVC was giving warnings from anonymous
structs... Odd


On Sun, Aug 24, 2008 at 6:22 AM, Jason McKesson <ko...@gm...> wrote:

> Henri Häkkinen wrote:
> > Indeed. At the moment, I don't have an access to a Windows box, but
> > could somebody who has, kindly test out the possibility of this.
> >
> > Does the MSVC produce warnings, when you try to compile something like
> > this:
> >
> > typedef struct FOO_s {
> >   union {
> >     struct {
> >       int di;
> >     };
> >     in do;
> >   };
> > } FOO;
> >
> > int main()
> > {
> >   FOO f;
> >   f.di = 1;
> >   f.do = 2;
> >   return 0;
> > }
> No, but I can't imagine GCC does. That's because "do" is a C keyword ;)
>
> When you change it to be a regular identifier, it compiles fine. I even
> switched the order of the struct and the int, and it still works.
>
> -------------------------------------------------------------------------
> 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

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

[Branan R. <br...@gm...>]

Could be a different version of MSVC giving different warnings.

On Sat, Aug 23, 2008 at 8:25 PM, Henri Häkkinen <hen...@gm...> wrote:
> Right :)
>
> Hmm, someone reported that MSVC was giving warnings from anonymous
> structs... Odd
>
>
> On Sun, Aug 24, 2008 at 6:22 AM, Jason McKesson <ko...@gm...> wrote:
>>
>> Henri Häkkinen wrote:
>> > Indeed. At the moment, I don't have an access to a Windows box, but
>> > could somebody who has, kindly test out the possibility of this.
>> >
>> > Does the MSVC produce warnings, when you try to compile something like
>> > this:
>> >
>> > typedef struct FOO_s {
>> >   union {
>> >     struct {
>> >       int di;
>> >     };
>> >     in do;
>> >   };
>> > } FOO;
>> >
>> > int main()
>> > {
>> >   FOO f;
>> >   f.di = 1;
>> >   f.do = 2;
>> >   return 0;
>> > }
>> No, but I can't imagine GCC does. That's because "do" is a C keyword ;)
>>
>> When you change it to be a regular identifier, it compiles fine. I even
>> switched the order of the struct and the int, and it still works.
>>
>> -------------------------------------------------------------------------
>> 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
>
>
> -------------------------------------------------------------------------
> 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
>
>

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

[H. H. <hen...@gm...>]

I think we should just use #pragma disable warning for those.

On Sun, Aug 24, 2008 at 6:31 AM, Branan Riley <br...@gm...> wrote:

> Could be a different version of MSVC giving different warnings.
>
> On Sat, Aug 23, 2008 at 8:25 PM, Henri Häkkinen <hen...@gm...>
> wrote:
> > Right :)
> >
> > Hmm, someone reported that MSVC was giving warnings from anonymous
> > structs... Odd
> >
> >
> > On Sun, Aug 24, 2008 at 6:22 AM, Jason McKesson <ko...@gm...>
> wrote:
> >>
> >> Henri Häkkinen wrote:
> >> > Indeed. At the moment, I don't have an access to a Windows box, but
> >> > could somebody who has, kindly test out the possibility of this.
> >> >
> >> > Does the MSVC produce warnings, when you try to compile something like
> >> > this:
> >> >
> >> > typedef struct FOO_s {
> >> >   union {
> >> >     struct {
> >> >       int di;
> >> >     };
> >> >     in do;
> >> >   };
> >> > } FOO;
> >> >
> >> > int main()
> >> > {
> >> >   FOO f;
> >> >   f.di = 1;
> >> >   f.do = 2;
> >> >   return 0;
> >> > }
> >> No, but I can't imagine GCC does. That's because "do" is a C keyword ;)
> >>
> >> When you change it to be a regular identifier, it compiles fine. I even
> >> switched the order of the struct and the int, and it still works.
> >>
> >>
> -------------------------------------------------------------------------
> >> 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
> >
> >
> > -------------------------------------------------------------------------
> > 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
> >
> >
>
> -------------------------------------------------------------------------
> 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

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

[Stefanos A. <sta...@gm...>]

On Sun, Aug 24, 2008 at 6:31 AM, Branan Riley <br...@gm...> wrote:
>         Could be a different version of MSVC giving different
>         warnings.

Actually no, just stricter warnings (warning level 4, where the default
is 3). GCC doesn't produce any warnings even with -Wall.

However, please note that the anonymous union is *not* valid C89 (fails
to compile with "gcc -ansi"). I'm not saying this is a problem (//-style
comments aren't valid C89 either), just something to keep in mind and
document.

// Not valid C89
union
{
    float data[2];
    struct { float x, y; };
};

/* Valid C89 */
union foo_union
{
    float data[2];
    struct bar_struct { float x, y; } bar;
} foo;

Anyone knows if these have been standardized in C99?

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

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

Stefanos A. wrote:
> On Sun, Aug 24, 2008 at 6:31 AM, Branan Riley <br...@gm...> wrote:
>   
>>         Could be a different version of MSVC giving different
>>         warnings.
>>     
>
> Actually no, just stricter warnings (warning level 4, where the default
> is 3). GCC doesn't produce any warnings even with -Wall.
>
> However, please note that the anonymous union is *not* valid C89 (fails
> to compile with "gcc -ansi"). I'm not saying this is a problem (//-style
> comments aren't valid C89 either), just something to keep in mind and
> document.
>
> // Not valid C89
> union
> {
>     float data[2];
>     struct { float x, y; };
> };
>
> /* Valid C89 */
> union foo_union
> {
>     float data[2];
>     struct bar_struct { float x, y; } bar;
> } foo;
>
> Anyone knows if these have been standardized in C99?
>   
Hmm, I did a test with VC7.1, and he's right: on warning level 4, it 
does produce a warning. Even when compiled as C++, it produces a warning.

So this kind of anonymous structure is widely supported but invalid C89 
behavior. I suppose you could pragma around it.

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

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

Henri Häkkinen wrote:
>
>
> On Sun, Aug 24, 2008 at 4:19 AM, Jason McKesson <ko...@gm... 
> <mailto: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;
>
Admittedly it's been a while since I last used pure C, but if I'm 
reading that right, to access the x or y members, I would need:

GLMvec2f someValue;

someValue.GLMvec3fcoords_s.x = 0.5f

This is a pretty clear violation of design goal #2: Simplicity. And if 
the inner struct can't be accessed with a simple ".x", then what's the 
point in having it at all?

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

[H. H. <hen...@gm...>]

On Sun, Aug 24, 2008 at 4:44 AM, Jason McKesson <ko...@gm...> wrote:

>  Henri Häkkinen wrote:
>
>
>
> 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;
>
>   Admittedly it's been a while since I last used pure C, but if I'm
> reading that right, to access the x or y members, I would need:
>
> GLMvec2f someValue;
>
> someValue.GLMvec3fcoords_s.x = 0.5f
>
> This is a pretty clear violation of design goal #2: Simplicity. And if the
> inner struct can't be accessed with a simple ".x", then what's the point in
> having it at all?
>

No that is not correct at all.

There is a difference between the name of the structure and the name of the
variable. When you write in C like this:

struct FOO {
  int baz;
} fizban;

You access baz inside the struct like this:

fizban.baz = 12;

When we have the vector type:

typedef struct GLMvec2f_s {
  union {
    GLfloat v[2];
    struct GLMvec2fcoords_s {
      GLfloat x, y;
    };
  };
} GLMvec2f;

You access it normally;

GLMvec2f v;
v.x = 10.0f;

The 'GLMvec2fcoords_s' is a structure name, nor a variable name.



>
> -------------------------------------------------------------------------
> 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

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

[H. H. <hen...@gm...>]

On Sun, Aug 24, 2008 at 4:53 AM, Henri Häkkinen <hen...@gm...> wrote:

>
>
> On Sun, Aug 24, 2008 at 4:44 AM, Jason McKesson <ko...@gm...> wrote:
>
>>  Henri Häkkinen wrote:
>>
>>
>>
>> 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;
>>
>>   Admittedly it's been a while since I last used pure C, but if I'm
>> reading that right, to access the x or y members, I would need:
>>
>> GLMvec2f someValue;
>>
>> someValue.GLMvec3fcoords_s.x = 0.5f
>>
>> This is a pretty clear violation of design goal #2: Simplicity. And if the
>> inner struct can't be accessed with a simple ".x", then what's the point in
>> having it at all?
>>
>
> No that is not correct at all.
>
> There is a difference between the name of the structure and the name of the
> variable. When you write in C like this:
>
> struct FOO {
>   int baz;
> } fizban;
>
> You access baz inside the struct like this:
>
> fizban.baz = 12;
>
> When we have the vector type:
>
> typedef struct GLMvec2f_s {
>   union {
>     GLfloat v[2];
>     struct GLMvec2fcoords_s {
>       GLfloat x, y;
>     };
>   };
> } GLMvec2f;
>
> You access it normally;
>
> GLMvec2f v;
> v.x = 10.0f;
>
> The 'GLMvec2fcoords_s' is a structure name, nor a variable name.
>

TYPO: s/nor/not/


>
>
>
>>
>> -------------------------------------------------------------------------
>> 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
>
>


-- 
Henri 'henux' Häkkinen

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

[H. H. <hen...@gm...>]

See this link,

http://msdn.microsoft.com/en-us/library/bb172573(VS.85).aspx

In Direct3D they are using similar design.



On Sun, Aug 24, 2008 at 4:55 AM, Henri Häkkinen <hen...@gm...> wrote:

>
>
> On Sun, Aug 24, 2008 at 4:53 AM, Henri Häkkinen <hen...@gm...>wrote:
>
>>
>>
>> On Sun, Aug 24, 2008 at 4:44 AM, Jason McKesson <ko...@gm...>wrote:
>>
>>>  Henri Häkkinen wrote:
>>>
>>>
>>>
>>> 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;
>>>
>>>   Admittedly it's been a while since I last used pure C, but if I'm
>>> reading that right, to access the x or y members, I would need:
>>>
>>> GLMvec2f someValue;
>>>
>>> someValue.GLMvec3fcoords_s.x = 0.5f
>>>
>>> This is a pretty clear violation of design goal #2: Simplicity. And if
>>> the inner struct can't be accessed with a simple ".x", then what's the point
>>> in having it at all?
>>>
>>
>> No that is not correct at all.
>>
>> There is a difference between the name of the structure and the name of
>> the variable. When you write in C like this:
>>
>> struct FOO {
>>   int baz;
>> } fizban;
>>
>> You access baz inside the struct like this:
>>
>> fizban.baz = 12;
>>
>> When we have the vector type:
>>
>> typedef struct GLMvec2f_s {
>>   union {
>>     GLfloat v[2];
>>     struct GLMvec2fcoords_s {
>>       GLfloat x, y;
>>     };
>>   };
>> } GLMvec2f;
>>
>> You access it normally;
>>
>> GLMvec2f v;
>> v.x = 10.0f;
>>
>> The 'GLMvec2fcoords_s' is a structure name, nor a variable name.
>>
>
> TYPO: s/nor/not/
>
>
>>
>>
>>
>>>
>>> -------------------------------------------------------------------------
>>> 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
>>
>>
>
>
> --
> Henri 'henux' Häkkinen
>
>


-- 
Henri 'henux' Häkkinen