Re: Any research putting c above ada?

[clines@delete_this.airmail.net (Kevin Cline)]

"John G. Volan" <johnvolan@sprintmail.com> wrote:

>> That's fine for embedded applications where the amount of data to be handled
>> is carefully defined ahead of time.  It's useless for desk-top applications,
>> where the size of the data to be handled, and the physical resources available
>> to handle it vary widely from user to user.  For those applications, you must
>> resort to truly dynamic data structures, and Ada's arrays are of little use.
>
>Of course, but what were you expecting? The semantic level of Ada95 is
>comparable to that of C++, and neither language was designed to include
>the kind of unbounded ADTs you're looking for -- at least, not as
>built-in features of the language.  Rather, these languages provide the
>raw materials from which such ADTs might be constructed.  A standard
>library might contain such examples as Ada.Strings.Unbounded in Ada95
>and the STL in C++, but these components are _written in_ the given
>language, not _built into_ the language (i.e., implemented with compiler
>support).

That's exactly what I was expecting.  This thread has gotten away from the
post I originally replied to.  That post essentially said that Ada's arrays
were vastly superior to C arrays because in Ada one could write a function
that would read a line count, then declare an array of strings of that size,
read the lines into the array, and then return that array.  All I wanted to do
was point out that:

1.  It's a silly example.
2.  Generally the entire array has to be deep-copied to be returned, so the
return statement from that function hides a whole lot of overhead that will
surprise many programmers.  I don't know about the Ada'95 ARM, but I think the
Ada'83 ARM should have contained some comment on this.

Still, it IS nice to be able to declare temporary arrays on the stack that
have a size declared at run-time.  I don't know if such code actually runs
faster than code that allocates the array on the heap and then frees it, but
it's easier to write.

>> This is one of the biggest blind spots I observed in experienced Ada
>> programmers in a shop a few years ago.  Ada programmers tend to use arrays
>> instead of more dynamic data structures, resulting in inefficient and
>> inflexible applications.  
>
>This observation is not necessarily universal of all Ada programmers.

Of course it isn't.  That is why I was careful to specify the extent of my
observation.

>> OTOH, I have observed that the availability of the
>> C++ STL containers is already expanding the toolkit of average C++ developers.
>
>There's nothing about the STL containers that couldn't be done in Ada95
>-- probably much more simply, and thus, IMHO, better. 

It's hard to say until it's been done.  I think the lack of automatic
instantiation in Ada will make any such library somewhat more cumbersome to
use than the C++ STL.

>The advantange of the STL in C++ is that someone has gone to the trouble
>of working it up as a "standard" toolkit, and the general C++ user
>community is accepting it as such. 

Precisely.  This relative slowness of the Ada community in agreeing on such
standards was one of the biggest factors that prevented Ada'83 from being more
widely adopted.

>There's no technical obstacle to this, only an economic/cultural one.

"More projects fail due to sociological reasons than technical ones"
Tom DeMarco, Peopleware