class types as proxies to an array

[Steven T. Hatton]

I'm in a situation where I want to be sure all my data is organized in a
specific pattern in memory. The array is vertex data which I want to
represent as individual vectors per vertex, and per vertex type. That is,
the array has data such as position, color, normal vectors, etc. I wrote
what I consider to be a pretty nice vector class template and a
corresponding matrix template. The vector I have stores its data locally,
rather than through a reference or pointer.

I want virtuall the same behavior as the current vector gives me, with the
exception that the data should be a reference into the vertex array. If I
derive from vector to create a vectorRef class, I'm pretty sure I'll need
to make most of the functions in the vector virtual. My understanding is
doing so will mean that they will not be inlined because the actual call is
determined after compilation.

Is there a standard strategy for dealing with this kind of situation?
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Victor Bazarov]

I'm in a situation where I want to be sure all my data is organized in a
specific pattern in memory. The array is vertex data which I want to
represent as individual vectors per vertex, and per vertex type. That is,
the array has data such as position, color, normal vectors, etc. I wrote
what I consider to be a pretty nice vector class template and a
corresponding matrix template. The vector I have stores its data locally,
rather than through a reference or pointer.

I want virtuall the same behavior as the current vector gives me, with the
exception that the data should be a reference into the vertex array. If I
derive from vector to create a vectorRef class, I'm pretty sure I'll need
to make most of the functions in the vector virtual. My understanding is
doing so will mean that they will not be inlined because the actual call is
determined after compilation.

Is there a standard strategy for dealing with this kind of situation?

Templates. Possibly, policies. A vector template will have policies
for storing its values and accessing these values as template template
arguments. Take a look at "Modern C++ Design".

V

 

[Steven T. Hatton]

Templates. Possibly, policies. A vector template will have policies
for storing its values and accessing these values as template template
arguments. Take a look at "Modern C++ Design".

That does sound like a (good) solution. It also sounds a bit beyond what I'm
ready to take on just yet. I'm going to try the living dangerously
approach and simply put all my data for a vertex in a concrete class and
shove it all into a boost::array<> then throw it at OpenGL with something
like glInterleavedArrays. My expectation (guess) is the data will be
arranged correctly.

It really is a shame there isn't a better C++ OO interface to OpenGL. I
wish I had the resources to dedicate to developing such an interface. As
it stands it's like buying a new house and having the seller go to the lot
with a dumptruck and dumping all the building materials and giving you the
keys.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Victor Bazarov]

[...]
It really is a shame there isn't a better C++ OO interface to OpenGL.

<offtopic>
Better than what? We here are using Cosmo3d and Optimizer (these are
old, but manageable), and there is the Performer. Another group here
use Hoops3d (and I've seen many references to it). How much better do
you really need?

Take a good look at those libraries. There are others, too. Post to
comp.graphics.api.opengl and see what they suggest.

[...]

V