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

[Maciej Sobczak <see.my.homepage@gmail.com>]

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