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