From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 1999-08-09 09:56:40
Beman Dawes wrote:
> 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
> >important question.
> Ed's right. It was a (stupid) word play, not a proposal to add bits.
The term "$64000 question" wasn't part of my cultural background !
> Although the question of whether boost should include support for
> "long long" is certainly a valid question.
If we extend/replace/rewrite inttypes.h/numeric_limits, we
should certainly support long long if the implementation does.
A #define to know that would help.
> >>> Is it worthwhile for boost to supply an
> >>> class?
> >>> To me, it seems more trouble that it is worth. What do others
> >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
> >simply boost::numeric_limits?
> Sounds OK to me. Assuming boost::numeric_limits just extends
> std::numeric_limits without changing its existing functionality.
My xnumerical_limit class is limited to char, short, int, long,
eventually long long, and their unsigned and signed variants.
OTOH std::numerical_limit applies to every types.
xnumerical_limit isn't a general purpose replacement for
numerical_limit, just a small limited extention.
> Using the same name for something as the standard probably always
> adds some potential for confusion.
Please note that Dietmar did that in the heaps library.
-- Valentin Bonnard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk