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

[REH <spamjunk@stny.rr.com>]

On Aug 13, 9:51 am, John McCabe <j...@nospam.assen.demon.co.uk> wrote:
> On Wed, 12 Aug 2009 14:24:50 -0700 (PDT), REH <spamj...@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++ :-)

You are making the assumption that hardware exceptions map to software
exceptions. An Ada run-time may do this (or it may not). C++ does not
( there is no such animal as C/C++). Ada has specific requirements for
what happens when your Int16 overflows. C++ considered a signed
integer overflow undefined behavior. The compiler is allowed to do
anything it wants.

REH