Re: [boost] [function] function wrapping and exception safety recap

Subject: Re: [boost] [function] function wrapping and exception safety recap
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-10-23 13:43:27

"Emil Dotchevski" <emil_at_[hidden]> wrote in message 
news:AANLkTim6iz7OBR-jT0e5ffFFXguFjNUDiK77LWGO+Ff9_at_mail.gmail.com...
> On Tue, Oct 19, 2010 at 1:45 PM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>>
>> "Emil Dotchevski" <emil_at_[hidden]> wrote in message
>> news:AANLkTikGfE0KcMXjPMpqL-+12rUbouOrVGr1Rfgr_m_-_at_mail.gmail.com...
>>>
>>> On Tue, Oct 19, 2010 at 12:34 AM, Domagoj Saric <dsaritz_at_[hidden]> 
>>> 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