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]

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.
*Today* one may use a std::pair or a combination of std::pairs for
return values.

E.g.

//Returns 2 values
pair<int, int> somefunc();
// Returns 4 values
pair<pair<int, int>, pair<int, int> >somefunc();

// Returns 3 values
pair<pair<int, int>, int>somefunc();
Also this gets more syntactic sugar with the upcoming TR1 standard
library extension and more particularly with "Tuple types".
Here are the proposals that have been accepted for the upcoming TR1:

http://www.open-std.org/jtc1/sc22/wg...al_report.html
Personally although more sugar-rich (and still built with the current
C++ facilities, which demonstrates the power and expressiveness of the
language), I am not sure we needed Tuple types, since std::pair does the
job. :-)

I suppose tuple types continue to be convenient for something like 10
return values, since it is just a returned object with the contained
values, but I think returning (or passing) so many values means
something is wrong. :-)
--
Ioannis Vranos

http://www23.brinkster.com/noicys

[REH]

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

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.
Ada allows you to define a primative type (int, etc.) that is "distinct"
from others. This is nice for overload resolution, etc.


C++ provides general purpose facilities with which one can build his own
special purpose libraries, rather than providing special purpose
facilities as built in.

I know, but being about to write "is new integer" is a lot simplier than
creating a class just to create a "unique" integer type. Plus. since it is
a unique type I can define its exact size in bits which make portabililty
easier:

type Byte is new integer range 0 .. 16#ff#;
for Byte'size use 8;
Vital! C++ and C suffer a lot from not enforcing encapsulation,
allowing headers to break stuff etc. Better control of scope
and visibility. Better separation of interface and implementation

May I assume that packages are a form of precompiled dynamic-link
libraries, like dlls in Windows?

No, they are compilation construct (and can be define in a hierarchy). The
are kind of like namespaces. If you ever used Borland's Turbo Pascal, they
are like units. They make it easy to separate interface and implementation.
Even inlines and generic bodys go in the body package, and not the
specification package, and can be used in a library without needing the
source present to be used. They also allow for the creation of an
elaboration (static construction) order between packages to be defined.

[Ioannis Vranos]

Ioannis Vranos wrote:

Personally although more sugar-rich (and still built with the current
C++ facilities, which demonstrates the power and expressiveness of the
language), I am not sure we needed Tuple types, since std::pair does the
job. :-)

I suppose tuple types continue to be convenient for something like 10
return values, since it is just a returned object with the contained
values, but I think returning (or passing) so many values means
something is wrong. :-)

Since tuple types are to be used for more things than only returned and
passed values, I recall the above. :-)


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Dr. Adrian Wrigley]

On Fri, 11 Mar 2005 19:32:31 +0100, Peter Koch Larsen wrote:

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

On Thu, 10 Mar 2005 17:39:13 -0500, REH wrote:

Ada features I would love to have in C++:
* "new types" and sub-ranges
Agree strongly. (with compiler-generated checking!)

This can be implemented mostly with templates.

the evidence I find is that these Ada features meet programmers'
needs (because they are widely used), yet the nearest equivalent
with templates is almost never used (I have never seen examples).
I don't think new template classes match the utility of new
types and subranges in practical terms (but I'm prepared to
be shown wrong!).

How, for example, do you create a new 2-D array indexed by
enumeration sub-ranges?

For example, what is the templated, range-checked equivalent of:
------------------------------------------
generic
type Index_T is (<>);
type Intensity_T is digits <>;
package CrossBright_P is
type CrossIntensity_ T is array (Index_T, Index_T) of Intensity_T;
-- more subprograms here
end CrossBright_P;

type EMSpectrum_T is (Gamma_Ray, X_Ray, Ultra_Violet, Visible, Infra_Red, Microwave, Radio_Wave);
type Intensity_T is digits 6 range 0.0 .. 10_000.0;

type CrossSpectrumIn tensity_T is array (EMSpectrum_T, EMSpectrum_T) of Intensity_T;

package MyCrossBright is new CrossBright_P (EMSpectrum_T, Intensity_T);

