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...
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:
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<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 ?
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...
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.
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-tp45002... Sent from the Boost - Dev mailing list archive at Nabble.com.