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?

[Pascal Obry]

Ioannis Vranos <iv*@remove.thi s.grad.com> writes:

Pascal Obry wrote:

Note that it is for this very reason that Java was born (a safer C++). Java
has indeed removed lot of unsafe constructs from C++.

Please do not start a real flame! Java is far behind C++. It is a silver

Sorry I do not intend to. This is history and as described by Java
creators. Please read my other post.

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

[Alberto]

Ki*******@SpamC op.net (Larry Kilgallen) wrote in message

Nobody objects to someone using the name ADA in a program written in Ada.
The comments are about someone using improper capitalization in text
written in English, a language which is case-sensitive.
As many people on this thread noticed, it was only a (bad?) joke. I
simply wanted to remark that I was somewhat tired of reading the same
story of Ada L. when some innocent soul dared to write "ADA" :)

3. Many of you want us to believe that ADa performs ra nge checking
without loss of performance: it can be true at compile time with fixed
ranges, but it can't definitely be done without chechinkg array bounds
every time data is accessed if we don't know these bounds before
compiling (e.g.: typical cases where dynamic allocation of memory is
used)

As has been stated, it is _much_ more efficient that do-it-yourself
range checking written in C++, because the compiler has more data.
For those who insist on _no_ range checking (compute intensive inner
loops), turn off the range checking if it gets in the way for that
one area of code. But be certain it gets in the way first - it
is common to make bad guesses about whether range checking will
affect overall performance. Ada programmers are better able than
C* programmers to know that, because in Ada it is easier to turn
range checking on and off.

Yes, but consider the existence of STL that lets you not to
"do-it-yourself" when storing or accesing data ;)

mechanisms, only interfaces (pure virtual classes)[2]. To me, it
sounds reasonable to work with the last version of a compiler when
possible.

That does not seem so reasonable to people working on a mission-critical
30 year project. In many cases such circumstances warrant working with
the compiler originally used for the project.

You are right: if something works, it is usually better not to touch
it, but in this case, you are stuck with Ada83!

[Ioannis Vranos]

Pascal Obry wrote:

That's not a misunderstandin g. That's how Sun has described Java. They started
from C++ and have removed many unsafe features. They eventually stop the
process at some point and this has given birth to Java. That's history.

The bottom line is that as a language itself it has less abilities than
C++, the framework being another case.

There is an upcoming ECMA C++/CLI standard (that will be finished
probably this month), which is about ISO C++ extensions for taking
advantage of a CLI VM when one is available (it replaces and extends
Microsoft's current "managed extensions" for C++).
You may download the latest draft from here:

http://www.plumhall.com/C++-CLI%20draft%201.8.pdf
With C++/CLI and VC++ 2005, C++ becomes the systems programming language
of CLI (and .NET):
You may take a look at these:

http://msdn.microsoft.com/msdnmag/is...s/default.aspx

http://pluralsight.com/blogs/hsutter...0/05/2672.aspx

http://blogs.msdn.com/branbray/archi.../07/51007.aspx

http://www.accu.org/conference/prese...keynote%29.pdf
And a page of mine:

http://www23.brinkster.com/noicys/cppcli.htm

With C++/CLI, C++ has two worlds: The unmanaged world and the managed world.

In the managed world every CLI (.NET) feature is provided separately
from the unmanaged world features.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Hans Malherbe]

>"Interesting ", indeed. ;-) Unfortunately, about half of this

information is complete nonsense -- about both languages!

I would like to believe that people like you would point out the
nonsense preventing people like me from consuming it.

[Georg Bauhaus]

Ioannis Vranos wrote:

Pascal Obry wrote:

package API is
pragma Remote_Call_Int erface;

procedure Call_Me (Str : in String);
end API;

What is it doing?

pragma Remote_Call_Int erface categorizes the package "API"
as a remote call interface library unit.

LRM E.2.3:
7. A remote call interface (RCI) is a library unit to which the pragma
Remote_Call_Int erface applies. A subprogram declared in the
visible part of such a library unit is called a remote subprogram.

It might be worth mentioning that Ada programs can constist of
partitions. They can be distributed programs then. A remote
call interface is assigned to one partition.

Georg

[Ioannis Vranos]

Dmitry A. Kazakov wrote:

Heap is far slower than stack. Also stack is much safer, because objects
allocated on the stack have visible scopes, as compared to adventures with
pointers. Do you want to add one more indirection layer - smart pointers,
or do it even worse by using GC?

Regarding Storage_Error exception, C++'s one is bad_alloc, which is
guaranteed to *never fail* in case of memory starvation.

