Re: Why use C++?

[Stuart Redmann <DerTopper@web.de>]

On 10 Aug, Randy Brukardt wrote:
> >> There are uses for wrapping types, but they are far less likely
> >> than wanting overflow detection. The default should be to catch
> >> errors, not turn them into different ones.


Dmitry A. Kazakov wrote
> > The OP mentioned image processing, the behavior frequently needed
> > there is saturated integer arithmetic, which is nether ranged
> > nor modular.
> >
> > As for modular types, wrapping is the mathematically correct
> > behavior, it is not an error.
> >
> >
> > You just cannot provide every possible arithmetic at the language
> > level.


On 11 Aug., "Jed" wrote:
> What do you think the practical level of limitation is? Were you thinking
> "beyond integers" with your statement? What kinds of integer types would
> you like to see built-in to a hypothetical ideal language?


Well, I found the following snippet on
http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-1-3-5.html:

<citation (hopefully covered by fair use ;-)>
Ada 95 introduced modular types which are of course unsigned integers.
However it has in certain cases proved very difficult to get unsigned
integers and signed integers to work together. This is a trivial
matter in fragile languages such as C but in Ada the type model has
proved obstructive. The basic problem is converting a value of a
signed type which happens to be negative to an unsigned type. Thus
suppose we want to add a signed offset to an unsigned address value,
we might have
type Offset_Type is range –(2**31) .. 2**31–1;
type Address_Type is mod 2**32;
Offset: Offset_Type;
Address: Address_Type;
We cannot just add Offset to Address because they are of different
types. If we convert the Offset to the address type then we might get
Constraint_Error and so on. The solution in Ada 2005 is to use a new
functional attribute S'Mod which applies to any modular subtype S and
converts a universal integer value to the modular type using the
corresponding mathematical mod operation. So we can now write
Address := Address + Address_Type'Mod(Offset);
</citation>

This is clearly cumbersome: We have to use a wrapping int for
Address_Type because Ada does not provide a non-signed integer as the
underlying hardware supports (at least not guaranteed by the language
spec).

Ideally, we should be able to do this:
type IncrediblyLargeType is range -1e100 .. +1e100;
and Ada provides some large number representation that is suitable for
this range (Chinese remainder theorem). Why should I worry about
performance? Remember that premature optimization is the root of all
evil. If it takes half a second for multiplication of such types, then
so be it. However, if it turns out that performance matters, I should
be able to add attributes to the type so that Ada can choose a
hardware supported representation.

I think that we could also drop the wrapping ints at all (I consider
them rather a kludge). If someone want wrapping semantics, he could
still write:
type MyType is range 0 .. 100;
MyVar : MyType;
MyVar = (MyVar * MyVar) mod 100;

Be honest, how often do you really _want_ a wrapping int?

Regards,
Stuart