boost.type_traits - is_convertible issue with aligned types
Hi,
consider the following simple example
struct aligned_type {
__declspec(align(16)) float vals[4];
};
BOOST_STATIC_ASSERT((boost::is_convertible
A bug database search did not bring up any relevant matches, so I wonder if that is a new issue or just by design?
It's more a limitation of the current design - if the "To" template parameter is a type which can not be used as a function parameter (which is the case here), then the implementation won't compile - we can work around std conforming types that fall into that category, but not compiler specific extensions which have strange properties! Switching to the implementation to use the __is_convertible builtin fixes this issue BTW, but unfortunately causes other issue... HTH, John.
It's more a limitation of the current design - if the "To" template parameter is a type which can not be used as a function parameter (which is the case here)
It cannot be passed by value, but i'm quite confident that it could be passed by (const) reference.
Switching to the implementation to use the __is_convertible builtin fixes this issue BTW, but unfortunately causes other issue...
Are you talking about switching the library implementation, or calling __is_convertible from user coder? The latter option is problematic, since my problem arises inside transform iterator: We frequently access members of structs by selecting them through a transform iterator. If, however, that member has alignment, the is_convertible metafunction called by transform iterator internals breaks.
It's more a limitation of the current design - if the "To" template parameter is a type which can not be used as a function parameter (which is the case here)
It cannot be passed by value, but i'm quite confident that it could be passed by (const) reference.
OK, but I'm not sure if that change would break the implementation or not... will investigate.
Switching to the implementation to use the __is_convertible builtin fixes this issue BTW, but unfortunately causes other issue...
Are you talking about switching the library implementation,
Yes, I'm talking about switching the implementation - it's probably something we should do at some point, but it means a breaking change from TR1/Boost behaviour to C++0x behaviour. John.
OK, but I'm not sure if that change would break the implementation or not... will investigate.
Thanks.
Yes, I'm talking about switching the implementation - it's probably something we should do at some point, but it means a breaking change from TR1/Boost behaviour to C++0x behaviour.
Do you think it is feasible to patch my boost distribution locally so it uses the intrinsic? If so, do you have a patch at hands?
If so, do you have a patch at hands?
I think i did figure it out myself. Something along the lines of
(removed preprocessor directives for brevity)
template
Yes, I'm talking about switching the implementation - it's probably something we should do at some point, but it means a breaking change from TR1/Boost behaviour to C++0x behaviour.
Do you think it is feasible to patch my boost distribution locally so it uses the intrinsic? If so, do you have a patch at hands?
Yes: if you look at the MSVC section in the intrinsics.hpp header you'll see __is_convertible usage commented out, just re-enable it and let us know how you get on ;-) HTH, John.
On Wed, Jan 19, 2011 at 10:36 AM, John Maddock
Yes: if you look at the MSVC section in the intrinsics.hpp header you'll see __is_convertible usage commented out, just re-enable it and let us know how you get on ;-)
Thanks John, that worked. I needed to add an include to typetraits/add_reference inside iterator_adaptor, because that one is required but not included by iterator_adaptor directly. Until now it was indirectly included through the inclusion of typetraits/is_convertible. Best regards, Christoph
participants (2)
-
Christoph Heindl -
John Maddock