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?

[REH]

"Ioannis Vranos" <iv*@remove.thi s.grad.com> wrote in message
news:1110607809 .837000@athnrd0 2...

I am pretty sure one can write a library that can enable just that.
Now that I am thinking of it, there are some, and let's begin from Boost:
http://www.boost.org/libs/integer/integer.htm
#include <boost/integer.hpp>
int main()
{
using namespace boost;

int_t<24>::leas t my_var;
}

with "least" being the smallest built-in type that supports the given bit
count.

You see, that's easy. :-) Just "plug in" Boost.

Yes, I'd used Boost. It's an amazing library, but the above is not
equivalent to what I wrote. The major different, and the feature I'd mainly
like to see in C++ in that the definition of Byte above is a unique type.
It can participate in overload resolution. Different typedefs using
int_t<24> are not distinct. I know this can be achieved with an extra
template parameter, enums, or classes, but I don't want to go to that kind
of effort just to tell the compiler to treat it as a unique type. Another
difference, in C++ you cannot create an array of int_t<3> and have all the
element be exactly 3 bits. Using 'size and 'component_size (or even pragma
pack), in Ada you can. I can also specify a range other than zero to max.
You may not care (as your other post suggests), but for fault tolerance, I
do.

Don't get me wrong. I'm not one of the C++ bashers (I think
language-bashing is nonsense). C++ is my favorite language. But Ada has
some really nice features I'd like to see in it. I don't care about the
forced range checking. I don't think that "fits" C++. I would however,
like to be able to easily define unique types of primatives. Being able to
portable and explicitly define its size in bits (so that arrays and structs
obey) would be nice, too.

[Ioannis Vranos]

REH wrote:

Not all of us do "regular application programming." I write
mission-critical systems. In such an environment, it is non-sense NOT to
define ranges for data types that have them. I would rather it "failed
loudly" when a variable strayed out of range and raised an exception I can
recover from, then continuing to run, causing unknown or undefined behavior.

If you are having for loops with arrays in mind, a simple high level
safe C++ solution exists. Consider:
#include <algorithm>
#include <vector>

inline int doubleF(const int &arg) { return 2*arg; }

// ...

vector<int>some Array(10, 1);

// ...

transform( someArray.begin (), someArray.end() ,
someArray.begin (), doubleF );
This can't ever be out of bounds.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[REH]

"Ioannis Vranos" <iv*@remove.thi s.grad.com> wrote in message
news:1110632256 .180589@athnrd0 2...

If you are having for loops with arrays in mind, a simple high level safe
C++ solution exists. Consider:
#include <algorithm>
#include <vector>

inline int doubleF(const int &arg) { return 2*arg; }

// ...

vector<int>some Array(10, 1);

// ...

transform( someArray.begin (), someArray.end() ,
someArray.begin (), doubleF );
This can't ever be out of bounds.

Much more just array accesses. Variables of particular units that must stay
within range (i.e., lat/long, BAMS, radians, velocities, altitudes, depths,
etc.). I'm not saying this can't be done in C++, because I've done it.
It's just easier in Ada.

[Robert A Duff]

Pascal Obry <pa****@obry.or g> writes:

This is not ok, P3 deeper than PA.

<<
procedure Demo is

type PA is access procedure;

procedure P (Proc : in PA) is
begin
null;
end P;

procedure P1 is
begin
null;
end P1;

