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

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

[John McCabe]

I was just wondering if anyone here has been following the C++0x
development, particularly wrt concurrency etc.

Obviously we all know that one of the big issues Ada compilers had in
the early days was providing a supporting run-time system that was
robust, efficient and reliable.

To be honest, I haven't been following the C++0x development but,
based on what I have read about C++0x's threads stuff (based on
Boost.Thread) am I right in assuming that all that's being proposed is
a standardised abstraction of the threading functions of whatever OS
that your C++ program is running on?

I'm fairly sure this is how many Ada implementations work anyway, but
I believe there are (or have been) many Ada implementations developed
for bare machines where the Ada vendor provided the run time system.
That's definitely how TLD Systems Ada 83 run-time worked anyway.

So, are we seeing something arriving in C++ that need only be
supported by implementations running on a 3rd party OS (e.g. Windows,
VxWorks etc), or will threads need to be supported for bare machines
as well?

Thanks for any responses. This may seem like a C++ question, but it's
more a question of "why will Ada's threading model remain vastly
superior"!

Thanks

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

[Maciej Sobczak]

On 11 Sie, 17:30, John McCabe <j...@nospam.assen.demon.co.uk> wrote:

> I was just wondering if anyone here has been following the C++0x
> development, particularly wrt concurrency etc.

Yes.

> Obviously we all know that one of the big issues Ada compilers had in
> the early days was providing a supporting run-time system that was
> robust, efficient and reliable.

Right, we will come back to this statement.

> To be honest, I haven't been following the C++0x development but,
> based on what I have read about C++0x's threads stuff (based on
> Boost.Thread) am I right in assuming that all that's being proposed is
> a standardised abstraction of the threading functions of whatever OS
> that your C++ program is running on?

Yes. This basically standardizes the existing practice (which is very
good for users) and allows easier implementation (which is very good
for users).

> I'm fairly sure this is how many Ada implementations work anyway, but
> I believe there are (or have been) many Ada implementations developed
> for bare machines where the Ada vendor provided the run time system.

And there is absolutely nothing that could prevent the C++ vendor from
implementing a stand-alone run-time that will implement the given API.

> So, are we seeing something arriving in C++ that need only be
> supported by implementations running on a 3rd party OS

Absolutely not, see above. There is nothing that prevents vendors from
implementing stand-alone run-times. Actually, with the API that is
borrowed from *existing implementations* (read: maturity, industrial
experience, etc.), implementing such a stand-alone run-time is
actually much easier than being forced to work with API that is
constructed in isolation from the existing practise.
You might even pick a source code from the Linux kernel and build on
that. Why not? This is the comfort that Ada vendors did not have.

> or will threads need to be supported for bare machines
> as well?

No standard can force anybody to provide implementations. Vendors will
do it if they will see a business opportunity in it.

> Thanks for any responses.

You are welcome.

> This may seem like a C++ question, but it's
> more a question of "why will Ada's threading model remain vastly
> superior"!

Why do you think it is "vastly superior"? It is certainly more
complex, but the most visible effect of complexity is the cost (both
in time and money) of implementation and this is where we come back to
what you have stated at the beginning - the complexity of run-time has
*hurt* Ada heavily at the beginning and the consequences of it are
still visible in low adoption of the language.

Being complex does not guarantee higher expressiveness, either.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

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

[John McCabe]

On Tue, 11 Aug 2009 13:51:35 -0700 (PDT), Maciej Sobczak
<see.my.homepage@gmail.com> wrote:

>On 11 Sie, 17:30, John McCabe <j...@nospam.assen.demon.co.uk> wrote:

<..snip..>

>> So, are we seeing something arriving in C++ that need only be
>> supported by implementations running on a 3rd party OS
>
>Absolutely not, see above. There is nothing that prevents vendors from
>implementing stand-alone run-times. Actually, with the API that is
>borrowed from *existing implementations* (read: maturity, industrial
>experience, etc.), implementing such a stand-alone run-time is
>actually much easier than being forced to work with API that is
>constructed in isolation from the existing practise.
>You might even pick a source code from the Linux kernel and build on
>that. Why not? This is the comfort that Ada vendors did not have.

>> or will threads need to be supported for bare machines
>> as well?

>No standard can force anybody to provide implementations. Vendors will
>do it if they will see a business opportunity in it.

My point/question really was whether it will be acceptable for a C++
compiler to NOT support the threading library (i.e. if a vendor
chooses not to provide a bare board run-time system with built in
threading).

I think you've got the gist of the question, but you've split it in to
two when it's only really one question.

>> This may seem like a C++ question, but it's
>> more a question of "why will Ada's threading model remain vastly
>> superior"!

>Why do you think it is "vastly superior"? It is certainly more
>complex, but the most visible effect of complexity is the cost (both
>in time and money) of implementation and this is where we come back to
>what you have stated at the beginning - the complexity of run-time has
>*hurt* Ada heavily at the beginning and the consequences of it are
>still visible in low adoption of the language.
>
>Being complex does not guarantee higher expressiveness, either.

It seems to me that Ada's model started off with a clean slate and was
designed from the ground up whereas with C++ it's always been a case
of "how can we bolt this on". That's primarily what I was getting at.
As I mentioned earlier I've not read a huge amount about this yet, but
I've seen little evidence that there are any standards proposed in C++
to handle thread priorities, dispatching policies and so on.

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

[Maciej Sobczak]

On 12 Sie, 14:25, John McCabe <j...@nospam.assen.demon.co.uk> wrote:

> >No standard can force anybody to provide implementations. Vendors will
> >do it if they will see a business opportunity in it.
>
> My point/question really was whether it will be acceptable for a C++
> compiler to NOT support the threading library (i.e. if a vendor
> chooses not to provide a bare board run-time system with built in
> threading).

Why not? If this is acceptable for their customers...
Note that the vendor can always sell a C++98 compiler naming it as
such and avoiding any accusations of wrongly using the C++ name on a
non-conforming product. They can even provide everything else as
"extensions" and still be OK.

It is somewhat like a question on whether an Ada vendor can today sell
the Ada compiler even if it does not implement interfaces, object-dot-
notation, etc.
Sure - just call it Ada95 and be explicit about it. This is actually
what we observe.

> It seems to me that Ada's model started off with a clean slate and was
> designed from the ground up whereas with C++ it's always been a case
> of "how can we bolt this on".

This is true and reflects the fact that operating systems evolved
faster than the language in this respect.

> As I mentioned earlier I've not read a huge amount about this yet, but
> I've seen little evidence that there are any standards proposed in C++
> to handle thread priorities, dispatching policies and so on.

Because the target is different. And because the C++ committee, unlike
the Ada one, feels a bit uncomfortable with the idea of *optionally
implemented* parts of the language.

If you need these features in C++, talk to your compiler and OS
vendor.
At the end, if you find an Ada compiler that offers these features on
a given OS, then apparently there is some API provided by the OS that
enables these features (and which API is being used by the Ada run-
time) and there is no reason not to benefit from them in C++ as well.

Of course there is always an argument that the use of these features
is portable in Ada and not portable in C++ (as there is no standard
API for them), but frankly - if you need *these* features, you are
targeting a very specific hardware/OS environment anyway and therefore
code portability is of lesser importance.

In this context I think that what the C++ committee did is very fair
and rational, as it addresses the overwhelming majority of users with
something that is simple to implement while putting perhaps some more
work on the minority that has very specific needs. It would be wrong
to do the other way round.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

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

[REH]

