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
> On Tue, Oct 19, 2010 at 1:45 PM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>> "Emil Dotchevski" <emil_at_[hidden]> wrote in message
>>> On Tue, Oct 19, 2010 at 12:34 AM, Domagoj Saric <dsaritz_at_[hidden]>
>>>> Just like in the case of shared_ptr, I still don't buy this
>>>> would replacing hardcoded dynamic behaviour with configurability
>>>> 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
>> 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
- '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
"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
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?
- 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
(... >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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk