Re: [Boost-users] [shared_ptr] Member functions as deallocators

Subject: Re: [Boost-users] [shared_ptr] Member functions as deallocators
From: Max (more4less_at_[hidden])
Date: 2009-06-04 20:35:11

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_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Roman Perepelitsa
Sent: Thursday, June 04, 2009 4:35 AM
To: boost-users_at_[hidden]
Subject: Re: [Boost-users] [shared_ptr] Member functions as deallocators

 

2009/6/3 OvermindDL1 <overminddl1_at_[hidden]>

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.