Delegating to boost::function with arbitrary signature

Alexander Lamaison

14 Dec 2013 14 Dec '13

2:49 p.m.

I've asked this question on Stack Overflow but not found a solution yet: http://stackoverflow.com/q/20578575/67013. It's Boost.Function/MPL-related so I'll ask here too. I'm trying to create something like a `boost::function`, but with an extra 'smart handle' tucked inside, which controls the lifetime of a resource the functions needs to execute correctly. If I didn't need the function signature to be completely generic, this would be easy. I would just create a functor with the correct signature, and keep a `boost::function` and the handle as members. However, I do need generic signatures. The code below is as close as I've got but gets a compile error, presumably, because I'm not able to unpack a list of arguments like this: template<typename Signature> class library_function { public: library_function( library_handle handle, boost::function function) : m_handle(handle), m_function(function) {} typename result_type operator()(arg1_type arg1, arg2_type arg2) { return m_function(arg1, arg2); } // I don't think I can declare the 'params' like this ... typename boost::function_types::result_type<Signature>::type operator()( boost::function_types::parameter_types<Signature> params) { return m_function(params); // ... nor unpack them like this } private: boost::function<Signature> m_function; library_handle m_library; }; I think `params` is an MPL list, so what I've actually done is declare a call operator with a single MPL-list parameter. My MPL-foo is not good. Is there a way to convert the list to a legal definition of multiple function paramters? A suggested solution on SO is to use `boost::bind`, but I still don't see how to bind an arbitrary number of arguments. All advice greatly appreciated. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

Show replies by date

TONGARI J

14 Dec 14 Dec

3:20 p.m.

New subject: Delegating to boost::function with arbitrary signature

2013/12/14 Alexander Lamaison

...

I've asked this question on Stack Overflow but not found a solution yet: http://stackoverflow.com/q/20578575/67013. It's Boost.Function/MPL-related so I'll ask here too.

I'm trying to create something like a `boost::function`, but with an extra 'smart handle' tucked inside, which controls the lifetime of a resource the functions needs to execute correctly.

If I didn't need the function signature to be completely generic, this would be easy. I would just create a functor with the correct signature, and keep a `boost::function` and the handle as members.

However, I do need generic signatures. The code below is as close as I've got but gets a compile error, presumably, because I'm not able to unpack a list of arguments like this:

template<typename Signature> class library_function { public: library_function( library_handle handle, boost::function function) : m_handle(handle), m_function(function) {}

typename result_type operator()(arg1_type arg1, arg2_type arg2) { return m_function(arg1, arg2); }

// I don't think I can declare the 'params' like this ... typename boost::function_types::result_type<Signature>::type operator()( boost::function_types::parameter_types<Signature> params) { return m_function(params); // ... nor unpack them like this }

private: boost::function<Signature> m_function; library_handle m_library; };

I think `params` is an MPL list, so what I've actually done is declare a call operator with a single MPL-list parameter. My MPL-foo is not good. Is there a way to convert the list to a legal definition of multiple function paramters?

Why not just derive from boost::function so you get the call operator for free?

Alexander Lamaison

4:24 p.m.

New subject: Delegating to boost::function with arbitrary signature

TONGARI J writes:

...

...
2013/12/14 Alexander Lamaison mailto:awl03@doc.ic.ac.uk I've asked this question on Stack Overflow but not found a solution yet: http://stackoverflow.com/q/20578575/67013. It's Boost.Function/MPL-related so I'll ask here too.

I'm trying to create something like a `boost::function`, but with an extra 'smart handle' tucked inside, which controls the lifetime of a resource the functions needs to execute correctly.

If I didn't need the function signature to be completely generic, this would be easy. I would just create a functor with the correct signature, and keep a `boost::function` and the handle as members.

However, I do need generic signatures. The code below is as close as I've got but gets a compile error, presumably, because I'm not able to unpack a list of arguments like this:

template<typename Signature> class library_function { public: library_function( library_handle handle, boost::function function) : m_handle(handle), m_function(function) {}

typename result_type operator()(arg1_type arg1, arg2_type arg2) { return m_function(arg1, arg2); }

// I don't think I can declare the 'params' like this ... typename boost::function_types::result_type<Signature>::type operator()( boost::function_types::parameter_types<Signature> params) { return m_function(params); // ... nor unpack them like this }

private: boost::function<Signature> m_function; library_handle m_library; };

I think `params` is an MPL list, so what I've actually done is declare a call operator with a single MPL-list parameter. My MPL-foo is not good. Is there a way to convert the list to a legal definition of multiple function paramters?

...

Why not just derive from boost::function so you get the call operator for free?

I avoided publicly-inheriting from `boost::function` because that's just asking for slicing problems. Private inheritance seemed like a good idea but I then run into a problem passing the resulting object to anything expecting a `boost::function`. Instead of treating as any regular callable object, the compiler knows that it inherits from a `boost::function` and complains that the conversion is hidden. Maybe there's some way round this? template<typename Signature> class library_function : private boost::function<Signature> { public: library_function( shared_ptr<HMODULE> library, Signature* library_funtion) : m_library(library), m_function(library_function) {} using boost::function<Signature>::operator(); private: shared_ptr<HMODULE> m_library; boost::function<Signature> m_function; }; error C2243: 'type cast' : conversion from 'library_function<Signature> *' to 'const boost::function_base *' exists, but is inaccessible Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

TONGARI J

4:53 p.m.

New subject: Delegating to boost::function with arbitrary signature

2013/12/15 Alexander Lamaison

...

TONGARI J writes:

...
...
2013/12/14 Alexander Lamaison I've asked this question on Stack Overflow but not found a solution yet: http://stackoverflow.com/q/20578575/67013. It's Boost.Function/MPL-related so I'll ask here too.

I'm trying to create something like a `boost::function`, but with an extra 'smart handle' tucked inside, which controls the lifetime of a resource the functions needs to execute correctly.

If I didn't need the function signature to be completely generic, this would be easy. I would just create a functor with the correct signature, and keep a `boost::function` and the handle as members.

However, I do need generic signatures. The code below is as close as I've got but gets a compile error, presumably, because I'm not able to unpack a list of arguments like this:

template<typename Signature> class library_function { public: library_function( library_handle handle, boost::function function) : m_handle(handle), m_function(function) {}

typename result_type operator()(arg1_type arg1, arg2_type arg2) { return m_function(arg1, arg2); }

// I don't think I can declare the 'params' like this ... typename boost::function_types::result_type<Signature>::type operator()( boost::function_types::parameter_types<Signature> params) { return m_function(params); // ... nor unpack them like this }

private: boost::function<Signature> m_function; library_handle m_library; };

I think `params` is an MPL list, so what I've actually done is declare a call operator with a single MPL-list parameter. My MPL-foo is not good. Is there a way to convert the list to a legal definition of multiple function paramters?

...
Why not just derive from boost::function so you get the call operator for free?

I avoided publicly-inheriting from `boost::function` because that's just asking for slicing problems. Private inheritance seemed like a good idea but I then run into a problem passing the resulting object to anything expecting a `boost::function`. Instead of treating as any regular callable object, the compiler knows that it inherits from a `boost::function` and complains that the conversion is hidden. Maybe there's some way round this?

Another thought is to use boost::function directly, and provide a make function: template<typename Signature> boost::function<Signature> make_library_function(shared_ptr<HMODULE> library, Signature* f) { return library_function<Signature>(library, f); } And library_function becomes: template<typename Signature>

...

class library_function { public: library_function( shared_ptr<HMODULE> library, Signature* library_funtion) : m_library(library), m_function(library_function) {}

operator Signature*() const { return m_function; }

...

private: shared_ptr<HMODULE> m_library; Signature* m_function; };

Note: code not tested

Michael Powell

5:12 p.m.

New subject: Delegating to boost::function with arbitrary signature

On Sat, Dec 14, 2013 at 10:53 AM, TONGARI J wrote:

...

2013/12/15 Alexander Lamaison

...
TONGARI J writes:

...
...
2013/12/14 Alexander Lamaison mailto:awl03@doc.ic.ac.uk I've asked this question on Stack Overflow but not found a solution yet: http://stackoverflow.com/q/20578575/67013. It's Boost.Function/MPL-related so I'll ask here too.

I'm trying to create something like a `boost::function`, but with an extra 'smart handle' tucked inside, which controls the lifetime of a resource the functions needs to execute correctly.

If I didn't need the function signature to be completely generic, this would be easy. I would just create a functor with the correct signature, and keep a `boost::function` and the handle as members.

However, I do need generic signatures. The code below is as close as I've got but gets a compile error, presumably, because I'm not able to unpack a list of arguments like this:

template<typename Signature> class library_function { public: library_function( library_handle handle, boost::function function) : m_handle(handle), m_function(function) {}

typename result_type operator()(arg1_type arg1, arg2_type arg2) { return m_function(arg1, arg2); }

// I don't think I can declare the 'params' like this ... typename boost::function_types::result_type<Signature>::type operator()( boost::function_types::parameter_types<Signature> params) { return m_function(params); // ... nor unpack them like this }

private: boost::function<Signature> m_function; library_handle m_library; };

I think `params` is an MPL list, so what I've actually done is declare a call operator with a single MPL-list parameter. My MPL-foo is not good. Is there a way to convert the list to a legal definition of multiple function paramters?

...
Why not just derive from boost::function so you get the call operator for free?

I avoided publicly-inheriting from `boost::function` because that's just asking for slicing problems. Private inheritance seemed like a good idea but I then run into a problem passing the resulting object to anything expecting a `boost::function`. Instead of treating as any regular callable object, the compiler knows that it inherits from a `boost::function` and complains that the conversion is hidden. Maybe there's some way round this?

Another thought is to use boost::function directly, and provide a make function:

There you go. Simple decorator pattern. Nice and transparent and tucked away.

...

template<typename Signature> boost::function<Signature> make_library_function(shared_ptr<HMODULE> library, Signature* f) { return library_function<Signature>(library, f); }

And library_function becomes:

...
template<typename Signature> class library_function { public: library_function( shared_ptr<HMODULE> library, Signature* library_funtion) : m_library(library), m_function(library_function) {}

operator Signature*() const { return m_function; }

private: shared_ptr<HMODULE> m_library; Signature* m_function; };

Note: code not tested

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Alexander Lamaison

16 Dec 16 Dec

2:10 p.m.

New subject: Delegating to boost::function with arbitrary signature

TONGARI J writes:

...

2013/12/15 Alexander Lamaison mailto:awl03@doc.ic.ac.uk TONGARI J mailto:tongari95@gmail.com writes:

...
...
2013/12/14 Alexander Lamaison mailto:mailto:awl03@doc.ic.ac.uk I've asked this question on Stack Overflow but not found a solution yet: http://stackoverflow.com/q/20578575/67013. It's Boost.Function/MPL-related so I'll ask here too.

I'm trying to create something like a `boost::function`, but with an extra 'smart handle' tucked inside, which controls the lifetime of a resource the functions needs to execute correctly.

If I didn't need the function signature to be completely generic, this would be easy. I would just create a functor with the correct signature, and keep a `boost::function` and the handle as members.

However, I do need generic signatures. The code below is as close as I've got but gets a compile error, presumably, because I'm not able to unpack a list of arguments like this:

template<typename Signature> class library_function { public: library_function( library_handle handle, boost::function function) : m_handle(handle), m_function(function) {}

typename result_type operator()(arg1_type arg1, arg2_type arg2) { return m_function(arg1, arg2); }

// I don't think I can declare the 'params' like this ... typename boost::function_types::result_type<Signature>::type operator()( boost::function_types::parameter_types<Signature> params) { return m_function(params); // ... nor unpack them like this }

private: boost::function<Signature> m_function; library_handle m_library; };

I think `params` is an MPL list, so what I've actually done is declare a call operator with a single MPL-list parameter. My MPL-foo is not good. Is there a way to convert the list to a legal definition of multiple function paramters?

...
Why not just derive from boost::function so you get the call operator for free?

I avoided publicly-inheriting from `boost::function` because that's just asking for slicing problems. Private inheritance seemed like a good idea but I then run into a problem passing the resulting object to anything expecting a `boost::function`. Instead of treating as any regular callable object, the compiler knows that it inherits from a `boost::function` and complains that the conversion is hidden. Maybe there's some way round this?Another thought is to use boost::function directly, and provide a make function:template<typename Signature> boost::function<Signature> make_library_function(shared_ptr<HMODULE> library, Signature* f){ return library_function<Signature>(library, f);} And library_function becomes:

template<typename Signature> class library_function { public: library_function( shared_ptr<HMODULE> library, Signature* library_funtion) : m_library(library), m_function(library_function) {}

operator Signature*() const { return m_function; }

private: shared_ptr<HMODULE> m_library; Signature* m_function; };Note: code not tested

This works well. The key was `operator Signature*()`. Clever idea, thanks! I didn't expect it to work because I though `boost::function` would pull out the `Signature*` via the cooersion operator, and then the `library_function` would be destroyed before the call was made. However, this code proves that it has the desired behaviour, so it must be keeping a copy of the `library_function` instance inside `boost::function`: http://ideone.com/BZvuk9. I didn't use`make_library_function` because inferring the signature from the raw function isn't something I need. If you would like to add this answer to the Stack Overflow qusetion, I'll happily give you the brownie points :) Thanks, Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

