Re: [boost] (Boost.)Overload vs Boost.Functional/OverloadedFunction (was Re: Status of proposed boost.overload?)

Subject: Re: [boost] (Boost.)Overload vs Boost.Functional/OverloadedFunction (was Re: Status of proposed boost.overload?)
From: Marco Cecchetti (mrcekets_at_[hidden])
Date: 2012-03-27 05:11:11

On Mon, 26 Mar 2012 14:39:10 +0200, lcaminiti <lorcaminiti_at_[hidden]>
wrote:

>
> Marco Cecchetti wrote
>>
>> On Sun, 25 Mar 2012 00:15:38 +0100, lcaminiti &lt;lorcaminiti@&gt;
>> wrote:
>>
>>> How's this different from:
>>> http://svn.boost.org/svn/boost/trunk/libs/functional/overloaded_function/doc/html/index.html
>>>
>>
>> Hi Lorenzo,
>> (Boost.)Overload is a dynamic wrapper of multiple callable objects.
>> All started from a Joel de Guzman's post where he showed a proof
>> of concept of a thin-wrapper of several Boost.Functions.
>> See: http://lists.boost.org/Archives/boost/2007/09/127906.php
>> On that code base, I designed (Boost.)Overload that provides an
>> interface similar to Boost.Function.
>>
>> A first difference is that with (Boost.)Overload is possible
>> to create an empty boost::overload object, and then set up
>> callable targets at a later time, obviously the library provides
>> methods for checking if a given callable target is empty.
>> That matches exactly what Boost.Function does.
>> Here's a basic example extracted from the tutorial:
>>

>
> It seems that the two libraries do the same things a part for a slightly
> different API.

Well, indeed I find the 'slightly' adjective a bit inappropriate.
In fact for what I can see OverloadedFunction API is made of
constructors and call operators only, whilst Overload provides
also more than 15 methods, some metafunctions and Boost.ResultOf support.
I understand that such a minimalism is due to the fact that you
designed such a library mainly for providing overloaded functions
in Boost.Local, but I am evaluating OverloadedFunction as a standalone
library. I hope to have not been rude.

For more details, you can give a look at the overload class reference:
http://svn.boost.org/svn/boost/sandbox/overload/trunk/libs/overload/docs/html/boost_overload/references.html#boost_overload.references.boost_overload_hpp.class_template_overload

> At a first look, your library API seems a super set of mine.
> Therefore, if your library passes the review maybe it can simply extend  
> my OverloadedFunction adding default constructors, set(), etc (so we  
> don't end up with two different libraries serving the same purpose).

I agree that the two library overlap, on the other hand I have good
reasons for retaining my implementation:

1) overload<S1, S2, ..., SK> inherits from boost::function<SI> for 1<=I<=K
    that means you can pass an overload object that support the  call
    signature S everywhere a boost::function<S> is expected.
    Btw, why do you prefer to wrap each boost::function in an ad-hoc
    base class ?

2) the Overload API implementation is heavily based on the fact that
    boost::overload inherits recursively from base classes (similar to
    Boost.Tuple) containing metainfo (types, static const data fields).

3) I have already tested my implementation with a good amount of compilers
    (gcc 3.4.2+, Intel 9.1+, clang 2.9, ekopath 4, MSVC 7.1+, mingw 3.4.2+)
    and where I got failures I provided workarounds.

4) I keep dependencies from other libraries as minimal as possible,
    for what I can see OverloadedFunction has two more dependencies:
    Boost.FunctionTypes and Boost.MPL.

> BTW, do you have something similar to my make_overloaded_function?

Yep, Overload provides a make_overload utility:
http://svn.boost.org/svn/boost/sandbox/overload/trunk/libs/overload/docs/html/boost_overload/tutorial.html#boost_overload.tutorial.the_make_overload_utility

Indeed, I'm not so happy with that because it requires Boost.TypeOf,
for such a reason I prefer to keep it in a separate header.

Ciao,
-- Marco

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/