Hi,
Chris 'Xenon' Hanson wrote:
I'm also looking for a STL expert who knows for_each, mem_fun and
bin1st better than I to tell me what I'm doing wrong on a piece of
GDAL code related to VPB. But that's a different issue. Anyone who
wants to point out my mistake, contact me privately and I'll
Hi Chris,
On Fri, Aug 7, 2009 at 3:07 AM, Chris 'Xenon'
Hansonxe...@alphapixel.com wrote:
So, two questions:
1. Robert, are you even in support of refactoring the existing Vec* classes
into
manifestations of a template if it can be done transparently and cleanly with
regard to
existing
Robert Osfield wrote:
Well I have no clue what you are specifically thinking of changing so
I can't say anything about it either one way or the other. The
osg::Array classes already use templates, and are already extensible,
so I don't what you're trying to address.
Well, I'm not aiming at
J.P. Delport wrote:
I'm no expert, but what I do know is that tr1::function and tr1::bind
are much easier to understand than the original variants. I've once made
a little test app for myself that I attach.
I agree. However, I can't rely on tr1 in my build at this time. Likewise with
boost.
HI Chris,
OK, I understand better where you coming from now - making a template
of Vec to enable easier implementation of the various implementations.
I chose not to use templates in the first place to avoid the compiler
doing too much work on such a commonly used class and to enable easier
Robert Osfield wrote:
HI Chris,
OK, I understand better where you coming from now - making a template
of Vec to enable easier implementation of the various implementations.
I chose not to use templates in the first place to avoid the compiler
doing too much work on such a commonly used class
Tomlinson, Gordon wrote:
Hi Chris
We for one use vec arrays out side these, it would be nice to have OSG
support all the typically POD types :).
It would makes a few thing more straight forward for us
I started looking at this issue. I can certainly create VecnBlah types out the
ying-yang,
While the core OSG currently doesn't have any call for a Vec2ul (2d vector,
unsigned
long) type, I've found I need one for some OSG-related code. I'm using it as a
2D array
subscript type, for lack of any better type. Really, probably a size_t is
better than an
unsigned long, but I wasn't
Hi Chris,
The osg::Array subclasses exist to support OpenGL rendering so just
map what OpenGL can support. You could create your own subclasses to
go beyond what OpenGL supports if you wish, I'm not sure it's
generally useful though.
Robert.
On Mon, Jul 27, 2009 at 5:29 PM, Chris 'Xenon'
Robert Osfield wrote:
Hi Chris,
The osg::Array subclasses exist to support OpenGL rendering so just
map what OpenGL can support. You could create your own subclasses to
go beyond what OpenGL supports if you wish, I'm not sure it's
generally useful though.
Well, this is distinct from
, 2009 12:29 PM
To: OpenSceneGraph Users
Subject: [osg-users] Vec2ul and isomorphic variants?
While the core OSG currently doesn't have any call for a Vec2ul (2d
vector, unsigned
long) type, I've found I need one for some OSG-related code. I'm using
it as a 2D array subscript type, for lack of any
11 matches
Mail list logo
