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

[Pascal Obry]

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

 

[Ioannis Vranos]

That's not a misunderstanding. 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 draft 1.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/issues/05/01/COptimizations/default.aspx

http://pluralsight.com/blogs/hsutter/archive/2004/10/05/2672.aspx

http://blogs.msdn.com/branbray/archive/2003/11/07/51007.aspx

http://www.accu.org/conference/pres...Relevant_on_Modern_Environments_(keynote).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.

 

[Alberto]

(e-mail address removed) (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"

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!

 

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

 

[Alberto]

2. The C++ exception mechanism should be very similar to aDa's,
because it was inspired partially from it [1].

Yes, but there is a sufficient difference. Ada's exceptions are values of
same predefined type. It has advantages and disadvantages. Being on Ada's
side I start with advantages and leave disadvantages to you:

2. C++ has no truly dynamic classes. But if it some time will, then how
would it deal with:

[snip example]

I have never done or needed to do this, but I'll make a few tests with
the compiler anyway...

3. The size of all exception objects has an upper bound.

What is the advantage here?

But even then bounds checking is not needed for every access. Example:

procedure Dynamic (A : Some_Array) is
subtype Index is Array_Index range A'Range;
J : Index := A'First;

for I in A'Range loop
A (I) := .. -- No checks
...
J := I;
end loop;
A (J) := ... -- Still no checks

C++ completely lacks the notion of constrained subtypes which makes the
above possible.

If Some_Array is any array supplied at run-time, how can the compiler
know what values are stored in A'Range? (I mean, what the bounds of
the array are) It *has* to check these bounds at run-time. This
behaviour is also easily done with C++, creating a 'bounds' class,
similar to A'Range. The only difference is that it is a mechanism
provided by the user and not the compiler.

4. Also, some people wrote that C++ is bad because it is difficult
(but not imposible, see Comeau C++) to follow 100% the Standard. The
same can be said to adA, because at least if we own a compiler of the
'83 Standard, we can't have the derivation a virtual function
mechanisms, only interfaces (pure virtual classes)[2]. To me, it
sounds reasonable to work with the last version of a compiler when
possible.

As long as you have only one compiler vendor...

Sorry, I don't understand you very well here.

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

Well, we have alloca() for this

 

[Hans Malherbe]

C++ features I would to have in Ada:
* reference (in out) types in functions (without resorting
to access types)

Here's a feature I want in both:
Having the compiler force you to specify "in" or "out" at the call
site.

C# does this. The problem with C# is that "in" isn't deep.
You know at the call site that the _value_ of an "in" parameter is not
going to be mutated. What you don't know is whether any member
functions is going to be called on your parameter that mutates it. This
often makes "in" useless for parameters of user-defined type.

Groete
Hans

 

[Alex R. Mosteo]

Yes. That's refreshing.



^^^^^^^^^^^^^^^^

"Interesting", indeed. ;-) Unfortunately, about half of this
information is complete nonsense -- about both languages! Plus some
misinformation about what optimizing compilers can and cannot do, thrown
in for good measure.

Yes. Quite some biased/unfounded stuff but for people fairly familiar
with both languages, the eventual gold seed in the mud is worth the long
thread.

Regards!

 

[Adrien Plisson]

Second, if the work had been done exclusively or primarily in a
language the DoD considered its own, I suspect opening it up to the
public would have taken even longer, if it was ever allowed to happen
at all.

but still ARPA-net was created by the United States Defense Advanced
Research Project Agency, part of... the DoD !

To ensure that, connecting to this system would only be allowed after
passing an extensive (and expensive) certification process, and only
one OS in existence would be capable of passing -- and it wouldn't be
from a bunch of hackers like Microsoft either. It would be from some
place thoroughly professional, with a thoroughly professional license
fee (i.e. well out of reach of over 99% of the people who currently use
the Internet).

I don't remember running UNIX (implemented in C) was cheap at the time
ARPA-net was born ! also, one of the major Ada compiler is available
for free, so why would it be so expensive ?

 

[Peter Koch Larsen]

Many of these checks have been described as being compile-time checks.
A goal of fast compiles should not dominate.


Nobody has come up with something that cannot be expressed in Ada (or
in C++ for that matter). Ada code is more verbose, on the grounds that
code is read more often than it is written (or at least it should be).

I see no reason for verbosity here ;-)

/Peter

 

[Dmitry A. Kazakov]

What is the advantage here?

You can catch the exception Storage_Error! -))

If Some_Array is any array supplied at run-time, how can the compiler
know what values are stored in A'Range? (I mean, what the bounds of
the array are)

The bounds are in the array dope.

It *has* to check these bounds at run-time. This
behaviour is also easily done with C++, creating a 'bounds' class,
similar to A'Range. The only difference is that it is a mechanism
provided by the user and not the compiler.

