From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2004-08-31 13:50:22
David Abrahams wrote:
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
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.
(^^^^^ 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 ?
>>Is there something like this in boost somewhere, already ?
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
On the other hand it bans type computation to function templates unless
How can something like this fit into a generalized facility ?
[ ref. design discussion in function_pointer_traits.zip
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 ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk