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?

[Dr. Adrian Wrigley]

On Sat, 12 Mar 2005 09:42:26 +0100, Georg Bauhaus wrote:

Falk Tannhäuser wrote:

Dr. Adrian Wrigley wrote:

But what of features not present in either?

[...]

associative arrays (from Perl)

Wouldn't that be std::map in C++?

and in Ada 2005,

Ada.Containers. Hashed_Maps and Ada.Containers. Hashed_Maps

I have probably missed a trick in the C++, but I couldn't get
std::map code to compile (except in the trivial cases):

#include <map>

struct compoundindex {
int a, b, c;
};

int main()
{
std::map<compou ndindex, float> hash;
compoundindex fred = { 1, 2, 4 };

hash[fred] = 0.123;
}

cpptest.cpp: In function `int main()':
cpptest.cpp:14: error: `main()::compou ndindex' uses local type
`main()::compou ndindex'
(8 more lines of errors here!)

(what is the simplest C++ code to get this intent?)
--
The Ada associative arrays from the new draft standard
are specified as something like:

generic
type Key_Type is private;
type Element_Type is private;
with function Hash (Key : Key_Type)
return Hash_Type is <>;
with function Is_Equal_Key (Left, Right : Key_Type)
return Boolean is "=";
with function "=" (Left, Right : Element_Type)
return Boolean is <>;
package Ada.Containers. Hashed_Maps is...
Which clearly won't work unless you can find the three
function generic parameters. I don't see how this can be
used easily in a generic context.

I don't think I am being *that* unreasonable in asking for arrays
indexed by arbitrary types, without jumping through hoops :)
--
Adrian

[Dr. Adrian Wrigley]

On Sat, 12 Mar 2005 12:59:31 -0500, CTips wrote:

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.

If you need thread-private storage, there are *much* cheaper solutions.

isn't uplevel addressing usually zero cost? Are you saying it is
expensive whenever you use it? Or expensive on all programs, whether
or not it is used? Is it absent from C++ because of cost?
(I'm sure Robert understands this far better than I!)
--
Adrian

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

#include <map>

struct compoundindex {
int a, b, c;
};

inline bool operator <(const compoundindex &a, const compoundindex &b)
{
return (a.a<b.a && a.b<b.b && a.c<b.c)? true: false;
}

int main()
{
std::map<compou ndindex, float> hash;
compoundindex fred = { 1, 2, 4 };

hash[fred] = 0.123;
}

As a rule of thumb remember that most standard containers and algorithms
require the presence of operator <.
From a design perspective, in the example above, it is better to make
operator< a member of the struct. I made it a global function, in case
you want a POD struct.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Peter Koch Larsen]

"Dr. Adrian Wrigley" <am**@linuxchip .demon.co.uk.uk .uk> skrev i en
meddelelse
news:pa******** *************** *****@linuxchip .demon.co.uk.uk .uk...

On Sat, 12 Mar 2005 09:42:26 +0100, Georg Bauhaus wrote:

Falk Tannhäuser wrote:

Dr. Adrian Wrigley wrote:

But what of features not present in either?

[...]

associative arrays (from Perl)

Wouldn't that be std::map in C++?
and in Ada 2005,

Ada.Containers. Hashed_Maps and Ada.Containers. Hashed_Maps

I have probably missed a trick in the C++, but I couldn't get
std::map code to compile (except in the trivial cases):

#include <map>

struct compoundindex {
int a, b, c;
};

int main()
{
std::map<compou ndindex, float> hash;
compoundindex fred = { 1, 2, 4 };

hash[fred] = 0.123;

First off, std::map is not hash-based. It is a sorted container. Now in
order to use this, you need a comparing function. It can be the "standard"
ordering function for your key or it can be a user specified function.
}

cpptest.cpp: In function `int main()':
cpptest.cpp:14: error: `main()::compou ndindex' uses local type
`main()::compou ndindex'
(8 more lines of errors here!)
You must have snipped the most interesting errormessage.
(what is the simplest C++ code to get this intent?)
What you need here is a comparator:

