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]>
> Marco Cecchetti wrote
>> On Sun, 25 Mar 2012 00:15:38 +0100, lcaminiti <lorcaminiti@>
>>> How's this different from:
>> 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:
> 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:
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.
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk