On Monday 18 August 2008 18:29:27 Zeljko Vrba wrote:
On Mon, Aug 18, 2008 at 06:03:11PM +0300, dizzy wrote:
It can work perfectly, there are only two cases: - a < 0 : true, done, no need for conversion - a >= 0 : ordinary unsigned comparison
Well that still is a too much cost for some people. You just transformed a single CPU comparison of a < b to 2 comparison instructions. People who made sure that "a" is always positive in their program do not want to pay for the price of doing one more comparison for those who didn't.
Well, then they get to cast their signed number to unsigned: (unsigned)a < b, problem solved.
Then I'm out of my arguments (for the case of comparison alone, there are other cases where such conversions are also performed where more problems need to be solved than the additional compare operation). If I were to decide how to do it I would have decided as you suggested since it seems the least error prone for the user. I'm sure however that there were other reasons that made it be this way and I don't think they are arbitrary. Maybe someone more knowledgeable can comment. I also do not consider this little feature something so important that because it doesn't do as we see it best then we can say the language integer types are broken.
It's not about trust - it's about being unable to detect invalid input.
And how does current C++ makes it impossible to detect invalid input?
So you make your new Integer class a POD. But then how do you enable implicit conversions (for most of the operator overloads sure you can overload them non-member).
PODs can have member functions, at least if I interpret this correctly: http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/ISOcxx/doc/POD.html
By that URL: The term POD class types collectively refers to aggregate classes (POD-struct types)... And then it says: The term aggregate refers to an array or class that has none of the following characteristics [§8.5.1, ¶1]: user-declared constructors, And since a ctor used for conversion is such a user declared ctor then you can't have it POD anymore. Either if you don't want implicit conversion with a ctor you still need your own ctors taking integer values or other integer types (with other ranges) and that makes it not a POD anymore right?
That's how CPUs were made, they don't make much sense in strict mathematical arithmetic but they make a lot of sense in binary mode arithmetic.
CPUs provide various simple means to detect anomalous conditions. C++ does not.
Yes it would have been nice to know portably an arithmetic operation has overflowed that results in fast CPU code checking for some flag. But I am not sure if this is possible for all CPUs that C++ is supposed to run on or how useful would be. -- Dizzy "Linux is obsolete" -- AST