On Aug 12, 8:25 am, John McCabe <j...@nospam.assen.demon.co.uk> wrote:
> My point/question really was whether it will be acceptable for a C++
> compiler to NOT support the threading library (i.e. if a vendor
> chooses not to provide a bare board run-time system with built in
> threading).

C++ defines two types of implementations: hosted and freestanding. The
later is not required to provided threads (among other things).

> It seems to me that Ada's model started off with a clean slate and was
> designed from the ground up whereas with C++ it's always been a case
> of "how can we bolt this on". That's primarily what I was getting at.

If the Ada model suits your needs, use it. Why should C++ be
identical? It serves a different community.

> As I mentioned earlier I've not read a huge amount about this yet, but
> I've seen little evidence that there are any standards proposed in C++
> to handle thread priorities, dispatching policies and so on.

Even Ada isn't perfect in this regard. For example, the Ada compilers
that run on Linux (that I have used) cannot use priorities unless you
are running as root (because they are built upon Linux threads).

REH

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

[John McCabe]

On Wed, 12 Aug 2009 08:56:34 -0700 (PDT), REH <spamjunk@stny.rr.com>
wrote:

>> It seems to me that Ada's model started off with a clean slate and was
>> designed from the ground up whereas with C++ it's always been a case
>> of "how can we bolt this on". That's primarily what I was getting at.

>If the Ada model suits your needs, use it. Why should C++ be
>identical? It serves a different community.

In what way?

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

[REH]

On Aug 12, 12:59 pm, John McCabe <j...@nospam.assen.demon.co.uk>
wrote:
> On Wed, 12 Aug 2009 08:56:34 -0700 (PDT), REH <spamj...@stny.rr.com>
> wrote:
>
> >> It seems to me that Ada's model started off with a clean slate and was
> >> designed from the ground up whereas with C++ it's always been a case
> >> of "how can we bolt this on". That's primarily what I was getting at.
> >If the Ada model suits your needs, use it. Why should C++ be
> >identical? It serves a different community.
>
> In what way?

There is less concern with (compiler-provided) safety, and more with
speed. The C++ philosophy is "if you don't need it, you don't pay for
it." For example, you don't take a (potential) performance hit for
exceptions or range-checking, unless you explicitly use them. The C++
committee would rather (I surmise) define an interface that maps
easily to existing systems as a light wrapper, than one that is harder
to implement but much safer. I don't think one way is better than the
other. It depends on your needs. I use both languages extensive where
I work.

REH

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

[Robert A Duff]

REH <spamjunk@stny.rr.com> writes:

>...The C++ philosophy is "if you don't need it, you don't pay for
> it."

Ada has the same philosophy.

>... For example, you don't take a (potential) performance hit for
> exceptions or range-checking, unless you explicitly use them.

The philosophy has nothing to do with "explicitly".  And I don't
understand why you said "potential".  If you leave out those two words,
as in "you don't take a performance hit for exceptions or
range-checking, unless you use them," then I would agree with you 100%.

The point is, if you use some feature X, you should not have
to pay the cost of feature Y that you do not use, just because
feature Y exists, and might have some interaction with feature
X in some other program that DOES use Y with X.

C++ and Ada both share this philosophy.  It's called
"avoid distributed overhead".

- Bob

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

[REH]

On Aug 12, 4:41 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> The philosophy has nothing to do with "explicitly".  And I don't
> understand why you said "potential".  If you leave out those two words,
> as in "you don't take a performance hit for exceptions or
> range-checking, unless you use them," then I would agree with you 100%.
>
> The point is, if you use some feature X, you should not have
> to pay the cost of feature Y that you do not use, just because
> feature Y exists, and might have some interaction with feature
> X in some other program that DOES use Y with X.
>
> C++ and Ada both share this philosophy.  It's called
> "avoid distributed overhead".

The reason I said "potentially" is you may or maybe pay the cost in
Ada, depending on the implementation. There are implementations where
you will always pay a speed penalty for exceptions (e.g., in setting
up the frame), and there are ones where you only pay if an exception
is raised (e.g., a table-based implementation). A C++ compiler will
not make me "pay" the cost of exceptions if I never make use of them.
What I mean by that is, if I don't have a try block, there will never
be any setup code to catch or propagate exceptions. In Ada, you may or
may not.

Similarly with range-checking. If I index an array in Ada, it may or
may not range check the index (a smart compiler can remove the check
if it can prove it cannot be out-of-range). C++ will not range check
the index. I have to do it explicitly (which is why I used that word),
or if I am using vectors, call the at member explicitly.


REH

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

[Randy Brukardt]

"REH" <spamjunk@stny.rr.com> wrote in message 
news:6d23274b-d649-4a83-a6f1-6d1e9c4c3998@d34g2000vbm.googlegroups.com...
On Aug 12, 4:41 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
...
>> C++ and Ada both share this philosophy. It's called
>> "avoid distributed overhead".
>
>The reason I said "potentially" is you may or maybe pay the cost in
>Ada, depending on the implementation. There are implementations where
>you will always pay a speed penalty for exceptions (e.g., in setting
>up the frame), and there are ones where you only pay if an exception
>is raised (e.g., a table-based implementation).  A C++ compiler will
>not make me "pay" the cost of exceptions if I never make use of them.
>What I mean by that is, if I don't have a try block, there will never
>be any setup code to catch or propagate exceptions. In Ada, you may or
>may not.

It seems to me that you are says Ada and C++ are exactly the same here. The 
cost for exception handling in Ada only exists if you have an exception 
handler. I've never seen an Ada implementation that has any overhead for a 
frame that doesn't contain a handler - it would be a horrible performance 
drag. That's essentially equivalent to the C++ situation, as a "try block" 
is roughly equivalent to an Ada block with an exception handler. (Ada just 
allows handlers in more places.)

>Similarly with range-checking. If I index an array in Ada, it may or
>may not range check the index (a smart compiler can remove the check
>if it can prove it cannot be out-of-range). C++ will not range check
>the index. I have to do it explicitly (which is why I used that word),
>or if I am using vectors, call the at member explicitly.

Range checking is very cheap (generally only a couple of instructions); you 
can only detect the overhead in benchmarks. The odds that it would matter to 
a program is minimal (and the program is a lot safer for its enclusion). 
Overhead from exceptions and potentially finalizations are several orders of 
magnitude larger, and matter a lot more.

Premature optimization (which includes worrying about overhead without 
determining that it is significant) is the root of much evil.

                                                       Randy.

REH 

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

[REH]

On Aug 12, 9:28 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> It seems to me that you are says Ada and C++ are exactly the same here. The
> cost for exception handling in Ada only exists if you have an exception
> handler. I've never seen an Ada implementation that has any overhead for a
> frame that doesn't contain a handler - it would be a horrible performance
> drag. That's essentially equivalent to the C++ situation, as a "try block"
> is roughly equivalent to an Ada block with an exception handler. (Ada just
> allows handlers in more places.)

The point was an Ada program will most likely have to code in it to
handle exceptions. C++ may not. And before you start: I am not saying
one way is better.


> Range checking is very cheap (generally only a couple of instructions); you
> can only detect the overhead in benchmarks. The odds that it would matter to
> a program is minimal (and the program is a lot safer for its enclusion).
> Overhead from exceptions and potentially finalizations are several orders of
> magnitude larger, and matter a lot more.

That's my point. Range checking may be an acceptable cost, and is done
so for safety. C++ isn't willing to pay that cost by default. It's a
trade off safety vs. speed. That's all. You seem to think I am arguing
against the checks, or against Ada. I'm not. Just pointing out the
differences.

