Teaching new tricks to an old dog (C++ -->Ada)

[Turamnvia Suouriviaskimatta]

I 'm following various posting in "comp.lang. ada, comp.lang.c++ ,
comp.realtime, comp.software-eng" groups regarding selection of a
programming language of C, C++ or Ada for safety critical real-time
applications. The majority of expert/people recommend Ada for safety
critical real-time applications. I've many years of experience in C/C++ (and
Delphi) but no Ada knowledge.

May I ask if it is too difficult to move from C/C++ to Ada?
What is the best way of learning Ada for a C/C++ programmer?

[Frank J. Lhota]

<ad******@sbcgl obal.net> wrote in message
news:9l******** ******@newssvr2 1.news.prodigy. com...

And that is the unfortunate aspect of the language: its foundation on C.

I once heard Stroustrup confess that, if he had had his druthers, he would
not have started with C as the seed language.

Stroustrup said in an interview that his preference would have been Algol
with classes.

I think that I probably would have preferred that as well!

[Robert A Duff]

"Frank J. Lhota" <NO************ ******@verizon. net> writes:

<ad******@sbcgl obal.net> wrote in message
news:9l******** ******@newssvr2 1.news.prodigy. com...

And that is the unfortunate aspect of the language: its foundation on C.

I once heard Stroustrup confess that, if he had had his druthers, he would
not have started with C as the seed language.
Stroustrup said in an interview that his preference would have been Algol
with classes.

Hmm... Isn't that language called Simula 67? ;-)
I think that I probably would have preferred that as well!

- Bob

[Ioannis Vranos]

Georg Bauhaus wrote:

I hope these example illustrate some points. They are not meant to
trigger a discussion as to whether an array is the best data
structure for everything. (Note that it might be necessary to read
values from the array/Vector using random access in O(1), and to
store and replace values in O(1), another reason to use an array.)

I forgot to say here that the cost of map's operator[] is O(log(n))
which is fairly cheap for large amount of data.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[red floyd]

Robert A Duff wrote:

"Frank J. Lhota" <NO************ ******@verizon. net> writes:

Stroustrup said in an interview that his preference would have been Algol
with classes.

Hmm... Isn't that language called Simula 67? ;-)

Darn! YOu beat me to it!

[Georg Bauhaus]

Ioannis Vranos wrote:

Georg Bauhaus wrote: I forgot to say here that the cost of map's operator[] is O(log(n))
which is fairly cheap for large amount of data.

compare O(log(n)) to O(1) where n is 1, 1000, 1_000_000.
Make this access a part of an inner loop.

Georg

[Georg Bauhaus]

Ioannis Vranos wrote:

Georg Bauhaus wrote:

Hm. Searching a *map* of entries at numeric keys is different
from scanning an array of values and counting occurences. What
are you trying to do here?
Just using the appropriate available container. :-)

Nope.

The std::vector is missing an instantiation argument which adds
the guarantee that no index value is outside the range
-800_000..12_000 _000;

vector provides method at() that performs range checking.

I think we've been through this. Again, this is not the point.
Also if you
want a vector that has signed integer subscripts or even floating point,
We want a vector type indexed by values between M and N only *and* we
want the compiler + tools to help us make data structures in accord
with these ranges. We want it to take advantage of what it can learn
from the type system which allows index range checking _at compile time_.

(How do you make a subrange of double, which is missing from
your example.)

Do you mean like this?

No. I mean a double subtype whose values range from N.M to N'.M'.

I think you are missing the point here. As someone else said this is
not about functions operating on containers.

[STL for constructs] These are bullet-proof code approaches.
Unfortunatly, this is not relevant in this discussion, which is not
just about algorithms.

Imagine an array shared between a number of threads. The program's
task is to count the number of occurences of a particular value
in the array. Examples:
1) A shop has 10 unique doors (use an enum). We can use whatever I like, perhaps strings. What is wrong with "Door 1"
etc? :-)
I see the smiley but this is what might be wrong with your
approach: a map indexed by strings is not the same as an array
indexed by ten and only ten numbers. (Actually the numbers are in a
type which includes only 10 numbers and their operations.)

Imagine a Matrix. String indexing of matrix element seems possible
but you'd rather have proper arrays. There is something
wrong with ("Row 5", "Column 1") indexing unless you have very much
time and a lot of RAM.
For each door 4 states
can be measured: open/closed, van/no van at the door.

OK, this sounds easy. What do you think? Since you want an array:

bool operator() (const Door &arg)
Nice. However, operator() doesn't return one out of four states,
it returns a Boolean, but o.K.
(If the door is closed and there is a van, you still want some action to
take place. Likewise for the other cases. I know you can write this,
no need as this is not the point, see below)
{
return open== arg.IsOpen() && van== arg.IsVan();
}
vector<Door> doors(10);
Here you can see one point that you might want to demonstrate:
The compiler won't tell you that there is something wrong
with

