Update of the (not yet officially proposed) Function Types library
Dear Boost community, after three complete rewrites and numerous steps of incremental refinement (some of it based on feedback from you) I am proud to hereby present my attempt to provide a "truely boostish" metaprogramming facility to work with function-, function reference - and (member) function pointer types. The functional range includes: - type classification ("is T a * function ?") - type decomposition (e.g. "what is the result of the function T describes ?") - type synthesis ("create a * function with these subtypes !") All of the above work with variadic functions and (configuration dependent) with arbitrary calling conventions. Common applications are: - generating callbacks (the most prominent special case of this is argument binding) - extracting meta infromation from function prototypes - concept checking (e.g. "let's see if this is a setter/getter pair...") - systematic overload selection See the Documentation for further information. [ -> http://tinyurl.com/4fw9n ] A downloadable archive has been put into the vault. [ -> http://tinyurl.com/4oe7q ] Its quality has improved by an order of magnitude since my first naive attempts, last year - and not at least because of those of you who helped. Thank you ! I decided to use the next couple of days for finalizing refinement and to wait for some more feedback to confirm or disprove my suspicion that the submission is "review ready", before sending out a formal request. Regards, Tobias
The first thing I want to tell you about "Function Types" library is that I like it a lot. But I have small feature request: I would to like to be able to create signalN and functionN using your library. For Example: is_same< function_type_parameters< void(int,float) >::signal_type, signal2<void, int, float>
AFAIK, Creation of signal and function in preffered form is already possible. E.g. signal<function_type_signature<my_function> >. P.S. There is small typo in Classification section: there is no comma between typename Tag and typename T of template is_function_type.
Pavel Chikulaev wrote:
The first thing I want to tell you about "Function Types" library is that I like it a lot.
But I have small feature request:
I would to like to be able to create signalN and functionN using your library. For Example:
is_same< function_type_parameters< void(int,float) >::signal_type, signal2<void, int, float>
It is possible already: Do you know mpl::unpack_args [ http://tinyurl.com/6a64h ] ?? The Function Types library is a rather low-level facility and it may be used to implement libraries such as Boost.Signal in the future. This is why I avoid any direct coupling to higher-level facilities.
AFAIK, Creation of signal and function in preffered form is already possible. E.g. signal<function_type_signature<my_function> >.
IIRC there is no version of signal taking an MPL-Sequence. 'signal<my_function>' should work, though.
P.S. There is small typo in Classification section: there is no comma between typename Tag and typename T of template is_function_type.
Right, thanks! Regards, Tobias
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:d0rs1h$22j$1@sea.gmane.org...
is_same< function_type_parameters< void(int,float) >::signal_type, signal2<void, int, float> It is possible already: No. You can unpack arguments, but you can't choose signal2 or signal3 and so on.
IIRC there is no version of signal taking an MPL-Sequence. 'signal<my_function>' should work, though.
I meant a bit another thing. //From your examples: typedef void my_function(int); typedef function_type_signature<my_function> my_signature; typedef mpl::push_back<my_signature,float>::type my_modified_signature; boost::signal<my_modified_signature::representee>. == boost::signal<void (int, float)> //You can't do the same for signalN!!!!! -- Pavel Chikulaev
Pavel Chikulaev wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:d0rs1h$22j$1@sea.gmane.org...
is_same< function_type_parameters< void(int,float) >::signal_type, signal2<void, int, float>
It is possible already:
No. You can unpack arguments, but you can't choose signal2 or signal3 and so on.
You're right - unpack_args won't help, here. OK, then let's say: signal< function_type<plain_function,Seq>::type >
IIRC there is no version of signal taking an MPL-Sequence. 'signal<my_function>' should work, though.
I meant a bit another thing.
//From your examples: typedef void my_function(int);
typedef function_type_signature<my_function> my_signature;
typedef mpl::push_back<my_signature,float>::type my_modified_signature;
boost::signal<my_modified_signature::representee>. == boost::signal<void (int, float)> ^^^ This is invalid code and not part of my example (can't compare types with '==').
//You can't do the same for signalN!!!!!
I already explained why, in my previous post! Regards, Tobias
"Tobias Schwinger" wrote in message news:d0sc04$l6l$2@sea.gmane.org...
boost::signal<my_modified_signature::representee>. == boost::signal<void (int, float)> ^^^ This is invalid code and not part of my example (can't compare types with '=='). I know. I felt to lazy to write BOOST_MPL_ASSERT and is_same.
-- Pavel Chikulaev
"Tobias Schwinger" wrote in message news:d0sc04$l6l$2@sea.gmane.org...
boost::signal<my_modified_signature::representee>. == boost::signal<void (int, float)> ^^^ This is invalid code and not part of my example (can't compare types with '=='). I know. I felt to lazy to write BOOST_MPL_ASSERT and is_same.
-- Pavel Chikulaev
Pavel Chikulaev wrote:
"Tobias Schwinger" wrote in message news:d0sc04$l6l$2@sea.gmane.org...
boost::signal<my_modified_signature::representee>. == boost::signal<void (int, float)>
^^^ This is invalid code and not part of my example (can't compare types with '==').
^^^ Yeah, this sounds pretty harsh, again. I'm sorry !
I know. I felt to lazy to write BOOST_MPL_ASSERT and is_same.
I figured you probably do. I did not mean to pick on you !!! Regards, Tobias
participants (2)
-
Pavel Chikulaev -
Tobias Schwinger