Boost logo

Boost Users :

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

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net