NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/lang/ada/2226

Internet Message Format | 1992-07-29 | 3.4 KB

Path: sparky!uunet!dtix!darwin.sura.net!wupost!usc!nic!jonesm
From: [e-mail] (Matthew Jones)
Newsgroups: comp.lang.ada
Subject: Re: Review of "Ada & C++: A Business Case Analysis
Message-ID: <[e-mail]>
Date: 29 Jul 92 14:51:23 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: usa
Organization: CERFnet
Lines: 55

In article <[e-mail]> [e-mail] (David Kramer) writes:
>
>For one thing, Ada has a realtime paradigm built into the language. You can't
>have a realtime application without some means of interprocess communication.
>There is no commercially available C++ compiler today that I know of (and I've
>been looking) that allows for interprocess communication (by that I mean the
>ability to pass messages and object pointers between two C++ processes). So
>unless you modify the compiler or go through great pains to write your own
>mechanisms you cannot use C++ for a realtime application!

C (and C++) is not an operating system, real time or other. There are many
real time operating systems available, usually tied to the hardware
(ie VxWorks or OS9 for the 68k family...). This way seems much more sensible
to me than the Ada "we can solve everyones real time requirements on
all hardware with one paradigm." Also you might consider that many
people have found the Ada tasking model to be implemented very
poorly by the Ada vendors. Many people even in this group advocate
using the Unix process or threads interprocess paradigm (or other options
than Ada tasking) because the Ada tasking
model is so often a failure. Finally you might consider that Unix
(and the myriad of real time knockoffs) have plenty of (real time)
interprocess features and since C is often developed for some sort of
Unix (or real time) box there is a default standard of sorts.

>Also, for most serious real-time applications the runtime constaint checking
>and exception handling that Ada provides is crucial in providing a reliable
>system that is able to respond well to unpredictable and unexpected situations.
>Yes, C++ will  provide exception handling in the future, but today that is  not
>part of the language, and even when it will be, all runtime checks will have to
>be explicit in the code.

Interesting point. I am not sure if I agree or not. One has to consider among
other things that some people suppress checks in a deliverable system
(for speeds sake) and that exceptions can cause errors by making the structure
of the code more complicated, because exceptions are kind of like a nonlocal goto
(Exception handling reminds me of the use of the Unix C library function setlj,
in terms of lodgic flow).

>Finally, the C philosphy of 'give the programmer freedom at the expense of
>safety because he knows what he's doing' is continued to a great degree in
>C++ as well. While this might be acceptable in many applications, most real-time
>applications cannot afford this luxury.

Or ...C/C++ gives a programmer the freedom to chose the
best real time paradigm (operating system) for the job, rather than
requiring the same paradigm for everyone everywhere.

I do admit you make some good points. Also I think a POSIX real time
extensions standard will benefit everyone, C and Ada a like. And
just as note:
for C (but not as far as I know C++) there is a tasking extension
called ConcurrenC (sp?).

Matthew Jones
[e-mail]