procedure P2 is
procedure P3 is
begin
null;
end P3;
begin
P (P3'Access);
end P2;

begin
null;
end Demo;

However, it will be legal to pass a nested procedure in Ada 2005,
and GNAT already supports that. The rules still prevent dangling
pointers:

procedure P (Proc : access procedure(...)) is
begin
Proc;
end P;

procedure P2 is
P2_Local: Integer := 0;
procedure P3 is
begin
P2_Local := P2_Local + 1;
end P3;
begin
P (P3'Access);
end P2;

In Pascal's example, P can assign Proc into a global variable, and it
can be called after P2 returns, which is why it is forbidden to pass
P3. In my example, on the other hand, you can pass P3, but P cannot
assign Proc into a global variable. Either way, no dangling pointers,
unless you play some low-level tricks.
Can templates recurse?

Yes.

I think he meant "can generic instantiation be recursive", and the
answer is "no, it cannot". A generic procedure can call itself,
but that's not the same thing.

Can you program "const correct"? Eg. if you declare a member function
as const the compiler will help you not mutate the object or call any
functions that do. Also, if you pass a parameter as a const reference,
you will not be able to mutate the object the parameter references.

Not sure to understand everything. But yes, if you have:

Value : constant String := "whatever";

It will never be able to mutate Value.

.... and 'in' mode parameters can't be modified, and you can't modify
what an access-to-constant points at.

I think it's a bit more difficult to "cast away const" in Ada,
and the results can be bad news.

- Bob

[Robert A Duff]

Falk Tannhäuser <fa************ *@crf.canon.fr> writes:

I believe Ada also has exceptions, but I don't know if
they work in the same manner. Does Ada have some equivalent
of C++ constructors and destructors?

Yes. I believe that the C++ exception design was based on Ada
exceptions, and the Ada finalization stuff was based on the C++
features. The differences in these areas are fairly minor.
I guess the biggest one is that a C++ exception is a first-class
object, so you can pass extra information along with a thrown exception
in a straightforward way, whereas in Ada, the mechanism for passing
extra information is an ugly kludge.

Another difference is that Ada doesn't rely so heavily on constructors
-- there is something like a constructor in Ada, but the *usual* way to
create objects is simply to call a function that returns one, as in:

X: Int_Set := Empty_Set;
Y: constant Int_Set := Singleton_Set(1 7);

- Bob

[Robert A Duff]

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

[Martin Krischik]

Peter Koch Larsen wrote:

I do not believe that to be the problem. There is a standard and there are
commercial libraries out there to test conformance. The problem rather
lies in other areas such as:

- compiler vendors wanting to be backwards compatible.
- compiler vendors wanting to get a grip on their customers by ofering
"extensions " to the language.
- compiler vendors who don't care if their product is standards-compliant.
How very true.

By 1990 or so when compilers conforming reasonably closely with the C
standard became available, it appears likely that essentially all new
development was being done in Ada. Under the circumstances, it would be
rather surprising if the C code was ever rewritten into standard C.

On the last project I was working with a 3rd party library which had not
a single "const" in its header files - probably to be compatible with old
compilers. So a major "savety" feature of C89 was still missing in
current code - and affected our current development - since I has to use
that library.

You could use another library out there. Cars are not bad just because one
manufacturer ships buggy cars out.

It was a very special lib with only a very few alternatives out there.

The most compatible C/C++ compiler AFAIK is digital mars
(http://www.digitalmars.com) with "only" 4 C99 features missing:
(http://www.digitalmars.com/ctg/ctgLa...unimplemented).

But even digital mars aims only at the C++98 and not the current C++
2003. And there are still 4 features missing:
(http://www.digitalmars.com/ctg/ctgLa...unimplemented).
Did you have a look at Comeau C++?
No. Got a link to have a look?
Maybe just maybe - if there realy was any standart compiler available -
but
there isn't - the C/C++ compiler vendors are allways one release behind
the
actual ISO standart.

If you look at C++ (i can't comment on C), all major vendors i know of
have a high level of compliance.

For the '98 standart yes - but how about the '03 standard. As I said - one
release behind.

And they havn't got 100% compliance - as the Ada compiler vendors have. And
they can indedd claim that - Ada has the ACATS test - pass the test you are
100% compliant - fail the thest and (almost) no customer will consider your
offer.

By contrast, comparing modern C++ to the pre-standard C shows _large_
improvements in nearly all areas. This is due in part to the changes in
the language itself, but perhaps even more so to improved understanding
of how to use the language.

True - the former slim languages designed by individuals have become fad
languages desined by the ISO commitie ;-). This is simply not true.
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.
The "ISO commitie" you refer to consists of
people using C++ in daily life.

So are the Ada commitie memebers. Still Ada was/is bashed for beeing a
commitie language and C++ isn't.
It is true that a programming language need some minimum features set to
be
usefull. And that feature set is a lot larger then most belive. If a
successfull language does not provide that set it will be bolted on
later. If anything the current C/C++ ISO standards clearly show that the
advocates
for slim languages hat been wrong all along.

I have to disagree again. C/C++ has been most succesfull as a language if
you measure that by the number of applications written in that language.

Shure C/C++ are successfull I never said any different - I just pointed out
that C/C++ are not slim and lightweight languages any more. They have
become fat over time. Only the fat does not show - because theree so many
implit features which only show when you read the ISO standart itself.

And since the very successfull C/C++ have become as big as they are I
rightfully claim the the advocates for slim languages hat been wrong all
along.

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.

Martin
--
mailto://kr******@users. sourceforge.net
Ada programming at: http://ada.krischik.com

[Ioannis Vranos]

Martin Krischik wrote:

For the '98 standart yes - but how about the '03 standard. As I said - one
release behind.

C++03 is C++98 bug fixed. You can have a look at the list of fixes:

http://www.acceleratedcpp.com/author.../revisions.pdf
And they havn't got 100% compliance - as the Ada compiler vendors have.

Today in the latest compiler releases of the major vendors, compliance
is at least >98% (*there are* 100% compliant implementations ).
And
they can indedd claim that - Ada has the ACATS test - pass the test you are
100% compliant - fail the thest and (almost) no customer will consider your
offer.

There are compliance tests for C++ too.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[CTips]

Simon Wright wrote:

Pascal Obry <pa****@obry.or g> writes:

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

protected type Atomic_Integer is
procedure Increment;
private
Value : Integer;
end Atomic_Integer;
-- Implementation
protected body Atomic_Integer is
procedure Increment is
begin
Value := Value + 1;
end Increment;
end Atomic_Integer;
Will that generate:
L0:
lwlock temp,&Value
add temp,temp,1
stwcond temp,&Value
if( failed ) goto L0;
or will it generate something much more heavy-weight.

Google shows me lwlock as a C function in the PostGres support groups;
I don't know what machine architecture has these instructions? PowerPC?

Yes, and alpha.

It could be used by any compiler as part of a low-level
implementation, of course, but it's hardly likely that a C compiler
could use it off its own bat. Why whould it want to unless you the
programmer tells it to?

If you're talking about assembler inserts in C -- for Pete's sake, we
can insert assembler in Ada as a last resort if it's needed.
Can you do the following in Ada: use an assembler inset for just stwcond
and lwlock, and use C for everything else, and then get the expected
assembly code.
What happens with lwlock about priority inversion?
You don't need it. Thats one of the big advantages about lock free schemes.

No protected type implementations will be so light.

Umm ... look at the set of lock-free data-structures out there. Quite
heavy-weight structures can be implemented, including a queue where a
thread can be adding elements while other threads are removing elements.

[CTips]

REH wrote:

"Ioannis Vranos" <iv*@remove.thi s.grad.com> wrote in message
news:1110609321 .686344@athnrd0 2...

Myself thinks though that this whole range specialisation thing is
non-sense for regular application programming at least.

Indeed. :-)

Not all of us do "regular application programming." I write
mission-critical systems. In such an environment, it is non-sense NOT to
define ranges for data types that have them. I would rather it "failed
loudly" when a variable strayed out of range and raised an exception I can
recover from, then continuing to run, causing unknown or undefined behavior.

Thats another problem with Ada's run-time checking. If you're using it
in an environment where the hardware may "fail" [e.g. alpha particles
randomizing memory], the checks are quite often in the wrong place.

For example, look at the Ada equivalent of the following code.
typedef enum {0, 1, 2, 3} four_val;
four_val x;

x = (four_val) some_int;
....
assert( x < 4);

The compiler will drop in a check at the cast to ensure that the wrong
value is not getting stored into x. Then, it will proceed to eliminate
the check that x < 4, because it knows that 0..3 are the only legal
values of x. However, if there is a hardware bug, the value of x will
get changed between the definition point and the use point.

When bringing up hardware, I like to have a little more control over
where the run-time checks are going to be placed. This is another niche
situtation in which the compiler's "automatic" checking does the wrong
thing.