From: Daryle Walker (darylew_at_[hidden])
Date: 2001-02-21 14:45:34
on 2/20/01 3:36 PM, Howard Hinnant at hinnant_at_[hidden] wrote:
> Daryle Walker wrote on 2/20/01 2:48 PM
>> The "char" type is supposed to be like either "signed char" or "unsigned
>> char," which one is implementation defined. Similarly, the "wchar_t" type
>> is supposed to be like one of the other integral types, which one is
>> implementation defined. Could we have some sort of structure indicating
>> those types' base types? I guess it would be something like:
>> How would we figure out the types? I guess something using <climits> macros
>> and/or comparisons from <limits> values would be used. What header would
>> this go under, "type_traits.hpp" or a new one?
> I'm sure this could be done with <climits> macros. But the following
> might be more fun! :-)
[SNIP big example with a bunch of old and hopeful class templates]
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) );
return static_cast< signed char >( static_cast<const T&>(*this) );
operator wchar_t() const
// The underlying type here is a complete guess. Help!
return static_cast< unsigned short >( static_cast<const T&>(*this) );
(It's from an upcoming version of the "operators.hpp" header.)
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.
> Seems like I've seen someone talk about a "integral best fit" lib that
> might simplify all the if'ing I'm doing in the wchar_t specialization,
> but alas I can't remember who or where.
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.
> After all that, this is not a comment on your first question of whether
> such a struct should be part of boost. It is simply a sample
If it's just for my quick needs above, it could just stay in that header. I
guess that someday someone else might need that information.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk