"Emil Dotchevski" <emil@revergestudios.com> wrote in message news:AANLkTim6iz7OBR-jT0e5ffFFXguFjNUDiK77LWGO+Ff9@mail.gmail.com...
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.
- 'Burden of remembering'? - that's what default template parameters and typedefs are for...for example my changed boost::function<> has two template parameters yet it still functions as a drop-in replacement for the original one because the second parameter is defaulted to give it the same semantics as the original one...So, once again, giving options does not necessarily take away simplicity while hardcoding 'simplicity' _does_ take away options... - 'Dynamicness'/'polymorphism', as explained so many times before...you can have this also even if you allow an arbitrary amount of policies through an arbitrary amount of template parameters because this gives you the >option< of specifying dynamic/polymorphic policies at compile time and then using different implementations of the same policies at runtime....OTOH hardcoding dynamic policies does _not_ give you the option to benefit from compile-time driven efficiency... "So, once again, giving options does not necessarily take away simplicity while hardcoding 'simplicity' _does_ take away options..." - 'Burden the user'? Are we again designing around "Managed Joe Sixpack"? Last time I checked, in C++ (the language, unfortunately not necessarily the standard library) having more options was called 'power' not 'burden'...Why can't you accept that your preconceptions of what is 'good enough for everyone' just simply is not good enough for everyone, as proven time and time again by these very questions and requests on this very list? AFAIK C++ used to boast by being able to do both high level and low level things...if you start hardcoding 'rule of thumb' decisions into the core of the standard library that 'power'/'magic'/'burden?' is quickly lost...and we're in 'managed land' again...where the sun always shines...until of course you try to think outside the box/'the standard library'... - Why did you use allocators as an argument here anyway? This looks like a straw man, AFAICT noone contested this yet...In any case, even this argument does not help your 'case'/POV (which is defending the status quo, if I deduced correctly), quite the opposite if I may say. Namely, the issue of allocators is different (from for example on-empty policy) because boost::function<> needs the desired allocator only on construction and assignment so explicitly/manually/separately passing them as arguments then (at runtime, instead of specifying them once through a template parameter) incurs no overhead and can even be seen as giving more power (or in your view, burdening the user) as you can use different allocators at different times...thus, seeing it this way, it becomes quite dubious to claim that this runtime way of specifying allocators actually makes things easier for users when in reality it seems the opposite, because instead of specifying your desired allocator only once you have to specify/pass it every time...QeD. ps. are you implying that the various allocator template parameters in the STL are examples of bad/'burdening' design?
What is the advantage of the function<T,A> interface anyway?
Um...to choose: - on-empty behaviour - size of the SBO buffer - 'decoration' of the boost::function instance (for example whether it is/holds nothrow targets) - default allocator ... IOW: if I want to have a pink flying elephant on my screen every time an empty boost::function<> is invoked, than let me have my pink flying elephant! (... >without< having to wrap or reimplement boost::function ...)
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.
Neither does (s)he have to not know the type of everything... I'm sorry if I missed some deeper point but this just seems like more of the old "running in circles"...let's not do that please... -- "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