bool operator<(compo undindex const& lhs,compoundind ex const& rhs)
{
.....
}

And the map should work. --
The Ada associative arrays from the new draft standard
are specified as something like:

generic
type Key_Type is private;
type Element_Type is private;
with function Hash (Key : Key_Type)
return Hash_Type is <>;
with function Is_Equal_Key (Left, Right : Key_Type)
return Boolean is "=";
with function "=" (Left, Right : Element_Type)
return Boolean is <>;
package Ada.Containers. Hashed_Maps is...
Which clearly won't work unless you can find the three
function generic parameters. I don't see how this can be
used easily in a generic context.

I don't think I am being *that* unreasonable in asking for arrays
indexed by arbitrary types, without jumping through hoops :)
But I do! How can you index without at least knowing if two values are
different or the same?
The C++ standard will have a hash-based container later. Those interested in
having one can download one from e.g. boost (I believe this container also
to be implemented by boost and prbably several others).
--
Adrian

/Peter

[Falk Tannhäuser]

Dr. Adrian Wrigley wrote:

I have probably missed a trick in the C++, but I couldn't get
std::map code to compile (except in the trivial cases):

#include <map>

struct compoundindex {
int a, b, c;
};

int main()
{
std::map<compou ndindex, float> hash;
compoundindex fred = { 1, 2, 4 };

hash[fred] = 0.123;
}

C++ associative containers (map, set, multimap, multiset) require
a "strict weak ordering" for their key types. In the present case,
it is enough to define the following 'operator<' to induce a total
ordering:

bool operator<(compo undindex const& x, compoundindex const& y)
{
if(x.a < y.a) return true;
if(x.a == y.a)
{
if(x.b < y.b) return true;
if(x.b == y.b)
return x.c < y.c;
}
return false;
}

Alternatively, if there is no natural definition for a general-purpose
operator< for the key type in question, it is possible to create a
comparison functor and to instantiate the container with it as
supplementary template parameter.
In either case, the container implementation uses the order to store its
elements in a balanced tree, so that element access becomes possible
with logarithmic complexity regarding to the number of elements currently
in the container.

Hash-based associative containers (guaranteing constant-time access as
long as there are no key collisions) are not (yet) provided by the
standard library but are widely available through third party / extension
libraries.

Falk

[Larry Kilgallen]

In article <wc************ *@shell01.TheWo rld.com>, Robert A Duff <bo*****@shell0 1.TheWorld.com> writes:

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

In article <wc************ *@shell01.TheWo rld.com>, Robert A Duff <bo*****@shell0 1.TheWorld.com> writes:

> 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.

Yes, I just said Pascal had that.

Oh, sorry, I must have thought you said "...in addition to what Pascal
has..." or something. My bad.

Anyway, nested functions are really nested in any useful sense if you
can't do uplevel addressing, right?

I much prefer that capability, but in Bliss (which lacks uplevel addressing)
there is some benefit provided by just the reduced visibility of the
nested function. I know for sure that I can call my nested function
RETRIEVE_STATUS without worrying about a conflict with something else
of the first name.

This is _certainly_ not a Bliss vs. Ada argument, but for me it is
a Bliss vs. C argument.

Please remember, however, that I only mentioned it because you asked :-)

[Larry Kilgallen]

In article <opsnlu5k0q5afh vo@localhost>, "Ed Falis" <fa***@verizon. net> writes:

On 13 Mar 2005 19:31:47 -0500, Robert A Duff
<bo*****@shell0 1.TheWorld.com> wrote:

As far as I know, all Ada compiler vendors take it seriously, and ensure
that their compilers pass 100% of the test suite. My company (Sofcheck,
Inc.) runs the ACATS every night, so we notice any regressions quickly.
We don't normally release a compiler that doesn't pass. I believe
AdaCore (the folks who produce the gcc version of Ada (GNAT)) do the
same.

