"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 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... If one wants to fix(ate) one or all template parameters of boost::function in an interface (for example to what they are now implicitly hardcoded when you have no option to choose) one is perfectly free to do so (thus e.g. transforming your function<T, A1> to function<T>)... ...the difference is that the user has the >_option_< (or is time to be pathetic and say "freedom") to choose... You can always go from "freedom" to "rule of thumb"/"happy Joe Sixpack" but not vice verse... -- "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