Preview of the Function Types library (function_traits replacement)
Dear Boosters, a preview of the Function Types library is available, now. [ Online documentation: http://tinyurl.com/4fw9n ] [ Downloadable archive: http://tinyurl.com/6u77y ] It is the third (nearly) complete rewrite and the design finally feels right for me. However, I am very curious to hear any of your opinions about it ! So, if you have been hoping for the retirement of function_traits, please take a few minutes to find out if this would suit your needs. Regards, Tobias
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:cvq3mh$o6$1@sea.gmane.org...
Dear Boosters,
a preview of the Function Types library is available, now.
[ Downloadable archive: http://tinyurl.com/6u77y ]
needs these patch (VC7.1)............... in function_type_result.hpp: namespace boost { //------------------------------------------------------------------------------ namespace function_types { namespace detail { template<typename S,typename K> struct result_impl : mpl::at_c< S, 0 > { }; ///////////////////////////////////////////////// // struct result_impl <S,no_function,I> /////////////////////////////////////// template<typename S> ///////// struct result_impl <no_function,S> { }; } in function_type_parameter.hpp: line 44 : //////////////////// // , typename detail::mask_fun_kind_attr ////////////// , typename detail::mask_func_kind_attr ////////// regards Andy Little
Andy Little wrote:
Thanks for the fixes ! The online version has been corrected. in function_type_result.hpp:
namespace boost { //------------------------------------------------------------------------------ namespace function_types { namespace detail { template<typename S,typename K> struct result_impl : mpl::at_c< S, 0 > { };
///////////////////////////////////////////////// // struct result_impl <S,no_function,I>
Yeah, this is wrong !
/////////////////////////////////////// template<typename S> ///////// struct result_impl <no_function,S>
Well, it should be <S,no_function> to work (this specialization is to keep the type member from being defined if used incorrectly with a non-function type, the other way around <no_function,S> doesn't keep things from working but doesn't do anything useful, either).
{ }; }
in function_type_parameter.hpp:
line 44 : //////////////////// // , typename detail::mask_fun_kind_attr ////////////// , typename detail::mask_func_kind_attr //////////
Agreed, here.
regards Andy Little
It shows me that I have to write more tests/examples, very soon... Regards, Tobias
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
It shows me that I have to write more tests/examples, very soon...
From what I have seen its very cool. :-)
How does this play with boost::result_of. Is there any potential to extend result_of by this? regards Andy Little
Andy Little wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
It shows me that I have to write more tests/examples, very soon...
From what I have seen its very cool. :-)
How does this play with boost::result_of. Is there any potential to extend result_of by this?
result_of should already get the right answers for these types. Jonathan
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cvvvpc$ipt$1@sea.gmane.org...
Andy Little wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
It shows me that I have to write more tests/examples, very soon...
From what I have seen its very cool. :-)
How does this play with boost::result_of. Is there any potential to extend result_of by this?
result_of should already get the right answers for these types.
#include <iostream> #include "boost/utility/result_of.hpp" // v 1.32.0 // BTW following requires #include "boost/function_types/function_type_parameter.hpp" #include "boost/function_types/function_type_result.hpp" typedef int f(int); int main() { // fails (Vc7.1, gcc3.2) // typedef boost::result_of<f>::type result_type; //succeeds(Vc7.1, gcc3.2) typedef boost::function_types::function_type_result< f >::type result_type; std::cout << typeid(result_type).name() <<'\n'; } regards Andy Little
Andy Little wrote:
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cvvvpc$ipt$1@sea.gmane.org...
Andy Little wrote:
From what I have seen its very cool. :-)
Glad you like it !
How does this play with boost::result_of. Is there any potential to extend result_of by this?
result_of should already get the right answers for these types.
There's a different intention behind result_of (as it detects the result of a Functor concept, given that functor classes have a result_type member. This library, in contrast, is about working with function types (making it work on functors would be in some ways similar to making remove_pointer work on smart pointers). This library (once it is in stable state) could be used to implement result_of, I believe.
#include <iostream> #include "boost/utility/result_of.hpp" // v 1.32.0
// BTW following requires #include "boost/function_types/function_type_parameter.hpp" #include "boost/function_types/function_type_result.hpp"
Oh nice, another typo. Fixed, now - thanks for detecting ! ( this line: using function_types::function_type_parameter; should be: using function_types::function_type_result; in function_type_result.hpp )
[...code...]
Assumed the bug above is fixed, this code should compile: #include <boost/mpl/assert.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/utility/result_of.hpp> #include <boost/function_types/function_type_result.hpp> typedef int (*f)(int); // result_of needs ref/ptr to function to work using namespace boost; BOOST_MPL_ASSERT((is_same< function_type_result<f>::type , result_of< f(int) >::type // see http://www.tinyurl.com/6a87k
));
Regards, Tobias
Andy Little wrote:
"Jonathan Turkanis":
Andy Little wrote:
How does this play with boost::result_of. Is there any potential to extend result_of by this?
result_of should already get the right answers for these types.
#include <iostream> #include "boost/utility/result_of.hpp" // v 1.32.0
// BTW following requires #include "boost/function_types/function_type_parameter.hpp" #include "boost/function_types/function_type_result.hpp"
typedef int f(int); int main() { // fails (Vc7.1, gcc3.2) // typedef boost::result_of<f>::type result_type;
//succeeds(Vc7.1, gcc3.2) typedef boost::function_types::function_type_result< f >::type result_type; std::cout << typeid(result_type).name() <<'\n'; }
I was too quick to say that result_of works with all the types handled by funtion_types. It works with function pointers, function references and member function pointers, but not with pure function types. The reason is purely syntactic: a function type is not a legal return type. Why does this matter? Because the type expression passed to result_of must be of the form F(arg1, ..., argN). The correct way to use result_of with function pointers is as follows: #include <boost/static_assert.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/utility/result_of.hpp> typedef int (*f)(int); int main() { typedef boost::result_of<f(int)>::type result_type; BOOST_STATIC_ASSERT((boost::is_same<result_type, int>::value)); } Jonathan
"Jonathan Turkanis" <technews@kangaroologic.com> wrote
Because the type expression passed to result_of must be of the form F(arg1, ..., argN).
The correct way to use result_of with function pointers is as follows:
[original example snip] This also works : #include <boost/static_assert.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/utility/result_of.hpp> typedef int (*f)(int); // <-- no change int main() { typedef boost::result_of<f(double,bool,long,char,int)>::type result_type1; typedef boost::result_of<f()>::type result_type2; BOOST_STATIC_ASSERT((boost::is_same<result_type1, result_type2>::value)); } IOW the args are 'sugar' in the function pointer/ref case. regards Andy Little
Andy Little wrote:
This also works :
#include <boost/static_assert.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/utility/result_of.hpp>
typedef int (*f)(int); // <-- no change
int main() { typedef boost::result_of<f(double,bool,long,char,int)>::type result_type1; typedef boost::result_of<f()>::type result_type2; BOOST_STATIC_ASSERT((boost::is_same<result_type1, result_type2>::value)); }
IOW the args are 'sugar' in the function pointer/ref case.
Hmmm ... interesting. That seems to be what TR1 says. Do you know why this is? A compile-time error would seem to be more useful in this case. Jonathan
"Jonathan Turkanis" <technews@kangaroologic.com> wrote
Andy Little wrote:
IOW the args are 'sugar' in the function pointer/ref case.
Hmmm ... interesting. That seems to be what TR1 says. Do you know why this is?
Not really....but the only useful data to result_of in the function pointer typedef is the return type, while in the case of function-objects the arguments are potent. IOW where T is a function-pointer, T describes it completely ; whereas where T is a function-object, the T(a,b,c) syntax is essential. Therefore when T is a function-pointer, reference or straight function type result_of<T>::type would seem to me to be a valid invocation. regards Andy Little
Andy Little wrote:
"Jonathan Turkanis" <technews@kangaroologic.com> wrote
Andy Little wrote:
IOW the args are 'sugar' in the function pointer/ref case.
Hmmm ... interesting. That seems to be what TR1 says. Do you know why this is?
Not really....but the only useful data to result_of in the function pointer typedef is the return type, while in the case of function-objects the arguments are potent.
I realize this. I'm just saying that if someone has a unary function pointer type f and queries result_of<f(int, int)>::type she's probably making a mistake, and it would be useful for the compiler to let her know. (Of course the mistake will probably show up somewhere else too.)
IOW where T is a function-pointer, T describes it completely ; whereas where T is a function-object, the T(a,b,c) syntax is essential.
Therefore when T is a function-pointer, reference or straight function type result_of<T>::type would seem to me to be a valid invocation.
One of the main points (if not the main point) of result_of is to provide a uniform syntax, so you don't have to worry what sub category of callable objects you're dealing with.
regards Andy Little
Jonathan
Andy Little wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
It shows me that I have to write more tests/examples, very soon...
By the way, Andy, you seem to have played around quite a bit - if there is anything usable for examples I'ld be interested.
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote aplogies for tardy reply)
By the way, Andy, you seem to have played around quite a bit -
I'd like to say I have... but I have only done a couple of quick tests.
if there is anything usable for examples I'ld be interested.
I dont have anything that exciting I'm afraid. I would guess that this library is most useful for FP...synthesising Functors? but that isnt my strongest suit :-( regards Andy Little
Andy Little wrote:
aplogies for tardy reply)
By the way, Andy, you seem to have played around quite a bit - if there is anything usable for examples I'ld be interested.
I'd like to say I have... but I have only done a couple of quick tests.
Nevermind. I have written examples for every part of the interface, by now (see the message just posted about the update in this thread).
I dont have anything that exciting I'm afraid. I would guess that this library is most useful for FP...synthesising Functors? but that isnt my strongest suit :-(
As metaprogramming replaces external code generators there should be a facility to work with function types, right ? Currently there isn't - except function_traits, which is limited to only plain functions (no pointers, references, member function pointers), does not interoperate well with MPL and does only implement a subset of the features of this proposal. It is useful for all kinds of stuff such as call closures, smarter callback registration, concept checking, automatically generated interface descriptions... Currently most Boost libraries that need to work with function types do it their own way. This has the following disadvantages: a) It is tedious to implement in the first place. b) There is not support for variadic functions and non-default calling convetions for most of them. (*) c) These implementations depends on preprocessor unrolled cascades of partially specializing a template, which, when applied redundantly is a waste of compile time resources, because it involves quite some code. Which can be significant, especially when point b) is adressed properly. (*) This feature is planned but not implemented for the Function Types library, yet. The conclusion is a configurable global facility able to do this job once and for all. Nothing particulary interesting ;-) just a missing piece, that's all... Best, Tobias
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:cvsofs$c5i$1@sea.gmane.org...
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:cvq3mh$o6$1@sea.gmane.org...
Dear Boosters,
a preview of the Function Types library is available, now.
[ Downloadable archive: http://tinyurl.com/6u77y ]
needs these patch (VC7.1)...............
in function_type_result.hpp:
namespace boost { //------------------------------------------------------------------------------ namespace function_types { namespace detail { template<typename S,typename K> struct result_impl : mpl::at_c< S, 0 > { };
///////////////////////////////////////////////// // struct result_impl <S,no_function,I> /////////////////////////////////////// template<typename S> ///////// struct result_impl <no_function,S> { }; }
in function_type_parameter.hpp:
line 44 : //////////////////// // , typename detail::mask_fun_kind_attr ////////////// , typename detail::mask_func_kind_attr //////////
regards Andy Little
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tobias Schwinger wrote:
Dear Boosters,
a preview of the Function Types library is available, now.
[ Online documentation: http://tinyurl.com/4fw9n ] [ Downloadable archive: http://tinyurl.com/6u77y ]
It is the third (nearly) complete rewrite and the design finally feels right for me. However, I am very curious to hear any of your opinions about it !
So, if you have been hoping for the retirement of function_traits, please take a few minutes to find out if this would suit your needs.
Hi Tobias, Thanks for taking the time to implement this! I haven't had a chance yet to look at it carefully, but I will soon. Jonathan
Jonathan Turkanis wrote:
Tobias Schwinger wrote:
Dear Boosters,
a preview of the Function Types library is available, now.
[ Online documentation: http://tinyurl.com/4fw9n ] [ Downloadable archive: http://tinyurl.com/6u77y ]
It is the third (nearly) complete rewrite and the design finally feels right for me. However, I am very curious to hear any of your opinions about it !
So, if you have been hoping for the retirement of function_traits, please take a few minutes to find out if this would suit your needs.
Hi Tobias,
Thanks for taking the time to implement this!
I found Joel's complaints about function_traits (about two weeks ago) quite motivating to finally get its state straightened.
I haven't had a chance yet to look at it carefully, but I will soon.
I'm curious about it.... Tobias
Hello Boosters, the Function Types library has just been updated. A lot of bugs have been fixed (including those reported here) and there is an example suite, hyperlinked to the documentation and including Jamfiles (by the way: I am very curious to know any test results when using "officially unsupported" compilers (no need to try BCC or worse) - feel free to send me a formless email with compiler dump). Planned but not yet implemented is support for different calling conventions and variadic functions. Portability and testing will be extended and the documentation may need some refinement (english is only my secondary language, after all). Any help in form of pre-review inspection is very welcome ! Best, Tobias P.S.: It should be in "worthy state" for uploading to the vault, by now. If you find this is a good idea, please help me.
participants (3)
-
Andy Little -
Jonathan Turkanis -
Tobias Schwinger