integer overflow detection would be a nice addition.

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

"Chris Becke" <chris.becke@gmail.com> writes: > 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. 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 -- __Pascal Bourguignon__

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

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

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.

On Oct 16, 3:54 am, Stephen Horne <sh006d3...@blueyonder.co.uk> wrote: > 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.kanze@gmail.com Conseils en informatique orient=E9e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34