Re: [boost] string_algo review part 3

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-25 08:42:58

On Sat, Oct 25, 2003 at 01:07:07PM +0100, John Maddock wrote:
> 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?

They are not documented and in detail directory, so I did nit considered them
to be used for a general usage.
This yes/no type is very important, I wonder why it is not on some common place.
AFAIR, there has been discussed that it has to be done. 
If type_traits one is considered to be standard,  can easily switch to it.

> 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;

Added to fix list.

> 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.

I have not done anything regarding the portability issues yet. This will
be one of issues after the library gets accepted.

Thanks for hints.

> 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.
> 

Thanks for your review comments.

Pavol.