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?

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

the problem as I suggested in my previous post is that you have to
pass in the comparison operator or hash function down the tree
of template/generic instantiation, (composing them along the way)
if you want to use maps/hashes.

In the standard library containers and algorithms case you do not pass
any function to the container. operator< is implicitly used.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote:

Dr. Adrian Wrigley wrote:

the problem as I suggested in my previous post is that you have to
pass in the comparison operator or hash function down the tree
of template/generic instantiation, (composing them along the way)
if you want to use maps/hashes.

In the standard library containers and algorithms case you do not pass
any function to the container. operator< is implicitly used.

The comparison operator here seems to be a generic formal function
parameter with a default value. This must be available at instantiation.
The operator becomes part of the interface (implicitly or explicitly) for
any code instantiating the std::map. Where does the code for the
comparison operator go? It *has* to go at the point the class
is defined. This could be at the other end of a hierarchy of
generic instantiations. The result is that the implementation
requirement (needs a comparison operator) has propagated up the
generic hierarchy to some otherwise completely independent code as an
interface requirement. I'm sorry I can't explain this any better!
(should I give a code example?)
--
Adrian

[kevin cline]

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

Consider a military commmand and control system, a
complex system with a lot
of requirementss built in. Now, think of this
system in terms of its size: 4.5 million
lines of source code.

But not all lines of source code are created equally. Written in a
more expressive language the application might be only half that size,
or most likely even less.

[kevin cline]

Martin Krischik wrote:

Shure it is true: The C++ ISO standard has ruffly 200 pages more then the Ada ISO standard. The C standard is a few pages shorter - but C hasn't got object orientation, concurency, real time and distributed system included.

No surprise there. The C++ standard covers the C++ standard library.
But prove me wrong and show me any successful slim language - which has not become fat (either by language or by build in library) withing 10 years of becomming successfull.

Personally I prefer slimmer languages and fatter libraries whenever
possible.

[Dmitry A. Kazakov]

On Mon, 14 Mar 2005 19:29:25 GMT, Dr. Adrian Wrigley wrote:

On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote:

Dr. Adrian Wrigley wrote:

the problem as I suggested in my previous post is that you have to
pass in the comparison operator or hash function down the tree
of template/generic instantiation, (composing them along the way)
if you want to use maps/hashes.

In the standard library containers and algorithms case you do not pass
any function to the container. operator< is implicitly used.

The comparison operator here seems to be a generic formal function
parameter with a default value. This must be available at instantiation.
The operator becomes part of the interface (implicitly or explicitly) for
any code instantiating the std::map. Where does the code for the
comparison operator go? It *has* to go at the point the class
is defined. This could be at the other end of a hierarchy of
generic instantiations. The result is that the implementation
requirement (needs a comparison operator) has propagated up the
generic hierarchy to some otherwise completely independent code as an
interface requirement. I'm sorry I can't explain this any better!

It can be formulated in two words: "contract model" is what C++ templates
lack.

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

[Georg Bauhaus]

Dr. Adrian Wrigley wrote:

On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote:

Dr. Adrian Wrigley wrote:

the problem as I suggested in my previous post is that you have to
pass in the comparison operator or hash function down the tree
of template/generic instantiation, (composing them along the way)
if you want to use maps/hashes.

In the standard library containers and algorithms case you do not pass
any function to the container. operator< is implicitly used.

The comparison operator here seems to be a generic formal function
parameter with a default value.

I think this description is o.K. for Ada, but perhaps not
for C++. E.g. you can place the following in three different
files (modules), somewhat like in Ada, and you don't have
to write the < into the module containing the compared type.

// 1

#include "comp.h"
#include <map>

bool operator< (V a, V b) { return a.val() < b.val(); }

int main()
{
std::map<V, float> m;
V key1, key2 = V(3);

m[key1] = 1.0;
m[key2] = 1.0;

return 0;
}

// 2

class V {
int v;
public:
V() : v(0) {}
V(int val) : v(val) {}
int val() const;
};

// 3

#include "comp.h"

int V::val() const {
return v;
}

Georg

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

The comparison operator here seems to be a generic formal function
parameter with a default value. This must be available at instantiation.
The operator becomes part of the interface (implicitly or explicitly) for
any code instantiating the std::map. Where does the code for the
comparison operator go? It *has* to go at the point the class
is defined.

Yes. However if you later convert to a hash container, it can remain
around unused in the particular container.

This could be at the other end of a hierarchy of
generic instantiations. The result is that the implementation
requirement (needs a comparison operator) has propagated up the
generic hierarchy to some otherwise completely independent code as an
interface requirement. I'm sorry I can't explain this any better!
(should I give a code example?)

Yes, also operator< is used to all containers and algorithms where a
comparison takes place, like sorting algorithms (std::sort,
std::stable_sor t, etc).
I can not understand how this could be avoided for such operations and
containers, since a comparison is required.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Robert A Duff]

CTips <ct***@bestweb. net> writes:

Robert A Duff wrote:

Ki*******@SpamC op.net (Larry Kilgallen) writes:

Even Bliss has nested functions. What Ada has that Pascal has in addition
to nested functions is uplevel addressing, allowing an inner function to
access data declared in outer scopes. Heh? Pascal has that. In fact, practically every programming language
outside the C family has this feature. It's quite useful -- almost
essential in multi-threaded programs.
- Bob

Yeah, and don't ask what it costs you. I'd carefully forgotten about all
the grungy details about displays and static/dynamic chaining, and you
had to remind me. I particularily like solutions that reserves a
register for the top-of-display/top-of-static-chain. Thats right - blow
away a register for that. And then of course the cost of
maintaining/walking those structures.

I beg to differ. Uplevel references can be implemented as efficiently
as parameter passing (which is what you normally do in C-family
languages as a substitute). And it can cost nothing when not used.
It can also cost nothing when the procedures involved can be inlined
(which is a very common case -- the reason I'm writing a nested procedure
is usually so I can pass it to an iterator, and both the iterator and
the nested procedure are usually small enough to deserve inlining).

(I'm not a big fan of displays, by the way.)
If you need thread-private storage, there are *much* cheaper solutions.

This seems like a nonsequitor -- thread-private storage and uplevel
references are different things, with different (though somewhat
related) purposes. C and C++ have neither, which can make using thread
packages painful, though gcc supports uplevel references (for both C and
Ada, and I think C++ also).

And having implemented both, I'd say thread-private storage is
generally more expensive than uplevel references. What's your
much cheaper solution?

- Bob

[Ioannis Vranos]

kevin cline wrote:

Personally I prefer slimmer languages and fatter libraries whenever
possible.

However C++ has also the ideal to be able to write these libraries with
the language itself.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

It can be formulated in two words: "contract model" is what C++ templates
lack.

I think "explicit contract model" is slightly better, and perhaps
you can say something about the closure that the compiler needs
to find out whether a contract is fulfilled (Can_Copy etc.)?
Georg