CrossIntensity : MyCrossBright.C rossIntensity_T := (others => (others => Intensity_T'Fir st));
--------------------------------------------------------------

* runtime template instantiation (I think being able to instantiate
generics dynamically is the coolest thing!)

This would be nice!

How would you do that without "compiling on the fly"?

same way as in Ada!

* subprograms inside subprograms. I think it would be great for use
with the STL (i.e., using a local function with std::foreach)

Agree strongly.

This will be part of the next standard, I hope. Still i do not believe it to
be esential for use.

It is sometimes handy to use the C preprocessor for local functions

* packages. namespaces are nice, but packages make modularity of very
large system a lot easier. Especially now with "use type"

Vital! C++ and C suffer a lot from not enforcing encapsulation,
allowing headers to break stuff etc. Better control of scope
and visibility. Better separation of interface and implementation

* representation specifications! !!!

Agree.

Why? What is the purpose - if not to restrict portability?

To get access to externally defined data storage!!
For example, hardware devices, network data representation,
interfacing to machine code etc.

....

-------------------------------------------------------------
My list of Ada features I would love to have in C++ adds:

Concurrency. Tasks. Protected objects.
Distributed programs. Persistent variables.

I doubt that this should be part of the standard. What is needed is
specification of low-level features in e.g. multiprocessor environments.

I think portable concurrent or distributed programming is a paradigm
poorly (non) supported by C++. The current situation is a mess.

Eliminate large swathes of the C++ standard which leaves
the semantics up to the compiler!

Most of these "implementa tion defined" parts are there for portability. To
many definitions will make it more difficult to port C++ to other platforms.

But at least any difficulty is addressed once per platform,
rather than once for each program!

Named parameter association. Proper parameter modes
"out" and "in out" modes

I do not see the purpose of the out-parameter. Why not simply return the
value(s)?

How do you return multiple values?
As for named parameter associations, these can again be implemented in a
library.

Again, they are widely used in Ada code, but very rarely in C++.
I found the library implementation kludgey.

clarity over arrays. C++ gives you choice of pointers
C arrays, vectors. This is one example of where the
'C' facilities were too limited, and C++ added
alternatives, rather fhan fixing what existed in C.
(and char *, char arrays, string etc)

For C++ portability from C was (and is) an important issue. Thus there is no
question about remocing e.g. pointer-arithmetic and decaying of arrays to
pointers. This simply can not happen. Also some of these features are needed
for an efficient implementation of low-level classes (e.g. std::vector).
What you can do is not use these features. And it is just a matter of
education to routinely use e.g. std::vector< t > and std::string instead of
arrays and char pointers.

You can't routinely use only the new features, because library
code mainly uses the old features. (most libraries are supplied
via C-style header files)

Strong(er) typing, better enumerations, fixed point types,
modular types *and* non-modular types. Basic type attributes.

There are some bad decisions in the type system - specifically i hate the
automatic conversions from double to integral value. But again - this is
something you have to live with.

(only if you have to use C++!)

More robust, more readable, less terse syntax, particularly
for complex templates (really!)

Right. The template stuff could possibly have been more elegant.

Portability without resorting to preprocessor directives
and conditional compilation

I am not sure i follow you here. In what way do you want portability? Are
you thinking of e.g. portability between an X-windows system and Windows? Or
portability of lower-level constructs such as multithreading or networking?
I wonder how Ada does this stuff.

portability for different type sizes (eg pointer widths, char signedness,
basic type ranges, data alignment)

associative arrays (from Perl)

I thought Ada supported generic programming. Isn't it then just a question
of creating a library?

it's a nuisance to have to define a suitable hashing function for
each type, particularly one you are several levels into a generic nesting!
The hashing function might need to be passed in at the top and
built in stages at each level. Not nice. (is there an alternative?)
--
Adrian

[REH]

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

[REH]

"Dr. Adrian Wrigley" <am**@linuxchip .demon.co.uk.uk .uk> wrote in message
news:pa******** *************** *****@linuxchip .demon.co.uk.uk .uk...

* subprograms inside subprograms. I think it would be great for use
with the STL (i.e., using a local function with std::foreach)

Agree strongly.

This will be part of the next standard, I hope. Still i do not believe it to be esential for use.

It is sometimes handy to use the C preprocessor for local functions

That would not work in the example above, i.e., for use as the operation
given to STL algorithms. Besides, inline is better for "quick" functions
than the preprocessor.

The closest thing I've seen in C++ is a locally define class with operator
() defines, but:

1) All the compilers I have used usually choke on this, especially with
optimization turned on (I don't know what the standard actually says about
doing this, though).

2) To access variables from "outer scopes" you would have to send them in
through the constructor.

