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: lcaminiti (lorcaminiti_at_[hidden])
Date: 2012-03-27 17:10:59

Marco Cecchetti wrote
> 
> On Mon, 26 Mar 2012 14:39:10 +0200, lcaminiti <lorcaminiti@>
> wrote:
> 
>>
>> Marco Cecchetti wrote
>>>
>>> On Sun, 25 Mar 2012 00:15:38 +0100, lcaminiti <lorcaminiti@>
>>> 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:
> 

Sure you can keep your implementation. The main point is if your library
(with your implementation) can replace mine after your library gets
accepted. I'd think so because my library API seems to be a subset of yours
but can you think if that replacement will be possible or not? (The
"replacement" is important so users that start using my library can later
use yours without affecting backward compatibility.) For example, have you
tried to compile my library examples using your library and vice versa? That
might be a good start in assessing if my library will be able to be replaced
by yours. These things will come up during the review of your library so
it's better to address them now :)

> 1) overload&lt;S1, S2, ..., SK&gt; 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 ?
> 

For performance (based on a very quick analysis I've done back then...).

> 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.
> 

Also OveloadedFunction seems to pass most trunk regression tests :)
http://www.boost.org/development/tests/trunk/developer/functional-overloaded_function.html

> 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.
> 

BTW, I wasn't able to handle polimorphic functions. For example, the
following will not work :(

struct poly {
    template<typename T>
    void operator()( T const& x ) { std::cout << "poly" << std::endl; }
};

void mono( int x, int y ) { std::cout << "mon" << std::endl;

overload_function< void(int, int), /* some type which I couldn't figure out
*/ > f(mono, poly);
f(1, 2); // call mono
f(123); // call poly
f("abc"); // call poly

// or even harder
auto g = make_overloaded_function(mono, poly);
g(1, 2); // call mono
g(123); // call poly
g("abc"); // call poly

Can your library handle polymorphic functions?

Ciao,
--Lorenzo

--
View this message in context: http://boost.2283326.n4.nabble.com/Status-of-proposed-boost-overload-tp4500266p4510227.html
Sent from the Boost - Dev mailing list archive at Nabble.com.