Boost logo

Boost :

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


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:



  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

Boost list run by bdawes at, gregod at, cpdaniel at, john at