integer overflow detection would be a nice addition.

[Chris Becke]

I *know* my CPU has opcodes that can do this - when adding (or subtracting) there is a carry flag that can be invoked to make the result essentially 1 bit longer than the data size used in calculations.
When multiplying two numbers, the CPU automatically returns a double width result.

c & c++ give programmers these bloody ridiculous integer types of undetermined size and no really optimal way to even build a variable width number library without resorting to platform specific assembler code.

I know that c & c++ have built a lot of their success on the many many many CPUs other than x86 that they target, but really, this inability to write portable code that deals with large numbers relaibly (& quickly) is a bit of a pain.. And lets not forget the pre and post increment operators owe their existance to assembly language level features of the first CPU a c compiler was developed for (at least, so Ive been led to believe).

The 6502 processor in my Vic20 had these basic features more than 20 years ago. Its not like carry flags and double width multiplaction results are novel or new ideas.

/rant

[Pascal J. Bourguignon]

Re: integer overflow detection would be a nice addition.

"Chris Becke" <chris.becke@gm ail.comwrites:

I *know* my CPU has opcodes that can do this - when adding (or
subtracting) there is a carry flag that can be invoked to make the
result essentially 1 bit longer than the data size used in
calculations. When multiplying two numbers, the CPU automatically
returns a double width result.
>
c & c++ give programmers these bloody ridiculous integer types of
undetermined size and no really optimal way to even build a variable
width number library without resorting to platform specific
assembler code.
>
I know that c & c++ have built a lot of their success on the many
many many CPUs other than x86 that they target, but really, this
inability to write portable code that deals with large numbers
relaibly (& quickly) is a bit of a pain.. And lets not forget the
pre and post increment operators owe their existance to assembly
language level features of the first CPU a c compiler was developed
for (at least, so Ive been led to believe).
>
The 6502 processor in my Vic20 had these basic features more than 20
years ago. Its not like carry flags and double width multiplaction
results are novel or new ideas.
>
/rant

Basically, you've got two choices:

- use gmp or some other bignum library. With C++ operator overloading
this may even be pleasant.

- switch to Common Lisp: bignums are natively supported in all
implementations . Some implementations also support long-float,
where you can specify the size of the mantissa.


C/USER[35](! 100) ; factorial of 100.
933262154439441 526816992388562 667004907159682 643816214685929 638952175999932 299156089414639 761565182862536 979208272237582 511852109168640 000000000000000 00000000

--
__Pascal Bourguignon__

[Zeppe]

Re: integer overflow detection would be a nice addition.

Chris Becke wrote:

I *know* my CPU has opcodes that can do this -

when adding (or subtracting) there is a carry flag
that can be invoked to make the result essentially
1 bit longer than the data size used in calculations.
When multiplying two numbers, the CPU automatically
returns a double width result.

I'm not an expert on this, but as far as I know there is not such
facility in C++. In C, however (and therefore in most C++ compilers,
even though formally this is not required), there is some support for
floating point exceptions, in the header fenv.h. Check out:

http://qnxclub.net/files/articles/unix03/basedefs/fenv.h.html

However, this support is not event-driven, so you have to query for
exceptions. I know this is not optimal, you may consider writing guards
on some exception to wrap pieces of code that you don't want to generate
NaNs, underflows, overflows, and so on.

Best wishes,

Zeppe

[Juha Nieminen]

Re: integer overflow detection would be a nice addition.

Chris Becke wrote:

I *know* my CPU has opcodes that can do this

Then write your own inline asm to do that. It will be exactly as
portable as anything else related to that.

[jacob navia]

Re: integer overflow detection would be a nice addition.

The lcc-win C compiler (not C++) detects overflow
if the user asks for it.
I agree that it should be part of the language.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Stephen Horne]

Re: integer overflow detection would be a nice addition.


I agree, but only to a point.

One option you have is to use Ada, which has overflow detection built
in. You can declare subtypes with different ranges, and the overflow
check is based on that. Performance isn't normally badly hit because
the compiler can determine when the checks are needed and when they
aren't.

The main problem with Ada is that it's nowhere near as widely used as
C++, meaning few third party libraries, limited compiler choices etc.

Within C++, you can use big integer classes or other integer-type
wrapper classes that either never overflow (unless you go really nuts)
or which have overflow checks built in. Libraries like this can be
used pretty much as easily as simple integers due to operator
overloading.

There are big integer classes available

Wrapping a normal integer is more likely to be done for strict typing
reasons - it's easy enough to write a template wrapper class, but
getting the checks right (without exploiting a platform-specific
overflow flag) can be fiddly. What's more, the overflow checking
probably needs to make a 2s complement assumption - I wouldn't be
surprised if this is non-portable in itself. There used to be machines
that used sign-value for integers, for instance - I have no idea if
that kind of thing is still in use.

[James Kanze]

Re: integer overflow detection would be a nice addition.

On Oct 16, 3:54 am, Stephen Horne <sh006d3...@blu eyonder.co.ukwr ote:

One option you have is to use Ada, which has overflow
detection built in. You can declare subtypes with different
ranges, and the overflow check is based on that. Performance
isn't normally badly hit because the compiler can determine
when the checks are needed and when they aren't.

I don't think the original poster was looking for Ada-like
overflow checking (although it would be nice as well). He
specifically mentionned the problem of implementing variable
width numbers, and his problem seemed to be that there are
always (or almost always) specific hardware features which would
help here, but which cannot be accessed from C++: every machine
I've worked on has a carry bit, for example, and the vast
majority will calculate a double word result when multiplying
words. Thus, if you're implementing an extended + operator on
an 80x86, your main loop would almost certainly contain
something like:

mov eax, [esi]
adc eax, [ebx]
mov [edi], eax

That adc instruction (add with carry) makes things go a lot
faster, and there's no way to get the C++ compiler to generate
it. (I suppose a really good optimizer could recognize some
pattern in your code, deduce that this was the target semantics,
and generate it. But I've never seen an optimizer that good.)
The case of multiplication is even worse: when multiplying two
32 bit values, you need the full 64 bit results; the hardware
multiply on an 80x86 gives you this, but the compiler won't let
you get at the top 32 bits.

As an extreme example of this sort of problem, I once maintained
a product which used BCD arithmetic; there was a module of
somewhere around 1000 LOC in C which implemented the four basic
operators for 13 digit BCD values. The person who ported this
application to the Siemens BS2000 mainframe (IBM 360
architecture) rewrote this module in assembler. With about 10
machine instructions and no loops for each operator: the
hardware had hardwired 8 byte BCD arthimetic. In this case, the
assembler was not only faster (by several orders of magnitude),
it was also significantlly shorter and simpler to understand and
maintain.

The main problem with Ada is that it's nowhere near as widely
used as C++, meaning few third party libraries, limited
compiler choices etc.

Within C++, you can use big integer classes or other
integer-type wrapper classes that either never overflow
(unless you go really nuts) or which have overflow checks
built in. Libraries like this can be used pretty much as
easily as simple integers due to operator overloading.

The problem is that either you write the actual code for such a
class in assembler, or you take a serious performance hit.
Because the hardware has special instructions for this, the
assembler is typically easier to understand and maintain than
the C++ would. As for portability, however...

I rather agree with the original poster. It would be nice if
C++ offered some way to access this funtionality. Practically,
however, I don't really know what the syntax would look like.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34