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 13:39:48

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

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 05/03/2010 12:42 PM, vicente.botet wrote:
> 
>> I have some question about the interface.
>> 
>> I know that these functions appears on N1744
>> bool getbit( intege r const &, size _t );
>> void setbit( intege r &, size_t );
>> void clearbit( integer &, size_ t );
>> 
>> But are these really necessary? A use case?
> 
> setbit can be used to create a large power-of-two more efficiently than
> a shift function -- that's what the pow2 convenience function uses. I
> haven't found a use for the other two, but I imagine that the use case
> for them was using a large integer as an unlimited-length bit field.

OK. I see.
 
>> 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.
 
>> Or should these functions return -infinity, infinity?
> 
> If I had such values, I'd use them there.
> 
>> 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?

> 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.

Vicente