[boost] Re: Extend numeric_limits<> integer traits?

From: Beman Dawes (beman_at_[hidden])
Date: 1999-08-06 13:25:03

At 12:24 PM 8/6/99 -0500, Ed Brey wrote:

>Email seemed somewhat boring, until Valentin Bonnard wrote:
>>
>>Beman Dawes wrote:
>[...]
>>> Now the 64-bit question:
>>
>>I would go as a far as 128 bits.
>
>My suspecion is that Beman's "64-bit question" is not a reference to
>any current or future computer archetecture, but rather an
>ever-so-clever reference to the "$64000 question" TV show that was
>popular in the US long before I was born.  The idea stuck so well
that
>the term "$64000 question" is basically now a metaphore for any
>important question.

Ed's right.  It was a (stupid) word play, not a proposal to add bits.
 Although the question of whether boost should include support for
"long long" is certainly a valid question.

>>>    Is it worthwhile for boost to supply an
extended_numeric_limits<>
>>> class?
>>> 
>>> To me, it seems more trouble that it is worth.  What do others
think?
>
>It seems to me that
boost::extended_numeric_limits<type>::constant_max is
>an aweful lot of typing.  What do others think about calling the
class
>simply boost::numeric_limits?

Sounds OK to me.  Assuming boost::numeric_limits just extends
std::numeric_limits without changing its existing functionality.

>This is a general issue.  If boost wishes to extend the
functionality of
>a std class, is it appropriate to place an identically named class
in
>the boost namespace?  I think this would be fine, so long as it is
>understand that in the boost namespace one finds the "boost version
of
>the class", which is extended and (optionally?) backward-compatible
with
>the std (or other) class.

Using the same name for something as the standard probably always
adds some potential for confusion.  So I would have to feel the
benefit was great enough to justify that cost.

Another way to look at it is to say, if we were the standard
committee and were revising the standard, would we (1) add the
feature to the existing class, (2) provide an adapter class, or (3)
provide a whole new class.  If the answer is (1) then
namespace::boost adding the feature to an extended class of the same
name makes more sense than in the (2) or (3) cases.

--Beman