On Monday 18 August 2008 17:18:34 Zeljko Vrba wrote:
- it can promote both arguments to the signed integer type that supports all values of both (say long) and compare that; this may seem fine to you but it has the following problems: - it assumes there is a type that can represent both those values; we can clearly imagine that a and b might have been long and unsigned long in the beginning so that won't work; not to mention there is no guarantee that even
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.
program that something may be negative or not? That's actually _why_ I use unsigned types, to signal that it can't be negative from that moment on (ie
It can't be negative, but it can assume a meaningless, huge positive value.
So? It is the fault of the code that converted a negative value to a positive one if it did this and it's not of your matter where you have received unsigned types and working with them. Same as with references, it is the fault of the code that dereferenced an invalid pointer if it gave you an invalid reference but that does not mean your code cannot safely assume your reference is valid.
As the case is now with C++, "being positive" is a worthless constraint because "a-b" always results in a positive value,
Because you want it to do more than it does (and other people need it to do). If so you can add your own checks of course.
regardless of a < b or a > b. This syntactic constraint just gives a false sense of security, imho, at least when it is used the way you have just described (guarantee that something is positive).
Depends how do you define security, when you receive a reference are you feeling secure enough it points to a valid object or it may come as a result of dereferencing a null pointer and thus do you check the address of references? I hope not! And if not, then why do you trust references but do not trust other syntactic sugar like "unsigned"? Because I meant of using it to express positive value integers as syntactic sugar, obviously anyone can shoot himself in the foot with them if they want (and they should be able to if otherwise means to perform costly checks).
But you should make some more strict requirements then. You can't assume a negative value encoding (such as 2's complement) thus you should not allow bitwise operations affecting more than the bits forming the value, ie without the sign bit. Otherwise you (as the C++ standard) get "unspecified value".
OK, more food for thought. Though, I primarily target 2nd complement machines. If somebody needs support for other representation, he's welcome to contribute
Just make sure the library does not need redesign to add another negative value encoding and then of course whomever needs it can implement it himself (oh and also that you compile time error when such assumptions are violated).
struct Integer { int x ; }; Integer a;
the standard guarantees that (void*)&a == (void*)&a.x
Compiler will hopefully not insert any additional padding, so the result is in practice achieved.
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).
- that the arithmetic, as it is defined now, can be mathematically nonsensical
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.
- that the language definition does not give an option for well-defined arithmetic, either implemented in the compiler or as part of the standard library
Sure it can, the new Integer type you are doing is such an option. Where should the line be drawn between whatever other high level language features some users need and what the standard library provides? -- Dizzy "Linux is obsolete" -- AST