TONGARI J

3:31 p.m.

New subject: Delegating to boost::function with arbitrary signature

2013/12/16 Alexander Lamaison

...

TONGARI J writes:

...
template<typename Signature> class library_function { public: library_function( shared_ptr<HMODULE> library, Signature* library_funtion) : m_library(library), m_function(library_function) {}

operator Signature*() const { return m_function; }

private: shared_ptr<HMODULE> m_library; Signature* m_function; };Note: code not tested

This works well. The key was `operator Signature*()`. Clever idea, thanks!

I didn't expect it to work because I though `boost::function` would pull out the `Signature*` via the cooersion operator, and then the `library_function` would be destroyed before the call was made. However, this code proves that it has the desired behaviour, so it must be keeping a copy of the `library_function` instance inside `boost::function`: http://ideone.com/BZvuk9.

I didn't use`make_library_function` because inferring the signature from the raw function isn't something I need.

If you would like to add this answer to the Stack Overflow qusetion, I'll happily give you the brownie points :)

Done: http://stackoverflow.com/a/20614403/2969631 BTW, the reason why I knew this trick is because I implemented this: http://tinyurl.com/mptekbr and it credits to Proto.

Bjorn Reese

14 Dec 14 Dec

3:25 p.m.

New subject: Delegating to boost::function with arbitrary signature

