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]

Ioannis Vranos wrote:

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.
I am sure there are other libraries too.

Actually the Boost type that you are probably looking for is:
"uint_value _t: The smallest built-in unsigned integral type that
supports the given value as a maximum. The parameter should be a
positive number."
This is the equivalent of 0..whatever.
Myself thinks though that this whole range specialisation thing is
non-sense for regular application programming at least.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

Actually the Boost type that you are probably looking for is:
"uint_value _t: The smallest built-in unsigned integral type that
supports the given value as a maximum. The parameter should be a
positive number."
So the example becomes:

#include <boost/integer.hpp>
int main()
{
using namespace boost;

// Value range 0..16
uint_value_t<16 >::least my_var;

my_var= 9;
}
This is the equivalent of 0..whatever.
Myself thinks though that this whole range specialisation thing is
non-sense for regular application programming at least.

Indeed. :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Georg Bauhaus]

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
Georg

[Simon Wright]

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?

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.

What happens with lwlock about priority inversion?

No protected type implementations will be so light. This is impossible as it
brings far more than atomic integer. For an atomic integer it is possible to
declare :

Value : Integer;
pragma Atomic (Value);

I don't think this will make

Value := Value + 1;

atomic, though!

--
Simon Wright 100% Ada, no bugs.

[Martin Krischik]

Jerry Coffin wrote:

Pascal Obry wrote:

"Jerry Coffin" <jc*****@taeus. com> writes:

> Your claim of fewer bugs is just the sort of unsupported anti-C
> comment we see all the time.
Just plain wrong, there is data (a PHD) see
http://www.adaic.com/whyada/ada-vs-c/cada_art.html

Perhaps you should reread this, paying paritcular attention to the
dates involved. According to the paper, they started switching from C
to Ada around 1986. C wasn't standardized until 1989, and (as you'd
expect) it was some time after that before most compilers implemented
the standard language.

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.

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.
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.
In short, this is not a comparison to the C language as it exists
today, or has existed in well over a decade.
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.

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).
If anything, based on my own experience with standard C vs.
pre-standard C, I'd say his study shows rather the opposite of what you
think it does. Standard C was enough of an improvement over
pre-standard C that it would be rather surprising if standard C didn't
beat Ada in most areas studied (the primary exception being code
reuse).
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.
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 ;-).

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.

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

[Peter Koch Larsen]

"REH" <bo***@nowhere. net> skrev i en meddelelse
news:d0******** *@cui1.lmms.lmc o.com...

"Ioannis Vranos" <iv*@remove.thi s.grad.com> wrote in message
news:1110570242 .82910@athnrd02 ...

REH wrote:

>>Named parameter association. Proper parameter modes
>>"out" and "in out" modes
>
> I would love have named parameters too. That way I would not have to
> "agonize" over the "priority" of my default parameters (i.e., if there are > 10 and I have to change the 10th from its default, I have to define the
> first 9).

The many parameters passed by reference to be modified is an outdated C
style.

That's not what I mean. I mean I have a function foo that takes many
parameters. I can think of nothing beyond a contrived example:

void foo(int a= 1, int b = 2, int c = 3);

I usually try and determine which will change most often, and make that
the
first one, and on down the line. The is because if I need to define
parameter c in a call to foo, I need to define a and b also. In Ada I can
just say:

foo(c => 5);

I had one instance where I had many complex objects that took a lot of
constructor parameters. I ended up putting the parameters in related
groups, and making each group a struct, each with its own set of defaults
so
I would only have to define them if I cared about a particular group. I'm
sure there is probably a better design. I hope that was clear.

First off, I do not believe in procedures with many parameters. But if you
do want to use such a feature, look at boost, which lets you say e.g. foo(c
= 5) or foo(c = 4,a = 2). This is all outside the core language, relying on
some (vlever) template programming.

[Peter Koch Larsen]

"Martin Krischik" <ma****@krischi k.com> skrev i en meddelelse
news:49******** ********@linux1 .krischik.com.. .

