Re: [boost] [xint] Third release is ready, requesting preliminary review

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-03 15:48:50

----- Original Message ----- 
From: "Chad Nelson" <chad.thecomfychair_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, May 03, 2010 8:04 PM
Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 05/03/2010 01:39 PM, vicente.botet wrote:
> 
>>>> The std::numeric_limits specialization defines functions that
>>>> return 0 with a comment
>>>>
>>>> 00298 namespace std {
>>>> 00299 template<>
>>>> 00300 class numeric_limits<boost::xint::integer> {
>>>> 00301     public:
>>>> 00302     static const bool is_specialized = true;
>>>> 00303 
>>>> 00304     static boost::xint::integer min() throw() { return 0; } // Not applicable
>>>> 00305     static boost::xint::integer max() throw() { return 0; } // Not applicable
>>>>
>>>> If a value can not be given, shouldn't these be undefined?
>>>
>>> If they weren't defined, could generic code work with them? The GCC
>>> specialization for the int type includes all of the members, even the
>>> ones that are only applicable to floating-point values, so I did too.
>> 
>> How generic code could work if the returned values are not 
>> applicable, not significant. I would prefer a compile error than a
>> runtime error.
> 
> if (numeric_limits<T>::is_bounded) {
>    // do something using max() and min()
> }
> 
> That wouldn't even compile if definitions of max and min weren't
> provided, even though it's perfectly legal and useful.

Yes,  I missed the is_bounded detail. I understand now.
 
>>>> xint::integer is a signed integer. It is worth having an
>>>> unsigned integer xint::uinteger? If not why?
>>> 
>>> I'd say the question is why have one, rather than why not. :-)
>> 
>> Well imagine you have decimal numbers. You can define any integer
>> using decimal number with 0 decimal digits. Does this means that you
>> don't need a integer type?
> 
> Depends on the case. If floating-point numbers were just as fast and
> efficient as integers, you might not. I've seen at least one programming
> language where every number is a floating-point one, at least
> potentially (I don't recall which one though... possibly Common Lisp,
> which I haven't looked at in a long time).

We are in C++.
 
>>> There are only two advantages I know of to unsigned int over int:
>>> you never have to check whether it's negative, and you get one
>>> extra bit's worth of room, allowing you to work with larger
>>> numbers. The second isn't a problem here, and the first can easily
>>> be dealt with. Is there a use case where a signed integer wouldn't
>>> be sufficient?
>> 
>> Well if in my application the domain type is unsigned by nature, I
>> don't see why I will define it as signed one if I can avoid it.
> 
> Because programmer time is a finite resource. Provide a good use case
> for an unsigned large-integer and I'll add one, otherwise I'd rather
> spend my limited time on more important things.

I was trying to find possible holes on the library. I have too other more important things to do.

Vicente