On 12/14/2013 03:49 PM, Alexander Lamaison wrote:

...

I'm trying to create something like a `boost::function`, but with an extra 'smart handle' tucked inside, which controls the lifetime of a resource the functions needs to execute correctly.

The two aspects (resource life-time and generic signatures) should probably be handled separately. Regarding resource life-time, a common pattern is to bind to a member function on an object obtained via shared_from_this(). Here is an example from Boost.Asio: http://www.boost.org/doc/html/boost_asio/tutorial/tutdaytime3.html Regarding generic signatures I am less certain, but maybe you could look into Boost.TypeErasure. Especially its type-safe printf example (or the subsequent example with multiple signatures) http://www.boost.org/doc/html/boost_typeerasure/examples.html#boost_typeeras...

Michael Powell

3:30 p.m.

New subject: Delegating to boost::function with arbitrary signature

On Sat, Dec 14, 2013 at 9:25 AM, Bjorn Reese wrote:

...

On 12/14/2013 03:49 PM, Alexander Lamaison wrote:

...
I'm trying to create something like a `boost::function`, but with an extra 'smart handle' tucked inside, which controls the lifetime of a resource the functions needs to execute correctly.

The two aspects (resource life-time and generic signatures) should probably be handled separately.

Regarding resource life-time, a common pattern is to bind to a member function on an object obtained via shared_from_this(). Here is an example from Boost.Asio:

