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

From: Andrea Denzler (andrea_at_[hidden])
Date: 2008-08-17 13:43:14

Actually the compiler issue a warning if you convert something that will
create an overflow (like unsigned int to signed int). When there is no
overflow you will get no warning (like unsigned char to signed int).
Avoid such warnings writing your own conversion code (see assert below).
What else can the compiler do since the value to convert is unknown (unless
you have a const).

To get an assert on integer overflow at runtime you must write your own
integer class, handling the conversion from all integral types (modern CPUs
doesn't offer interrupts on integer overflow). You will have an overhead of
course, but it can be minimized very well using assembler instructions.

The operators < and > works well mathematically. The problem with -1U < 2 is
that you are going to have an overflow because you are converting -1 to
unsigned. This happens before the operator is applied (it require both value
of the same type).

-----Messaggio originale-----
Da: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] Per conto di Michiel
Helvensteijn
Inviato: domenica 17 agosto 2008 19.13
A: boost-users_at_[hidden]
Oggetto: Re: [Boost-users] size_type doubts / integer library..

Zeljko Vrba wrote:

> Actually, I think I could simplify my requirements a bit:

I strongly agree with your proposal, and pretty much everything in your
post.

I would also like the possibility to explicitly state the lower- and
upper-bound in the type and the possibility to use a dynamic integer
(without any bounds), should the need arise.

In my opinion, the ideal solution would be to have only one int type in the
language, which would conceptually have no bounds. Convenient sub-types
(like uint) would be defined which would enforce type-invariants (like:
value >= 0). The programmer may also define his own sub-types. All
int-types would be compatible, however, and behave correctly in a
mathematical sense. If an operation between two integers overflows, an
assertion failure would arise.

This is clearly not possible for C++. But I'm designing a programming
language where integers work this way. The hope is that the bounds of a
plain int may be found (formally proved) at compile-time, so it can be
cleanly mapped to a hardware-int without any runtime overhead. If the
programmer specifies bounds, they are either proved correct at compile-time
or enforced at run-time. In all other cases, a dynamic int is used. This
should completely eliminate unexpected runtime overflow.

I'm also thinking of making int itself a subtype of a bit-array, which would
take care of bit-shift operations. But I'm not really sure how that would
work yet for all integers, since I would like to make the behavior hardware
independent and predictable.

-- 
Michiel Helvensteijn
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users