[boost] string_algo review part 3

From: John Maddock (john_at_[hidden])
Date: 2003-10-25 07:07:07

I have some minor quibbles with the code based on the result of running the
regression tests:

yes_type / no_type are messing up MSVC 6 for some reason - can you migrate
to type_traits::yes_type/no_type instead?

In container_traits the second and third typenames are not required (in fact
they are actually forbidden here, but only a few compilers complain, Borland
being one):

typedef BOOST_STRING_TYPENAME ::boost::mpl::apply_if<
::boost::string_algo::detail::is_pair<T>,
detail::pair_container_traits_selector<T>,
/*BOOST_STRING_TYPENAME*/ ::boost::mpl::apply_if<
::boost::is_array<T>,
detail::array_container_traits_selector<T>,
/*BOOST_STRING_TYPENAME*/ ::boost::mpl::apply_if<
::boost::is_pointer<T>,
detail::pointer_container_traits_selector<T>,
detail::default_container_traits_selector<T>
>
>
>::type container_helper_type;

There are also a number of places where typename is followed by :: which
messes up the Borland compiler, for example:

                typedef BOOST_STRING_TYPENAME ::boost::detail::
                    iterator_traits<element_type>::value_type value_type;

As a workaround removing the leading :: in these specific cases fixes the
problem.

Conclusions:
~~~~~~~~

Subject to the issues raised being addressed, I vote "yes" to acceptance of
this library - it meets an obvious need, and the design appears to be
satisfactorily.  My one reservation is the size of the library, and the fact
that there are often many different ways of accomplishing the same task -
however only testing "in the wild" will determine whether that is an issue
or not in practice.

John.