On Sun, 25 Mar 2012 00:15:38 +0100, lcaminiti <lorcaminiti@gmail.com> 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: ///////////////////////////////////////////////////////////////// #include <boost/detail/lightweight_test.hpp> #include <boost/overload.hpp> int int_sum(int x, int y) { return x + y; } float float_inc(float x ) { return x + 1.0f; } int main() { boost::overload<int (int, int ), float (float )> f; f.set(&int_sum); // here automatic call signature f.set(&float_inc); // deduction occurs int r1 = f(1, 2); // invokes int_sum float r2 = f(3.0f); // invokes float_inc BOOST_ASSERT( r1 == 3 ); BOOST_ASSERT( r2 == 4.0f ); return boost::report_errors(); } ///////////////////////////////////////////////////////////////// One can set all callable targets at once: f.set(&float_inc, &int_sum). Order does not matter, the callable entity is assigned automatically to the embedded boost::function with a matching call signature. However that works for monomorphic callable objects only. For polymorphic one it is needed to utilize the set method based on the call signature syntax: ///////////////////////////////////////////////////////////////// #include <boost/detail/lightweight_test.hpp> #include <boost/overload.hpp> /* polymorphic function object */ struct bar { int operator()(int ) { return 1; } template<typename T> int operator()(T ) { return ( 2 + sizeof(T) ); } }; int main() { boost::overload<int (int ), int (char ), int (double )> f; // function object bar foo; // we use the call signature syntax for setting a copy of // foo as object target for the call signature int (char ) // only f.set<int (char )>(foo); // invokes int foo(char ) template instantiation BOOST_ASSERT( f('x') == foo('x') ); // through the empty<Signature>() method we check // that no other object target has been set up BOOST_ASSERT( f.empty<int(int )>() ); BOOST_ASSERT( f.empty<int(double )>() ); // now we set a copy of foo as object target tied to // the call signature int( int ) f.set<int (int )>(foo); BOOST_ASSERT( f('x') == foo('x') ); BOOST_ASSERT( f(1) == foo(1) ); BOOST_ASSERT( f.empty<int(double )>() ); // and finally we set up also the object target // for the int(double ) call signature f.set<int (double )>(foo); BOOST_ASSERT( f('x') == foo('x') ); BOOST_ASSERT( f(1) == foo(1) ); BOOST_ASSERT( f(1.0) == foo(1.0) ); return boost::report_errors(); } ///////////////////////////////////////////////////////////////// In case we are dealing with a statefull function object copying it several times is both expensive and probably also semantically incorrect. The solution is to wrap the function object with boost::ref. The call signature based syntax can be used with overloaded free and member functions, too. Another point where the two libraries differ is that a boost::overload object that supports a given call signature S can be passed everywhere an object of type boost::function<S> is expected. Lately I implemented also support for boost::result_of. So it is possible to utilize (Boost.)Overload with Boost.Fusion algorithms such as boost::fusion::for_each. A natural use case is to utilize (Boost.)Overload for generating a Boost.Variant visitor: ///////////////////////////////////////////////////////////////// #include <boost/variant.hpp> #include <boost/detail/lightweight_test.hpp> #include <boost/overload.hpp> template< typename Overload, typename R = ::boost::detail::static_visitor_default_return

struct overloaded_visitor : public Overload { typedef R result_type; }; int apply_to_int(int ) { return 1; } int apply_to_string(const std::string & ) { return 2; } typedef boost::overload<int (int ), int(const std::string & )> overload_type; typedef overloaded_visitor<overload_type, int> visitor_type; int main() { boost::variant< int, std::string > u("hello world"); visitor_type my_visitor; my_visitor.set( &apply_to_int, &apply_to_string ); int result = boost::apply_visitor( my_visitor, u ); BOOST_ASSERT( result == 2 ); return boost::report_errors(); } ///////////////////////////////////////////////////////////////// You can find more details on the documentation page: http://svn.boost.org/svn/boost/sandbox/overload/trunk/libs/overload/docs/htm... Kind Regards, -- Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

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/

AMDG On 03/27/2012 02:10 PM, lcaminiti wrote:

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?

No. This is fundamentally impossible. Let's ignore the overload part for now. We're trying to define a class F, such that: For any types T and U, such that T is copy constructible and T is callable with an argument of type U: Given an object t of type T, and an object u of type U. F f(t); shall be valid and f shall store a copy of t. Call this copy t_f. Now, f(u) shall compile and shall call t_f(u). Let's assume that F exists. Now, suppose that T is declared only in translation unit A, and U is declared only in translation unit B. Further, suppose that T is a class type with a templated function call operator. The constructor F(t) can be executed in A, and the function call can be executed in B. The result must call T::operator()<U>. However, T and U are never available in the same translation unit, so T::operator()<U> cannot be instantiated. -><- Therefore, we can conclude that type erasure cannot handle polymorphic functions like this, without adding further restrictions. Some possibilities are: a) type erase the argument to T::operator(). b) Limit T and/or U to some fixed set of types. (a la Boost.Variant) c) Allow T/U pairs to be registered dynamically and fail at runtime if there is no viable function. (As the author of a library for general type erasure, I've spent an inordinate amount of time thinking about this problem.) In Christ, Steven Watanabe

Passing to another issue, do you know a way for getting the call signature of the call object type resulting from a lambda or phoenix bind expression at least in the case that the call object is monomorphic ?

Do you mean Boost.Lambda or C++11 lambda? For C++11 lambda, if T is the type of the lambda, and it's monomorphic, get the address of its call operator using &T::operator(), and examine it using Boost.FunctionTypes (keeping in mind that the first argument will be the "this" pointer because it's a member function). Regards, Nate

On Tue, 27 Mar 2012 23:10:59 +0200, lcaminiti <lorcaminiti@gmail.com> wrote:

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 viceversa? 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 :)

I agree, I'll do some test for checking compatibility.

...

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

Ok, that looks sensible, but I think "backward compatibility" is a nice feature.

...

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

I see, but with a minimalist API is easier! :) Indeed, the biggest workaround is needed for MSVC 7.1, now it has been removed from the compiler set used for regression tests, but on 2007 when I started implementing the library it had to be supported.

...

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?

No Overload supports a *finite* overload set, what you'd like to design is a TemplateFunction supporting an *infinite* overload set: template_function< void(int, int), void (_1) > f( &mono, poly() ); where _1 is a placeholder for a template parameter. As Steven Watanabe explained very clearly in the other post that is not doable in general. However Overload provides a method that accepts a polymorphic function object as argument. The passed function object sets/replaces all the existent object targets related to the call signatures supported by both the given instantiation of the template class overload and the passed function object itself. poly polyfunc; overload< void (int, int ), void (int ), void (std::string )> f(&mono); f.set_for_each_shared_signature( boost::ref(polyfunc) ); f(1, 2); // call mono(1,2) f(123); // call polyfunc(123) f("abc"); // call polyfunc("abc") Passing to a less complex issue, do you know a way for getting the call signature of the call object resulting from a lambda or phoenix bind expression ? Can you pass a bind expression to make_overloaded_function ? Ciao, -- Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/