About stack. Strictly speaking, C++ standard does not define any stack
apart from a stack container , but "automatic storage" and "dynamic
storage".
It is common though the first to be called "stack" and the second "heap"
or "free store".
It is an implementation' s/platform's job to provide stack and heap.
Usually the stack is limited in comparison to the heap, and it sounds
strange to me that in Ada there is a large stack. My guess is that you
are using the heap for data storage implicitly(?) and you think you are
using the stack.
Are you familiar with "Resource Acquisition is Initialisation" (RAII)
technique? This is supported by C++ and used by all standard library
containers.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Alex R. Mosteo]

Ioannis Vranos wrote:

Usually the stack is limited in comparison to the heap, and it sounds
strange to me that in Ada there is a large stack. My guess is that you
are using the heap for data storage implicitly(?) and you think you are
using the stack.

Nope. And you can control in portable Ada how big the stack for a given
task must be.

[Ioannis Vranos]

Ioannis Vranos wrote:

Regarding Storage_Error exception, C++'s one is bad_alloc, which is
guaranteed to *never fail* in case of memory starvation.

About stack. Strictly speaking, C++ standard does not define any stack
apart from a stack container , but "automatic storage" and "dynamic
storage".
It is common though the first to be called "stack" and the second "heap"
or "free store".
It is an implementation' s/platform's job to provide stack and heap.
Usually the stack is limited in comparison to the heap, and it sounds
strange to me that in Ada there is a large stack. My guess is that you
are using the heap for data storage implicitly(?) and you think you are
using the stack.

As is the case when I use a vector<int> for example. The object itself
is in the stack, however internally it allocates memory in the heap to
store its members, which releases with its destructor when it is
destroyed (e.g. in the end of its scope).

Are you familiar with "Resource Acquisition is Initialisation" (RAII)
technique? This is supported by C++ and used by all standard library
containers.

In summary RAII is a technique which is used to encapsulate resources
(as vector does for memory and is used as a general array, and string
also and is used as a string type), with the constructor allocating the
resources and the destructor releasing them, and thus producing
bullet-proof code.
When an exception is thrown or the object reaches the end of its scope,
the object gets destroyed releasing the resources via its destructor.
RAII can be used for any kind of resources, IP connections, memory,
files, etc. All standard library containers use RAII.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Larry Kilgallen]

In article <e3************ **************@ posting.google. com>, az****@yahoo.es (Alberto) writes:

Ki*******@SpamC op.net (Larry Kilgallen) wrote in message

Somebody no longer attributed wrote:

> mechanisms, only interfaces (pure virtual classes)[2]. To me, it
> sounds reasonable to work with the last version of a compiler when
> possible.

That does not seem so reasonable to people working on a mission-critical
30 year project. In many cases such circumstances warrant working with
the compiler originally used for the project.

You are right: if something works, it is usually better not to touch
it, but in this case, you are stuck with Ada83!

I have made many changes in the past 6 months to a 16 year old program
written in Ada 83. There are now about 200,000 source lines of code,
and since the changes were all to do "more of the same" I never felt
any lack of capability in the language. The problems I encountered
while debugging were almost all in three or so modules _not_ written
in Ada.

But similar to what we agreed about compilers, I am not about to
switch programming languages on those few modules at this point.

[Peter Koch Larsen]

"Dmitry A. Kazakov" <ma*****@dmit ry-kazakov.de> skrev i en meddelelse
news:qe******** *************** ******@40tude.n et...

On Fri, 11 Mar 2005 10:42:51 +0100, Peter Koch Larsen wrote:

"Dmitry A. Kazakov" <ma*****@dmit ry-kazakov.de> skrev i en meddelelse
news:97******** *************** ******@40tude.n et...

> 2. C++ is unable to allocate objects of indefinite size on the stack.

Well, we have alloca() for this ;)

Try to return such object from a function. Ada can

declare
Object : T'Class := Read_It_From_Fi le;

Here neither the specific type, nor the size of the object are known at
compile time. Another example:

declare
Line : String := Read_Source_Lin e (File);

Or even:

Put_Line (Read_Source_Li ne (File));

The solution is simple here - just allocate your memory on the heap.

Heap is far slower than stack. Also stack is much safer, because objects
allocated on the stack have visible scopes, as compared to adventures with
pointers. Do you want to add one more indirection layer - smart pointers,
or do it even worse by using GC?

I believed the object might have to be returned? Read the post once again.
If this is so, you can not allocate it on the stack without having to copy
when you return the object. Surely the copy must be more expensive than the
allocation?
Ordinary heap-based speed is not so slow and if you need to get the last
cpu-cycle away, you can simply use an arena for your allocation.
Also you will of course use a smart pointer in the situation above. A C++
programmer with respect for himself only rarely uses new without putting the
result in some kind of smart pointer. Personally, I do not remember when i
did that last.

/Peter
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de