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
>the term "$64000 question" is basically now a metaphore for any
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
>>> To me, it seems more trouble that it is worth. What do others
>It seems to me that
>an aweful lot of typing. What do others think about calling the
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
>a std class, is it appropriate to place an identically named class
>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
>the class", which is extended and (optionally?) backward-compatible
>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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk