[shared_ptr] Member functions as deallocators
I'm using shared_ptr to hold a SceneManager object. In this particular case, I don't actually want the shared_ptr to have ownership of the SceneManager, but rather take advantage of it to insure that the SceneManager it holds is cleared when the containing object (a game's state) is destroyed. The deallocator needs to call SceneManager::clearScene, but it needs to call it on the held object, so the deallocator call would be essentially (pointer held in shared_ptr)->clearScene( ); Can anyone give me some guidance on how to accomplish this? Thanks, MBC
AMDG Michael Crawford wrote:
I'm using shared_ptr to hold a SceneManager object. In this particular case, I don't actually want the shared_ptr to have ownership of the SceneManager, but rather take advantage of it to insure that the SceneManager it holds is cleared when the containing object (a game's state) is destroyed. The deallocator needs to call SceneManager::clearScene, but it needs to call it on the held object, so the deallocator call would be essentially (pointer held in shared_ptr)->clearScene( ); Can anyone give me some guidance on how to accomplish this
The pointer will be passed as an argument to the deallocator. boost::shared_ptr<SceneManager> p(s, boost::bind(&SceneManager::clearScene, _1)); In Christ, Steven Watanabe
I'm using shared_ptr to hold a SceneManager object. In this particular case, I don't actually want the shared_ptr to have ownership of the SceneManager, but rather take advantage of it to insure that the SceneManager it holds is cleared when the containing object (a game's state) is destroyed. The deallocator needs to call SceneManager::clearScene, but it needs to call it on the held object, so the deallocator call would be essentially (pointer held in shared_ptr)->clearScene( ); Can anyone give me some guidance on how to accomplish this?
boost::shared_ptr<SceneManager > sceneManager(new SceneManager, boost::bind(&SceneManager::clearScene, _1));
Actually, using Boost.Bind will use a lot more memory overall. Would it not be better to create a static function somewhere, something like: class SceneManager { ... static deallocSM(SceneManage *ptr) { ptr->clearScene(); } ... }; And create as: SceneManager *s=fromSomewhere(); boost::shared_ptr<SceneManager> p(s, &SceneManager::deallocSM); Doing this means it only keeps a pointer to the function call, instead of through a bind instantiation, meaning this will execute ever so tiny slightly faster, as well as take less space? It has been a while since I created a new handler like that, but I 'think' the function takes a pointer to the embedded pointer type, check the smart_ptr docs for details I guess.
2009/6/3 OvermindDL1
Actually, using Boost.Bind will use a lot more memory overall. Would it not be better to create a static function somewhere, something like:
class SceneManager { ... static deallocSM(SceneManage *ptr) { ptr->clearScene(); } ... };
And create as: SceneManager *s=fromSomewhere();
boost::shared_ptr<SceneManager> p(s, &SceneManager::deallocSM);
Doing this means it only keeps a pointer to the function call, instead of through a bind instantiation, meaning this will execute ever so tiny slightly faster, as well as take less space? It has been a while since I created a new handler like that, but I 'think' the function takes a pointer to the embedded pointer type, check the smart_ptr docs for details I guess.
Modern compiler's might surprise you. Always measure performance or look at generated code before resorting to manual optimizations. Roman Perepelitsa.
On Wed, Jun 3, 2009 at 2:35 PM, Roman Perepelitsa
2009/6/3 OvermindDL1
Actually, using Boost.Bind will use a lot more memory overall. Would it not be better to create a static function somewhere, something like:
class SceneManager { ... static deallocSM(SceneManage *ptr) { ptr->clearScene(); } ... };
And create as: SceneManager *s=fromSomewhere();
boost::shared_ptr<SceneManager> p(s, &SceneManager::deallocSM);
Doing this means it only keeps a pointer to the function call, instead of through a bind instantiation, meaning this will execute ever so tiny slightly faster, as well as take less space? It has been a while since I created a new handler like that, but I 'think' the function takes a pointer to the embedded pointer type, check the smart_ptr docs for details I guess.
Modern compiler's might surprise you. Always measure performance or look at generated code before resorting to manual optimizations.
Of course, but the bind will, at the very least, keep the function pointer and the pointer to the class itself, so 2*sizeof(void*), whereas the smart pointer already passes the pointer to the deallocation function, meaning there is no reason to duplicate it. In the best case you are doubling the necessary amount of used memory for that data structure.
This paradox seems to be always there.
Using Bind or handwritten functors is a compromise between ease of use (and
maintenance)
and code performance (and code size). One of the main advantages of Bind is
the ability to
create in-place function objects to avoid the scattered handwritten functors
(global class,
global functions, static methods, etc.) which will give code maintainers
(sometimes the original
author himself) more head scratch.
In code that is not hotspot or in case memory foorprint is not critical, I
think most of peaple will
prefer Bind version.
B/Rgds
Max
From: boost-users-bounces@lists.boost.org
[mailto:boost-users-bounces@lists.boost.org] On Behalf Of Roman Perepelitsa
Sent: Thursday, June 04, 2009 4:35 AM
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] [shared_ptr] Member functions as deallocators
2009/6/3 OvermindDL1
On Wed, Jun 3, 2009 at 13:28, OvermindDL1
Actually, using Boost.Bind will use a lot more memory overall. Would it not be better to create a static function somewhere, something like:
In this case SceneManager comes from a 3rd party library, so I would just have to have a free function sitting out there somewhere to wrap the clearScene() call - not something I would prefer. Also, clearing the scene here means the destruction of dozens if not hundreds of resources (meshes, textures, and so on) so whatever overhead bind may incur is going to be trivial by comparison. Given that, I think it's just easier on me and more clear in the long run to go ahead and use bind. Cheers, MBC
participants (6)
-
Igor R -
Max -
Michael Crawford -
OvermindDL1 -
Roman Perepelitsa -
Steven Watanabe