>
> Premature optimization (which includes worrying about overhead without
> determining that it is significant) is the root of much evil.
>

I know that, and it's beside the point. I was just trying to explain
(and obviously poorly) the philosophical differences that (in my
opinion) the two languages take. It nothing do with slighting each
one. I use and like both. Ada has an emphasis on safety, C++ on speed.

REH

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

[Pascal Obry]

Le 13/08/2009 04:08, REH a �crit :
> I use and like both. Ada has an emphasis on safety, C++ on speed.

Agreed. I like to think that Ada is 3 months behind in term of speed as 
computer are making progress regularly. It is so much safer that I just 
stick to Ada even when speed is the first requirement (my time cost lot 
more than a computer, I don't want to loose it in debug party).

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

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

[Dmitry A. Kazakov]

On Thu, 13 Aug 2009 10:38:31 +0200, Pascal Obry wrote:

> Le 13/08/2009 04:08, REH a �crit :
>> I use and like both. Ada has an emphasis on safety, C++ on speed.
> 
> Agreed. I like to think that Ada is 3 months behind in term of speed as 
> computer are making progress regularly. It is so much safer that I just 
> stick to Ada even when speed is the first requirement (my time cost lot 
> more than a computer, I don't want to loose it in debug party).

Don't you wonder why should it be this way? Shouldn't safer code be more
efficient?

I prefer to think that Ada has an emphasis on *semantics*, which, when
properly defined allows a deeper optimization and safer programming.

The major problem of C++ is not its awful syntax. It is that a "normal"
programmer reading and writing C++ code does not really understand what
this code does. It is like X'Access attribute in Ada, you newer know what
surprises accessibility checks will give. You have some little "theory" of
what it could be, but this theory is customary wrong, and you have neither
time nor desire to verify it. In C++ most of such pet "theories" are wrong.
Ada is designed to be more friendly...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Pascal Obry]

Dmitry,

> Don't you wonder why should it be this way? Shouldn't safer code be more
> efficient?

Should... maybe! My experiences is often that Ada is a *bit* slower. I 
have also some experiences where a concurrent and distributed 
application in Ada was a bit faster than a C++ one using OpenMP + MPI.

> I prefer to think that Ada has an emphasis on *semantics*, which, when

Agreed.

> properly defined allows a deeper optimization and safer programming.

Well checks are still taking some time. Note that I was speaking of 
applications built with checks on.

> Ada is designed to be more friendly...

Agreed.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

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

[Dmitry A. Kazakov]

On Thu, 13 Aug 2009 13:32:18 +0200, Pascal Obry wrote:

>> Don't you wonder why should it be this way? Shouldn't safer code be more
>> efficient?
> 
> Should... maybe! My experiences is often that Ada is a *bit* slower. I 
> have also some experiences where a concurrent and distributed 
> application in Ada was a bit faster than a C++ one using OpenMP + MPI.

In that case there must be something suboptimal in the language design.

I would also argue that where C++ is faster, the corresponding C++ code is
probably wrong, which a full coverage test would show. The trick is, that
nobody tests the code.

>> properly defined allows a deeper optimization and safer programming.
> 
> Well checks are still taking some time. Note that I was speaking of 
> applications built with checks on.

To continue the argument above:

1. These checks must be there, else the program is wrong
2. The language is wrong not allowing programmer to design these checks
static [*]

When it is neither 1 nor 2, then it is something which we can prove to be
OK in our program, while the compiler cannot. Is a normal programmer that
smart?

-----------
* Example in Ada. If you wanted to iterate two arrays at once, you could
not eliminate index checks of one of them:

   for I in A'Range loop
      ... A (I) + B (I + B'First - A'First) ...
                             -- No way to eliminate B index check
   end loop;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Brian Drummond]

On Thu, 13 Aug 2009 14:28:43 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On Thu, 13 Aug 2009 13:32:18 +0200, Pascal Obry wrote:
>
>>> Don't you wonder why should it be this way? Shouldn't safer code be more
>>> efficient?
>> 
>> Should... maybe! My experiences is often that Ada is a *bit* slower. I 
>> have also some experiences where a concurrent and distributed 
>> application in Ada was a bit faster than a C++ one using OpenMP + MPI.
>
>In that case there must be something suboptimal in the language design.
>
>I would also argue that where C++ is faster, the corresponding C++ code is
>probably wrong, which a full coverage test would show. The trick is, that
>nobody tests the code.

It's also likely that there are two orders of magnitude more eyes on the C++
compiler's performance, and that must count for something.
Just look at the progress a few pairs of eyes can make in a few days on one Ada
benchmark.

- Brian

