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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,4215feeab2a8154a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!fdn.fr!gegeweb.org!aioe.org!not-for-mail From: John McCabe Newsgroups: comp.lang.ada Subject: Re: C++0x and Threads - a poor relation to Ada's tasking model? Date: Thu, 13 Aug 2009 14:51:26 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <7q2385104kihs87d79p8kfphuoki6r01vq@4ax.com> <7961a91c-a5af-40e2-bbc0-6bf69a98176d@z31g2000yqd.googlegroups.com> <362f621e-a01c-4772-ba02-4e18e9962188@j19g2000vbp.googlegroups.com> <128d63da-361f-4e33-be5e-e06bdc71e39f@r34g2000vba.googlegroups.com> <850893f5-46e5-443f-af0f-f16eef5cfa37@n2g2000vba.googlegroups.com> NNTP-Posting-Host: RXEkuaSUwmKe0XIGFYSK7A.user.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.7.9 X-Newsreader: Forte Agent 2.0/32.652 Cancel-Lock: sha1:ZgZzsqOlvkBfrKu/PgrpMaJ7cv4= Xref: g2news2.google.com comp.lang.ada:7736 Date: 2009-08-13T14:51:26+01:00 List-Id: On Wed, 12 Aug 2009 14:24:50 -0700 (PDT), REH wrote: >On Aug 12, 4:41�pm, Robert A Duff >wrote: >> The philosophy has nothing to do with "explicitly". > >Sure it does. I have to *explicitly* throw an exception or call >something that throws an exception, to raise an exception in C++. In >Ada, I don't. It automatic. A simple assignment can raise an >exception. Although this is not an assignment operation, let's take the MIL-STD-1750A instruction set (I know it's probably a bit old hat, but it's the last one that I really had to study in any detail!) as an example. There is an instruction described in section 5.55 which is a single precision integer add. The effect of this instruction is: "The Derived Operand (DO) is added to the contents of the RA register. The result (a 2's complement sum) is stored in register RA. The condition status (CS) is set based on the result in register RA and carry. A fixed point overflow occurs if both operands are of the same sign and the sum is of opposite sign." What this is saying is that, for a 16 bit integer: type Int16 is range -32768..32767; for Int16'size use 16; -- or something like that and some fiddling around... x : Int16 := 32767; y : Int16 := 1; z : Int16 := 0; begin z := x + y; end ...; In Ada this should raise a Constraint_Error (or Numeric_Error or something - forgive my vagueness, I haven't used Ada in anger for a while) as the bounds of the type have been passed. In this case, all we need to do is handle the fixed point overflow interrupt. We don't need additional code to carry out this check. I don't know how common this feature in a processor is, but it's very simple to implement in hardware and my guess is that many numeric faults are as easy trap without having to add code in to do the checks. In C/C++ this would be a wrapping operation so you would have to ignore the FP overflow interrupt. That's not such a big deal, but what if you actually wanted to catch it on occasion? My point I guess is that some processors may have support for facilities that map nicely on to Ada's exception handling, some probably don't, but generalising in the way you have is not an accurate representation (like there being no way to provide an accurate representation of an object in C/C++ :-)