Yes, we do.

As I said elsewhere, passing 100% of the ACATS, or 100% of any other
test suite, does not guarantee the absense of bugs (obviously).

Agree wholeheartedly.

But it is reassuring to know that a particular compiler does at least
some things correctly.

[Larry Kilgallen]

In article <pa************ *************** *@linuxchip.dem on.co.uk.uk.uk> , "Dr. Adrian Wrigley" <am**@linuxchip .demon.co.uk.uk .uk> writes:

On Sat, 12 Mar 2005 12:59:31 -0500, CTips wrote:

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.

If you need thread-private storage, there are *much* cheaper solutions.

But what if you actually need uplevel addressing ?

Why would one presume that users of uplevel addressing actually need
thread-private storage ? Thread-private storage would give just
a single instance per thread, not multiple nested instances per
thread.
isn't uplevel addressing usually zero cost? Are you saying it is
expensive whenever you use it? Or expensive on all programs, whether
or not it is used? Is it absent from C++ because of cost?

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 17:06:10 +0100, Falk Tannhäuser wrote:

Alternatively, if there is no natural definition for a general-purpose
operator< for the key type in question, it is possible to create a
comparison functor and to instantiate the container with it as
supplementary template parameter.

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. If the necessary functions are
not passed in and built up, you can't instantiate the map/hash.
This means that you can't write an implementation of a template/generic
function using a map/hash without changing some/all the implementations
and interfaces up the instantiation tree (am I right?). Obviously this
may not be possible, for example in large a multi-team or multi
language project. If you changed from a map to a hash, you'd have
to change all the interfaces to pass the hashing function instead
or as well as the comparison operator.

In Ada, a private (nonlimited) generic formal type guarantees
an equality operation and assignment is defined for the type.
These are the only logical requirements for an associative array.
I guess an efficient hash/map library could be written for
private nonlimited generic formals, but neither std::map nor
hashed maps meet this less restrictive requirement.

Put another way, neither language has minimally restrictive
associative arrays in their (or their standard library) specification.
--
Adrian

[jtg]

Turamnvia Suouriviaskimat ta wrote:

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?

I had the same problem several years ago.
I was learning Ada from tutorials (www.adahome.com) and online
articles. They were nice and I could get the ideas quickly, but
they were rather shallow and I just could not find answers to
many questions.

After buying one poor book (just the only I could find in local
bookstores) I decided to search for a good book in online bookstores.
I chose "Ada as a second language" by Norman Cohen and I am very glad
with it. All the questions that bothered me (some for months) were
answered in no time. AFAIR always when I needed to know something
about Ada I could find it in this book (well, one exception:
I could not find any information about preprocessor, but some
Ada programmers claim you don't need preprocessor in Ada).

As the title suggests, the book assumes that the reader is already
a skilled programmer :-)
In the book there are many comparisons to C, C++ and some other
languages. If an Ada feature is similar to something in C or C++,
the book mentions it to help pick the idea. If there are differences,
the book mentions them too, to help avoid potential pitfalls
or correct "bad habits", i.e. ways which are natural in one
language but are not the right way to do sth in Ada. So I think
the book would be as useful for you as it was for me.

Is it difficult to move from C/C++ to Ada? Maybe I can tell
you what you may expect (from my own experience only).
When you write in Ada, it is much, much easier to get bugless
program once you manage to compile it (of course if you make
use of Ada features). However, trying to compile an Ada code may be
sometimes very, very frustrating, when the compiler complains
about sth, you look into the code and cannot find out what a strange
rule you are breaking this time in this particular place.

And in Ada you must write a lot more.
You must declare everything, you must be explicit, you must obey
the rules which sometimes seem stupid.
And you must forget about these handy i++, --j, i+=a etc.