Boost logo

Boost :

Subject: Re: [boost] [function] function wrapping and exception safety recap
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-10-19 03:34:40

"Emil Dotchevski" <emil_at_[hidden]> wrote in message

On Mon, Oct 11, 2010 at 7:49 AM, Domagoj Saric
<domagoj.saric_at_[hidden]> wrote:
>> What (de)coupling (and the related benefits) are you referring to? The
>> ABI
>> compatibility/stability and safe cross .DLL/.so passing arguments also
>> used
>> for the justification of the hardcoded dynamic deleter in shared_ptr or
>> something else?
> Yes, that ability is a result of the reduced coupling. One of the main
> objectives of boost::function is type erasure: being able to hold on
> to functions without knowing their exact type, and the allocator
> policy directly interfered with that.

Just like in the case of shared_ptr, I still don't buy this argument...: why
would replacing hardcoded dynamic behaviour with configurability through
policies 'interfere' with type erasure? Adding more template parameters in
no way changes the first/main parameter or causes the actual type stored in
the boost::function to somehow 'leak' out through the interface...

As for the 'safe shared module border crossing' argument you are still left
with the _option_ of using a dynamic policy for anything that might use the
runtime library...The fact that an inexperienced user might forget to do so
(while at the same time linking with different runtimes in different 'DLLs')
thus shooting oneself in the foot is no justification for crippling other
users that 'know what they are doing'...AFAIK C++ is _not_ a managed
language where the case of Joe Sixpack is the lead use case...

> Also, with the removal of the default Allocator parameter of the main
> boost::function template, it is possible to define APIs in terms of
> boost::function without including boost/function.hpp; just a
> declaration in the API header suffices:
> namespace boost { template <class> function; }
> void foo( boost::function<void()> const & );

I'm sorry if I am ignorant of some crucial C++ fact but I fail to see why
the same thing could not be done if boost::function had more template
Furthermore, whatever the case my be, this forward declaration ability would
make any relevance only in headers that mention boost::function only as
function parameters and return types and/or as members held by reference
_and_ one is using an ancient compiler incapable of including/parsing
Boost.Function headers in the blink of an eye....hopefully this not the use
case for modelling (and crippling) a Boost library interface...

"What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than
from one whose countenance exudes suspicion and hate."
Neil Postman 

Boost list run by bdawes at, gregod at, cpdaniel at, john at