By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,375 Members | 1,369 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,375 IT Pros & Developers. It's quick & easy.

class types as proxies to an array

P: n/a
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

Jul 22 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Steven T. Hatton wrote:
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
Jul 22 '05 #2

P: n/a
Victor Bazarov wrote:
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

Jul 22 '05 #3

P: n/a
Steven T. Hatton wrote:
[...]
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.
</offtopic>
[...]


V
Jul 22 '05 #4

P: n/a
Victor Bazarov wrote:
Steven T. Hatton wrote:
[...]
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.
</offtopic>
> [...]


V


There are many different abstractions built over OpenGL which support C++
programming. I've come to favor OpenSceneGraph since it does seem to be
consistent with the spirit of C++. What I had intended by my comment
lamenting the lack of a C++ interface to OpenGL is that there seems to be a
possible level of abstraction that would be much closer to design of OpenGL
than what I've seen so far. I'll have to take a closer look at Performer
before I can really say it doesn't provide what I'm looking for.

The biggest problem with Performer I've had so far is that the documentation
and demos focus on features I don't currently have an interest in. I'll
have to plow through a lot of material to get to the features I'm looking
for.

I actually started writing my own SceneGraph API because I find the others
unintuitive, but I can to the conclusion that the undertaking is huge, and
probably not overly productive.

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

Jul 22 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.