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