On Mon, 26 Mar 2012 14:39:10 +0200, lcaminiti <lorcaminiti@gmail.com> 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...
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/htm...
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/htm... 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/