Quote:Original post by someboddy

Quote:Original post by snk_kid

If your compiler doesn't have intrinsic support for is_pod then you're are suppose to (partially) specialize your user-defined types to state that they are POD-struct types.

How can I do that?

Just (partially) specialize boost::is_pod:

#include <boost/static_assert.hpp>#include <boost/type_traits/is_pod.hpp>struct my_pod_type {};template <>struct boost::is_pod<my_pod_type> : boost::true_type {};BOOST_STATIC_ASSERT((boost::is_pod<my_pod_type>::value));

There most probably is a macro to help write specialization boiler-plate code, just check the documentation.

You can do that but then... are you going to reimplement STL to use boost::type_traits?

Just write normal code and then see if the program is reasonably fast and what are the bottle-necks if any.

Quote:Original post by visitor
You can do that but then... are you going to reimplement STL to use boost::type_traits?

Just write normal code and then see if the program is reasonably fast and what are the bottle-necks if any.

I haven't read the entire thread so I don't know what you're talking about, standard library containers & algorithms are not typically based off of boost's type traits.

Besides, as I said already most modern compilers have compiler intrinsic support for type traits and use it for their library implementations so you don't need to worry about having to explicitly specialize code. Furthermore iterator categories are also used to specialize generic code to.

So if a compiler doesn't have intrinsic support they will still use iterator categories to use the most optimal implementation for example loops with random accessible iterators can be written to be more amenable to loop unrolling, as opposed to the generic itr != end pattern.

[Edited by - snk_kid on January 13, 2009 12:43:22 PM]