Re: [boost] Re: Traits for character underlying types

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-02-22 11:19:17

----- Original Message -----
From: "Daryle Walker" <darylew_at_[hidden]>
> I don't necessarily need something big & fun, maybe something quick &
dirty
> will do -_^.  This is what I have so far:
>
>
//=========================================================================
> template <class T, class B = ::boost::detail::empty_base>
> struct character_convertible : B
> {
>   operator char() const
>   {
> #if CHAR_MIN == 0
>     return static_cast< unsigned char >( static_cast<const T&>(*this) );
> #else
>     return static_cast< signed char >( static_cast<const T&>(*this) );
> #endif
>   }
>
> #ifndef BOOST_NO_INTRINSIC_WCHAR_T
>   operator wchar_t() const
>   {
>     // The underlying type here is a complete guess.  Help!
>     return static_cast< unsigned short >( static_cast<const T&>(*this) );
>   }
> #endif
> };
>
//=========================================================================
>
> (It's from an upcoming version of the "operators.hpp" header.)

Something that dirty is not going to be acceptable to me for operators.hpp.
What is the special motivation for wanting character convertibility, anyway?
What substantially large category of classes needs implicit conversion to
both char and wchar_t, with all the attendant ambiguities that come along
when you do that?

Daryle, I really appreciate the work you are doing on operators.hpp, but I
also think you are going to have to exercise more restraint if you want your
changes to be accepted. A class for implicit conversions to a particular
type seems to be very far outside the spirit of operators.hpp. Try being
conservative at first: propose a few incremental changes to what we already
have in the boost release. The smaller the change, the easier it will be to
review and accept. If you take it in steps, we may eventually incorporate
most of what you'd like to see into the library

> BTW, where does the BOOST_LONGLONG_SUPPORT come from?  I didn't see it in
> the latest "config.hpp" on CVS.  Is this also a wish?  For now, I #include
> <climits> and check if ULLONG_MAX and/or LLONG_MAX exist.

You may need to look for another (non-standard) macro, ULONG_LONG_MAX. See
integer_traits.hpp for an example.

> Could you be talking about the "/boost/integer.hpp" header, which lets an
> user pick the best integral type for a certain bit size?  I started that
> discussion for the CRC stuff.  I've thought of it, but I would have to
> somehow incorporate the signed/unsigned determination.

see boost/detail/numeric_traits.hpp for an implementation of is_signed<>

-Dave