[type_traits] function_pointer_traits extension
I'll continue this discussion (previously in private email) on the boost mailinglist, in order to allow others to join in. Any critiques (i.e. having a look at the (comparatively small) submission and dropping me a couple of lines) are still very welcome, in fact ! Alexander Nasonov wrote:
[... char array in struct as sizer for type classification via overload resultion ...]
Good point. This will be changed. By the way: the same hack is in the current boost release [boost/type_tratis/function_traits.hpp:177].
This has been changed [ref. 5.3.3].
// tester returns a reference to an array template< /* ... */ > char (& tester( /* ... */ ) ) [size];
This would have been my personal preference. Unfortunately this causes bcc to fail with an 'Internal compiler error'.
or making it a meta-function
template<std::size_t Size> struct sized_type { typedef char (&type)[Size]; };
and using typename sized_type<Size>::type in place of sized_type<Size>.
This is the current, but not necessarily the best implementation. Comments ?
I believe this could be a common issue - for that matter: What about a type synthesizer like 'type_with_size<size_t>::type' or a 'BOOST_TYPE_WITH_SIZE(n)' macro ? Or even: BOOST_SIZED_RESULT_TYPE_OVERLOAD_PROTO(template_args,function_args,size_expression). Is there something like this in boost somewhere, already ?
The example compiles fine on g++ 3.2.2, g++ 3.4.0 and Intel 8.0 under linux. I didn't check that BOOST_STATIC_ASSERT covers all cases but non-empty output looks suspicious for metaprogramming library ;-)
The static assertion just aids keeping the errors where they belong. If it doesn't work there is a more obscure error message and one has to read the manual for proper usage.
The documentation has been updated (Intel 8.0 is listed as tested and your work has been acknowledgeded).
I appreciate your efforts in boostifying function traits. Keep doing!
I sure will !
Thanks a lot for your work, ideas and the very nice mail - despite the fact of having no time, that is !
Have you considered wrapping function signature into mpl sequence?
Currently function_signature<T>::type is an mpl::vector and therefore a model of sequence. I believe I don't understand you correctly. In general, I aim to keep it as 'pure' as possible, so any conveniene feature should outweigh its cost in terms of code complexity , compilation time and maintainability. Tobias
Tobias Schwinger <tschwinger@neoscientists.org> writes:
I'll continue this discussion (previously in private email) on the boost mailinglist, in order to allow others to join in.
Any critiques (i.e. having a look at the (comparatively small) submission and dropping me a couple of lines) are still very welcome, in fact !
Alexander Nasonov wrote:
[... char array in struct as sizer for type classification via overload resultion ...]
Good point. This will be changed. By the way: the same hack is in the current boost release [boost/type_tratis/function_traits.hpp:177].
This has been changed [ref. 5.3.3].
// tester returns a reference to an array template< /* ... */ > char (& tester( /* ... */ ) ) [size];
This would have been my personal preference. Unfortunately this causes bcc to fail with an 'Internal compiler error'.
Just use an external template template< /* ... */ > typename char_array<size>::type tester( /* ... */ ); (See boost/python/detail/char_array.hpp)
or making it a meta-function
template<std::size_t Size> struct sized_type { typedef char (&type)[Size]; };
and using typename sized_type<Size>::type in place of sized_type<Size>.
This is the current, but not necessarily the best implementation. Comments ?
Whoops! That's basically what I did. If you need to represent zero it has to change slightly.
I believe this could be a common issue - for that matter:
What about a type synthesizer like 'type_with_size<size_t>::type' or a BOOST_TYPE_WITH_SIZE(n)' macro ? Or even: BOOST_SIZED_RESULT_TYPE_OVERLOAD_PROTO(template_args,function_args,size_expression).
Is there something like this in boost somewhere, already ?
See above.
I sure will !
Thanks a lot for your work, ideas and the very nice mail - despite the fact of having no time, that is !
Have you considered wrapping function signature into mpl sequence?
Currently function_signature<T>::type is an mpl::vector and therefore a model of sequence.
Have you seen boost/python/detail/signature.hpp? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
(See boost/python/detail/char_array.hpp)
It was exactly the same technique, which started the discussion in the first place (maybe I compressed the previous discussion to hard). Alexander stated correctly, that the size of the surrounding class must not necessarily match the size of the member padding it. [ref. 5.3.3 (sizeof)] [...] When applied to a class the result is the number of bytes in an object of that class including any padding required for placing objects of that type in an array.[...] This implicitly allows an optimizing compiler to blow up struct char_array's size up to the next power of two so array-dereference can be implemented with bit shifting operations, for example. Probably there is no compiler doing things like this so this might be hairsplitting. However, boost policy says that the code shall conform to the standard so I changed my implementation to use a metafunction returning a reference to an array, instead:
template<std::size_t Size> struct sized_type { typedef char (&type)[Size]; };
Whoops! That's basically what I did. If you need to represent zero it has to change slightly.
[ ref. http://groups.yahoo.com/group/boost/files/function_pointer_traits.zip //<root>/boost/type_traits/detail/func_ptr_classify.hpp ] (^^^^^ contains a 'translation of the problem by one byte' to map zero values, too ;+).
I believe this could be a common issue - for that matter:
What about a type synthesizer like 'type_with_size<size_t>::type' or a BOOST_TYPE_WITH_SIZE(n)' macro ? Or even: BOOST_SIZED_RESULT_TYPE_OVERLOAD_PROTO(template_args,function_args,size_expression).
Is there something like this in boost somewhere, already ?
See above.
Since I am at building a contribution to the type_traits library anyway, the idea behind it was to just add a 'type_with_size' type synthesizing trait to have this in a central place, so not every library has to provide its own somewhere in detail namespaces.
Have you considered wrapping function signature into mpl sequence?
Currently function_signature<T>::type is an mpl::vector and therefore a model of sequence.
Have you seen boost/python/detail/signature.hpp?
Honestly I haven't, before now - thanks for pointing me out. I like the idea of not having to depend upon partial specialization of class templates. On the other hand it bans type computation to function templates unless having 'typeof'. How can something like this fit into a generalized facility ? [ ref. design discussion in function_pointer_traits.zip //<root>/doc/function_pointer_traits.html ] I am still not sure I got the original point, though. I assume the implicit conversion from 'mpl::list' to 'mpl::vector' is a typo in the comments, since the generator code just returns an 'mpl::list'. Looks like it has changed from 'mpl::vector' to 'mpl::list' at some point... Coosing an 'mpl::vector' in my case was primarily because of flat random access complexity, but somewhat arbitrary. Probably using mpl::list instead would be better in my case, too ? Best regards, Tobias
Tobias Schwinger <tschwinger@neoscientists.org> writes:
David Abrahams wrote:
(See boost/python/detail/char_array.hpp)
It was exactly the same technique, which started the discussion in the first place (maybe I compressed the previous discussion to hard).
No. You're misreading my code. Its char_array's nested ::type member is a reference to a char array. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
No. You're misreading my code. Its char_array's nested ::type member is a reference to a char array.
I don't think so ;+). [ http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/python/detail/char_a... ] Revision: *1.2*, /Fri Aug 20 11:09:16 2004 UTC/ (11 days, 9 hours ago) does *not* contain *any* nested type members... Am I looking in the wrong place / at the wrong version ? Where sould I have looked instead ?
Tobias Schwinger <tschwinger@neoscientists.org> writes:
David Abrahams wrote:
No. You're misreading my code. Its char_array's nested ::type member is a reference to a char array.
I don't think so ;+).
[ http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/python/detail/char_a... ]
Revision: *1.2*, /Fri Aug 20 11:09:16 2004 UTC/ (11 days, 9 hours ago) does *not* contain *any* nested type members...
Am I looking in the wrong place / at the wrong version ? Where sould I have looked instead ?
<blush> Can't believe I made that error. I've been complaining about people making the same sort of mistake for some time. </blush> That said, it appears that char_array isn't used anywhere. I guess I should remove it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u3c23gdsp.fsf@boost-consulting.com...
<blush> Can't believe I made that error. I've been complaining about people making the same sort of mistake for some time. </blush>
Hi Dave, I wrote and documented this little utility some time ago but put it on the back burner: http://tinyurl.com/3vjwf. It's a generalization of type_traits::yes_type/no_type which handles arbitrarily many cases with a user-friendly interface. Any interest? Jonathan
participants (3)
-
David Abrahams -
Jonathan Turkanis -
Tobias Schwinger