"Emil Dotchevski" <emil@revergestudios.com> wrote in message news:AANLkTimenndg89tGkUepkP-5mizv_NtNEdh-DAkNG1Tv@mail.gmail.com... On Mon, Oct 11, 2010 at 7:49 AM, Domagoj Saric <domagoj.saric@littleendian.com> 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 parameters? 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