
Hi Goran,
There are a few choices here: 1) BOOST_TYPEOF_REGISTER_TYPE(wstring); 2) BOOST_TYPEOF_REGISTER_TYPE(wchar_t); BOOST_TYPEOF_REGISTER_TEMPLATE(std::basic_string, 1); 3) BOOST_TYPEOF_REGISTER_TYPE(wchar_t); BOOST_TYPEOF_REGISTER_TEMPLATE(std::basic_string, 3); BOOST_TYPEOF_REGISTER_TEMPLATE(std::char_traits, 1); BOOST_TYPEOF_REGISTER_TEMPLATE(std::allocator, 1); Pre-registration of STL types would be a very nice addition to the library. For now I am avoiding this, and trying to focus on the facility itself.
This is much more complicated problem, and I am not sure it can be resolved... The problem is that you can't specialize (or overload) on a nested types. The Standard clearly says that this is a non-deducible context. So we can't do something like: template<class V, class T> encode_type<V, T::iterator>{}; // compiler error! This is VERY unfortunate, and I 've been trying to think of workarounds, but so far I only came up with one that is quite limited and ugly... So I decided to put this on hold. Regards, Arkadiy

Arkadiy Vertleyb wrote:
Can enable_if help you? template<class V, class T, class Enabled = void> struct encode_type; template<class V, class T> struct encode_type<V, T, typename enable_if<has_iterator<T> >::type> { typedef typename T::iterator this_is_what_you_need; }; -- Alexander Nasonov

"Alexander Nasonov" <alnsn@yandex.ru> wrote in message
I think this is a specialization for a container that has an iterator rather for the iterator itself. And any similar specialization for an _iterator_, that I can think about, would not have information about the container type :( The workaround I was talking about was to extract the value_type from the iterator, and using it bring the type into deducible context, but this only works for the simplest container types (only parameterized with value_type). Regards, Arkadiy
participants (2)
-
Alexander Nasonov
-
Arkadiy Vertleyb