Delegating to boost::function with arbitrary signature
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<result_type(arg1_type, arg2_type)> 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)
2013/12/14 Alexander Lamaison <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<result_type(arg1_type, arg2_type)> 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?
TONGARI J <tongari95@gmail.com> writes:
2013/12/14 Alexander Lamaison <span dir="ltr"><mailto:awl03@doc.ic.ac.uk></span> 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<result_type(arg1_type, arg2_type)> 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)
2013/12/15 Alexander Lamaison <awl03@doc.ic.ac.uk>
TONGARI J <tongari95@gmail.com> writes:
2013/12/14 Alexander Lamaison <span dir="ltr"><mailto: awl03@doc.ic.ac.uk></span> 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<result_type(arg1_type, arg2_type)> 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
On Sat, Dec 14, 2013 at 10:53 AM, TONGARI J <tongari95@gmail.com> wrote:
2013/12/15 Alexander Lamaison <awl03@doc.ic.ac.uk>
TONGARI J <tongari95@gmail.com> writes:
2013/12/14 Alexander Lamaison <span dir="ltr"><mailto:awl03@doc.ic.ac.uk></span> 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<result_type(arg1_type, arg2_type)> 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
TONGARI J <tongari95@gmail.com> writes:
2013/12/15 Alexander Lamaison <span dir="ltr"><mailto:awl03@doc.ic.ac.uk></span> TONGARI J <mailto:tongari95@gmail.com> writes:
2013/12/14 Alexander Lamaison <span dir="ltr"><mailto:mailto:awl03@doc.ic.ac.uk></span> 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<result_type(arg1_type, arg2_type)> 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)
2013/12/16 Alexander Lamaison <awl03@doc.ic.ac.uk>
TONGARI J <tongari95@gmail.com> 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.
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...
On Sat, Dec 14, 2013 at 9:25 AM, Bjorn Reese <breese@mail1.stofanet.dk> 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
Michael Powell <mwpowellhtx@gmail.com> writes:
On Sat, Dec 14, 2013 at 9:25 AM, Bjorn Reese <breese@mail1.stofanet.dk> 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)
participants (4)
-
Alexander Lamaison -
Bjorn Reese -
Michael Powell -
TONGARI J