[boost] Re: concept archetypes

From: Kevin S. Van Horn (Kevin.VanHorn_at_[hidden])
Date: 2002-10-17 09:33:35

Anthony Williams writes:

> Peter Dimov writes:
>  > This means that the requirements are broken, not that there is
>  > something wrong with the code. The requirement should be "usable in
>  > boolean expressions and other contexts where a bool is required" and not
>  > "convertible to bool". I'm sure that this is the original intent.
>
> How does this differ from "must be bool"?

I believe that integer types, and possibly pointers, would satisfy the 
above definition. (Yes, "p && e" is legal if p is a pointer and e is a 
pointer, int, or bool.)

YEESH... I just realized that this issue extends pervasively throughout 
the entire standard library.  If T is the value type of an input iterator, 
and U is convertible to T, then it is NEVER safe to write

  f(*it)

because f might be overloaded on both U and T!  Nor is the static_cast<T> 
solution acceptable, as this requires that T be copy constructible (which 
is not required by many algorithms).  Hmmm.... How about this:

  f(convert<T>(*it))

where

  template <typename T>
  T const & convert(T const & x)
  {
    return x;
  }

  template <typename T>
  T & convert(T & x)
  {
    return x;
  }

  template <typename T, typename U>
  T convert(U const & x)
  {
    return x;
  }

This only requires T to be copy constructible if the iterator returns a U 
value.