[Robert A Duff]

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

Robert A Duff wrote:

[ ... ]

If you really want to know about these languages that are being
discussed (Ada and C++) nothing beats reading a textbook or two.

Much as I hate to further my (undoubtedy bad) reputation for being
disagreeable, I still have to disagree.

If you follow-up the reading with some real use, it beats reading alone
by a wide margin, at least IME.

But I agree with that! Your reputation as disagreeable is ruined. ;-)

On the other hand, if you do "real use" by itself, you're liable to fall
into the trap of thinking that "what my compiler happens to do" is equal
to "the language definition".

- Bob

[Robert A Duff]

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

Dmitry A. Kazakov wrote:

On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote:

How easy is it to build an arena allocator in Ada?

It is trivial:
type Object is ...;
type Object_Ptr is access Object;
for Object_Ptr'Stor age_Pool use My_Arena;
Here you are:
Ptr : Object_Ptr := new Object; -- This allocates it in My_Arena

And how is My_Arena defined? Is it just a blob of memory? Or is it a
"class" that can invoke sbrk (or whatever) when it needs to?

Dmitry showed how to *use* an arena allocator. You (CTips) seem to be
asking how to write the code of the allocator itself.

Yes, it's ``a "class" that can invoke sbrk (or whatever)''.
That is, the code for Allocate and Deallocate are written by the
programmer to do whatever is necessary, and are called automatically by
"new" and "Unchecked_Deal location". (Unchecked_Deal location is like
free.) The "arena" allocator can of course do what it likes -- allocate
from a blob of memory, or allocate small pieces out of large chunks,
or request more memory from the OS (if there *is* an OS), etc.

I'm a little confused about what you (CTips) are asking.
Maybe you could clarify a bit...

Note that Object can still be allocated on the stack or in any other
pool:
type Object_Universa l_Ptr is access all Object;
This : Object;
-- This allocates it on the stack
That : Object_Universa l_Ptr := new Object;
-- This will be in the(a) default pool (in the heap)

Given a processor with load-word-locked and store-word-conditional,
how would I build an atomic increment function?

Why should I have atomic increment function? Ada has native concurrency
support. But if somebody would need that extremely low level thing as
atomic integers, then:
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.

It will generate something much more heavy-weight, but portable,
in most Ada compilers. If you want access to machine instructions,
you use machine code inserts, but of course you then lose portability.

I don't know of any Ada compiler that's smart enough to compile the
above into the most efficient code on machines that *do* have those
atomic instructions.

I thought this discussion was about C++ vs. Ada. Both allow
machine-code inserts. And (of course) machine-code is not portable.
I don't see any difference there.

- Bob

[Wes Groleau]

fm**@tiscali.it wrote:

In order to suppress all checks, with Ada we can use Pragma Suppress()
yet with C++ we have to write a totally different new code when you
don't want anymore checks (if using C++ "try .. catch" constructs).

And in the pragma, you can be explicit about which checks to suppress,
which entity to suppress them on, and what scope to do it in.
--
Wes Groleau

Trying to be happy is like trying to build a machine for which
the only specification is that it should run noiselessly.
-- unknown

[Wes Groleau]

Jerry Coffin wrote:

Thinking of Java as a safer C++ betrays misundertanding of one (or
probably) both languages. Comparisons between Ada and C++ are at least

A misunderstandin g shared by the inventors of Java?

I watched a 30-minute video tape in which they said
they kept having this and that problem, so they invented
a language that would not have those problems. One of them
held up for the camera a copy of some C++ book with lots of
things lined out and said something like, "Basically, we just
eliminated all this unsafe stuff."

--
Wes Groleau

There are some ideas so wrong that only a
very intelligent person could believe in them.
-- George Orwell