----- Original Message ----- From: "Chad Nelson" <chad.thecomfychair@gmail.com> To: <boost@lists.boost.org> 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