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

[CTips]

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.

 

[Martin Krischik]

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

 

[Jeff C]

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]

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_With (X);

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

- Ed

 

[Martin Krischik]

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

http://www.acceleratedcpp.com/authors/koenig/c++std/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.

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.

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

 

[Robert A Duff]

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]

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.

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]

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_val'

C:\c>

 

[CTips]

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_With (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]

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.

 

[Martin Dowie]

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 what CBIT is for.

Cheers

-- Martin

 

[Robert A Duff]

That was exactly my point: it started out as a DoD-funded project. The
question is about what happened then -- how willing the DoD was to open
the project to the public at large. As it was, the project was done
with DoD funding, but was really done at and by universities. While it
is openly acknowledged to have fulfilled its original intent extremely
well, nearly every choice in its design and implementation was about as
UN-military as possible. Despite this, it took 20+ years before it was
really open to the general public.

Had even ONE element in the design or implementation fit even slightly
more closely with the military mind-set, I doubt it would have been
opened up to the public yet, or possibly ever.

Sorry, I don't know how to say it politely, but this argument (on both
sides) is patently ridiculous. For one thing, neither C++ nor Ada 95
existed at the time the Arpanet was created. For another thing, Ada has
never been "a language the DoD considered its own" -- the design has
always been entirely open. For goodness sakes, they even chose a
foreigner (Jean Ichbiah, who is French) to do the original 1983 language
design!

- Bob

 

[Larry Kilgallen]

Heh? Pascal has that.

Yes, I just said Pascal had that.

 

[Robert A Duff]

B.Stroustrup wrote in his "C++ Programming Language" that He was partly
inspired by Ada (and by a misterious to me "Clu") in creating C++
templates and exceptions. Does it mean these languages are closer than
everyone would expect?

Yes, these languages (C++ and Ada) are quite similar in many ways, and
both borrowed something from each other. To a programmer familiar with
Common Lisp or ML or many others, the arguments in this endless thread
must seem pretty silly. Kind of like arguing whether McDonald's or
Burger King is the better restaurant, not knowing about any others. On
the other hand, *those* languages also have serious flaws, too.

Clu is definitely worth learning.

- Bob

 

[dave]

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.

Turamnvia, use what you like. A good compiler, good library set is only
as good as the programmer that uses it.

C is fast, small very flexible and somewhat dangerous. The MISRA subset
of C produce better mission critical code, because the richness of the
language is restricted/disallowed.

C++ is an object oriented extension to C. It is an improvement on C, but
IMHO not well suited to small embedded systems. However it depends on
your tools and your writing skills. (Java would be better than C++ for
embedded design, but try finding native compilers!)

ADA provides for concise system description right there within the
language. It works everytime, all the time. It is not prone to code
ambiguity like C and therefore C++, even though all code ambiguity is
the programmers fault.

Every mission critical system I developed or assisted on pre 2001 was
ADA and Occam based. After 2001 some of my employers have switched to
the use of C (adhering to the MISRA subset/controls.) Conversely, pre
and post 2001 every GUI, test tool, front-end, test engine and
instrumentation interface was written in C, C++, Java, Delphi and more
recently C# (quick and dirty).

I've many years of experience in C/C++ (and
Delphi) but no Ada knowledge.

Delphi grew from Turbo Pascal at Borland. ADA is Pascal with necessary
enhancements for mission critical (military) applications. btw VHDL grew
out of ADA.

May I ask if it is too difficult to move from C/C++ to Ada?

You may ask. Answer: it depends on you. IMHO no, but I learned Pascal
before C, OOA/OOD before C++ and ADA after 'Z'. Simply put, the
languages are different, the concepts and methods are different. The
applications are not.

What is the best way of learning Ada for a C/C++ programmer?

Get some books you like. You want a hacker's guides to start with, free
stuff, online manuals, tutorials etc. Make notes and lots of code
snippets; lots and lots of code snippets.