doors[10].SetOpen().SetN oVan();

Worse, the program won't tell you either. This shows the missing
link between vector indexing and the base type system in your
approach. You could use

doors.at(10).Se tOpen().SetNoVa n();

and handle the exception _at run time_.
In Ada, the compiler will tell you: "index value 10 is no good!"
because the array "doors" can only be indexed by values effectively
between 0 .. 9. These and only these are the values of the type
enumerating the ten doors, and only these are allowed as index
values x in expressios doors(x).
No exception handling, no .at() needed when you listen to your
compiler and fix the indexing error before you deliver a program.
You get this for free as a result of the language's type handling
at compile time.

2) A 5-player team, each team is identified by number drawn from a fixed
set of team numbers. An array (an array, not some other data
structure) measures the number of players from each team present in
a room. Count the number of odd-team players in a room.

This is easy too. I do not get your point. This can be done with arrays
as also with other containers. Why should we be restricted to one type
of container?

There is a reason that arrays still exist. One of the reasons
should be obvious when comp.realtime is on the recipient list.
Again, imagine a wave file manipulation process.
A map indexed by strings is probably not the recommended container
when you need fast matrix computations. In fact, a map might not be
suitable at all irrespective of its key type, when r/w should be in O(1).

- Given an enum, and
- given a language that allows the enum as a basis for the construction
of an array type in the type system (not using some run time computation
method, like those you have shown here, IINM)
- given that the compiler can use its knowledge of the enum
+ when it sees an array type based on the enum
+ when it sees an array
+ when it sees an array indexed by a statically known enum value
+ etc.,
you have
(a) useful names for objects in your problem domain, checked at compile-time
(b) a conceptual link between the enum (naming the single items) and
a container _type_ (containing these items); you cannot use anything
but these named numbers for indexing
(c) the fastest possible access, for both reading and writing, possibly
checked at compile time
(d) etc.

The STL descriptions provide further reaonsing why there can be restrictions
on the uses of specific containers in specific situations, viz. O(f(n)).

I hope these example illustrate some points. They are not meant to
trigger a discussion as to whether an array is the best data
structure for everything. (Note that it might be necessary to read
values from the array/Vector using random access in O(1), and to
store and replace values in O(1), another reason to use an array.)

What if a compiler or other tool can show that in the following expression
(pseudo notation)

array_variable. at_index [n + m] <- f(x)

does not need an index range check on the lhs? (Again, yes, it is possible
to write correct programs. The question is, does one notation + compilation
system have advantages when compared to another? What is the price to pay?)
It is not difficult to write a
container getting a signed integer as a subscript and have range checking.

Which is not the point.

Georg

[Randy Brukardt]

"Paul Dietz" <pa**********@m otorola.com> wrote in message
news:d1******** **@avnika.corp. mot.com...

ad******@sbcglo bal.net wrote:

Still, when we hold one development environment (an Ada compiler)
to a higher standard, we need to understand that difference when
making comparions. It costs a great deal more money to produce
a compiler that must pass validation (now conformity) than to
create one in which the defects are intended to be discovered
by the users and fixed in some future release.

If one has a copy of the validation test suite, why is it necessary
to wait for the users to find the bugs? Is it that you have to pay
for the cost of fixing the bugs that the users would never encounter?

I'm not quite sure what your point is. But I think Richard was comparing a
compiler that was conformity tested against one that was not. So, such a
system wouldn't have been tested against any test suite.

Of course, in actual practice, there is a continuum of testing practice,
from formal conformity assessment to completely untested. I doubt that there
are many commercial systems on either extreme of that continuum, but Ada
systems tend to be close to the formally tested end.

Randy.

[Ioannis Vranos]

Georg Bauhaus wrote:

We want a vector type indexed by values between M and N only *and* we
want the compiler + tools to help us make data structures in accord
with these ranges. We want it to take advantage of what it can learn
from the type system which allows index range checking _at compile time_.