Language checks (Was: C++0x and Threads - a poor relation to Ada's tasking model?)

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> 1. These checks must be there, else the program is wrong
> 2. The language is wrong not allowing programmer to design these checks
> static [*]
> 
> When it is neither 1 nor 2, then it is something which we can prove
> to be OK in our program, while the compiler cannot. Is a normal
> programmer that smart?

Probably not.

> -----------
> * Example in Ada. If you wanted to iterate two arrays at once, you could
> not eliminate index checks of one of them:
> 
>    for I in A'Range loop
>       ... A (I) + B (I + B'First - A'First) ...
>                              -- No way to eliminate B index check
>    end loop;

In your example we don't know if the index check on B is needed.  An
alternative:

   if B'Length >= A'Length then
      for I in A'Range loop
         ... A (I) + B (I + B'First - A'First) ...
      end loop;
   else
      ...
   end if;

Here a compiler should be able to figure out statically that there is
no need for an index check on B in the loob.

Greetings,

Jacob
-- 
�Later software patents have had a similar effect, they
 force us to stand on each other's toes instead of on each
 other's shoulders.�                       -- Per Abrahamsen

Re: Language checks (Was: C++0x and Threads - a poor relation to Ada's tasking model?)

[Dmitry A. Kazakov]

On 14 Aug 2009 13:24:09 +0200, Jacob Sparre Andersen wrote:

> Dmitry A. Kazakov wrote:
> 
>> * Example in Ada. If you wanted to iterate two arrays at once, you could
>> not eliminate index checks of one of them:
>> 
>>    for I in A'Range loop
>>       ... A (I) + B (I + B'First - A'First) ...
>>                              -- No way to eliminate B index check
>>    end loop;
> 
> In your example we don't know if the index check on B is needed.  An
> alternative:
> 
>    if B'Length >= A'Length then
>       for I in A'Range loop
>          ... A (I) + B (I + B'First - A'First) ...
>       end loop;
>    else
>       ...
>    end if;
> 
> Here a compiler should be able to figure out statically that there is
> no need for an index check on B in the loob.

I would prefer something more universal and binding than a compiler with
AI. For example:

declare
   B_View : array (Index range A'Range) of Element renames B;
begin
   for I in A'Range loop
      ... A (I) + B_View (I) ...
   end loop;

renaming raises Constraint_Error if something goes wrong.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Language checks (Was: C++0x and Threads - a poor relation to Ada's tasking model?)

[REH]

On Aug 14, 8:01 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> declare
>    B_View : array (Index range A'Range) of Element renames B;
> begin

I didn't know you could do that! That's very cool. So, as long as the
element type and length are the same, Ada will let you change the
index type in a rename?

REH

Re: Language checks (Was: C++0x and Threads - a poor relation to Ada's tasking model?)

[John McCabe]

On Fri, 14 Aug 2009 06:33:21 -0700 (PDT), REH <spamjunk@stny.rr.com>
wrote:

>On Aug 14, 8:01�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>wrote:
>> declare
>> � �B_View : array (Index range A'Range) of Element renames B;
>> begin
>
>I didn't know you could do that! That's very cool. So, as long as the
>element type and length are the same, Ada will let you change the
>index type in a rename?

I think I read about that recently in M. Ben-Ari's book. It's pretty
cool.

Re: Language checks (Was: C++0x and Threads - a poor relation to Ada's tasking model?)

[John McCabe]

On Fri, 14 Aug 2009 14:48:56 +0100, John McCabe
<john@nospam.assen.demon.co.uk> wrote:

>On Fri, 14 Aug 2009 06:33:21 -0700 (PDT), REH <spamjunk@stny.rr.com>
>wrote:
>
>>On Aug 14, 8:01�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>wrote:
>>> declare
>>> � �B_View : array (Index range A'Range) of Element renames B;
>>> begin
>>
>>I didn't know you could do that! That's very cool. So, as long as the
>>element type and length are the same, Ada will let you change the
>>index type in a rename?
>
>I think I read about that recently in M. Ben-Ari's book. It's pretty
>cool.

Oops - I guess that wasn't what I read about! Never mind.

Re: Language checks (Was: C++0x and Threads - a poor relation to Ada's tasking model?)

[Dmitry A. Kazakov]

On Fri, 14 Aug 2009 06:33:21 -0700 (PDT), REH wrote:

> On Aug 14, 8:01�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> declare
>> � �B_View : array (Index range A'Range) of Element renames B;
>> begin
> 
> I didn't know you could do that! That's very cool.

No, unfortunately it is illegal, and for all, renaming of arrays is broken
in Ada. It does not slide indices. Consider this:

with Ada.Text_IO;  use Ada.Text_IO;
procedure Test_Arrays is
   type T is array (Positive range <>) of Integer;
   subtype S is T (10..20);
   X : T (1..10) := (others => 0);
   Y : S renames X;
begin
   Ada.Text_IO.Put_Line (Integer'Image (Y'First));
end Test_Arrays;

It prints 1, instead of expected 10.

> So, as long as the
> element type and length are the same, Ada will let you change the
> index type in a rename?

Not in renaming, but in type conversion it is OK. Unfortunately type
conversions are not allowed in renaming. (But function calls are)

I think the whole issue should be revised some day...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Language checks

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> I think the whole issue should be revised some day...

I agree that this part of Ada is broken.  Subtypes on renamings should
not be ignored!

The right "some day" to fix this is circa 1982 -- anytime after 1983 is
too late.  Sigh.

Unless someone can come up with a fix that is upward compatible,
which is quite hard.  It has been discussed many times.

Note that the original designers of Ada 83 knew about this problem,
and discussed it, but did not come up with a proper fix.

- Bob

Re: Language checks (Was: C++0x and Threads - a poor relation to Ada's tasking model?)

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:874osar63q.fsf_-_@jspa-nykredit.sparre-andersen.dk...
...
> Here a compiler should be able to figure out statically that there is
> no need for an index check on B in the loob.

Gee, I thought the "loob" was that place I visited in Paris where I saw the 
Mona Liba and the Venus be Milo...

                     Randy (ducking out in hurry...)

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

[Gautier write-only]

On 12 août, 23:15, REH <spamj...@stny.rr.com> wrote:

> Similarly with range-checking. If I index an array in Ada, it may or
> may not range check the index (a smart compiler can remove the check
> if it can prove it cannot be out-of-range).

You can also make the compiler remove range checks: pragma Suppress,
or the corresponding compiler option. That way it is trivial to switch
between full checks and no checks (range checks or others, BTW).
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/
NB: For a direct answer, e-mail address on the Web site!

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

[REH]

On Aug 14, 9:10 am, Gautier write-only <gautier_niou...@hotmail.com>
wrote:
> On 12 août, 23:15, REH <spamj...@stny.rr.com> wrote:
>
> > Similarly with range-checking. If I index an array in Ada, it may or
> > may not range check the index (a smart compiler can remove the check
> > if it can prove it cannot be out-of-range).
>
> You can also make the compiler remove range checks: pragma Suppress,
> or the corresponding compiler option. That way it is trivial to switch
> between full checks and no checks (range checks or others, BTW).

Yes, I know that (even through Suppress is not guaranteed to remove
all checks). It's completely besides the point.

REH

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

[REH]

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. Most C++ compilers even have a flag to remove exceptions
because it make the build a lot smaller. With MSVC++, you have to
explicitly set a flag to get exceptions in the first place.

REH

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

[John McCabe]

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++ :-)

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

[REH]

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

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

[John McCabe]

On Thu, 13 Aug 2009 09:24:33 -0700 (PDT), REH <spamjunk@stny.rr.com>
wrote:

>On Aug 13, 9:51�am, John McCabe <j...@nospam.assen.demon.co.uk> wrote:

>> 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.

It's not an assumption, it's a point; if an Ada compiler were to
choose not to use the features of the processor where those features
mapped closely to a feature of the language, then that's their choice.
I would hope that most compilers would assess whether the use of that
feature would be more effective than doing it "by hand" and choose
whichever is the most appropriate.

> An Ada run-time may do this (or it may not).

See above.

> C++ does not ( there is no such animal as C/C++).

Under the circumstances I use C/C++ to represent C and C++ as this
particular example is common to both; they both incorpoate
overwrapping semantics for operations on integer types (unlike Ada,
which provides a separate Modular type for that purpose).

>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.

Oh dear.

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

[REH]

On Aug 14, 7:09 am, John McCabe <j...@nospam.assen.demon.co.uk> wrote:
> Under the circumstances I use C/C++ to represent C and C++ as this
> particular example is common to both; they both incorpoate
> overwrapping semantics for operations on integer types (unlike Ada,
> which provides a separate Modular type for that purpose).

C++ and C provide separate types of that purpose also. Signed and
unsigned integers are not the same type. They have different rules.
It's a common misconception that signed integers portably wrap. Signed
integer do not have "overwrapping sematics."

Using C/C++ is frowned upon by both the C and C++ communities. Even in
your simple example, the languages have different rules as to what is
portable.


>
> >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.
>
> Oh dear.

That! That is the only point I was trying to make in answering your
original question of how the communities are different. You are
appalled by that because it is not safe. The C++ community is not
because it allows the compiler maximum flexibility for raw speed.
Which position is "better" wasn't my point, only the fact that the
difference exists.

REH

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

[John McCabe]

On Fri, 14 Aug 2009 06:00:05 -0700 (PDT), REH <spamjunk@stny.rr.com>
wrote:

>On Aug 14, 7:09�am, John McCabe <j...@nospam.assen.demon.co.uk> wrote:
>> Under the circumstances I use C/C++ to represent C and C++ as this
>> particular example is common to both; they both incorpoate
>> overwrapping semantics for operations on integer types (unlike Ada,
>> which provides a separate Modular type for that purpose).
>
>C++ and C provide separate types of that purpose also. Signed and
>unsigned integers are not the same type. They have different rules.
>It's a common misconception that signed integers portably wrap. Signed
>integer do not have "overwrapping sematics."

I bow to your superior knowledge of the C++ standard. I assume you're
referring to something like this C++ section:

"If during the evaluation of an expression, the result is not
mathematically defined or not in the range of representable values for
its type, the behavior is undefined, unless such an expression is a
constant expression (5.19), in which case the program is ill-formed.
[Note: most existing implementations of C++ ignore integer overflows.
Treatment of division by zero, forming a remainder using a zero
divisor, and all floating point exceptions vary among machines, and is
usually adjustable by a library function. ]"

Thank you for that clarification.

Very intriguing note though, a standard that tells you how most
implementations deal with it!

... and this C Section (so to speak!):

"C�s unsigned integer types are ��modulo�� in the LIA-1 sense in that
overflows or out-of-bounds results silently wrap. An implementation
that defines signed integer types as also being modulo need not detect
integer overflow, in which case, only integer divide-by-zero need be
detected."

That's from some section on language independent arithmentic, I
couldn't find anything else.

>Using C/C++ is frowned upon by both the C and C++ communities.

Never mind.

>Even in
>your simple example, the languages have different rules as to what is
>portable.

Not significantly as far as I can see; C++ says behaviour on overflow
on signed integers is undefined, and C seems to say that it's up to
the implementation (which seems like the same thing). Both say
unsigned overflow doesn't occur because they use modulo arithmetic.

Unless of course I'm looking in the wrong place.

>> >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.
>>
>> Oh dear.
>
>That! That is the only point I was trying to make in answering your
>original question of how the communities are different. You are
>appalled by that because it is not safe. The C++ community is not
>because it allows the compiler maximum flexibility for raw speed.
>Which position is "better" wasn't my point, only the fact that the
>difference exists.

Ok. Thanks for that. I think we'll have to agree to disagree on this.
I personally don't see that there is a significant difference in need
between users of Ada and C++ in general. Obviously you do. The
question of raw speed over safety is a moot point in my view as a huge
amount of the safety of Ada comes from the fact that problems can be
detected at compile time; the generation of code is a different matter
and that all depends on the cleverness of those writing the compilers.
As an example, when I used the TLD Ada 83 compiler for MIL-STD-1750A
it came out with some phenomenally tight code using instructions that
might not have been the first one that would have sprung to mind had
you been writing the code in assembler. Conversely, when using C on a
DSP56001 with the g56k compiler, it generated code where every
variable to variable assignment was surrounded by the set up of a loop
with 1 iteration.

Anyway. Thanks again.

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

[REH]

On Aug 14, 10:30 am, John McCabe <j...@nospam.assen.demon.co.uk>
wrote:
> Not significantly as far as I can see; C++ says behaviour on overflow
> on signed integers is undefined, and C seems to say that it's up to
> the implementation (which seems like the same thing). Both say
> unsigned overflow doesn't occur because they use modulo arithmetic.
>
> Unless of course I'm looking in the wrong place.
>

No, you're not. They both say that signed integer overflow is
undefined behavior. They diverge when it comes to other portability
guarantees. Both C and C++ have guaranteed minimum ranges (e.g., int
must be at least +/- 32767), and that each successive int type (that
is char, short, int, long, etc.) must at least support the range of
the one before it. It gets nasty after that because (if I remember
correctly), only C++ says that the SIZE of an integer type must also
be least as big as the one before it. I believe it is technically
acceptable for an implementation of standard C for sizeof(int) to be
larger than sizeof(long). This is, of course, pedantry on my part but
I just wanted to show that isn't safe to assume that C and C++ share
the same rules.

REH

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

[John McCabe]

On Fri, 14 Aug 2009 07:49:12 -0700 (PDT), REH <spamjunk@stny.rr.com>
wrote:

>On Aug 14, 10:30�am, John McCabe <j...@nospam.assen.demon.co.uk>
>wrote:
>> Not significantly as far as I can see; C++ says behaviour on overflow
>> on signed integers is undefined, and C seems to say that it's up to
>> the implementation (which seems like the same thing). Both say
>> unsigned overflow doesn't occur because they use modulo arithmetic.
>>
>> Unless of course I'm looking in the wrong place.
>>
>
>No, you're not. They both say that signed integer overflow is
>undefined behavior.

Good. One day I will go through some more of that standard, unless I
get my wish and we start using Ada here :-}

> They diverge when it comes to other portability
>guarantees.

Of course, but I was referring just to this example when using
"C/C++"!

>This is, of course, pedantry on my part but
>I just wanted to show that isn't safe to assume that C and C++ share
>the same rules.

That's something I was aware of but it's always worth reminding me :-)

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

[REH]

On Aug 14, 10:54 am, John McCabe <j...@nospam.assen.demon.co.uk>
wrote:
> Good. One day I will go through some more of that standard, unless I
> get my wish and we start using Ada here :-}

Now I understand your original post. I guess I did't realize how lucky
I was. Where I work, we use many different languages. Heck, today I am
looking at some Jovial (!) code.

Usually, when I am "stuck" with just C++, I've implemented classes
that behave more like Ada. Years ago, I wrote a class that does
rendezvouses. A couple of years ago, a wrote a class template that
would do range/overflow checking. That, of course, is trivial. The
neat thing about it is that it used template specialization to remove
unnecessary checks at compile-time (e.g., the compiler could determine
that the arithmetic operation could not overflow). It would "track" a
variable's max. possible bounds as it was manipulated, and strip the
unnecessary checks from expressions (again, all at compile-time). I
published an article on it in Dr. Dobb's.

REH

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

[Robert A Duff]

REH <spamjunk@stny.rr.com> writes:

>...A couple of years ago, a wrote a class template that
> would do range/overflow checking. That, of course, is trivial. The
> neat thing about it is that it used template specialization to remove
> unnecessary checks at compile-time (e.g., the compiler could determine
> that the arithmetic operation could not overflow). It would "track" a
> variable's max. possible bounds as it was manipulated, and strip the
> unnecessary checks from expressions (again, all at compile-time). I
> published an article on it in Dr. Dobb's.

Intereesting.  Is that available on-line somewhere?

- Bob

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

[REH]

On Aug 14, 2:43 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> REH <spamj...@stny.rr.com> writes:
> >...A couple of years ago, a wrote a class template that
> > would do range/overflow checking. That, of course, is trivial. The
> > neat thing about it is that it used template specialization to remove
> > unnecessary checks at compile-time (e.g., the compiler could determine
> > that the arithmetic operation could not overflow). It would "track" a
> > variable's max. possible bounds as it was manipulated, and strip the
> > unnecessary checks from expressions (again, all at compile-time). I
> > published an article on it in Dr. Dobb's.
>
> Intereesting.  Is that available on-line somewhere?
>

http://www.ddj.com/cpp/201001318

Please don't be too critical. It's my first article, and I am by no
means an Ada expert!

REH

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

[Robert A Duff]

REH <spamjunk@stny.rr.com> writes:

> http://www.ddj.com/cpp/201001318

Thanks for the link.

> Please don't be too critical. It's my first article, and I am by no
> means an Ada expert!

Not at all critical.  I read it.  I have no criticisms, I think it's a
nice demonstration of C++ templates.

Of course, a real Ada compiler can use data-flow analysis to remove even
more checks than your templates can.  But that's not a criticism of your
C++ templates.

Nice job!  I found your article interesting!

- Bob

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

[REH]

On Aug 14, 6:33 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> REH <spamj...@stny.rr.com> writes:
> >http://www.ddj.com/cpp/201001318
>
> Thanks for the link.
>
> > Please don't be too critical. It's my first article, and I am by no
> > means an Ada expert!
>
> Not at all critical.  I read it.  I have no criticisms, I think it's a
> nice demonstration of C++ templates.
>
> Of course, a real Ada compiler can use data-flow analysis to remove even
> more checks than your templates can.  But that's not a criticism of your
> C++ templates.
>
> Nice job!  I found your article interesting!
>

Thanks. I thought my Ada terminology might be wrong. I had it peer
review by C++ experts, but not Ada. I used the term "ranged types." I
thought I read later (here I think) that is technically not correct.

REH

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

[Robert A Duff]

REH <spamjunk@stny.rr.com> writes:

> Thanks. I thought my Ada terminology might be wrong. I had it peer
> review by C++ experts, but not Ada. I used the term "ranged types." I
> thought I read later (here I think) that is technically not correct.

I don't think "ranged types" is wrong.  It's not what the Ada RM calls
them, but so what?  You're not writing the Ada RM, nor a
language-lawyerly article about Ada; you're writing an article
about how to do something Ada-like in C++, and in that context,
it's perfectly reasonable to use informal terminology.

I use the term "pointer" all the time to refer to things that point,
such as Ada access values.

- Bob

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

[Hyman Rosen]

REH wrote:
I believe it is technically acceptable for an implementation of
 > standard C for sizeof(int) to be larger than sizeof(long).

This is tightened up in C++. The C++ standard says, in 3.9.1/2,
     There are four signed integer types: �signed char�,
     �short int�, �int�, and �long int.� In this list,
     each type provides at least as much storage as those
     preceding it in the list.

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

[REH]

On Aug 14, 11:09 am, Hyman Rosen <hyro...@mail.com> wrote:
> REH wrote:
>
> I believe it is technically acceptable for an implementation of
>  > standard C for sizeof(int) to be larger than sizeof(long).
>
> This is tightened up in C++. The C++ standard says, in 3.9.1/2,
>      There are four signed integer types: “signed char”,
>      “short int”, “int”, and “long int.” In this list,
>      each type provides at least as much storage as those
>      preceding it in the list.

Right, that's what I said (or meant to say).

REH

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

[John McCabe]

On Wed, 12 Aug 2009 10:21:36 -0700 (PDT), REH <spamjunk@stny.rr.com>
wrote:

>On Aug 12, 12:59�pm, John McCabe <j...@nospam.assen.demon.co.uk>
>wrote:
>> On Wed, 12 Aug 2009 08:56:34 -0700 (PDT), REH <spamj...@stny.rr.com>
>> wrote:
>>
>> >> It seems to me that Ada's model started off with a clean slate and was
>> >> designed from the ground up whereas with C++ it's always been a case
>> >> of "how can we bolt this on". That's primarily what I was getting at.
>> >If the Ada model suits your needs, use it. Why should C++ be
>> >identical? It serves a different community.
>>
>> In what way?
>
>There is less concern with (compiler-provided) safety, and more with
>speed. The C++ philosophy is "if you don't need it, you don't pay for
>it." For example, you don't take a (potential) performance hit for
>exceptions or range-checking, unless you explicitly use them. The C++
>committee would rather (I surmise) define an interface that maps
>easily to existing systems as a light wrapper, than one that is harder
>to implement but much safer. I don't think one way is better than the
>other. It depends on your needs. I use both languages extensive where
>I work.

Having followed this train of messages further, I still don't see that
you have justified the comment about C++ serving a different community
to Ada. As I see it, the community is the same (they're both basically
general purpose OO programming languages), it's just a viewpoint
that's different.

In a lot of ways what you have argued is that the perception of C++ as
a faster language leads to its choice in some situations. In my view,
many people use C++ because that's all they know and they don't want
to learn anything different even when it may be superior in many ways.

Of course C++ has some features that make it easier to use for certain
applications, e.g. actual MI rather than the interface level MI
available in Ada and Java, but there are loads of resources out there
describing why that is dangerous.

Anyhow - this wasn't meant to be a general C++ Vs Ada thread, so I'm
going to stop there.

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

[REH]

On Aug 13, 9:55 am, John McCabe <j...@nospam.assen.demon.co.uk> wrote:
> Having followed this train of messages further, I still don't see that
> you have justified the comment about C++ serving a different community
> to Ada. As I see it, the community is the same (they're both basically
> general purpose OO programming languages), it's just a viewpoint
> that's different.

Maybe it's no justified to your satisfaction (I honestly don't care).
I think if you ask the C++ community, they would say they are
different from the Ada community (and don't feel the need to justify
why). Different--not better or worse. I wouldn't call Ada or C++ OO
languages. C++ is considered multi-paradigm. I would think Ada is the
same, but I don't know if the Ada community uses that term.

>
> In a lot of ways what you have argued is that the perception of C++ as
> a faster language leads to its choice in some situations. In my view,
> many people use C++ because that's all they know and they don't want
> to learn anything different even when it may be superior in many ways.

NO, I was not arguing C++ is a faster language. There is no such thing
as a faster language. I am arguing what that community considers
important. Anyone here can tell me if I am wrong, but I believe the
Ada community considered a safe language paramount. The C++ community
does not. Period.

You perceptions are baseless. No one I know, "only knows C++" or "only
knows Ada." I've used many languages in my career, as has my coworkers
(and I'm sure many here has done).

>
> Of course C++ has some features that make it easier to use for certain
> applications, e.g. actual MI rather than the interface level MI
> available in Ada and Java, but there are loads of resources out there
> describing why that is dangerous.

Every language feature can be abused. I never found that a good reason
to disallow it. Although I don't understand your reasons for being it
up. I was never arguing Ada vs C++.

>
> Anyhow - this wasn't meant to be a general C++ Vs Ada thread, so I'm
> going to stop there.

That was your doing. I don't think anyone else on this thread was
arguing that. My only point was they are different, and difference is
good. If two things are exactly the same, what is the point? Why do I
need C++ to implement Ada's threading model? I already have that.


REH

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

[John McCabe]

On Thu, 13 Aug 2009 09:45:19 -0700 (PDT), REH <spamjunk@stny.rr.com>
wrote:

>> Anyhow - this wasn't meant to be a general C++ Vs Ada thread, so I'm
>> going to stop there.

>That was your doing.

I disagree.

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

[Maciej Sobczak]

On 12 Sie, 18:59, John McCabe <j...@nospam.assen.demon.co.uk> wrote:

> >If the Ada model suits your needs, use it. Why should C++ be
> >identical? It serves a different community.
>
> In what way?

Apart from the performance vs. safety considerations described by REH,
the communities differ in their needs for real-time features. The
majority of C++ programmers really could not care less about
dispatching policies, but are very much concerned with the portability
across mainstream operating systems and with the efficient
implementations.

The stuff that is highly demanded can be achieved with relative ease
and this is the whole point of standardizing it - and the features
that are not demanded are, well, out of scope.

The Ada community has different focus. There is nothing good/bad about
either approach.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

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

[jimmaureenrogers]

I did follow the threading issues early on.
During the early discussions the decision was made to provide
a standard threading library rather than adding any new
reserved words to the language. This approach provided
minimum impact on existing software while providing significant
threading support. My objection, which was not considered
significant, was that the compilers have less information for
checking the correctness of library calls than they do of checking
the syntax of reserved words.

Jim Rogers

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

[Jeffrey R. Carter]

jimmaureenrogers@worldnet.att.net wrote:
> I did follow the threading issues early on.
> During the early discussions the decision was made to provide
> a standard threading library rather than adding any new
> reserved words to the language. This approach provided
> minimum impact on existing software while providing significant
> threading support. My objection, which was not considered
> significant, was that the compilers have less information for
> checking the correctness of library calls than they do of checking
> the syntax of reserved words.

Ada's support for tasking is, and always has been, high-level and inherently 
safe. Threading provided by an OS, or a library, or Java, is low-level and 
error-prone. Since the C family of languages seems to prefer low-level and 
error-prone, I won't be surprised if that's what C++ adopts.

-- 
Jeff Carter
"My little plum, I am like Robin Hood. I take from
the rich, and I give to the poor. ... Us poor."
Poppy
96

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

[Maciej Sobczak]

On 12 Sie, 01:53, jimmaureenrog...@worldnet.att.net wrote:

> My objection, which was not considered
> significant, was that the compilers have less information for
> checking the correctness of library calls than they do of checking
> the syntax of reserved words.

As long as the library calls are based on *standard* API there is
nothing that could prevent the compiler from applying some special
treatment to these calls.
The reasoning is that any library call that is recognized as a
standard call (for example by namespace or package prefix) is
essentially a keyword that can attract the attention of the compiler.

A very simple example is the printf function, which is inherently
unsafe as it does not provide any type checking for its parameters.
This does not prevent the gcc (or g++) compiler from actually checking
them anyway:

#include <cstdio>
int main()
{
    int s = 1234;
    std::printf("%s\n", s);
}

~/temp/cpp $ g++ -Wall hello.cpp
hello.cpp: In function 'int main()':
hello.cpp:5: warning: format '%s' expects type 'char*', but argument 2
has type 'int'
~/temp/cpp $

Above, std::printf, even though not formally a keyword, has attracted
the compiler's attention and allowed it to perform type checks that
are not mandated by the language itself.

Can you give an example of correctness checking in the area of
multithreading that is possible with reserved words and that is
*certainly* not possible with library calls?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

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

[stefan-lucks]

On Wed, 12 Aug 2009, Maciej Sobczak wrote:

> A very simple example is the printf function [...]:
> 
> #include <cstdio>
> int main()
> {
>     int s = 1234;
>     std::printf("%s\n", s);
> }
>
> Above, std::printf, even though not formally a keyword, has attracted
> the compiler's attention and allowed it to perform type checks that
> are not mandated by the language itself.

This is easy, since "%s\n" is a constant. Try 

  "printf(someString, a, b, c, d);", 

where someString is a variable. (This is valid C. I didn't check for C++, 
but I expect C++ to allow variable format strings, just as well.)



-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

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

[Maciej Sobczak]

On 12 Sie, 07:29, stefan-lu...@see-the.signature wrote:

> This is easy, since "%s\n" is a constant.

Of course. And *static* analysis of keyword-based multitasking usage
patterns is also easy *only* if these patterns are in some way
constant (static).

Nothing prevents me from screwing up an instance of
Ada.Containers.Vectors.Vector, Ada.Text_IO.File_Type, or just about
anything else if I use it from multiple tasks without wrapping it in
the protected object.
(that's what I have done recently)

It is *exactly* the same problem - you can always make the analysis
difficult by moving from static to dynamic.
What does it prove?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

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

[Ludovic Brenta]

Maciej Sobczak wrote on comp.lang.ada:
> Above, std::printf, even though not formally a keyword, has attracted
> the compiler's attention and allowed it to perform type checks that
> are not mandated by the language itself.
>
> Can you give an example of correctness checking in the area of
> multithreading that is possible with reserved words and that is
> *certainly* not possible with library calls?

I think we're near the crux of the problem: C++ cannot and will not
*mandate* such checks, leaving compiler writers the option to issue
warnings (not errors) if they do add the checks and if the user asks
for them (i.e. in the case of gcc, passes -Wall explicitly).

Ada *mandates* the checks and requires errors (not warnings) from all
conformant compilers in their default mode. The user would have to
pass additional, implementation-defined options or pragmas to *not*
see the errors.

That's why Ada's tasking is inherently safer than the proposed C++
tasking.

--
Ludovic Brenta.

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

[Maciej Sobczak]

On 12 Sie, 11:27, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:

> I think we're near the crux of the problem: C++ cannot and will not
> *mandate* such checks [...]
>
> Ada *mandates* the checks [...]

But it has nothing to do with whether the given feature is implemented
in terms of keywords or standard library calls, has it?
That is what Jim was talking about.

> That's why Ada's tasking is inherently safer than the proposed C++
> tasking.

So what *compile-time* checks are mandated by Ada in tasking?

The only checks that I'm aware of are those that lead to Program_Error
at run-time.
Indeed, the classic C++ way of dealing with problems is the so-called
undefined behaviour, but this again has nothing to do with tasks/
threads in particular.

Even if multithreading in C++ was defined in terms of keywords (as
opposed to library calls), it would not change anything in how the
problems are dealt with.

That's why introducing new reserved words in C++ would not buy
anything.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

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

[Peter C. Chapin]

Maciej Sobczak <see.my.homepage@gmail.com> wrote in news:6239906b-e952-
4bf9-8a11-b7faf942bdde@k19g2000yqn.googlegroups.com:

> That's why introducing new reserved words in C++ would not buy
> anything.

Using library calls limits in some respects the way in which concepts can 
be expressed. It is true that the compiler can be aware of the semantics of 
the standard library. However, the syntax of function calls can still make 
expressing some ideas awkward. For example, I'm wondering how C++ try and 
catch blocks would look as library calls. My guess is that they would be 
harder to read and harder to understand than they are now as language 
syntax.

Ada provides language syntax for concurrency. It feels cleaner to me than 
any of the C++ thread libraries I have used. Is that because those C++ 
libraries just don't have the interface "right?" Maybe. But it might also 
be because it's just not possible to express concurrency in a nice clean 
way when using only library calls.

I've been recently studying the language Scala which provides a mechanism 
for, essentially, adding new syntax to the language (with some 
restrictions). Scala's support for concurrency (which is similar to 
Erlang's) is implemented as a library but the result looks like built in 
language syntax. It's nice.

Peter

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

[John McCabe]

On 13 Aug 2009 12:47:39 GMT, "Peter C. Chapin" <pcc482719@gmail.com>
wrote:

>Ada provides language syntax for concurrency. It feels cleaner to me than 
>any of the C++ thread libraries I have used. Is that because those C++ 
>libraries just don't have the interface "right?" Maybe. But it might also 
>be because it's just not possible to express concurrency in a nice clean 
>way when using only library calls.

This is true. I'm thinking in particular of the way 'futures' are
defined when compared to just using an Ada rendezvous.

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

[Maciej Sobczak]

On 13 Sie, 14:47, "Peter C. Chapin" <pcc482...@gmail.com> wrote:

> Ada provides language syntax for concurrency. It feels cleaner to me than
> any of the C++ thread libraries I have used. Is that because those C++
> libraries just don't have the interface "right?" Maybe. But it might also
> be because it's just not possible to express concurrency in a nice clean
> way when using only library calls.

Right and this is the first valid argument for preferring built-in
language support over library-based API. I agree with that.
You have to, however, take into account the history differences
between these two languages. Adding the concurrency features at the
very beginning when the language is designed is more comfortable than
doing it later on. There is a general dislike for adding new reserved
words in subsequent language revisions for compatibility reasons. You
cannot break anything by adding new API in the standard namespace
(which is reserved anyway), but you can break a lot by introducing new
reserved words like "thread", "task" or "job".

You can argue that built-in support for a given feature is better for
the reasons of syntax clarity, but it could not be applied to C++
within its constraints.
I think this is a tradeoff, but the final solution is optimal for the
target community.

Note: Some time ago I have written an article on how a language-based
support for basic threading features could possibly look like in C++:

http://www.inspirel.com/articles/Possible_Syntax_For_Cpp_Threads.html

I still think that what was standardized will serve the community
better.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

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

[John McCabe]

On Fri, 14 Aug 2009 00:39:14 -0700 (PDT), Maciej Sobczak
<see.my.homepage@gmail.com> wrote:

>On 13 Sie, 14:47, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
>
>> Ada provides language syntax for concurrency. It feels cleaner to me than
>> any of the C++ thread libraries I have used. Is that because those C++
>> libraries just don't have the interface "right?" Maybe. But it might also
>> be because it's just not possible to express concurrency in a nice clean
>> way when using only library calls.
>
>Right and this is the first valid argument for preferring built-in
>language support over library-based API. I agree with that.
>You have to, however, take into account the history differences
>between these two languages. Adding the concurrency features at the
>very beginning when the language is designed is more comfortable than
>doing it later on.

c.f. Adding classwide programming to Ada 95.

>Note: Some time ago I have written an article on how a language-based
>support for basic threading features could possibly look like in C++:
>
>http://www.inspirel.com/articles/Possible_Syntax_For_Cpp_Threads.html
>
>I still think that what was standardized will serve the community
>better.

I'll have a look at that. As a matter of interest, a long time ago
there were parallel C compilers for the Transputer. How did the
thread/processors communicate/interact in those languages?

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

[Dmitry A. Kazakov]

On Fri, 14 Aug 2009 12:13:49 +0100, John McCabe wrote:

> I'll have a look at that. As a matter of interest, a long time ago
> there were parallel C compilers for the Transputer. How did the
> thread/processors communicate/interact in those languages?

That was an operating system called PARIX. The idea was that each processor
ran one process communicating with its neighbours over four serial 10Mbaud
links. Individual transputers didn't have much memory, normally 4MB. I
remember it was possible to have simple LIFO scheduling, so one could have
threads, but that was not the "intended" use. I played with an idea to make
an Ada (83) compiler for the beast. That never happened. It is close to 20
years ago... (:-()

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John McCabe]

On Fri, 14 Aug 2009 14:23:49 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On Fri, 14 Aug 2009 12:13:49 +0100, John McCabe wrote:
>
>> I'll have a look at that. As a matter of interest, a long time ago
>> there were parallel C compilers for the Transputer. How did the
>> thread/processors communicate/interact in those languages?
>
>That was an operating system called PARIX. The idea was that each processor
>ran one process communicating with its neighbours over four serial 10Mbaud
>links. Individual transputers didn't have much memory, normally 4MB. I
>remember it was possible to have simple LIFO scheduling, so one could have
>threads, but that was not the "intended" use. I played with an idea to make
>an Ada (83) compiler for the beast. That never happened. It is close to 20
>years ago... (:-()

I did a lot of work on Transputers, but in Occam which made it
relatively easy for me to understand Ada's tasking when I got taught
it. We had a C compiler for the T800 from Niche I think, but I don't
remember anything specific about an OS.

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

[Dmitry A. Kazakov]

On Fri, 14 Aug 2009 13:50:11 +0100, John McCabe wrote:

> On Fri, 14 Aug 2009 14:23:49 +0200, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> wrote:
> 
>>On Fri, 14 Aug 2009 12:13:49 +0100, John McCabe wrote:
>>
>>> I'll have a look at that. As a matter of interest, a long time ago
>>> there were parallel C compilers for the Transputer. How did the
>>> thread/processors communicate/interact in those languages?
>>
>>That was an operating system called PARIX. The idea was that each processor
>>ran one process communicating with its neighbours over four serial 10Mbaud
>>links. Individual transputers didn't have much memory, normally 4MB. I
>>remember it was possible to have simple LIFO scheduling, so one could have
>>threads, but that was not the "intended" use. I played with an idea to make
>>an Ada (83) compiler for the beast. That never happened. It is close to 20
>>years ago... (:-()
> 
> I did a lot of work on Transputers, but in Occam which made it
> relatively easy for me to understand Ada's tasking when I got taught
> it. We had a C compiler for the T800 from Niche I think, but I don't
> remember anything specific about an OS.

To me it was the opposite, we didn't use Occam, only the C compiler, which
was a torture, because it was a native compiler! You first booted it into a
transputer closest to the host, then feed it with the code over the link,
make yourself a coffee and after a couple of minutes, you could read the
compiled image back...

As for the PARIX, it was rather a monitor than a true OS. It had some
rudimentary support for host communication with marshaling connections over
the transit nodes. I also remember that it had a TCP layer over the links.

----------
I wonder if transputers will make a come back. Arguably a multi-core memory
sharing architecture is a dead end. Transputers had local memory. If they
return as systems with 1000 and more loosely coupled nodes (cores), what
will be a programming of look like? Ada's rendezvous will probably shine
again...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Niklas Holsti]

Dmitry A. Kazakov wrote:

> I wonder if transputers will make a come back. Arguably a multi-core memory
> sharing architecture is a dead end. Transputers had local memory. If they
> return as systems with 1000 and more loosely coupled nodes (cores), what
> will be a programming of look like? Ada's rendezvous will probably shine
> again...

The XMOS multi-core chips look like a born-again transputer system. See 
www.xmos.com. The CTO is David May of Transputer fame. But no Ada 
compiler so far, it seems.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[Dmitry A. Kazakov]

On Fri, 14 Aug 2009 16:58:00 +0300, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
> 
>> I wonder if transputers will make a come back. Arguably a multi-core memory
>> sharing architecture is a dead end. Transputers had local memory. If they
>> return as systems with 1000 and more loosely coupled nodes (cores), what
>> will be a programming of look like? Ada's rendezvous will probably shine
>> again...
> 
> The XMOS multi-core chips look like a born-again transputer system. See 
> www.xmos.com. The CTO is David May of Transputer fame. But no Ada 
> compiler so far, it seems.

Cool! Thank you for the information! I was unaware of this.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Brian Drummond]

On Fri, 14 Aug 2009 16:58:00 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> wrote:

>Dmitry A. Kazakov wrote:
>
>> I wonder if transputers will make a come back. Arguably a multi-core memory
>> sharing architecture is a dead end. Transputers had local memory. If they
>> return as systems with 1000 and more loosely coupled nodes (cores), what
>> will be a programming of look like? Ada's rendezvous will probably shine
>> again...
>
>The XMOS multi-core chips look like a born-again transputer system. See 
>www.xmos.com. The CTO is David May of Transputer fame. But no Ada 
>compiler so far, it seems.

Plus the starter system is pretty affordable...
https://www.xmos.com/products/development-kits/xc-1-development-kit
free time to play with it is more of a problem!

- Brian

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

[John McCabe]

On Fri, 14 Aug 2009 00:39:14 -0700 (PDT), Maciej Sobczak
<see.my.homepage@gmail.com> wrote:

>On 13 Sie, 14:47, "Peter C. Chapin" <pcc482...@gmail.com> wrote:

>Note: Some time ago I have written an article on how a language-based
>support for basic threading features could possibly look like in C++:
>
>http://www.inspirel.com/articles/Possible_Syntax_For_Cpp_Threads.html
>
>I still think that what was standardized will serve the community
>better.

As I read that I was reminded of the PAR construct, and PRI PAR etc
then I got to the section "Feasibility and similar existing solutions"
where you explicitly mention occam2. Cool.