Jerry Coffin wrote:

Pascal Obry wrote:

"Jerry Coffin" <jc*****@taeus. com> writes:

> Your claim of fewer bugs is just the sort of unsupported anti-C
> comment we see all the time.

Just plain wrong, there is data (a PHD) see
http://www.adaic.com/whyada/ada-vs-c/cada_art.html
Perhaps you should reread this, paying paritcular attention to the
dates involved. According to the paper, they started switching from C
to Ada around 1986. C wasn't standardized until 1989, and (as you'd
expect) it was some time after that before most compilers implemented
the standard language.

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.

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.

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.

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.

In short, this is not a comparison to the C language as it exists
today, or has existed in well over a decade.
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.

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++?

If anything, based on my own experience with standard C vs.
pre-standard C, I'd say his study shows rather the opposite of what you
think it does. Standard C was enough of an improvement over
pre-standard C that it would be rather surprising if standard C didn't
beat Ada in most areas studied (the primary exception being code
reuse).

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.

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. The "ISO commitie" you refer to consists of people
using C++ in daily life.

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.

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

[Martin Krischik]

Ludovic Brenta wrote:

"Jerry Coffin" writes:

Short of using things like casts that are designed specifically to
_prevent_ the compiler from giving warnings (and which have their
counterparts in Ada) what practices on the "wrong side" do you see
that a C++ compiler can't warn about?

Aliasing?

There is this new "restrict" keyword in C99 - only MS-C does not support it
and so many 3rd party libraries won't use it and you can't use it (without
cast) because you need to use the library. It's a bit like the introduction
of const - only this time there is more legacy code and it will take even
longer until restrict is generaly accepted.

Martin

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

[Martin Krischik]

Ioannis Vranos wrote:

Dr. Adrian Wrigley wrote:

Ada features I would love to have in C++:
* "new types" and sub-ranges

I do not know what you mean exactly by that, however one can define his
own types rather than having everything as built-in.
explicit typedef int My_Integer;

As you know "explicit" deactivates implicid type convertions. Sadly it can
only by applied to type convertion contructors and not to types itself.

See: http://en.wikibooks.org/wiki/Program...pe_declaration

The other would be

explicit typdef int <1, 31> Day_Of_Month;

See: http://en.wikibooks.org/wiki/Program...da:Types:range
C++ provides general purpose facilities with which one can build his own
special purpose libraries, rather than providing special purpose
facilities as built in.
Shure you can create a template for the problem above - but without the
"explicit typdef" you always have the problem of

template Range <int Min, int Max> class {....}

typedef Range <1, 12> Month_Of_Year;
typedef Range <1, 12> US_Hour;

I have 10+ years experience of C/C++ - I already know the little tricks you
could do to circumvent the problem above. It would be nicer without tricks.
From my (perhaps limited) experience of .NET where run-time generics
are also available to C++ (with the upcoming C++/CLI, .NET 2 and VC++
2005 - currently Beta), run-time generics are more limited than
compile-time templates. Also since they are run-time they are less
efficient.
I think they are more free:

template <int Size> Bounded_Array class {...};

void F (int size)
{
auto Bounded_Array <size> Data;
}

And yes: that works in Ada.
May I assume that packages are a form of precompiled dynamic-link
libraries, like dlls in Windows?
No - usualy they result in .obj files. Ada packages consist of a
specification file and a body file which result into object file and some
form of precompiled header file. The Ada language more or less demands some
form of precompiled header files (very simply speaking).

Some Ada compilers use a library database to store the objects and the
compiled specifications.

See: http://en.wikibooks.org/wiki/Programming:Ada:Packages
Portability without resorting to preprocessor directives
and conditional compilation

These are used essentially for system-oriented code.

No, almost all header files need:

#if defined (X_INCLUDED)
#define X_INCLUDED)

#endif

Which brings us back to the packages ;-) .

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

[REH]

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