At first, it is easy to write a container in C++ that accepts a
specified range for indexes. The only reason that there is not one, is
because it does not make sense in C++ (when I learned some Pascal in the
past, I could not understand what was the use of the ability to use
negative indexes in arrays. The [0, +] style maps closely what is
happening in the machine.

Also it is possible to define range-checked at run-time, operations.
vector::at() is an example.
vector is also a dynamic-type array, so placing compile-time bounds
checking isn't possible/doesn't make sense.
For fixed size arrays and containers it is true, the compiler does not
catch at compile time any out of boundaries access. However we can do
this explicitly, by using compile-time checked assertions. For example:
#include <vector>
#include <boost/static_assert.h pp>

int main()
{
using namespace std;

const int MAX_SIZE=10;

vector<int> vec(MAX_SIZE);
// Many lines of code
BOOST_STATIC_AS SERT(10<MAX_SIZ E);

vec[10]=4;
}
C:\c\temp.cpp In function `int main()':

14 C:\c\temp.cpp incomplete type `boost::STATIC_ ASSERTION_FAILU RE<
false>' used in nested name specifier

No. I mean a double subtype whose values range from N.M to N'.M'.

May you give an example for a container along with such a subtype?
Here you can see one point that you might want to demonstrate:
The compiler won't tell you that there is something wrong
with

doors[10].SetOpen().SetN oVan();

Worse, the program won't tell you either. This shows the missing
link between vector indexing and the base type system in your
approach. You could use

doors.at(10).Se tOpen().SetNoVa n();

and handle the exception _at run time_.
In Ada, the compiler will tell you: "index value 10 is no good!"
because the array "doors" can only be indexed by values effectively
between 0 .. 9. These and only these are the values of the type
enumerating the ten doors, and only these are allowed as index
values x in expressios doors(x).
No exception handling, no .at() needed when you listen to your
compiler and fix the indexing error before you deliver a program.
You get this for free as a result of the language's type handling
at compile time.

Will the Ada compiler tell you this, for user-defined types too? Or is
this restricted to built-in arrays? If the latest is true, then its
value isn't that much.

There is a reason that arrays still exist. One of the reasons
should be obvious when comp.realtime is on the recipient list.
Again, imagine a wave file manipulation process. A map indexed by
strings is probably not the recommended container
when you need fast matrix computations. In fact, a map might not be
suitable at all irrespective of its key type, when r/w should be in O(1).

OK, although O(log(n)) is fairly cheap, let's stick to O(1). However
personally I think that the value of defined subranges in the style
-1000, -400 has not any practical use.

- Given an enum, and
- given a language that allows the enum as a basis for the construction
of an array type in the type system (not using some run time computation
method, like those you have shown here, IINM)
- given that the compiler can use its knowledge of the enum
+ when it sees an array type based on the enum
+ when it sees an array
+ when it sees an array indexed by a statically known enum value
+ etc.,
you have
(a) useful names for objects in your problem domain, checked at
compile-time

What do you mean by names?

(b) a conceptual link between the enum (naming the single items) and
a container _type_ (containing these items); you cannot use anything
but these named numbers for indexing

Which has no value in the world of C++, but I guess many things in Ada
depend on this.

(c) the fastest possible access, for both reading and writing, possibly
checked at compile time

Fastest possible access in C++. Checked at run-time. Explicitly checked
at compile-time with compile-time assertions (which are restricted only
to constants), but is the Ada compile-time boundaries checking available
to user-defined containers? If not, can compile-time assertions be used?
(d) etc.

The STL descriptions provide further reaonsing why there can be
restrictions
on the uses of specific containers in specific situations, viz. >O(f(n)).

The access of vector, deque, string, valarray and bitset (and built in
arrays) is O(1) and of map O(log(n)) which is fairly cheap.

If you have access to TC++PL 3, you may check page 17.1.2 on page 464.

I hope these example illustrate some points. They are not meant to
trigger a discussion as to whether an array is the best data
structure for everything. (Note that it might be necessary to read
values from the array/Vector using random access in O(1), and to
store and replace values in O(1), another reason to use an array.)

What if a compiler or other tool can show that in the following

expression (pseudo notation)

array_variable. at_index [n + m] <- f(x)

does not need an index range check on the lhs? (Again, yes, it is possible to write correct programs. The question is, does one notation + compilation system have advantages when compared to another? What is the price to

pay?)
Apart from being eager to see whether this compile-time range checking
is available to user-defined containers, :-) in C++ there is no much
need for run-time boundary checking, if programming properly. Of course
one can always program improperly. :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Georg Bauhaus wrote:

I forgot to say here that the cost of map's operator[] is O(log(n))
which is fairly cheap for large amount of data.

compare O(log(n)) to O(1) where n is 1, 1000, 1_000_000.
Make this access a part of an inner loop.

If you do the maths, you will see that log(10^6) isn't that large.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Pascal Obry]

Ioannis Vranos <iv*@remove.thi s.grad.com> writes:

arrays. The [0, +] style maps closely what is happening in the machine.

Certainly. But the Ada model can maps more closely to the domain problem.
And this is an important point. We are not writting software for the machine
but to solve problems. Most of the time you just don't care how such data will
be handled by the machine (i.e. how the compiler will generate the code).

Pascal.

--

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