From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_FILL_THIS_FORM_SHORT autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 109fba,cd8ed9115942852f X-Google-NewGroupId: yes X-Google-Thread: 103376,b92b95c9b5585075 X-Google-NewGroupId: yes X-Google-Attributes: gid4f1905883f,gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,CP1252 Path: g2news1.google.com!postnews.google.com!f41g2000yqh.googlegroups.com!not-for-mail From: Stuart Redmann Newsgroups: comp.lang.c++,comp.lang.ada Subject: Re: Why use C++? Date: Fri, 12 Aug 2011 04:48:13 -0700 (PDT) Organization: http://groups.google.com Message-ID: <4573053c-23a1-4a23-9afb-fa4d297ff8c5@f41g2000yqh.googlegroups.com> References: <1e292299-2cbe-4443-86f3-b19b8af50fff@c29g2000yqd.googlegroups.com> <1fd0cc9b-859d-428e-b68a-11e34de84225@gz10g2000vbb.googlegroups.com> <9ag33sFmuaU1@mid.individual.net> <1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net> NNTP-Posting-Host: 80.254.148.123 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1313149694 15306 127.0.0.1 (12 Aug 2011 11:48:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 12 Aug 2011 11:48:14 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: f41g2000yqh.googlegroups.com; posting-host=80.254.148.123; posting-account=oN-52woAAABHL8K37qsstwdocFkAyOMA User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729),gzip(gfe) Xref: g2news1.google.com comp.lang.c++:82846 comp.lang.ada:20566 Date: 2011-08-12T04:48:13-07:00 List-Id: 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.h= tml: 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 =96(2**31) .. 2**31=961; 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 :=3D Address + Address_Type'Mod(Offset); 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 =3D (MyVar * MyVar) mod 100; Be honest, how often do you really _want_ a wrapping int? Regards, Stuart