I tend to agree with this application of the pattern: dependency-injection and/or inversion-of-control, or in this case, method-injection. Trust me, from industry best practice, as well as experience, you'll be glad you did, because you can keep the concerns a) loosely coupled, and b) more concise, single-responsibility, closer to the problem they are actually trying to solve.

...

http://www.boost.org/doc/html/boost_asio/tutorial/tutdaytime3.html

Regarding generic signatures I am less certain, but maybe you could look into Boost.TypeErasure. Especially its type-safe printf example (or the subsequent example with multiple signatures)

http://www.boost.org/doc/html/boost_typeerasure/examples.html#boost_typeeras...

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Alexander Lamaison

3:56 p.m.

New subject: Delegating to boost::function with arbitrary signature

Michael Powell writes:

...

On Sat, Dec 14, 2013 at 9:25 AM, Bjorn Reese wrote:

...
On 12/14/2013 03:49 PM, Alexander Lamaison wrote:

...
I'm trying to create something like a `boost::function`, but with an extra 'smart handle' tucked inside, which controls the lifetime of a resource the functions needs to execute correctly.

The two aspects (resource life-time and generic signatures) should probably be handled separately.

Regarding resource life-time, a common pattern is to bind to a member function on an object obtained via shared_from_this(). Here is an example from Boost.Asio:

I tend to agree with this application of the pattern: dependency-injection and/or inversion-of-control, or in this case, method-injection.

Trust me, from industry best practice, as well as experience, you'll be glad you did, because you can keep the concerns a) loosely coupled, and b) more concise, single-responsibility, closer to the problem they are actually trying to solve.

...
http://www.boost.org/doc/html/boost_asio/tutorial/tutdaytime3.html

I'm probably being dense, but I don't see how this applies to what I'm trying to do. My 'smart handle' is just a `shared_ptr` controlling the loading/unloading of a DLL from which I load a function by name. I want to expose that function as a callable object, and the library needs to remain loaded as long as anyone might call it. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

4141

Age (days ago)

4143

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Alexander Lamaison
Bjorn Reese
Michael Powell
TONGARI J