On Tue, Oct 19, 2010 at 1:45 PM, Domagoj Saric <dsaritz@gmail.com> wrote:
"Emil Dotchevski" <emil@revergestudios.com> wrote in message news:AANLkTikGfE0KcMXjPMpqL-+12rUbouOrVGr1Rfgr_m_-@mail.gmail.com...
On Tue, Oct 19, 2010 at 12:34 AM, Domagoj Saric <dsaritz@gmail.com> wrote:
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?
Because function<T,A1> is not the same type as function<T,A2>.
And? So is function<T1> not the same type as function<T2>...what difference does that make?
The difference is that the current boost::function interface does not burden the user with having to remember the type of the allocator for each individual function object. You could for example organize a bunch of function<void()> objects in an array, even if each one of them uses a different type of allocator. What is the advantage of the function<T,A> interface anyway?
The point is, AFAIK, to erase the type of the object you put into a boost::function<> instance, not the type of boost::function itself...after all unlike in Objective-C(++) in C++ everything has _some_ type in the end...
Everything has a type, but the user doesn't have to know the type of everything. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode