My elaborate explanations about anonymous union simply demonstrate that full opengl compatibility comes at huge price - it forces internal data structure. A huge no-no in good OO design.
Not necessarily, if what you're primarily interested in doing is OpenGL. I think there is a middle ground that is OpenGL-friendly without being OpenGL-centric.
vec2 a two component floating-point vector vec3 a three component floating-point vector ... ivec4 a four component integer vector
With C++ templates one could represent all those in one class template
They could, but from an OpenGL point of view, it would also be nice to have typedefs that have the type and dimension built into the typename, OpenGL-style. Such as vertex2i, vertex2f, vertex3d. (The OpenGL API has variants such as glVertex2i, glVertex2f, etc) Along with that, a boost::gl namespace could wrap the entire OpenGL API glVertex2i(x,y) -> boost::gl::vertex(v) glVertex2f(x,y) -> boost::gl::vertex(v) glVertex3d(x,y) -> boost::gl::vertex(v)
Secondly, the OpenGL?vec? family above is used IIRC as a standard container for different purposes, such as a vertex, or a color, but IMO it would be more 'user friendly' to create a color type and a vertex type and only convert them to their low level OpenGL ?vec? equivalents for output,
More "user friendly" could be debated, but certainly more statically type-safe to have color3f and vertex3f versus vector3f for both. But, it is often useful to treat colors as vectors for interpolation, so there needs to be conversions. Here is an interesting question: Should there be a normal that behaves differently to a vector? (or vertex?) In the case of 4x4 matrix transformation, the translation is applied to vertecies, but not normals.
The general thrust of the above is that I would prefer to end up with a User Orientated design as opposed to a design which provides low level primitives of indeterminate meaning (eg using the same vector type to hold a vertex and a color as raw Open GL does).
OpenGL accepts either arrays or named x,y,z parameters, but I would like to clarify that OpenGL is a C API with no structures or types except for GLfloat, GLdouble, etc.
The downside of using higher level Concepts is that One may end up with a lot of structurally similar looking entities. The upside may be that what we are really discussing is Concepts which might correspond with the SoCalled Generic Programming approach. A simple example of the difference.
In the OpenGL context I'm interested in doing certain things in a concise efficient way. Genericity does not necessarily serve that purpose. It seems to me that an OpenGL-centric layer based on a templated generic library might serve both purposes, but I havn't seen that actually put into practice. :-) My intuition is that the genericity of templates isn't a good match for the specifically crafted OpenGL API that is rooted in assumptions about computer graphics hardware. A wrapper namespace might be a good way to harmonise between the general mathematical viewpoint and the specificness of OpenGL.
Fast disply in yade is much less important than geometrical computations themselves - related to physics of the system, not to the graphics.
That depends what your job is. Mine happens to be feeding OpenGL with information. Cheers, Nigel Stewart