Re: [Boost-users] size_type doubts / integer library..

From: dizzy (dizzy_at_[hidden])
Date: 2008-08-18 11:03:11

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