This will get you up and running. Then the heavy stuff later on: set
yourself tasks, projects etc. Discover what tools and methods are
available to perform ADA design on your target system(s).

----------------
Lastly, avoid comparing the languages. Avoid conversations especially
with lecturers and users of more modern languages (c/c++, c# even
Delphi). It will just start arguments.

All programming languages have their niches and some are more suited to
a task than others. Most Aircraft use ADA; Banks use C++; Most
Instrumentation and embedded engineers use C/Assembler (ASM); Most Game
developers use ASM and more recently C; Communication systems requiring
formal definition use CSP & Occam. Schools teach Basic; Colleges teach
C, C#, vb.net or vb; Universities teach Pascal, C, C++, Occam, ADA and
more......

An introduction to cat skinning. (The Abridged War and Peace version)

Good luck and God Bless.

 

[Ioannis Vranos]

C++ is an object oriented extension to C. It is an improvement on C, but
IMHO not well suited to small embedded systems. However it depends on
your tools and your writing skills. (Java would be better than C++ for
embedded design, but try finding native compilers!)

I can't understand why native Java would be better.

Lastly, avoid comparing the languages. Avoid conversations especially
with lecturers and users of more modern languages (c/c++, c# even
Delphi). It will just start arguments.

I agree completely with this.

Most Game developers use ASM and more recently C;

And more recently (years) C++.

Communication systems requiring
formal definition use CSP & Occam. Schools teach Basic;

Actually I think they teach Pascal and perhaps some C. But it depends on
the countries I guess.

 

[Robert A Duff]

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.

Umm ... what does this have to do with the discussion, which was about
C++ vs. Ada, or perhaps C vs. Ada?

Of course you can write lock-free algorithms equally well in all the
languages in question. Of course all these languages allow machine-code
inserts, and of course you can't know from the language standard what
the compiler does with them. If you have evidence to the contrary,
let's hear it.

- Bob

 

[REH]

REH wrote:
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.

You continue to make illogical arguments in some misguide attempt to prove
you are somehow better than those who program in Ada. Next you are going to
complain because Ada can recover from your hardware catching fire. You are
just being ridiculous.

 

[Greg Comeau]

Did they? Or did they just implemented some 80% of the new features? My
experience with C/C++ (and I have 10 years + of that) is that at no time
there was a fully compiant C compiler available. There where allways a lot
of compiler avaliable who claimed to be <small>almost</small> complinant -
but never one which realy was.

Many vendors have misspoken their situation. That aside,
I'm confused about the above. Are you saying that
from 10 years from 1989 you only came across 80% complaincy
of C compilers?

Partily because - unlike Ada (http://en.wikipedia.org/wiki/ISO_18009) -
there is not official testsuite to test a C/C++ compiler and runtime
library. Such an official testsuite would do C/C++ all sorts of good.

Partly, but on partly

 

[Greg Comeau]

What do you mean by "exists today"? C99 is 5 years old and still no compiler
is available which support all C99 features. "restrict" - missing in MS-C
(even thrue restrict can be implemented as "no operation") - VA - arrays
(savety critical feature) - missing in MS-C, buggy in GCC.

Comeau C (based on EDG) + Dinkumware has provided said for a
few years now. See http://www.peren.com/pages/cvsa_isocvpl.htm

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/ctgLanguageImplementation.html#c_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/ctgLanguageImplementation.html#cpp_unimplemented).

I think you've misread that URL. It does not say that.
It's a reasonable compiler, and has many pros, but it is
not to my knowledge the most compatible(?) C/C++ compiler.

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.

Comeau C (to C90 and C99) and Comeau C++ (to C++98 and C++03)
along with Dinkumware gives you it all, tons of additional modes,
multiplatform, etc. For many years for each language.

True - the former slim languages designed by individuals have become fad
languages desined by the ISO commitie ;-).

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.

There's room for each.