Re: [osg-users] Derived classes and ref_ptr
Martin Beckett wrote on Friday, September 04, 2009 5:20 PM: Hi, I have a class derived from PositionAttitudeTransform. It's simply an Adapter it contains no new variables but fixes up some methods for osg::PAT to be used in an existing design for some navigation routines. The existing navigation library is fixed I can't change it to understand osg::ref_ptr,=. Objects of the Adapter class need to be created on the stack in the library. Is there any way to define such a class so that it can be used as a regular class with objects on the stack in my library but still be reference counted in OSG? It's really not a good idea to mix stack-created objects with reference counting (when the reference count hits zero and the stack-created object is deleted, bad things happen), but if you're *REALLY SURE* that you can be careful about it, *still don't do it*, because eventually someone else will modify your code (it might even be a future you) who won't be as careful. HTH :) -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com P.S. You must be *REALLY REALLY SURE* to read this far, and if you are, I'll tell you the secret: all you have to do is declare a public destructor for your Adapter class to allow it to be created on the stack. See http://visualcpp.net/index.php?qID=65 for example. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Derived classes and ref_ptr
Don't think so, __ Gordon Tomlinson gor...@gordontomlinson.com IM: gordon3db...@3dscenegraph.com www.vis-sim.com www.gordontomlinson.com __ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Beckett Sent: Friday, September 04, 2009 6:20 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Derived classes and ref_ptr Hi, I have a class derived from PositionAttitudeTransform. It's simply an Adapter it contains no new variables but fixes up some methods for osg::PAT to be used in an existing design for some navigation routines. The existing navigation library is fixed I can't change it to understand osg::ref_ptr,=. Objects of the Adapter class need to be created on the stack in the library. Is there any way to define such a class so that it can be used as a regular class with objects on the stack in my library but still be reference counted in OSG? Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17080#17080 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Derived classes and ref_ptr
[quote=Paul Martz]If you can (obviously) change your code to understand instances of your new custom class, then I don't understand why you can't change your code to understand instances of ref_ptrs to your new custom class. Please explain this restriction further. I have a complicated navigation library with a few objects representing a position fix, GPS location, range+bearing observation etc. This library works ! I want to re-use this in an OSG app. So I have written an adapter class where a position is now represented underneath by a PAT (which can be used directly in my OSG scene) but has the same name and implements the same set/get position operations as the existing position class. But since it is ultimately derived from Referenced it has a virtual dtor, cannot be create on the stack and cannot be copied with '=' I can make the dtor public, but the more complicated part is implementing the copy operator - since it has to handle copying all the parent class of PAT. The alternative of having a bunch of interface functions to copy parameters to/from the scenegraph nodes into existing 'position' objects seemed a poor design. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17084#17084 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Derived classes and ref_ptr
2009/9/5 Martin Beckett m...@mgbeckett.com:
[quote=Paul Martz]If you can (obviously) change your code to understand
instances of your new custom class, then I don't understand why you can't
change your code to understand instances of ref_ptrs to your new custom
class. Please explain this restriction further.
I have a complicated navigation library with a few objects representing a
position fix, GPS location, range+bearing observation etc. This library
works !
I want to re-use this in an OSG app. So I have written an adapter class where
a position is now represented underneath by a PAT (which can be used directly
in my OSG scene) but has the same name and implements the same set/get
position operations as the existing position class.
But since it is ultimately derived from Referenced it has a virtual dtor,
cannot be create on the stack and cannot be copied with '='
I can make the dtor public, but the more complicated part is implementing the
copy operator - since it has to handle copying all the parent class of PAT.
The alternative of having a bunch of interface functions to copy parameters
to/from the scenegraph nodes into existing 'position' objects seemed a poor
design.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=17084#17084
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Hi Martin,
pimpl idiom may help you. That means you won't derive publicly from
PositionAttitudeTransform but have pointer to its implementation. This
is sometimes called a has-a relationship, rather than is-a
relationship. You may expose the same function interface with
PositionAttitudeTransform to outside world. Your methods will call
PAT's methods.
class MyAdapter
{
osg::ref_ptrosg::PositionAttitudeTransform m_sppat;
public:
MyAdapter() throw(std::bad_alloc)
: m_sppat(new osg::PositionAttitudeTransform)
{
}
// Transform methods
inline void setReferenceFrame(osg::ReferenceFrame rf) {
m_sppat-setReferenceFrame(rf); }
...
// PositionAttitudeTransform methods
inline void setPivotPoint(const osg::Vec3d pivot) {
m_sppat-setPivotPoint(pivot); }
..
};
you may need to implement all methods you need. I don't think you will
need all public methods available in a PositionAttitudeTransform
(including those are inherited). I didn't compile it but something
like that should work.
Does this help you? The constructor may throw.
try
{
MyAdapter adapter;
// call your library function
} // PAT dies here
catch (std::bad_alloc)
{
// out of memory
}
Ismail
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Derived classes and ref_ptr
Thanks but not really - then I can't use the new class in the scene graph. The idea was to have a 'location' object in the scenegraph which is a PAT as far as OSG is concerned but has methods which reflect the interface I'm used to and fit the needs of my problem domain. That I can do with an Adapter derived class It looks like the only way is to have a set of converter functions. Unfortunately the naming gets a bit complex because I have an osg::location class and a my::location class with the same interface but different internals. I think this is one of those areas where C++ falls behind Java or C# Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17086#17086 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Derived classes and ref_ptr
Hi Martin,
2009/9/5 Martin Beckett m...@mgbeckett.com:
Thanks but not really - then I can't use the new class in the scene graph.
Yes, you can, can't you? Pass your objects to constructor. I wouldn't
do it, but you want if you want to.
class MyAdapter
{
typedef osg::ref_ptrosg::PAT osg_pat_type;
osg_pat_type m_sppat;
public:
// we'll you use
explicit MyAdapter(osg_pat_type pat) : m_sppat(pat) { }
explicit MyAdapter(PAT* pat) : m_sppat(pat) { }
MyAdapter() : m_sppat(new osg::PAT) { }
osg::PAT* release() { m_sppat.release(); }
osg::ref_ptrosg::PAT GetPAT() /*const*/ { return m_sppat; }
// if you want conversions, provide conversion operators...
operator PAT*() { return m_sppat.get(); }
};
Pass your object to constructor and call release before scope ends.
You may automate this by adding a flag and checking that in
destructor. e.g.
const bool m_fShouldRelease;
public:
explicit MyAdapter(osg_pat_type pat) : m_sppat(pat),
m_fShouldRelease(true) { }
explicit MyAdapter(PAT* pat) : m_sppat(pat), m_fShouldRelease(true) { }
MyAdapter() : m_sppat(new osg::PAT), m_fShouldRelease(false) { }
~MyAdapter()
{
if (m_fShouldRelease) release();
}
The idea was to have a 'location' object in the scenegraph which is a PAT as
far as OSG is concerned but has methods which reflect the interface I'm used
to and fit the needs of my problem domain. That I can do with an Adapter
derived class
It looks like the only way is to have a set of converter functions.
Unfortunately the naming gets a bit complex because I have an osg::location
class and a my::location class with the same interface but different
internals.
You can use namespace aliases, or, typedef your my::location to
something else; it may help.
namespace my = AdapterNS;
typedef AdapterNS::location AdapterLocation;
or
namespace AdapterNS
{
typedef ::my::location AdapterLocation;
}
// use AdapterNS::AdapterLocation.
I think this is one of those areas where C++ falls behind Java or C#
Martin
How would you do it in C#? You can do a lot of strange-looking things
in C++, which you can't do in a managed language, because run-time
will not allow you (unless you explicitly express your intent is a
non-verifiable code).
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=17086#17086
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Derived classes and ref_ptr
It appears that I forgot comments in constructors.
2009/9/5 Ismail Pazarbasi pazarb...@gmail.com:
[snip]
class MyAdapter
{
typedef osg::ref_ptrosg::PAT osg_pat_type;
osg_pat_type m_sppat;
public:
// here is missing part
// you will use this constructor to pass a osg::ref_ptrosg::PAT
explicit MyAdapter(osg_pat_type pat) : m_sppat(pat) { }
// you will use this constructor to pass a raw PAT*
explicit MyAdapter(PAT* pat) : m_sppat(pat) { }
// default constructor will create a new one.
// you may alternatively set default value of pat to NULL in above
// constructor and instantiate the object when pat is NULL.
MyAdapter() : m_sppat(new osg::PAT) { }
osg::PAT* release() { m_sppat.release(); }
osg::ref_ptrosg::PAT GetPAT() /*const*/ { return m_sppat; }
// if you want conversions, provide conversion operators...
operator PAT*() { return m_sppat.get(); }
};
[snip]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
