On Fri, 7 Sep 2007, Steve Fink wrote:
On 9/7/07, Scott Lanning <[EMAIL PROTECTED]> wrote:
Vector3 *
Node::getPosition()
CODE:
RETVAL = new Vector3;
*RETVAL = THIS->getPosition();
OUTPUT:
RETVAL
where the OUTPUT typemap for Vector3* would be
sv_setref_pv($arg, "Ogre::Vector3", (void *) $var);
Is that correct?
You might want to set the READONLY flag on the referenced SV, but
that's a minor safety nitpick. Otherwise that seems fine.
The memory management is problematic, though. Nothing is going to free
that Vector3 for you. For a leaf type like that, though, you can
probably get away with defining an Ogre::Vector3::DESTROY that frees
the memory.
Urgh.. at least that's what I was thinking. Thanks.
I am wrapping something very similar (involving a proprietary C++ 3D
graphics framework), and I took a different approach for my equivalent
to your Vector3 (for which I use OpenInventor types, so that would be
SbVec3f). I convert it to an array ref of three values. I also convert
the other way. More recently, I've started blessing the reference into
a vector package that overloads various mathematical operators. But
it's all exposed directly at the Perl level, which saves having to go
through another layer of accessors to get at the contained X, Y, and Z
values. (It also avoids the memory management issue.)
It's a good idea, then, I think, to bless an array ref instead of
a pointer to the C++ object. I'd been thinking of a hashref, too,
with $v->{x}, etc..
Either way, like you said, it would get rid of the ugly (and Perl-specific)
$v->getX, $v->getY, etc. methods by hopefully allowing assignment to each
vector component (like $v->[0] = 0.5, or $v->{x} = 0.5, or $v->x = 0.5).