Re: [boost] Re: [type_traits] function_pointer_traits extension

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2004-08-31 13:50:22

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