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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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,ASCII Path: g2news2.google.com!postnews.google.com!g8g2000prn.googlegroups.com!not-for-mail From: Louisa Newsgroups: comp.lang.c++,comp.lang.ada Subject: Re: Why use C++? Date: Thu, 18 Aug 2011 06:39:10 -0700 (PDT) Organization: http://groups.google.com Message-ID: <6a7de1ce-7f94-4609-8c8c-3de257c3249e@g8g2000prn.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: 123.2.70.40 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1313674750 12193 127.0.0.1 (18 Aug 2011 13:39:10 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 18 Aug 2011 13:39:10 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: g8g2000prn.googlegroups.com; posting-host=123.2.70.40; posting-account=GnexqAoAAACiR9jTsPjYN6hq7PEZEMKN User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLEUHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729),gzip(gfe) Xref: g2news2.google.com comp.lang.c++:92949 comp.lang.ada:21644 Date: 2011-08-18T06:39:10-07:00 List-Id: On Aug 11, 5:54=A0pm, "Dmitry A. Kazakov" wrote: > On Wed, 10 Aug 2011 17:37:28 -0500, Randy Brukardt wrote: > > There are uses for wrapping types, but they are far less likely than wa= nting > > overflow detection. The default should be to catch errors, not turn the= m > > into different ones. > > The OP mentioned image processing, the behavior frequently needed there i= s > 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. Signed and unsigned arithmetic are provided in PL/I. Thus, 0:2**32-1 is available for unsigned binary arithmetic. So is 0:2**64-1.