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?

[CTips]

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.

[Jeff C]

CTips wrote:

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.

Of course one could insert manual checks for those cases as well and it
is certainly possible to disable the automatic checks (in fact, I'd
argue a bit with some others about the "cheapness" of these checks. It
certainly varies from compiler to compiler and program to program but in
a moderate sized set of applications (~150K SLOC) I have measured the
penalty as high as 10-15%.). The automatic checks are available. You
can use them just during development and disable for production or if
you can live with them, then you can leave them on during
production..But , arguing that it is bad for the language to provide for
them because it might not be what you want is like arguing that the C++
standard should not include any references to floating point since
sometimes you have a processor that does not have an FPU and then you'd
feel more comfortable rolling your own floating point.

[Ed Falis]

On Sat, 12 Mar 2005 12:46:11 -0500, CTips <ct***@bestweb. net> wrote:

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);

type Four_Val is range 0 .. 3;
X : Four_Val;
begin
X := Four_Val (Some_Int);
...
pragma Assert (X < 4, "Something is seriously honked here");
-- Currently supported by GNAT; part of Ada 2005
-- Or write your own subprogram in Ada 95 as I did for AUnit
Do_Something_Wi th (X);

Sounds to me as though you just like to argue, because this one was pretty
silly.

- Ed

[Martin Krischik]

CTips wrote:

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.

Well actualy: since 4 is not a valid value for the enum four_val the Ada
compiler won't compile the code - Ada does not automaticy convert enums
into integer.

The way you would do it in Ada is

pragma Assert (x'Valid);

The 'Valid attribute checks if a variable contains a valid value.
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.

'Valid is used when a variable may contain an invalid value because of
calling a non Ada function or maybe a hardware problem :-) .

You may also use "pragma Volatile" if you fear that a variable chances its
value. Which is the very same in C89: without "volatile" the optimizer may
remove a access to a variable. No difference between C and Ada once
optimizer kicks in.

But then: most C programmers fear the optimizer while most Ada programmers
welcome the optimizer.

With Regards

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

[Martin Krischik]

Ioannis Vranos wrote:

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
Ups, right C++ 2003 is only the 5 year bug fix. But then: that isn't good
news. The C++ 98 is out for 7 years and you still have to look hard to find
a fully compliant compiler.
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 ).
I still look for one. Not trolling here - I would realy love to see at least
one fully compiant compiler.

As for major vendors: MS-C++ 7.1 and digital mars do not know about
"export". In my book 98% does not apply when a hole keyword is missing.

Side note: All Ada templates are "export" - so it is possible implement
export.
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.

With ISO number? If so tell me - I love to know. Without ISO: better then
nothing but not as helpfull to get companies like M$ to comply.

With reagards

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

[Robert A Duff]

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

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.
That's like saying "another problem with my refrigerator is that it
doesn't cook food". Ada's run-time checking is not intended to deal
with hardware failures of this nature. Neither are if statements in Ada
or C++.
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.
That could happen whether or not you have automatic run-time checks.
And in the above, there is no guarantee that x<4 in the code following
the assert -- the alpha particle could hit just after the assertion.

Just as in "if (X < 4) { ... X ... }", the second reference to X might
produce 17, if hardware can fail.
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.

You have no such control in either language under discussion. Compilers
can and do optimize code based on the assumption that the hardware is
perfect. If you don't like that, you have to write in assembly
language, or dump out the assembly language and make sure it does what
you want. Or use redundant hardware, or wrap the thing in lead, or any
number of other techniques that have nothing whatsoever to do with Ada
or C++ or run-time checking!

- Bob

[Ioannis Vranos]

Martin Krischik wrote:

Today in the latest compiler releases of the major vendors, compliance
is at least >98% (*there are* 100% compliant implementations ).

I still look for one. Not trolling here - I would realy love to see at least
one fully compiant compiler.

http://www.comeaucomputing.com

As for major vendors: MS-C++ 7.1 and digital mars do not know about
"export". In my book 98% does not apply when a hole keyword is missing.

Side note: All Ada templates are "export" - so it is possible implement
export.

Comeau supports export.

Regarding MS, upcoming VC++ 2005 (8) is even more compliant (>~99%) than
7.1.

They say that they do not support export though, because there is no
user demand (use) of it and it takes much work to implement it.

There are compliance tests for C++ too.

With ISO number? If so tell me - I love to know. Without ISO: better then
nothing but not as helpfull to get companies like M$ to comply.

Third party test suites as far as I know. MS strives for complete ISO
C++ conformance (except export).

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Martin Krischik wrote:

Well actualy: since 4 is not a valid value for the enum four_val the Ada
compiler won't compile the code - Ada does not automaticy convert enums
into integer.

The way you would do it in Ada is

pragma Assert (x'Valid);

The 'Valid attribute checks if a variable contains a valid value.

Now that I am thinking of it, isn't it a value range?
int main()
{
enum four_val {a,b,c,d};

four_val x;

x = 4;
}
C:\c>g++ temp.cpp -o temp.exe
temp.cpp: In function `int main()':
temp.cpp:7: error: invalid conversion from `int' to `main()::four_v al'

C:\c>
--
Ioannis Vranos

http://www23.brinkster.com/noicys

[CTips]

Ed Falis wrote:

On Sat, 12 Mar 2005 12:46:11 -0500, CTips <ct***@bestweb. net> wrote:

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);

type Four_Val is range 0 .. 3;
X : Four_Val;
begin
X := Four_Val (Some_Int);
...
pragma Assert (X < 4, "Something is seriously honked here");
-- Currently supported by GNAT; part of Ada 2005
-- Or write your own subprogram in Ada 95 as I did for AUnit
Do_Something_Wi th (X);

Sounds to me as though you just like to argue, because this one was
pretty silly.

- Ed

Did you compile it and see if the check was still in the generated code?
If it is, I'd start wondering about the quality of the compiler...
(unless there was something which disabled range propagation [or its
equivalent] for asserts...)

[Robert A Duff]

Martin Krischik <ma****@krischi k.com> writes:

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.

Now wait. Let's be fair. Sure, the ACATS test suite is a good thing.
But no test suite can ensure 100% compliance with the language
standard. Ada compilers do have bugs that are not caught by the ACATS!

Having a standard compliance test suite is an advantage of ADa,
but it's not a 100% guarantee of anything. (In fact, all Ada compiler
vendors I know of have huge regression test suites that go way beyond
ACATS.)

- Bob

P.S. Oops, I typed "ADa" above, instead of "Ada". I think I'll leave
that typo in, just to taunt the zealots who think spelling the name of
the language correctly is important. ;-) Come on folks, do you think
being pedantic about ADA vs. Ada will win converts? I think it adds to
the (mostly wrong) impression that Ada is all about rules and
regulations for no good reason.