Re: C++0x and Threads - a poor relation to Ada's tasking model?

[John McCabe <john@nospam.assen.demon.co.uk>]

On Wed, 12 Aug 2009 14:24:50 -0700 (PDT), REH <spamjunk@stny.rr.com>
wrote:

>On Aug 12, 4:41�pm, Robert A Duff <bobd...@shell01.TheWorld.com>
>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++ :-)