No, the difference is that the compiler *statically* knows that both I and
J will be in the bounds at run-time. There is no way (except for dirty
tricks with casting) how they might become out of the bounds. Therefore the
compiler can safely omit any checks.

4. Also, some people wrote that C++ is bad because it is difficult
(but not imposible, see Comeau C++) to follow 100% the Standard. The
same can be said to adA, because at least if we own a compiler of the
'83 Standard, we can't have the derivation a virtual function
mechanisms, only interfaces (pure virtual classes)[2]. To me, it
sounds reasonable to work with the last version of a compiler when
possible.

As long as you have only one compiler vendor...

Sorry, I don't understand you very well here.

If your code depends on the compiler version, and you have to compile it
under gcc, Borland, MSVC, then you are in trouble man!

Well, we have alloca() for this

Try to return such object from a function. Ada can

declare
Object : T'Class := Read_It_From_File;

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

declare
Line : String := Read_Source_Line (File);

Or even:

Put_Line (Read_Source_Line (File));

 

[Peter Amey]

That's certainly an exaggeration about C++ programmers,
but it's not even close to an Ada programmer. An Ada
programmer likes Ada because he/she knows he/she is NOT
infallible.

This looks like the cue for my favourite quote. It was told to me by
the man who taught me to fly.

"The superior pilot uses his superior judgement to avoid those
situations that would otherwise require his superior skill".

Although it is about flying, it is also the reason I use Ada (and
particularly SPARK) --- so that I don't have contantly to flaunt my
superior skill

Peter

 

[Peter Koch Larsen]

You can catch the exception Storage_Error! -))

Well of course you can do that in C++.

If Some_Array is any array supplied at run-time, how can the compiler
know what values are stored in A'Range? (I mean, what the bounds of
the array are)

The bounds are in the array dope.

It *has* to check these bounds at run-time. This
behaviour is also easily done with C++, creating a 'bounds' class,
similar to A'Range. The only difference is that it is a mechanism
provided by the user and not the compiler.

No, the difference is that the compiler *statically* knows that both I and
J will be in the bounds at run-time. There is no way (except for dirty
tricks with casting) how they might become out of the bounds. Therefore
the
compiler can safely omit any checks.

4. Also, some people wrote that C++ is bad because it is difficult
(but not imposible, see Comeau C++) to follow 100% the Standard. The
same can be said to adA, because at least if we own a compiler of the
'83 Standard, we can't have the derivation a virtual function
mechanisms, only interfaces (pure virtual classes)[2]. To me, it
sounds reasonable to work with the last version of a compiler when
possible.

As long as you have only one compiler vendor...

Sorry, I don't understand you very well here.

If your code depends on the compiler version, and you have to compile it
under gcc, Borland, MSVC, then you are in trouble man!

The answer is simple: just do not write code that depends on a particular
compiler; write your code in C++.

Try to return such object from a function. Ada can

declare
Object : T'Class := Read_It_From_File;

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

declare
Line : String := Read_Source_Line (File);

Or even:

Put_Line (Read_Source_Line (File));

The solution is simple here - just allocate your memory on the heap. In C++
the last example would be:
std::string s;
file.getline(s);

 

[Dmitry A. Kazakov]

Although I have to admit, I prefer C++'s OO model.
I find it easier (personally) to see the encapsulation, and Ada's
dispatching rules still confuse my.

They are very simple. Dispatch happens only if the actual type is a class
(=the specific type is unknown) and the formal type is not a class. BTW,
C++ model of dispatch is inefficient and infeasible:

1. Small objects cannot be classes. Potentially, Ada can have Boolean
classes.
2. Permanent re-dispatch no matter that the type is already resolved.
3. Clumsy rules about dispatching in ctors. There is no need in that.
4. No dispatch on result.
5. No way to implement multiple dispatch.

Can someone explain why they chose the
package as the encapsulation level for a class?

Because class cannot be a holder of methods. It is unfeasible. Consider
operations with many arguments. Methods do not belong to classes.

C++ features I would to have in Ada:
* Implicit instantiation. Yeah, I know, it can be unsafe, but that is one
thing I really like about C++: the ability to automate repetitive things.
* actually having a class object encapulating the data and methods.
* reference (in out) types in functions (without resorting to access types)
* meta-templates. very neat stuff. ugly, but neat.
* The STL!!! (though I hear something similar is coming?)

I would like to eliminate generics in Ada in favor of better ADT. But I
seem to be alone.

 

[Dmitry A. Kazakov]

"Dmitry A. Kazakov" <[email protected]> skrev i en meddelelse


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?

 

[Georg Bauhaus]

Pascal Obry wrote:

What is it doing?

pragma Remote_Call_Interface 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_Interface 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]

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.

 

[Alex R. Mosteo]

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]

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.

 

[Larry Kilgallen]

(e-mail address removed) (Larry Kilgallen) wrote in message

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]

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