f



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

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?



0
Turamnvia
3/5/2005 1:42:05 PM
comp.lang.c++ 49423 articles. 7 followers. Post Follow

842 Replies
3327 Views

Similar Articles

[PageSpeed] 33

"Turamnvia Suouriviaskimatta" <TS> writes:
> 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?

Your knowledge of Delphi will help a great deal, more than your
knowledge of C++.  Learning a new imperative language is not all that
difficult once you know a couple other imperative languages.

I suggest you browse http://www.adaic.org, it has several books and
tutorials on-line, as well as references of hardcopy books you can
buy.  You may be interested in "Ada Distilled" by Richard Riehle.
Here is a direct link to it:

http://www.adaic.org/docs/distilled/adadistilled.pdf

-- 
Ludovic Brenta.
0
3/5/2005 2:11:34 PM
What specific features are you missing in C++. Before moving
to Ada consider this:

- It will be hard to find developers for Ada
- You might end up making more mistakes with Ada because of
   inexperience with Ada.
- Ada tools will fall short of the extensive set of C++ related tools.

Deepa
--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Real-time and Embedded System Modeling with Sequence Diagrams

0
eventhelix (355)
3/5/2005 2:17:02 PM
"EventHelix.com" writes:
> What specific features are you missing in C++. Before moving
> to Ada consider this:
>
> - It will be hard to find developers for Ada

Wrong.  There are more and more people knowledgeable in Ada, and if
someone won't learn, they probably are not a good software engineer to
begin with.  The OP, at least, shows proper scientific attitude of
willingness to learn and of choosing based on facts, not perception.

> - You might end up making more mistakes with Ada because of
>    inexperience with Ada.

Wrong.  I took that route 4 years ago, and found that the compiler
would catch all my stupid mistakes.  When it comes to reliability, Ada
compilers are your friends; C++ compilers are your enemies.

> - Ada tools will fall short of the extensive set of C++ related tools.

This depends on the actual environment; such a broad statement, not
backed up by any hard evidence, is just plain FUD.

-- 
Ludovic Brenta.
0
3/5/2005 2:25:14 PM
On Sun, 6 Mar 2005 00:42:05 +1100, Turamnvia Suouriviaskimatta wrote:

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

I don't think it is difficult. I learned C after Ada [83], that was
difficult! If you know C++ you will find the concepts of classes and
templates in Ada again, however, built on a different fundament. From
Delphi you'll find a close, but much improved syntax, packages instead of
units. OO/ADT in Ada is closer to C++ than to that stump in Delphi. If you
programmed multi-threaded applications in C++, you will enjoy Ada's tasks
and protected objects.

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

As with any language, the best way is to buy a pile of books, but not
before starting a project. Do not concentrate on implementation details,
avoid micro optimization (common to C programmers), enjoy "renames" instead
of T& or Delphi's "with", never use pointers and remember, array index
starts where you want it do! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/5/2005 2:39:23 PM
"Ludovic Brenta" <ludovic.brenta@insalien.org> skrev i en meddelelse 
news:871xau9nlh.fsf@insalien.org...
> "EventHelix.com" writes:
>> What specific features are you missing in C++. Before moving
>> to Ada consider this:
>>


[snip]

>
>> - You might end up making more mistakes with Ada because of
>>    inexperience with Ada.
>
> Wrong.  I took that route 4 years ago, and found that the compiler
> would catch all my stupid mistakes.  When it comes to reliability, Ada
> compilers are your friends; C++ compilers are your enemies.

Out of curiosiy, could you give some few examples where Ada catches faults 
not found by a C++ compiler. I assume - of course - code written in modern 
C++: no casts, functions instead of macroes, a limited use of pointers and 
so on.

Kind regards
Peter

[snip]

>
> -- 
> Ludovic Brenta. 


0
pklspam (199)
3/5/2005 3:02:24 PM
Turamnvia Suouriviaskimatta wrote:
> 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?
> 
> 
> 

It hasn't a lot in common with C-based languages. Its origin is in 
Pascal and Algol. I had to wite an article about Ada just recently while 
I had never worked with it before. I didn't find it too hard to get into 
it, but I don't consier myself "knowing" Ada well, either (only worked a 
couple of weeks with it).
I didn't like the OO facilities, it feels like OO was stomped into the 
language just to keep up with modern OO languages (actually, that's 
exactly what happened with Ada-95).
Ada is also -- compared to e.g. C++ -- extremely limiting in terms of 
flexibility (which is a good thing for safety critical environments I 
guess).

Ada has a very interesting type system, which e.g. allows you to define 
your own fundamental types, e.g. fixed point types (you can even define 
how many digits it may have etc). Ada also has generics, but is 
primarily based on data abstraction in terms of data structures (called 
'records' in Ada).

Overall I'd say your C++ knowledge is pretty useless when you learn Ada, 
but a general, fundamental experience with computer programming is 
always good enough to get into a new language relatively quick IMO.

-- 
Matthias Kaeppler
0
nospam328 (459)
3/5/2005 3:03:48 PM
Turamnvia Suouriviaskimatta wrote:
> 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?
> 
> 
> 

This short tutorial appears to work quite well for C/C++ programmers I 
have used on my projects.

www dot adahome dot com/Ammo/cpp2ada.html

Note that everything at adahome is old and out of date since this 
website stopped updating many years ago. The front page of the website 
pretends to update every day by updating a date field so it tends to 
rank high on search engines (so I try to avoid linking to the website on 
a personal crusade to lower its rankings).

www.adapower.com
www.adaworld.com

are to good jumping off points that are maintained.

I still point to that tutorial for new staff though because for talented 
engineers it brings them up to speed very quickly.

I have been working with Ada on real projects for many years now. 
(genererally Embedded, real-time, distributed processing mid sizes 
projects of about 100K SLOC).

During that time I have had lots of different engineers come on and off 
projects. A few of them knew Ada. Most did not. In general, any (stated) 
a priori knowledge of Ada was not at all a good predictor of their 
usefulness to the projects.

Talented engineers are productive in any environment where the tools are 
  not garbage and the requirements are at least somewhat better than 
mud. Bad engineers write bad code in any language. This is true even 
after many years of being "professional" programmers.

(For some fun read these two papers:
   http://www.paulgraham.com/gh.html
   http://www.paulgraham.com/pypar.html)


Switching to a language where no one on the project has any experience 
IS however a risk. You can search through the literature and find plenty 
of examples of projects that failed (at least partly, and based on my 
previous comment perhaps not as much as the engineers would like to 
believe) because they were not familiar with the language (e.g. C++, 
Java, Ada)  they selected.

Whatever language you choose you should attempt have a champion or two 
on the project that has worked with it before. Perferably these people 
would actually be good at the language AND software design/architecture 
in general. Identifying these good engineers up front is left as an 
exercise for the reader.

Realize that no language is a magic bullet that "solves" all problems.


Finally, I recommend that after about 48/72 hours you put this thread in 
a kill file because I find it hard to believe that a cross-posted 
question like this is not going to turn into a flame fest.
0
jcreem (218)
3/5/2005 3:24:19 PM
Peter Koch Larsen writes:
> Out of curiosiy, could you give some few examples where Ada catches
> faults not found by a C++ compiler. I assume - of course - code
> written in modern C++: no casts, functions instead of macroes, a
> limited use of pointers and so on.

Generally speaking, the very fact that you feel an urge to distinguish
between "C++" and "modern C++" is an indication that C++ is a poor
language containing many unsafe features, some of which you obligingly
enumerated above.  By contrast, there is no distinction between "Ada"
and "modern Ada".  Ada is safe by design, from the ground up.

Now for one specific example, I wrote a buffer overflow in a C++
library a few years ago, and it took me and two other people 3 days to
find it.  The fix was, of course, trivial once the bug was found.  As
it turned out, this particular bug would have been impossible to write
in Ada.  I can't post the code, as it is proprietary and I don't have
it at hand anyway, but the gist of it is that, in Ada, loop variables
(a) are constants and (b) do not exist outside of the loop:

procedure Proc (A : in String) is
begin
   for J in A'Range loop
      J := J + 4; -- illegal, J is constant inside the loop
   end loop;
   Do_Womething_With (J); -- illegal, J no longer exists
end Proc;

Also notice that, in Ada, the "for" statement declares the loop
variable automatically.

The bug in the C++ library was that I was mistakenly reusing the loop
variable after the loop, instead of the intended variable.  Of course,
the loop variable was an index pointing after the end of the buffer.

Some other features that make Ada inherently safer than C++ are:

* assignment is not an operator; it is an operation which does not
  return a value.  Thus, bugs like "if (something = 0)" cannot exist.

* case statements (Ada's equivalent of a switch in C++) are required
  to handle all possible cases.  Thus it is impossible to forget one.
  And, of course, there is no "break;" crap in Ada.

* conditions cannot mix "and" and "or" without parentheses.  Thus
  there is no possibility that the programmer make wrong assumptions
  about precedence of operators or order of evaluation.

* the type system, when used appropriately, makes it possible for the
  compiler to find semantic errors in addition to just syntax errors.
  For example, you can declare that Numers_Of_Apples and
  Numers_Of_Oranges cannot be mixed.  This is not possible with C++'s
  typedef.

* conversions from floating point to integer types involve rounding.
  The rounding is precisely and deterministically defined by the ISO
  standard for the Ada language.  Similarly, floating-point and
  fixed-point types can be declared with known, deterministic,
  guaranteed precision.

* pointer types cannot be converted to one another.  You cannot
  convert a pointer-to-String to a pointer-to-random-object.

* accessibility rules are rather complex, but they are designed to
  minimise the chance of mistakes.  Basically, the scope of a pointer
  type must be included in the scope of the pointed-to type.  This
  makes many mistakes impossible, such as returning a pointer to an
  object which no longer exists.

* when the compiler cannot check some code statically, it inserts
  run-time checks which are guaranteed to catch all errors by raising
  exceptions.  In C++ you must code these checks by hand, and of
  course at some point you'll forget one crucial check which will cost
  you days in debugging.

-- 
Ludovic Brenta.
0
3/5/2005 3:39:24 PM
"Peter Koch Larsen" <pklspam@mailme.dk> writes:

> 
> Out of curiosiy, could you give some few examples where Ada catches faults 
> not found by a C++ compiler. I assume - of course - code written in modern 
> C++: no casts, functions instead of macroes, a limited use of pointers and 
> so on.

It serves no purpose to find small (theoretic) examples where f.x. Ada
will be an advantage over C++. These examples will always be
repudiated in long discussions. In order to appreciate one language
over another, you need to have used it in a "real" system of a certain
size.

I have used both C++ and Ada in large projects and (until now) I
prefer Ada over C++ (yes, the modern usage with STL, function objects
and templates). Ada gives me better productivity, fewer errors and
(most of all) a sense of engineering instead of programming.

But you of course need to learn a language in order to judge it, so
just programming small examples where you maybe touch 25% of the
languages doesn't really give the language any credit. And that is the
catch with using "new" languages in a commercial environment: There is
no time to learn a new language and therefore no time to evaluate
alternatives.

Regards,
- Mark Lorenzen
0
3/5/2005 4:16:47 PM
Matthias Kaeppler <nospam@digitalraid.com> writes:

[snip]

Strange... I find that the OO facilities integrate very well in the
non-OO part of Ada. Maybe it is because you look at it from an outside
perspective.

> Ada is also -- compared to e.g. C++ -- extremely limiting in terms of
> flexibility (which is a good thing for safety critical environments I
> guess).

You can do everything in Ada that you can in C and C++. It is more
work in Ada to "force" things together than in C++. So Ada is not as
forgiving, when you have a bad design to begin with.

Regards,
- Mark Lorenzen
0
3/5/2005 4:26:40 PM
"Ludovic Brenta" <ludovic.brenta@insalien.org> skrev i en meddelelse 
news:87r7iu85lf.fsf@insalien.org...
> Peter Koch Larsen writes:
>> Out of curiosiy, could you give some few examples where Ada catches
>> faults not found by a C++ compiler. I assume - of course - code
>> written in modern C++: no casts, functions instead of macroes, a
>> limited use of pointers and so on.
>
> Generally speaking, the very fact that you feel an urge to distinguish
> between "C++" and "modern C++" is an indication that C++ is a poor
> language containing many unsafe features, some of which you obligingly
> enumerated above.  By contrast, there is no distinction between "Ada"
> and "modern Ada".  Ada is safe by design, from the ground up.

We agree here. C++ is a "hackers language", in part because of its C roots.

>
> Now for one specific example, I wrote a buffer overflow in a C++
> library a few years ago, and it took me and two other people 3 days to
> find it.  The fix was, of course, trivial once the bug was found.  As
> it turned out, this particular bug would have been impossible to write
> in Ada.  I can't post the code, as it is proprietary and I don't have
> it at hand anyway, but the gist of it is that, in Ada, loop variables
> (a) are constants and (b) do not exist outside of the loop:
>
> procedure Proc (A : in String) is
> begin
>   for J in A'Range loop
>      J := J + 4; -- illegal, J is constant inside the loop
>   end loop;
>   Do_Womething_With (J); -- illegal, J no longer exists
> end Proc;

This is inherited from Pascal if I remember correctly. Of course, good C++ 
style is to declare your variable in the loop.
>
> Also notice that, in Ada, the "for" statement declares the loop
> variable automatically.
>
> The bug in the C++ library was that I was mistakenly reusing the loop
> variable after the loop, instead of the intended variable.  Of course,
> the loop variable was an index pointing after the end of the buffer.
>
> Some other features that make Ada inherently safer than C++ are:
>
> * assignment is not an operator; it is an operation which does not
>  return a value.  Thus, bugs like "if (something = 0)" cannot exist.
>
> * case statements (Ada's equivalent of a switch in C++) are required
>  to handle all possible cases.  Thus it is impossible to forget one.
>  And, of course, there is no "break;" crap in Ada.
>
> * conditions cannot mix "and" and "or" without parentheses.  Thus
>  there is no possibility that the programmer make wrong assumptions
>  about precedence of operators or order of evaluation.

This seems ridiculous. I would expect a programmer to know the precedence 
rules or at least insert parentheses if they are in doubt.

>
> * the type system, when used appropriately, makes it possible for the
>  compiler to find semantic errors in addition to just syntax errors.
>  For example, you can declare that Numers_Of_Apples and
>  Numers_Of_Oranges cannot be mixed.  This is not possible with C++'s
>  typedef.

I like that idea. It is possible using templates, of course. Is it general 
enough? If you replace "apples" with "weight" and "oranges" with "length", 
is it then permissible to multiply a length with a weight but not add the 
two together?

>
> * conversions from floating point to integer types involve rounding.
>  The rounding is precisely and deterministically defined by the ISO
>  standard for the Ada language.  Similarly, floating-point and
>  fixed-point types can be declared with known, deterministic,
>  guaranteed precision.

This point sounds as if it restricts the environments where Ada can be used.
>
> * pointer types cannot be converted to one another.  You cannot
>  convert a pointer-to-String to a pointer-to-random-object.

You can't do so in C++ either. (C has the conversion to/from void*).

>
> * accessibility rules are rather complex, but they are designed to
>  minimise the chance of mistakes.  Basically, the scope of a pointer
>  type must be included in the scope of the pointed-to type.  This
>  makes many mistakes impossible, such as returning a pointer to an
>  object which no longer exists.

I like that one to.

>
> * when the compiler cannot check some code statically, it inserts
>  run-time checks which are guaranteed to catch all errors by raising
>  exceptions.  In C++ you must code these checks by hand, and of
>  course at some point you'll forget one crucial check which will cost
>  you days in debugging.

I sort of like this one as well - although raising an exception seems to be 
to forgiving.
My conclusion is that there are some nice ideas out there, but that they 
mainly protect against the "sloppy" programmer.

>
> -- 
> Ludovic Brenta.

Thanks for your answer
Peter 


0
pklspam (199)
3/5/2005 4:30:23 PM
He Peter,

Peterath Larsen wrote:

> Out of curiosiy, could you give some few examples where Ada catches faults
> not found by a C++ compiler. I assume - of course - code written in modern
> C++: no casts, functions instead of macroes, a limited use of pointers and
> so on.

Well that's easy:

unsigned int X = -1;

char Y [10];
Y [10] = "X";

Or bit more subtle:

unsigned int X Day_Of_Month = 32;

Now, here as examples all bugs are easy to spot and the compiler might even
show a warning. But now imagine the same with say 200 lines of code in
between - or declaration in one file and assignment in another - and
prehaps a function call instead of an constant expression - and you find
yourself having fun with a debugger.

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

0
martin131 (308)
3/5/2005 4:42:00 PM
"EventHelix.com" <eventhelix@gmail.com> writes:

> What specific features are you missing in C++. Before moving
> to Ada consider this:
> 
> - It will be hard to find developers for Ada

This is generally not true. It is true that there is less Ada developers than
C++ but there is enough for the demand. I have never had problems finding Ada
developers for my projects.

> - You might end up making more mistakes with Ada because of
>    inexperience with Ada.

Leaning curve in Ada is not as steep as for C++. Of course a beginner will
never be as good as an experienced programmer in whatever language. But Ada
has less traps than other languages on the market. The compiler will help
catch lot of them...

> - Ada tools will fall short of the extensive set of C++ related tools.

That's a good point to keep in mind. Even if it easy to build binding to
existing libraries in C/C++ this will require some times.

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
0
pascal27 (183)
3/5/2005 5:14:02 PM
Peter Koch Larsen wrote:
> I sort of like this one as well - although raising an exception seems to be 
> to forgiving.
> My conclusion is that there are some nice ideas out there, but that they 
> mainly protect against the "sloppy" programmer.

Which the world is full of... :-(

It would be fine if the world only needed a couple of dozen good 
programmers, the cream would rise to the top and make very few mistakes 
and all our software could be written in the most forgiving language in 
the world and it would not matter.

But, of course, the world needs 100's of thousands (millions?) of 
programmers and they all have varying degrees of ability from the Guru's 
and God's to Joe Bloggs, who taught himself (badly) at home and is hired 
by his mates dad because he knew he was "into computers" and so on.

Cheers

-- Martin
0
3/5/2005 5:52:36 PM
On Sat, 05 Mar 2005 10:24:19 -0500, Jeff C <jcreem@yahoo.com> wrote:

> Finally, I recommend that after about 48/72 hours you put this thread in  
> a kill file because I find it hard to believe that a cross-posted  
> question like this is not going to turn into a flame fest.


Interestingly, it hasn't so far.

Since I'm in the business of providing Ada for safety-critical apps, I'll  
make few comments just to try to redeem that last one.

One of the big issues with both Java and C++ for safety-critical apps  
seems to be that there hasn't been much accomplished to define suitable  
subsets for high levels of certification.  (I'm aware of the embedded  
C++ effort, and of some work on the Java side - someone from Aonix may  
want to comment on the latter).  In contrast, a lot was done in Ada based  
on projects like the Boeing 777 in the early 90's, and Ada subset  
definition is currently in a "second generation" that is less restrictive,  
more amenable to reuse of existing code bases (despite more strict  
interpretation of certification standards), and often oriented towards IMA  
architectures (a la ARINC-653).

Anyway, the upshot is that there's a lot of experience fielding  
applications written in Ada at high levels of safety certification, and  
that should count for something.

- Ed
0
falis (298)
3/5/2005 7:11:14 PM
On Sat, 5 Mar 2005 17:52:36 +0000 (UTC), Martin Dowie wrote:

> ... Joe Bloggs, who taught himself (badly) at home ...

I don't think that he would be the worst possible choice. Look, if somebody
has a desire to be taught (+5 points), and is ready to do it by himself
(+20!), at his spare time at home (+100!). That's far above the average. I
saw much worse cases!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/5/2005 7:27:15 PM
Dmitry A. Kazakov wrote:
> On Sat, 5 Mar 2005 17:52:36 +0000 (UTC), Martin Dowie wrote:
> 
> 
>>... Joe Bloggs, who taught himself (badly) at home ...
> 
> 
> I don't think that he would be the worst possible choice. Look, if somebody
> has a desire to be taught (+5 points), and is ready to do it by himself
> (+20!), at his spare time at home (+100!). That's far above the average. I
> saw much worse cases!

I did say this hypothetical self-taught person taught themselves 
'badly'! :-)

Cheers

-- Martin

0
3/5/2005 7:39:36 PM
Peter Koch Larsen writes:
> "Ludovic Brenta" skrev i en meddelelse 
>> procedure Proc (A : in String) is
>> begin
>>   for J in A'Range loop
>>      J := J + 4; -- illegal, J is constant inside the loop
>>   end loop;
>>   Do_Womething_With (J); -- illegal, J no longer exists
>> end Proc;
>
> This is inherited from Pascal if I remember correctly. Of course,
> good C++ style is to declare your variable in the loop.

Most of Ada's syntax is inherited from Pascal.  In fact, Ada is
"Pascal done right", since Ada eliminated most of Pascal's problems
like separate compilation or the infamous "dangling else" problem. For
that matter, these problems also exist in C and C++.

It is true that, in ISO C++, loop variables declared in the for
statement are not visible outside the loop.  However, the library I
was working on did make use of the loop variable after the loop, and
none of our 4 or 5 different C++ compilers complained about it.

Which brings me to the general question: is there any
standard-compliant C++ compiler in existence?  Or are compilers only
"mostly compliant" or "close enough" or some other ill-defined term?

By contrast, consider Ada's formal validation process, which is also
an ISO standard (ISO/IEC 18009 - Ada: Conformity assessment of a
language processor).  In the 1980's, the DoD held the trademark "Ada",
and only validated compilers were allowed to call themselves "Ada
compilers".  Now, the rules are more lax, but all compilers in
existence pass the validation suite.  See:

http://www.ada-auth.org/acats.html

>> * conditions cannot mix "and" and "or" without parentheses.  Thus
>> there is no possibility that the programmer make wrong assumptions
>> about precedence of operators or order of evaluation.
>
> This seems ridiculous. I would expect a programmer to know the
> precedence rules or at least insert parentheses if they are in
> doubt.

This is the crux of the problem.  Assuming that the programmer "knows
the rules", "makes no mistakes" or "can be trusted" is a recipe for
disaster.  One of the principles in Ada's rationale is to make
everything explicit, rather than implicit.

>> * the type system, when used appropriately, makes it possible for
>> the compiler to find semantic errors in addition to just syntax
>> errors.  For example, you can declare that Numers_Of_Apples and
>> Numers_Of_Oranges cannot be mixed.  This is not possible with C++'s
>> typedef.
>
> I like that idea. It is possible using templates, of course. Is it
> general enough? If you replace "apples" with "weight" and "oranges"
> with "length", is it then permissible to multiply a length with a
> weight but not add the two together?

Yes:

type Weight is digits 8 range 0.0 .. 900.0;  -- 8 decimal digits of precision
type Length is digits 8 range 0.0 .. 1000.0;

Now these types are incompatible.  If you want to mix them, you need
to define the semantics and provide the appropriate operators:

type Weight_Length is digits 8 range 0.0 .. 900_000.0;

function "*" (Left : in Weight; Right : in Length) return  Weight_Length;

Since you don't provide "+", there is no way to add a weight to a
length.

For a more general discussion of physical quantities in Ada, see:

http://home.t-online.de/home/Christ-Usch.Grein/Ada/Universe.html

>> * conversions from floating point to integer types involve
>> rounding.  The rounding is precisely and deterministically defined
>> by the ISO standard for the Ada language.  Similarly,
>> floating-point and fixed-point types can be declared with known,
>> deterministic, guaranteed precision.
>
> This point sounds as if it restricts the environments where Ada can
> be used.

Do you mean that not all targets may implement the requested
precision?  That is true but it is not a language issue.  Ada
compilers are required to document which precision they support for
their targets.

And fixed-point types being really nothing more than integers, all
targets support them to some extent.

> I sort of like this one as well - although raising an exception
> seems to be to forgiving.

What other mechanism would you suggest?

> My conclusion is that there are some nice ideas out there, but that
> they mainly protect against the "sloppy" programmer.

It is a mistake to assume that the programmer makes no mistakes.
Mistakes are a given fact of the human nature.  Ada is designed with
this in mind.

A sloppy programmer will avoid Ada like the plague, because they
resent discipline in general and don't appreciate being taught
lessons.  A good software engineer will be attracted to Ada because
she is a powerful ally.

-- 
Ludovic Brenta.
0
3/5/2005 7:46:45 PM
Ludovic Brenta wrote:

> Generally speaking, the very fact that you feel an urge to distinguish
> between "C++" and "modern C++" is an indication that C++ is a poor
> language containing many unsafe features, some of which you obligingly
> enumerated above.  By contrast, there is no distinction between "Ada"
> and "modern Ada".  Ada is safe by design, from the ground up.


With Ada aside (I find no reason why one should not learn it), C++ is a 
powerful and systems programming language, and power implies painful low 
level details. However it also provides all major high level facilities, 
and if you stick in high level programming it is very safe, while it 
maintains the maximum space and run-time efficiency principle.


For example consider using std::string for strings, std::vector for 
arrays etc.



> Now for one specific example, I wrote a buffer overflow in a C++
> library a few years ago, and it took me and two other people 3 days to
> find it.  The fix was, of course, trivial once the bug was found.  As
> it turned out, this particular bug would have been impossible to write
> in Ada.  I can't post the code, as it is proprietary and I don't have
> it at hand anyway, but the gist of it is that, in Ada, loop variables
> (a) are constants and (b) do not exist outside of the loop:
> 
> procedure Proc (A : in String) is
> begin
>    for J in A'Range loop
>       J := J + 4; -- illegal, J is constant inside the loop
>    end loop;
>    Do_Womething_With (J); -- illegal, J no longer exists
> end Proc;


Yes but this limits flexibility.


> Also notice that, in Ada, the "for" statement declares the loop
> variable automatically.


That's not a big deal.



> 
> The bug in the C++ library was that I was mistakenly reusing the loop
> variable after the loop, instead of the intended variable.  Of course,
> the loop variable was an index pointing after the end of the buffer.


It looks like the code was not ISO C++ compliant.


> 
> Some other features that make Ada inherently safer than C++ are:
> 
> * assignment is not an operator; it is an operation which does not
>   return a value.  Thus, bugs like "if (something = 0)" cannot exist.
> 
> * case statements (Ada's equivalent of a switch in C++) are required
>   to handle all possible cases.  Thus it is impossible to forget one.
>   And, of course, there is no "break;" crap in Ada.
> 
> * conditions cannot mix "and" and "or" without parentheses.  Thus
>   there is no possibility that the programmer make wrong assumptions
>   about precedence of operators or order of evaluation.
> 
> * the type system, when used appropriately, makes it possible for the
>   compiler to find semantic errors in addition to just syntax errors.
>   For example, you can declare that Numers_Of_Apples and
>   Numers_Of_Oranges cannot be mixed.  This is not possible with C++'s
>   typedef.
> 
> * conversions from floating point to integer types involve rounding.
>   The rounding is precisely and deterministically defined by the ISO
>   standard for the Ada language.  Similarly, floating-point and
>   fixed-point types can be declared with known, deterministic,
>   guaranteed precision.
> 
> * pointer types cannot be converted to one another.  You cannot
>   convert a pointer-to-String to a pointer-to-random-object.
> 
> * accessibility rules are rather complex, but they are designed to
>   minimise the chance of mistakes.  Basically, the scope of a pointer
>   type must be included in the scope of the pointed-to type.  This
>   makes many mistakes impossible, such as returning a pointer to an
>   object which no longer exists.
> 
> * when the compiler cannot check some code statically, it inserts
>   run-time checks which are guaranteed to catch all errors by raising
>   exceptions.  In C++ you must code these checks by hand, and of
>   course at some point you'll forget one crucial check which will cost
>   you days in debugging.



In general, we cannot compare the two languages because they have 
different design ideals.


C++ supports 4 paradigms. Each paradigm is supported well with maximum 
run-time/space *efficiency*. At the same time it leaves no room for a 
lower level language except of assembly.


On the other hand I do not know ADAs ideals (for example I do not think 
it supports the generic programming paradigm - templates), but I suspect 
they are to be an easy (restricted to easy parts), safe (not letting you 
do low level operations), application development language, which is OK 
for usual application development.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/5/2005 7:48:56 PM
In article <1110032222.447846.167060@g14g2000cwa.googlegroups.com>, "EventHelix.com" <eventhelix@gmail.com> writes:
> What specific features are you missing in C++. Before moving
> to Ada consider this:
> 
> - It will be hard to find developers for Ada

To hire developers who are incapable of learning a second language
is really scraping the bottom of the barrel.  If that were the case,
I would hope the product is not one on which I will ever depend.

> - You might end up making more mistakes with Ada because of
>    inexperience with Ada.

But if you do, they will typically be caught at compile-time.
0
Kilgallen (2738)
3/5/2005 7:52:01 PM
In article <3SjWd.103128$Vf.3969241@news000.worldonline.dk>, "Peter Koch Larsen" <pklspam@mailme.dk> writes:

>>> - You might end up making more mistakes with Ada because of
>>>    inexperience with Ada.
>>
>> Wrong.  I took that route 4 years ago, and found that the compiler
>> would catch all my stupid mistakes.  When it comes to reliability, Ada
>> compilers are your friends; C++ compilers are your enemies.
> 
> Out of curiosiy, could you give some few examples where Ada catches faults 
> not found by a C++ compiler. I assume - of course - code written in modern 
> C++: no casts, functions instead of macroes, a limited use of pointers and 
> so on.

Which C++ compilers prevent those practices deprecated in your second
sentence ?
0
Kilgallen (2738)
3/5/2005 7:54:57 PM
Ioannis Vranos <ivr@remove.this.grad.com> writes:

[snip]

> On the other hand I do not know ADAs ideals (for example I do not
> think it supports the generic programming paradigm - templates), but I
> suspect they are to be an easy (restricted to easy parts), safe (not
> letting you do low level operations), application development
> language, which is OK for usual application development.

First of all, the language is called Ada. It is not an acronym, but a
woman's name.

Ada supports generic ("template") programming very well. It
furthermore lets you do all the low-level operations you can think of:
Reading from a memory location, converting bit sequences into
integers, performing pointer arithmetic etc. You can f.x. convert an
octet into an array of Booleans and thus refer to each "bit" as a
Boolean value.

Give it a try - it never hurts to gain experience with new/other
programming languages. The people at comp.lang.ada are always willing
to help and answer questions.

Regards,
- Mark Lorenzen
0
3/5/2005 8:12:34 PM
In article <y8lWd.103136$Vf.3969714@news000.worldonline.dk>, "Peter Koch Larsen" <pklspam@mailme.dk> writes:
> 
> "Ludovic Brenta" <ludovic.brenta@insalien.org> skrev i en meddelelse 
> news:87r7iu85lf.fsf@insalien.org...

>> it at hand anyway, but the gist of it is that, in Ada, loop variables
>> (a) are constants and (b) do not exist outside of the loop:

> This is inherited from Pascal if I remember correctly. Of course, good C++ 
> style is to declare your variable in the loop.

That is also good style in macro assemblers, and presumably in paper-only
languages used to write machine code where you toggle in the binary.  But
the purpose of a compiler is to help you avoid errors, whether you think
of such things at the time or not.

>> * conditions cannot mix "and" and "or" without parentheses.  Thus
>>  there is no possibility that the programmer make wrong assumptions
>>  about precedence of operators or order of evaluation.
> 
> This seems ridiculous. I would expect a programmer to know the precedence 
> rules or at least insert parentheses if they are in doubt.

Expectations are one thing, but having the compiler help you is better.

>> * the type system, when used appropriately, makes it possible for the
>>  compiler to find semantic errors in addition to just syntax errors.
>>  For example, you can declare that Numers_Of_Apples and
>>  Numers_Of_Oranges cannot be mixed.  This is not possible with C++'s
>>  typedef.
> 
> I like that idea. It is possible using templates, of course. Is it general 
> enough? If you replace "apples" with "weight" and "oranges" with "length", 
> is it then permissible to multiply a length with a weight but not add the 
> two together?

It is possible, with enough work, to do such things.

It is preferable to mandate that such project-specific needs be
programmed only by senior programming staff.  Thus the junior
members of the staff just say this_box_length * this_box_weight.

Any responsibility for the meaningfulness of that result is on the
shoulders of senior staff.

> My conclusion is that there are some nice ideas out there, but that they 
> mainly protect against the "sloppy" programmer.

My conclusion after 35 years with computers is that there are "sloppy"
programmers out there.  So I look for mechanisms to guard against such
things.  Formal inspection is great, but it is a waste of resources if
used to catch small errors that can be avoided with proper choice of
tools.
0
Kilgallen (2738)
3/5/2005 8:12:38 PM
Ioannis Vranos writes:
> In general, we cannot compare the two languages because they have
> different design ideals.
>
>
> C++ supports 4 paradigms. Each paradigm is supported well with
> maximum run-time/space *efficiency*. At the same time it leaves no
> room for a lower level language except of assembly.

Ada's efficiency is on par with C++'s, thank you very much.  In fact,
the most widely used Ada compiler is none other than GCC.

> On the other hand I do not know ADAs ideals (for example I do not
> think it supports the generic programming paradigm - templates),

Ada can teach C++ how to do templates properly.  In Ada they are
called "generics".  The reason why Ada's generics are better (IMHO)
than C++'s templates is that Ada alows you to express constraints
between generic parameters.  There is also a rich set of possible
generic parameters.  A generic parameter can be a type, an object, a
subprogram, or a package (in which case the actual package must be an
instance of some designated generic package!).  For example, in Ada,
you can say that a generic takes a type parameter which must be a
subclass of some designated class.  You can then go on to say that a
second parameter must be an instance of that particular subclass.

Ada supports procedural programming, object-oriented programming,
genericity, and exceptions, just like C++.

And, Ada supports multitasking.  How's that for a multiparadigm
language?

The one thing that C++ supports that Ada doesn't is multiple
inheritance.  This feature was left out as unsafe.  Interface
inheritance à la Java is being added in Ada 2005.

> but I suspect they are to be an easy (restricted to easy parts),
> safe (not letting you do low level operations), application
> development language, which is OK for usual application development.

Ada also has low-level facilities for systems programming.  These
facilities allow doing bit-level programming *cleanly* and
*explicitly*.  An entire chapter of the Ada reference manual is
devoted to this - chapter 13, "representation issues".

This means that, uness you see a representation clause or uses of
Unchecked_Conversion or Unchecked_Deallocation, you can pretty much
assume that an Ada program uses only safe features.  In Ada, unsafe
programming is possible but must be explicit.

There is also a gem of a language feature: pragma Restrictions.  This
pragma allows you to restrict usage of some language features, *and
the compiler enforces the restrictions*.  But the possible
restrictions are implementation-defined.

-- 
Ludovic Brenta.
0
3/5/2005 8:13:42 PM
Martin Krischik wrote:

> Well that's easy:
> 
> unsigned int X = -1;
> 
> char Y [10];
> Y [10] = "X";
> 
> Or bit more subtle:
> 
> unsigned int X Day_Of_Month = 32;



Day_Of_Month does not compile. You can make the Day_Of_Month an enum:


enum Day_Of_Month { Mon=1, Sun=7};


int main()
{
   Day_Of_Month X= 32;
}


C:\c>g++ temp.cpp -o temp.exe
temp.cpp: In function `int main()':
temp.cpp:6: error: invalid conversion from `int' to `Day_Of_Month'

C:\c>



The char Y thing does not compile, but try this:

#include <vector>

int main()
{
     using namespace std;

    vector<char> Y (10);

    Y.at(10) = 'X';
}


The most important thing that you may be missing, is that in C++ you can 
choose the level of abstraction and safety you want by using some 
third-party library or framework that fits your needs.


For example consider this:


// Using .NET facilities
int main()
{
    using namespace System;

    array<int> ^IntArray= {1,2,3,4,5,6,7,8,9,0};

    IntArray[10]= 10;
}


C:\c>temp

Unhandled Exception: System.IndexOutOfRangeException: Index was outside 
the boun
ds of the array.
    at main()

C:\c>



#include <iostream>
#include <ostream>

int main()
{
    using namespace System;
    using namespace std;

    int x= 71;

    char c= x.ToString()[0];

    cout<<c<<endl;

    cout<<x.ToString()->Length<<endl;
}

C:\c>temp
7
2

C:\c>


The above make use of the .NET 2 framework facilities, which provide 
additional safety and the high level things you are mentioning.


Bottom line is in C++ you can be as safe and as high level you like. 
Just pick the suitable libraries or frameworks.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/5/2005 8:14:44 PM
Mark Lorenzen wrote:

> You can do everything in Ada that you can in C and C++.


I suppose you mean in the application-programming domain. But I do not 
think this is true in the systems programming domain, that is efficiency 
under *severe* run-time and space constraints.


Also I am not sure if ADA is suitable for library writing, or you will 
have to switch to another language to do that.

I do not say this is bad, since the design ideals of ADA are different 
from C++. In effect, we are comparing different things here.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/5/2005 8:19:30 PM
Ioannis Vranos writes:
> Bottom line is in C++ you can be as safe and as high level you
> like. Just pick the suitable libraries or frameworks.

No, you cannot be as safe as you like.  For this, you would need the
ability to restrict usage of unsafe features.  Just because you also
have safe features at your disposal does not force you to use them.

Your sentence should read: in C++, despite all the high-level
features, you can be as unsafe as you like because the compiler will
let you.

-- 
Ludovic Brenta.
0
3/5/2005 8:22:23 PM
Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Mark Lorenzen wrote:
> 
> > You can do everything in Ada that you can in C and C++.
> 
> 
> I suppose you mean in the application-programming domain. But I do not
> think this is true in the systems programming domain, that is
> efficiency under *severe* run-time and space constraints.

Why? I see no reason that an executable programmed in Ada should be a
slow or big? 

> 
> 
> Also I am not sure if ADA is suitable for library writing, or you will
> have to switch to another language to do that.

Why?

Regards,
- Mark Lorenzen
0
3/5/2005 8:24:25 PM
"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:tx+GQm7$4SnO@eisner.encompasserve.org...

> > - You might end up making more mistakes with Ada because of
> >    inexperience with Ada.
>
> But if you do, they will typically be caught at compile-time.

I would argue that this isn't strictly true.  Of course, the bonehead errors
will be caught by the compiler, but the same is true for C++.

I found that, while I could write servicible code pretty quickly in Ada, it
took a long time, coming from C (and Pascal before that), to really
understand how to exploit the language.

By way of example, someone in this thread posted an example using a
Day_of_Month type.  It would never occur to a C programmer that the day of
the month was anything other than an integer.  At the other extreme, once
discovering all this wonderful capability, it is very easy to get carried
away and take it to extremes.  It takes quite some experience to understand
the correct balance for just this one useful feature of the language.

I also feel that Ada programs are more difficult -for experienced
programmers- to read.  Sure, any Joe off the street can probably get more
from an Ada program than a C++ program, but C and C++ have a lot of idioms
that express fairly large concepts in immediately recognizable ways.  With
Ada, not only is there less of this, but the language is so wordy that even
simple functions seem to go on and on.

Still, if I was back doing safety critical code, I don't think I could
honestly argue that C++ was a viable choice.

...


0
3/5/2005 8:24:44 PM
Ludovic Brenta wrote:

> It is true that, in ISO C++, loop variables declared in the for
> statement are not visible outside the loop.  However, the library I
> was working on did make use of the loop variable after the loop, and
> none of our 4 or 5 different C++ compilers complained about it.
> 
> Which brings me to the general question: is there any
> standard-compliant C++ compiler in existence?  Or are compilers only
> "mostly compliant" or "close enough" or some other ill-defined term?


int main()
{
     for(int i=0; i<10; ++i)
        ;

     i=7;
}

C:\c>g++ temp.cpp -o temp.exe
temp.cpp: In function `int main()':
temp.cpp:6: error: name lookup of `i' changed for new ISO `for' scoping
temp.cpp:3: error:   using obsolete binding at `i'

C:\c>



C:\c>cl temp.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.41013 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

temp.cpp
temp.cpp(6) : error C2065: 'i' : undeclared identifier

C:\c>



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/5/2005 8:27:51 PM
Ioannis Vranos writes:
> Mark Lorenzen wrote:
>
>> You can do everything in Ada that you can in C and C++.
>
>
> I suppose you mean in the application-programming domain. But I do
> not think this is true in the systems programming domain, that is
> efficiency under *severe* run-time and space constraints.

Then why is it that almost all spacecraft, satellites, airplanes,
trains, nuclear power stations, submarines are programmed in Ada?  Is
that not real-time enough for you?  Remember the Mars rover?  Ada.
The Cassini-Huygens mission?  Ada.  Europe's air traffic control
network?  Ada.  The US air traffic control network?  Ada.

I myself am involved in writing system-level avionics software.  There
is no operating system.  We do address and data manipulations at the
bit level.  We write to processor registers.  There are hard real-time
constraints, as well as safety constraints.  We write all of this in
Ada, with a few machine code insertions ("inline assembler") in a
couple places.

I have a feeling that you just don't know what you are talking about.

> Also I am not sure if ADA is suitable for library writing, or you
> will have to switch to another language to do that.

I will repeat what Mark Lorenzen just said above:

You can do everything in Ada that you can in C and C++.

> I do not say this is bad, since the design ideals of ADA are different
> from C++. In effect, we are comparing different things here.

Yes, we are comparing a hacker's language with an engineer's language.

-- 
Ludovic Brenta.
0
3/5/2005 8:28:03 PM
Ludovic Brenta wrote:

> Ada can teach C++ how to do templates properly.  In Ada they are
> called "generics".  The reason why Ada's generics are better (IMHO)
> than C++'s templates is that Ada alows you to express constraints
> between generic parameters.


You can also express constraints in templates. An important thing is 
this. Are Ada's generics run-time or compile time?

As I said in another message of mine, in C++ you can "plug in" whatever 
you want by using third-party libraries and frameworks.


For example in .NET 2, C++ will have both its compile-time templates and 
..NET's 2 run-time generics (with the keyword generic).


>  There is also a rich set of possible
> generic parameters.  A generic parameter can be a type, an object, a
> subprogram, or a package (in which case the actual package must be an
> instance of some designated generic package!). 


It looks like they are run-time, and in C++ you can do all the above. 
Actually Ada's compilers are probably written in C++.



> For example, in Ada,
> you can say that a generic takes a type parameter which must be a
> subclass of some designated class.  You can then go on to say that a
> second parameter must be an instance of that particular subclass.
> 
> Ada supports procedural programming, object-oriented programming,
> genericity, and exceptions, just like C++.
> 
> And, Ada supports multitasking.  How's that for a multiparadigm
> language?


I suppose you mean multithreading. You can do that in C++ in many 
different ways, by "plugging in" the necessary facilities:


By using the OpenMP standard (http://www.openmp.org)

#include <vector>

int main()
{
     using namespace std;

     vector<int> somearray(10);

     #pragma omp for
     for(vector<int>::size_type i=0; i<somearray.size(); ++i)
        somearray[i]=i;
}


The above pragma tells the compiler that each operation on vector's 
elements is independent from the others, and thus the compiler instantly 
creates a thread for each assignment, taking advantage of any 
multiprocessor/multicore CPUs that exist.

Unknown #pragmas are ignored by compilers, so a compiler not supporting 
OpenMP still compiles the code.


In .NET you can also use its multithreading facilities, in addition to 
OpenMP:


// .NET multithreading thread-lock model
__gc class SomeClass
{
  int index;

  //...

  public:

  // ...


  void DoSomething()
  {
     Monitor::Enter(this);

    // Modify index

     Monitor::Exit();
  }

  void DoSomethingElse()
  {
     Monitor::Enter(this);

     // Modify index

     Monitor::Exit();
   }

// ...
};


SomeClass *ps= __gc new SomeClass;

// ...

Thread *pthread1= __gc new Thread ( __gc new ThreadStart(ps, 
&SomeClass::DoSomething) );



Thread *pthread2= __gc new Thread ( __gc new ThreadStart(ps, 
&SomeClass::DoSomethingElse) );


//Start execution of ps->DoSomething()
pthread1->Start();

//Start execution of ps->DoSomethingElse()
pthread2->Start();

// ...


The are innumerable ways that you can do things in C++, you just 'plug 
in" the additional facilities that you want.



> The one thing that C++ supports that Ada doesn't is multiple
> inheritance.  This feature was left out as unsafe.  Interface
> inheritance à la Java is being added in Ada 2005.
> 
> 
>>but I suspect they are to be an easy (restricted to easy parts),
>>safe (not letting you do low level operations), application
>>development language, which is OK for usual application development.
> 
> 
> Ada also has low-level facilities for systems programming.  These
> facilities allow doing bit-level programming *cleanly* and
> *explicitly*.  An entire chapter of the Ada reference manual is
> devoted to this - chapter 13, "representation issues".


Do you know std::bitset?


> 
> This means that, uness you see a representation clause or uses of
> Unchecked_Conversion or Unchecked_Deallocation, you can pretty much
> assume that an Ada program uses only safe features.  In Ada, unsafe
> programming is possible but must be explicit.


In C++ you can be as safe, restricted and convenient as you want.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/5/2005 8:44:18 PM
Ioannis Vranos wrote:

> In C++ you can be as safe, restricted and convenient as you want.

Including garbage collection.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/5/2005 8:46:08 PM
Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> * accessibility rules are rather complex, but they are designed to
>   minimise the chance of mistakes.  Basically, the scope of a pointer
>   type must be included in the scope of the pointed-to type.  This
>   makes many mistakes impossible, such as returning a pointer to an
>   object which no longer exists.

It is extremely easy to make dangling pointers.

Ada makes it hard to have pointers to objects whose _type_ has gone
out of scope, but that's fairly unusual!

-- 
Simon Wright                               100% Ada, no bugs.
0
simon8285 (1465)
3/5/2005 8:55:31 PM
Ludovic Brenta wrote:
> The one thing that C++ supports that Ada doesn't is multiple
> inheritance.  This feature was left out as unsafe.  Interface
> inheritance =C3=A0 la Java is being added in Ada 2005.

there is also one other thing i can think of: template specialization.

this is an interresting construct, used a lot in C++, which gives the=20
ability to write "traits". there may be a way to do it in Ada but i'm=20
not aware of it (if there is, please tell me).

--=20
rien

0
3/5/2005 9:08:40 PM
Ioannis Vranos <ivr@remove.this.grad.com> writes:

> It looks like they are run-time, and in C++ you can do all the
> above. Actually Ada's compilers are probably written in C++.

At least GNAT (GNU/Ada) is written in Ada and DEC Ada was written in Ada IIRC.

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
0
pascal27 (183)
3/5/2005 9:11:31 PM
Ludovic Brenta wrote:

> Then why is it that almost all spacecraft, satellites, airplanes,
> trains, nuclear power stations, submarines are programmed in Ada?  Is
> that not real-time enough for you?  Remember the Mars rover?  Ada.
> The Cassini-Huygens mission?  Ada.  Europe's air traffic control
> network?  Ada.  The US air traffic control network?  Ada.

You wrote that like Ada was 100% of the software content of those missions. 
Far from it. Cassini also used some Forth on board (see list at:- 
<http://forth.gsfc.nasa.gov/>). I am sure that wasn't the only alternative 
language used either.

[%X]
 
> Yes, we are comparing a hacker's language with an engineer's language.

I am sure that hackers can work in many languages, even Ada. Engineering is 
a process thing not T&E.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************
0
peb (807)
3/5/2005 9:14:02 PM
Ioannis Vranos <ivr@remove.this.grad.com> writes:

> int main()
> {
>      for(int i=0; i<10; ++i)
>         ;
> 
>      i=7;
> }

And what about:

 int main()
 {
   int i;
      for(i=0; i<10; ++i)
         ;
 
      i=7;
 }

What is important for safety is not what a language permits but what
it forbids. As long as you have traps in a language you know that some
programmers will fall into it at some point.

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
0
pascal27 (183)
3/5/2005 9:15:46 PM
Ioannis Vranos wrote:

> Ludovic Brenta wrote:
> 
>> Generally speaking, the very fact that you feel an urge to distinguish
>> between "C++" and "modern C++" is an indication that C++ is a poor
>> language containing many unsafe features, some of which you obligingly
>> enumerated above.  By contrast, there is no distinction between "Ada"
>> and "modern Ada".  Ada is safe by design, from the ground up.
> 
> 
> With Ada aside (I find no reason why one should not learn it), C++ is a
> powerful and systems programming language, and power implies painful low
> level details.

But Ada is used for system programming language as well. Only it is not
painfull. Most C/C++ programmers think that a language suitable for system
programming must be painfull - but this is not true.

Well, there is a drawback: you have to type more. But then: once you typed
it in it's easer to read - and most programms are read more then written.

> However it also provides all major high level facilities, 
> and if you stick in high level programming it is very safe, while it
> maintains the maximum space and run-time efficiency principle.

The real difference is that Ada puts emphasis on "save" while C++ puts
emphasis on "fast". C++ only becomes save by use of the STL.

And with the speed of the computers today "save" is better. I remember well
the time when Blaster/32 infected my computer faster then I could download
the fix (download the fix with Linux in the end - but that's another
story).

> In general, we cannot compare the two languages because they have
> different design ideals.
 
That is indeed true. But the differences are not system vs application -
both languages draw even here. Its save vs. fast, readabiltiy vs.
writeablity and explicid vs implicid.

Of corse, having stessed the save vs. fast point: Most Ada compiler allow
you to switch off the savety net with a compiler option.

> C++ supports 4 paradigms. Each paradigm is supported well with maximum
> run-time/space *efficiency*.

Ada supports the same 4 paradigms and concurrent programming on top.

> At the same time it leaves no room for a 
> lower level language except of assembly.

True. But C/C++ havn't got a monopoly/patent on that feature. 

> On the other hand I do not know ADAs ideals (for example I do not think 
> it supports the generic programming paradigm - templates), but I suspect

Actualy Ada has templates since it's 1983 release. I don't think C++ had
templates at the time.

> they are to be an easy (restricted to easy parts),

True Ada is easy - but not restricted. You think one excludes the other -
but that isn't true.

> safe (not letting you 
> do low level operations),

Ada can do more low level stuff then C++ - or have you ever seen 24 bit
integer types in C++.

> application development language, which is OK 
> for usual application development.

As I said, here you as mistaken. While Ada is indeed well suited for high
level application development is is mostly used for low level embedded
programming. Usualy in planes, railways, spacecraft and weapons.

I usualy read - at least - the wiki article before I say anything about a
programming language:

http://en.wikipedia.org/wiki/Ada_programming_language

With Regards

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

0
martin131 (308)
3/5/2005 9:23:18 PM
	Ugh... Cross-posted.... And since I don't know which group
replies are being /read/ from...

On Sat, 5 Mar 2005 17:30:23 +0100, "Peter Koch Larsen"
<pklspam@mailme.dk> declaimed the following in comp.lang.ada:

> 
> I like that idea. It is possible using templates, of course. Is it general 
> enough? If you replace "apples" with "weight" and "oranges" with "length", 
> is it then permissible to multiply a length with a weight but not add the 
> two together?
>
	Only if you've defined an overloaded "*" operator (and you also
have to overload for each order of arguments).

	In the case of the apples/oranges, one could also create a
"FruitBasket" type, then overload

	function "+"(left:apples; right:oranges) return FruitBasket 
and
	function "+"(left:oranges; right:apples) return FruitBasket

	You would, inside of these overloads, have to "convert" apples
and oranges to base numeric types, do the addition on that, then
"convert" the result to FruitBasket.

	For your length and weight, add a torque type, and define the
proper operator

	function "*"(left:length; right:weight) return torque

-- 
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >           Home Page: <http://www.dm.net/~wulfraed/>            <
 >        Overflow Page: <http://wlfraed.home.netcom.com/>        <
0
wlfraed (4596)
3/5/2005 9:27:16 PM
Ioannis Vranos wrote:

> Martin Krischik wrote:
> 
>> Well that's easy:
>> 
>> unsigned int X = -1;
>> 
>> char Y [10];
>> Y [10] = "X";
>> 
>> Or bit more subtle:
>> 
>> unsigned int X Day_Of_Month = 32;

> Day_Of_Month does not compile.

Shure - the X is to much - a cut/copy/paste mistake.

> You can make the Day_Of_Month an enum: 

Day_Of_Month - not Day_Of_Week ;-) 

> Bottom line is in C++ you can be as safe and as high level you like.
> Just pick the suitable libraries or frameworks.

I know. But the *default* is unsave - you have to explicitly *activate*
save. While in Ada it's the other way round (yes you can deactivate save in
Ada if you need to).

Martin

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

0
martin131 (308)
3/5/2005 9:32:37 PM
Ioannis Vranos wrote:
> For example in .NET 2, C++ will have both its compile-time templates and 
> ..NET's 2 run-time generics (with the keyword generic).

> #include <vector>
> 
> int main()
> {
>     using namespace std;
> 
>     vector<int> somearray(10);
> 
>     #pragma omp for
>     for(vector<int>::size_type i=0; i<somearray.size(); ++i)
>        somearray[i]=i;
> }

your 2 examples seems not standard C++. i don't think my favorite C++ 
compiler will understand "#pragma omp ..." out of the box, nor even 
"generic".

> In .NET you can also use its multithreading facilities, in addition to 
> OpenMP:
[snipped a long example of multi-threaded things relying on functions 
which are not in the C++ standard]

if you had ever written any multi-threaded code in Ada, you would have 
been ashamed of the example you gave.

protected Index is
     procedure Set( I : Integer );
     function Get return Integer;
end Index;

task Do_Something is
begin
     -- use Index as you wish
end Do_Something;

task Do_Something_Else is
begin
     -- use Index as you wish
end Do_Something_Else;

(the above example, does the same as your C++ example)

> The are innumerable ways that you can do things in C++, you just 'plug 
> in" the additional facilities that you want.

additional facilities you are talking about are called "third party 
libraries". any language have some, including C++ and Ada.

> Do you know std::bitset?

IIRC, std::bitset is implemented in term of functions performing at 
runtime the shift operations required to access a single bit.

-- 
rien

0
3/5/2005 9:39:58 PM
i just forgot some implementation details in my example. here is the 
complete example:

protected Index is
     procedure Set( I : Integer );
     function Get return Integer;
private
     Value : Integer;
end Index;

protected body Index is
     procedure Set( I : Integer ) is
     begin
         Value := I;
     end Set;

     function Get return Integer is
     begin
         return Value;
     end Get;
end Index;

task Do_Something;
task Do_Something_Else;

task body Do_Something is
begin
     -- use Index as you wish
end Do_Something;

task body Do_Something_Else is
begin
     -- use Index as you wish
end Do_Something_Else;

-- 
rien

0
3/5/2005 9:45:22 PM
Pascal Obry wrote:
>
> And what about:
> 
>  int main()
>  {
>    int i;
>       for(i=0; i<10; ++i)
>          ;
>  
>       i=7;
>  }
> 
> What is important for safety is not what a language permits but what
> it forbids. As long as you have traps in a language you know that some
> programmers will fall into it at some point.


Every variable is visible inside the scope that it was defined.

If you want to use i inside a for loop only, then define it in the for loop.


The restriction that you imply you desire, limits flexibility.

Once again, I have nothing against learning Ada, however personally I 
like the most powerful languages. The next thing I am going to learn 
after C++ (because I haven't learned it all yet), is probably some form 
of assembly language.


For example I like that I can do:

#include <iostream>
#include <string>
#include <bitset>
#include <limits>

class SomeClass
{
       std::string s;

       public:
              SomeClass()
              {
                         s="This is a text message";
              }
};


int main()
{
     using namespace std;

     SomeClass obj;

     unsigned char *p= reinterpret_cast<unsigned char *>(&obj);

     // Displays the individual bytes that obj
     // consists of as unsigned chars.
     for(unsigned i=0; i<sizeof(obj); ++i)
       cout<<"character: "<<p[i]<<"\n";

     cout<<"\n";


     p= reinterpret_cast<unsigned char *>(&obj);
     // Displays the decimal values of the
     // individual bytes that obj consists of.
     for(unsigned i=0; i<sizeof(obj); ++i)
       cout<<static_cast<unsigned>(p[i])<<" ";

     cout<<"\n\n";


     // Displays the bits of each byte that consist
     // this SomeClass object
      p= reinterpret_cast<unsigned char *>(&obj);
      for(unsigned i=0; i<sizeof(obj); ++i)
      {
           // A byte is not necessarily 8 bits
           // numeric_limits<unsigned char>::digits retrieves the number
           // of byte's bits, which *is* 8 usually.
           bitset<numeric_limits<unsigned char>::digits> bits(p[i]);

           for(unsigned j=0; j<bits.size(); ++j)
              cout<<bits[j];

           cout<<"\n";
      }
}


C:\c>temp
character: ⁿ
character: =
character: >
character:

252 61 62 0

00111111
10111100
01111100
00000000

C:\c>


I am sure that many ADA developers will say that this one is not needed 
(the ability to access the individual bytes of objects is needed in many 
cases, e.g. to create low level exact copies of objects ) and it is 
unsafe (yes it is, low level stuff are unsafe and it all depend on the 
programmer knowing what he does).


It is up to oneself to learn whatever languages fits his purposes. For 
example, a "safe" language is not an interest for me.

Someone who places much hopes on the language to protect him from his 
mistakes, probably ADA is better than C++ on this.


There is no language that provides satisfies all people desires, just 
because some desires are in contrast between them.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/5/2005 9:57:34 PM
In article <1110052142.832650@athnrd02>, Ioannis Vranos <ivr@remove.this.grad.com> writes:
> Ludovic Brenta wrote:

>> The bug in the C++ library was that I was mistakenly reusing the loop
>> variable after the loop, instead of the intended variable.  Of course,
>> the loop variable was an index pointing after the end of the buffer.
> 
> 
> It looks like the code was not ISO C++ compliant.

In that case, it looks like the compiler failed to detect that shortcoming.
0
Kilgallen (2738)
3/5/2005 10:01:57 PM
Ludovic Brenta wrote:

> * when the compiler cannot check some code statically, it inserts
>   run-time checks which are guaranteed to catch all errors by raising
>   exceptions.  In C++ you must code these checks by hand, and of
>   course at some point you'll forget one crucial check which will cost
>   you days in debugging.

I think the fallacy of that statement has been proven already (in a very 
expensive way).


-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************
0
peb (807)
3/5/2005 10:05:21 PM
In article <1110053977.478846@athnrd02>, Ioannis Vranos <ivr@remove.this.grad.com> writes:
> Mark Lorenzen wrote:
> 
>> You can do everything in Ada that you can in C and C++.
> 
> 
> I suppose you mean in the application-programming domain. But I do not 
> think this is true in the systems programming domain, that is efficiency 
> under *severe* run-time and space constraints.

And what guesswork makes you think there would be efficiency problems
with Ada ?

> Also I am not sure if ADA is suitable for library writing, or you will 
> have to switch to another language to do that.

Huh ?

Again, what guesswork makes you suggest that ?

It is even possible in Ada to make the calling convention be the
unsafe C-style interface (null terminated strings, etc.).  But for
better safety in all the languages that might call the library,
it is better to avoid those C conventions.
0
Kilgallen (2738)
3/5/2005 10:08:28 PM
Ioannis Vranos wrote:

> C:\c>temp
> character: ⁿ
> character: =
> character: >
> character:
> 
> 252 61 62 0
> 
> 00111111
> 10111100
> 01111100
> 00000000
> 
> C:\c>


Keep in mind that the code displays how things are implemented by the 
specific compiler. For VC++ 2005 Express Beta 1 we get:


C:\c>cl /EHsc temp.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.41013 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

temp.cpp
Microsoft (R) Incremental Linker Version 8.00.41013
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:temp.exe
temp.obj

C:\c>temp
character: ♂
character: Ψ
character: A
character:
character: Ι
character: /
character: 3
character:
character: α
character:
character: B
character:
character: ░
character:  
character: ↕
character:
character: <
character: ╡
character: @
character:
character: ▬
character:
character:
character:
character: ▼
character:
character:
character:

11 150 65 0 136 47 51 0 152 8 66 0 176 255 18 0 60 181 64 0 22 0 0 0 31 
0 0 0

11010000
01101001
10000010
00000000
00010001
11110100
11001100
00000000
00011001
00010000
01000010
00000000
00001101
11111111
01001000
00000000
00111100
10101101
00000010
00000000
01101000
00000000
00000000
00000000
11111000
00000000
00000000
00000000

C:\c>


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/5/2005 10:11:01 PM
"Larry Kilgallen" <Kilgallen@SpamCop.net> skrev i en meddelelse 
news:zrCcaGBZQ9Cx@eisner.encompasserve.org...
> In article <3SjWd.103128$Vf.3969241@news000.worldonline.dk>, "Peter Koch 
> Larsen" <pklspam@mailme.dk> writes:
>
>>>> - You might end up making more mistakes with Ada because of
>>>>    inexperience with Ada.
>>>
>>> Wrong.  I took that route 4 years ago, and found that the compiler
>>> would catch all my stupid mistakes.  When it comes to reliability, Ada
>>> compilers are your friends; C++ compilers are your enemies.
>>
>> Out of curiosiy, could you give some few examples where Ada catches 
>> faults
>> not found by a C++ compiler. I assume - of course - code written in 
>> modern
>> C++: no casts, functions instead of macroes, a limited use of pointers 
>> and
>> so on.
>
> Which C++ compilers prevent those practices deprecated in your second
> sentence ?

It is not a question of prevention. C++ allows you to do some really 
dangerous things - in my mind rightfully so. When you do program in C++ you 
must "constrain yourself" and not use the dangeous stuff - unless you need 
to do so, of course ;-)
It's kind of like driving. You can get into a lot of trouble if you do not 
follow the traffic laws (you just have to obey the physicla ones ;-), but so 
long as you do driving is a fairly safe practice.

/Peter 


0
pklspam (199)
3/5/2005 10:33:11 PM
"Larry Kilgallen" <Kilgallen@SpamCop.net> skrev i en meddelelse 
news:Q5TNweyx8scS@eisner.encompasserve.org...
> In article <1110053977.478846@athnrd02>, Ioannis Vranos 
> <ivr@remove.this.grad.com> writes:
>> Mark Lorenzen wrote:
>>
>>> You can do everything in Ada that you can in C and C++.
>>
>>
>> I suppose you mean in the application-programming domain. But I do not
>> think this is true in the systems programming domain, that is efficiency
>> under *severe* run-time and space constraints.
>
> And what guesswork makes you think there would be efficiency problems
> with Ada ?
>
>> Also I am not sure if ADA is suitable for library writing, or you will
>> have to switch to another language to do that.
>
> Huh ?
>
> Again, what guesswork makes you suggest that ?
>
> It is even possible in Ada to make the calling convention be the
> unsafe C-style interface (null terminated strings, etc.).  But for
> better safety in all the languages that might call the library,
> it is better to avoid those C conventions.

It is also possible to use zero-terminated strings in C++, but every 
knowledgeable person will advice that you use std::string. So what is the 
difference here?

/Peter 


0
pklspam (199)
3/5/2005 10:37:08 PM
Ioannis Vranos wrote:

> and it is 
> unsafe (yes it is, low level stuff are unsafe and it all depend on the 
> programmer knowing what he does).


But it *is* portable.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/5/2005 10:39:38 PM
"Ludovic Brenta" <ludovic.brenta@insalien.org> skrev i en meddelelse 
news:87is4598pm.fsf@insalien.org...
> Peter Koch Larsen writes:
>> "Ludovic Brenta" skrev i en meddelelse
>>> procedure Proc (A : in String) is
>>> begin
>>>   for J in A'Range loop
>>>      J := J + 4; -- illegal, J is constant inside the loop
>>>   end loop;
>>>   Do_Womething_With (J); -- illegal, J no longer exists
>>> end Proc;
>>
>> This is inherited from Pascal if I remember correctly. Of course,
>> good C++ style is to declare your variable in the loop.
>
> Most of Ada's syntax is inherited from Pascal.  In fact, Ada is
> "Pascal done right", since Ada eliminated most of Pascal's problems
> like separate compilation or the infamous "dangling else" problem. For
> that matter, these problems also exist in C and C++.
>
> It is true that, in ISO C++, loop variables declared in the for
> statement are not visible outside the loop.  However, the library I
> was working on did make use of the loop variable after the loop, and
> none of our 4 or 5 different C++ compilers complained about it.
>
> Which brings me to the general question: is there any
> standard-compliant C++ compiler in existence?  Or are compilers only
> "mostly compliant" or "close enough" or some other ill-defined term?

If you disregard the controversial "export" keyword, most recent compilers 
are close to being 100% conforming (but might not be so "out-of-the-box").

>
> By contrast, consider Ada's formal validation process, which is also
> an ISO standard (ISO/IEC 18009 - Ada: Conformity assessment of a
> language processor).  In the 1980's, the DoD held the trademark "Ada",
> and only validated compilers were allowed to call themselves "Ada
> compilers".  Now, the rules are more lax, but all compilers in
> existence pass the validation suite.  See:
>
> http://www.ada-auth.org/acats.html
>
I will look into that one later.
>>> * conditions cannot mix "and" and "or" without parentheses.  Thus
>>> there is no possibility that the programmer make wrong assumptions
>>> about precedence of operators or order of evaluation.
>>
>> This seems ridiculous. I would expect a programmer to know the
>> precedence rules or at least insert parentheses if they are in
>> doubt.
>
> This is the crux of the problem.  Assuming that the programmer "knows
> the rules", "makes no mistakes" or "can be trusted" is a recipe for
> disaster.  One of the principles in Ada's rationale is to make
> everything explicit, rather than implicit.

Do you also require parenthesis when mixing addition and multiplication? I 
do not like that degree of nannying - a matter of taste, surely.

>
>>> * the type system, when used appropriately, makes it possible for
>>> the compiler to find semantic errors in addition to just syntax
>>> errors.  For example, you can declare that Numers_Of_Apples and
>>> Numers_Of_Oranges cannot be mixed.  This is not possible with C++'s
>>> typedef.
>>
>> I like that idea. It is possible using templates, of course. Is it
>> general enough? If you replace "apples" with "weight" and "oranges"
>> with "length", is it then permissible to multiply a length with a
>> weight but not add the two together?
>
> Yes:
>
> type Weight is digits 8 range 0.0 .. 900.0;  -- 8 decimal digits of 
> precision
> type Length is digits 8 range 0.0 .. 1000.0;
>
> Now these types are incompatible.  If you want to mix them, you need
> to define the semantics and provide the appropriate operators:
>
> type Weight_Length is digits 8 range 0.0 .. 900_000.0;
>
> function "*" (Left : in Weight; Right : in Length) return  Weight_Length;
>
> Since you don't provide "+", there is no way to add a weight to a
> length.
>
> For a more general discussion of physical quantities in Ada, see:
>
> http://home.t-online.de/home/Christ-Usch.Grein/Ada/Universe.html

I believe I will prefer the C++ solution - a template that copes with all 
this stuff.

>
>>> * conversions from floating point to integer types involve
>>> rounding.  The rounding is precisely and deterministically defined
>>> by the ISO standard for the Ada language.  Similarly,
>>> floating-point and fixed-point types can be declared with known,
>>> deterministic, guaranteed precision.
>>
>> This point sounds as if it restricts the environments where Ada can
>> be used.
>
> Do you mean that not all targets may implement the requested
> precision?  That is true but it is not a language issue.  Ada
> compilers are required to document which precision they support for
> their targets.
>
> And fixed-point types being really nothing more than integers, all
> targets support them to some extent.
>
>> I sort of like this one as well - although raising an exception
>> seems to be to forgiving.
>
> What other mechanism would you suggest?

Termination of the program. Some might argue that they can't tolerate such 
an event. But can such an environment tolerate a faulty running program?

>
>> My conclusion is that there are some nice ideas out there, but that
>> they mainly protect against the "sloppy" programmer.
>
> It is a mistake to assume that the programmer makes no mistakes.
> Mistakes are a given fact of the human nature.  Ada is designed with
> this in mind.
>
> A sloppy programmer will avoid Ada like the plague, because they
> resent discipline in general and don't appreciate being taught
> lessons.  A good software engineer will be attracted to Ada because
> she is a powerful ally.
>
> -- 
> Ludovic Brenta.

/Peter 


0
pklspam (199)
3/5/2005 10:44:56 PM
"Peter Koch Larsen" writes:
> If you disregard the controversial "export" keyword, most recent
> compilers are close to being 100% conforming (but might not be so
> "out-of-the-box").

Good.  What kind of assurance does a C++ compiler user have?

> Do you also require parenthesis when mixing addition and
> multiplication? I do not like that degree of nannying - a matter of
> taste, surely.

No, just when mixing "and" and "or".

>> For a more general discussion of physical quantities in Ada, see:
>>
>> http://home.t-online.de/home/Christ-Usch.Grein/Ada/Universe.html
>
> I believe I will prefer the C++ solution - a template that copes with all 
> this stuff.

Read the paper first; it does use templates (generics).

>> What other mechanism would you suggest?
>
> Termination of the program. Some might argue that they can't
> tolerate such an event. But can such an environment tolerate a
> faulty running program?

That's what an unhandled exception results in.  In avionics, where we
have no operating system and no run-time system, exceptions cannot
propagate and thus always result in program termination.  When testing
the program, we prove that no exception is ever raised.

-- 
Ludovic Brenta.
0
3/5/2005 10:59:08 PM
Ioannis Vranos writes:
> The restriction that you imply you desire, limits flexibility.

Of course.  That's what all these stories about shooting yourself in
the foot mean.

> Once again, I have nothing against learning Ada, however personally
> I like the most powerful languages. The next thing I am going to
> learn after C++ (because I haven't learned it all yet), is probably
> some form of assembly language.

Yes, assembly is the most powerful and flexible language.  That's why
all compilers emit assembler.

> For example I like that I can do:

[...]

in Ada, you would use an overlaid array of characters, like this:

with Ada.Strings.Unbounded;
with Ada.Text_IO;
procedure Unsafe_Proc is
   type Some_Class is record
      S : Ada.Strings.Unbounded.Unbounded_String;
   end record;

   Obj : aliased Some_Class :=
      (S => Ada.Strings.Unbounded.To_Unbounded_String
               ("This is a text message"));

   Obj_As_String : String (1 .. Obj'Size / System.Storage_Unit);
   for Obj_As_String'Address use Obj'Address;
begin
   for J in Obj_As_String'Range loop
      Ada.Text_IO.Put_Line
         (Integer'Image (Character'Pos (Obj_As_String (J))) &
          "    " &
          Obj_As_String (J));
   end loop;
end Unsafe_Proc;


Here, Ada makes it explicit that unsafe programming is taking place.
First, Obj must be declared as "aliased", which means that two or more
paths can access it.  In our case, Obj and Obj_As_String are the two
paths.  This is another of Ada's nice safety-related features.  Since
aliasing must be made explicit, the reader of the program knows up
front whether or not aliasing takes place.  The reader of a C++
program has no such knowledge.  Also, the writer of the program must
think twice, and understand the consequences if they make an object
aliased.

Secondly, the representation clause for Obj_As_String ("for
Obj_As_String'Address use ...") says exactly what is happening.

I could make the code less verbose by using use clauses, similar to
"using namespace std" which you seem fond of.  In avionics, our coding
standards forbid that because we want everything to be explicit.

> I am sure that many ADA developers will say that this one is not
> needed (the ability to access the individual bytes of objects is
> needed in many cases, e.g. to create low level exact copies of
> objects ) and it is unsafe (yes it is, low level stuff are unsafe
> and it all depend on the programmer knowing what he does).

I am an Ada (not ADA) developer, and I use overlaid structures as
above in avionics software when necessary.  However, Ada has better
constructs for "low-level exact copies".  Ada's representation clauses
allow us to specify the bit pattern used for our low-level structures,
all the way down to endianness of numbers or absolute addresses.

> It is up to oneself to learn whatever languages fits his
> purposes. For example, a "safe" language is not an interest for me.

Then I am not interested entrusting my life to your software.

> Someone who places much hopes on the language to protect him from
> his mistakes, probably ADA is better than C++ on this.

Hear, hear!

> There is no language that provides satisfies all people desires,
> just because some desires are in contrast between them.

Agreed.  Even in Ada, we sometimes use machine code insertions
("inline assembler") when we must.

-- 
Ludovic Brenta.
0
3/5/2005 11:29:35 PM
Ludovic Brenta wrote:
> Ioannis Vranos writes:
> 
>>The restriction that you imply you desire, limits flexibility.
> 
> 
> Of course.  That's what all these stories about shooting yourself in
> the foot mean.
> 
> 
>>Once again, I have nothing against learning Ada, however personally
>>I like the most powerful languages. The next thing I am going to
>>learn after C++ (because I haven't learned it all yet), is probably
>>some form of assembly language.
> 
> 
> Yes, assembly is the most powerful and flexible language.  That's why
> all compilers emit assembler.
> 
> 
>>For example I like that I can do:
> 
> 
> [...]
> 
> in Ada, you would use an overlaid array of characters, like this:
> 
> with Ada.Strings.Unbounded;
> with Ada.Text_IO;
> procedure Unsafe_Proc is
>    type Some_Class is record
>       S : Ada.Strings.Unbounded.Unbounded_String;
>    end record;
> 
>    Obj : aliased Some_Class :=
>       (S => Ada.Strings.Unbounded.To_Unbounded_String
>                ("This is a text message"));
> 
>    Obj_As_String : String (1 .. Obj'Size / System.Storage_Unit);
>    for Obj_As_String'Address use Obj'Address;
> begin
>    for J in Obj_As_String'Range loop
>       Ada.Text_IO.Put_Line
>          (Integer'Image (Character'Pos (Obj_As_String (J))) &
>           "    " &
>           Obj_As_String (J));
>    end loop;
> end Unsafe_Proc;


May you provide the output of the code? Because I can not understand 
much by itself. Can Ada


> Then I am not interested entrusting my life to your software.


I wouldn't use low-level unsafe facilities for safety-critical 
situations but types which have checks all over the place and RAII.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/5/2005 11:55:34 PM
Ludovic Brenta wrote:

> in Ada, you would use an overlaid array of characters, like this:
> 
> with Ada.Strings.Unbounded;
> with Ada.Text_IO;
> procedure Unsafe_Proc is
>    type Some_Class is record
>       S : Ada.Strings.Unbounded.Unbounded_String;
>    end record;
> 
>    Obj : aliased Some_Class :=
>       (S => Ada.Strings.Unbounded.To_Unbounded_String
>                ("This is a text message"));
> 
>    Obj_As_String : String (1 .. Obj'Size / System.Storage_Unit);
>    for Obj_As_String'Address use Obj'Address;
> begin
>    for J in Obj_As_String'Range loop
>       Ada.Text_IO.Put_Line
>          (Integer'Image (Character'Pos (Obj_As_String (J))) &
>           "    " &
>           Obj_As_String (J));
>    end loop;
> end Unsafe_Proc;


May you provide the output of the code? Because I can not understand 
much by itself. Can Ada display the decimal value of each byte that 
consists an object of a user-defined type, along with the bit values of 
these bytes?


 > Then I am not interested entrusting my life to your software.


I wouldn't use low-level unsafe facilities for safety-critical 
situations but types which have checks all over the place and RAII.




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/6/2005 12:01:11 AM
Ioannis Vranos <ivr@remove.this.grad.com> wrote in
news:1110059861.560004@athnrd02: 

> 
> Once again, I have nothing against learning Ada, however personally I 
> like the most powerful languages. The next thing I am going to learn 
> after C++ (because I haven't learned it all yet), is probably some
> form of assembly language.
> 
> 
> For example I like that I can do:
> 
> #include <iostream>
> #include <string>
> #include <bitset>
> #include <limits>
> 
> class SomeClass
> {
>        std::string s;
> 
>        public:
>               SomeClass()
>               {
>                          s="This is a text message";
>               }
> };
> 
> 
> int main()
> {
>      using namespace std;
> 
>      SomeClass obj;
> 
>      unsigned char *p= reinterpret_cast<unsigned char *>(&obj);
> 
>      // Displays the individual bytes that obj
>      // consists of as unsigned chars.
>      for(unsigned i=0; i<sizeof(obj); ++i)
>        cout<<"character: "<<p[i]<<"\n";
> 
>      cout<<"\n";
> 
> 
>      p= reinterpret_cast<unsigned char *>(&obj);
>      // Displays the decimal values of the
>      // individual bytes that obj consists of.
>      for(unsigned i=0; i<sizeof(obj); ++i)
>        cout<<static_cast<unsigned>(p[i])<<" ";
> 
>      cout<<"\n\n";
> 
> 
>      // Displays the bits of each byte that consist
>      // this SomeClass object
>       p= reinterpret_cast<unsigned char *>(&obj);
>       for(unsigned i=0; i<sizeof(obj); ++i)
>       {
>            // A byte is not necessarily 8 bits
>            // numeric_limits<unsigned char>::digits retrieves the
>            number // of byte's bits, which *is* 8 usually.
>            bitset<numeric_limits<unsigned char>::digits> bits(p[i]);
> 
>            for(unsigned j=0; j<bits.size(); ++j)
>               cout<<bits[j];
> 
>            cout<<"\n";
>       }
> }
> 
> 
> C:\c>temp
> character: ⁿ
> character: =
> character: >
> character:
> 
> 252 61 62 0
> 
> 00111111
> 10111100
> 01111100
> 00000000
> 
> C:\c>
> 

All this can be done in Ada.

How good is C++ at exactly representing bit fields?

Can C++ do this portably:

type Byte is mod 2**8;
type Sign_Flag is mod 2;

type Mouse_Status_Type is record
   Left_Button_Pressed  : Boolean;
   Right_Button_Pressed : Boolean;
   X_Movement_Sign      : Sign_Flag;
   Y_Movement_Sign      : Sign_Flag;
   X_Movement_Overflow  : Boolean;
   Y_Movement_Overflow  : Boolean;
   X_Movement_Magnitude : Byte;
   Y_Movement_Magnitude : Byte;
end record;

for Mouse_Status_Type use record
   Left_Button_Pressed   at 0 range 0..0;
   Right_button_Pressed  at 0 range 1..1;
   X_Movement_Sign       at 0 range 4..4;
   Y_Movement_Sign       at 0 range 5..5;
   X_Movement_Overflow   at 0 range 6..6;
   Y_Movement_Overflow   at 0 range 7..7;
   X_Movement_Magnitude  at 1 range 0..7;
   Y_Movement_Magnitude  at 2 range 0..7;
end record;

The type Mouse_Status_Type defines a data
structure that occupies three bytes. The
first 6 fields of the record occupy a single
bit each, with bits 2 and 3 unused.

Furthermore, access to the individual fields of this record
are very direct, not requiring arcane bit masks.

foo : Mouse_Status_Type;


if foo.Left_Button_Pressed then
  do_something;
end if;

> 
> I am sure that many ADA developers will say that this one is not
> needed (the ability to access the individual bytes of objects is
> needed in many cases, e.g. to create low level exact copies of objects
> ) and it is unsafe (yes it is, low level stuff are unsafe and it all
> depend on the programmer knowing what he does).
> 

On the contrary, Ada is frequently used for low level bit manipulation.
Ada was designed to be used in safety-critical hard real-time 
embedded systems.

> 
> It is up to oneself to learn whatever languages fits his purposes. For
> example, a "safe" language is not an interest for me.

We are all free to have our own interests. I do ask that you look at
the capabilities of a language before you decide they are not in your
interest. Ada does not prevent you from doing unsafe things. It 
simply does not provide an unsafe behavior as its default.

> 
> Someone who places much hopes on the language to protect him from his 
> mistakes, probably ADA is better than C++ on this.

Programming is a human activity. All humans make mistakes. Some of those
mistakes are damned silly. Ada is designed to acknowledge that
programmers are human. Mistakes will be made. Ada attempts to identify
those mistakes as early in the development process as possible.
We all know that it is cheaper to fix mistakes early.

> 
> 
> There is no language that provides satisfies all people desires, just 
> because some desires are in contrast between them.


And there is no perfect language. Ada is not meant to satisfy the
desires of all programmers. It is meant to support programming as
a human activity with the goal of producing high quality programs
very efficiently.

Jim Rogers

0
3/6/2005 12:41:51 AM
Ioannis Vranos wrote:
> Ioannis Vranos wrote:
> 
>> In C++ you can be as safe, restricted and convenient as you want.
> 
> 
> Including garbage collection.

Also, allowed by Ada95 language definition.
0
3/6/2005 12:55:04 AM
On Sat, 05 Mar 2005 23:59:08 +0100, Ludovic Brenta  
<ludovic.brenta@insalien.org> wrote:

>>> What other mechanism would you suggest?
>>
>> Termination of the program. Some might argue that they can't
>> tolerate such an event. But can such an environment tolerate a
>> faulty running program?
> That's what an unhandled exception results in.  In avionics, where we
> have no operating system and no run-time system, exceptions cannot
> propagate and thus always result in program termination.  When testing
> the program, we prove that no exception is ever raised.


There are certainly other strategies available.  For instance, in an  
"integrated modular avionics" architecture, an unhandled Ada exception in  
a single partition could be forwarded to a global health monitoring  
facility that may restart that partition, a set of partitions, or the  
whole system - or do something else for error recovery.  This implies that  
exception propagation is a quite flexible capability, and can be embedded  
in a system with even greater error handling flexibility in a comfortable  
way.
0
falis (298)
3/6/2005 12:58:20 AM
Ioannis Vranos wrote:
> Ludovic Brenta wrote:
> 
>> Generally speaking, the very fact that you feel an urge to distinguish
>> between "C++" and "modern C++" is an indication that C++ is a poor
>> language containing many unsafe features, some of which you obligingly
>> enumerated above.  By contrast, there is no distinction between "Ada"
>> and "modern Ada".  Ada is safe by design, from the ground up.
> 
> 
> 
> With Ada aside (I find no reason why one should not learn it), C++ is a 
> powerful and systems programming language, and power implies painful low 
> level details. However it also provides all major high level facilities, 
> and if you stick in high level programming it is very safe, while it 
> maintains the maximum space and run-time efficiency principle.

It does NOT provide multi-tasking... or fixed-point numbers...


> In general, we cannot compare the two languages because they have 
> different design ideals.

We we _can_ compare them... but you are correct that we must take their 
design considerations into account. Ada95 was design specifically to 
support efficient, real-time safe environments (the OP of the original 
thread question), C++ was designed to produce an object-orientated 
extension to C.


> C++ supports 4 paradigms. Each paradigm is supported well with maximum 
> run-time/space *efficiency*. At the same time it leaves no room for a 
> lower level language except of assembly.

Ada83 suffered from some pretty poor implementations, but Ada95 has 
never had the same problems. My own experience is that Ada95 compilers 
produce as efficient code as any other language with the exception of 
assembler. Not scientific I know but...


> On the other hand I do not know ADAs ideals (for example I do not think 
> it supports the generic programming paradigm - templates), but I suspect 
> they are to be an easy (restricted to easy parts), safe (not letting you 
> do low level operations), application development language, which is OK 
> for usual application development.

Oh dear! That's a shocker!!!! Ada had generics back in Ada83 - and _all_ 
Ada83 compiler supported it then! The debugger support back then was 
pretty shabby, but hey, at least the compilers all supported it and in a 
completely uniform fashion.

Cheers

-- Martin

0
3/6/2005 1:01:58 AM
Ludovico Brena wrote:
> Most of Ada's syntax is inherited from Pascal.

I think Modula-3 was the prime inspiration but never having used it I 
could be wrong! :-)
0
3/6/2005 1:03:30 AM
Peter Koch Larsen wrote:
> It is not a question of prevention. C++ allows you to do some really 
> dangerous things - in my mind rightfully so. When you do program in C++ you 
> must "constrain yourself" and not use the dangeous stuff - unless you need 
> to do so, of course ;-)

And Ada lets you do all that but you have to be explicit that you are 
doing it - I don't know of any other language that forces you to be 
explicit that you are doing something dangerous.

Cheers

-- Martin
0
3/6/2005 1:07:56 AM
Jim Rogers wrote:

>>C:\c>temp
>>character: ⁿ
>>character: =
>>character: >
>>character:
>>
>>252 61 62 0
>>
>>00111111
>>10111100
>>01111100
>>00000000
>>
>>C:\c>
>>
> 
> All this can be done in Ada.


It would be great if we saw the code and its output.



> How good is C++ at exactly representing bit fields?
> 
> Can C++ do this portably:


Some explanations with remarks in the code along with the output, would 
make things easier to understand.



> type Byte is mod 2**8;
> type Sign_Flag is mod 2;
> 
> type Mouse_Status_Type is record
>    Left_Button_Pressed  : Boolean;
>    Right_Button_Pressed : Boolean;
>    X_Movement_Sign      : Sign_Flag;
>    Y_Movement_Sign      : Sign_Flag;
>    X_Movement_Overflow  : Boolean;
>    Y_Movement_Overflow  : Boolean;
>    X_Movement_Magnitude : Byte;
>    Y_Movement_Magnitude : Byte;
> end record;
> 
> for Mouse_Status_Type use record
>    Left_Button_Pressed   at 0 range 0..0;
>    Right_button_Pressed  at 0 range 1..1;
>    X_Movement_Sign       at 0 range 4..4;
>    Y_Movement_Sign       at 0 range 5..5;
>    X_Movement_Overflow   at 0 range 6..6;
>    Y_Movement_Overflow   at 0 range 7..7;
>    X_Movement_Magnitude  at 1 range 0..7;
>    Y_Movement_Magnitude  at 2 range 0..7;
> end record;
> 
> The type Mouse_Status_Type defines a data
> structure that occupies three bytes.


I guess the C++ equivalent is:

struct SomeStruct
{
  unsigned  Left_Button_Pressed:  1;
  unsigned  Right_button_Pressed: 1;
  unsigned  X_Movement_Sign:      1;
  unsigned  Y_Movement_Sign:      1;
  unsigned  X_Movement_Overflow:  1;
  unsigned  Y_Movement_Overflow:  1;
  unsigned  X_Movement_Magnitude: 8;
  unsigned  Y_Movement_Magnitude: 8;
};


It is interesting to see that ADA supports this.





> The
> first 6 fields of the record occupy a single
> bit each, with bits 2 and 3 unused.
> 
> Furthermore, access to the individual fields of this record
> are very direct, not requiring arcane bit masks.
> 
> foo : Mouse_Status_Type;
> 
> 
> if foo.Left_Button_Pressed then
>   do_something;
> end if;


The above in a simple C++ program:


#include <iostream>


int main()
{
     struct SomeStruct
     {
            unsigned  Left_Button_Pressed:  1;
            unsigned  Right_button_Pressed: 1;
            unsigned  X_Movement_Sign:      1;
            unsigned  Y_Movement_Sign:      1;
            unsigned  X_Movement_Overflow:  1;
            unsigned  Y_Movement_Overflow:  1;
            unsigned  X_Movement_Magnitude: 8;
            unsigned  Y_Movement_Magnitude: 8;
     };

     SomeStruct obj= {1, 0, true, false, 1, 16, 64};

     if(obj.Left_Button_Pressed)
       std::cout<<"It is pressed!\n";
}

C:\c>temp
It is pressed!

C:\c>




> On the contrary, Ada is frequently used for low level bit manipulation.
> Ada was designed to be used in safety-critical hard real-time 
> embedded systems.


It is interesting to hear that.


> We are all free to have our own interests. I do ask that you look at
> the capabilities of a language before you decide they are not in your
> interest. Ada does not prevent you from doing unsafe things. It 
> simply does not provide an unsafe behavior as its default.


Perhaps I will check it sometime in the future.



> 
> 
>>Someone who places much hopes on the language to protect him from his 
>>mistakes, probably ADA is better than C++ on this.
> 
> 
> Programming is a human activity. All humans make mistakes. Some of those
> mistakes are damned silly. Ada is designed to acknowledge that
> programmers are human. Mistakes will be made. Ada attempts to identify
> those mistakes as early in the development process as possible.
> We all know that it is cheaper to fix mistakes early.


Yes, however I have the feeling that it does so by imposing several 
restrictions that apart from protecting from possible misuses, also 
prevent from flexible uses.

Again, this is just a feeling, I have not studied the language.


> And there is no perfect language. Ada is not meant to satisfy the
> desires of all programmers. It is meant to support programming as
> a human activity with the goal of producing high quality programs
> very efficiently.

OK.


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/6/2005 1:23:43 AM
Martin Dowie wrote:

> It does NOT provide multi-tasking... or fixed-point numbers...


C++ provides whatever the system it is used to provides. In Windows you 
can create multithreading applications for example.



> 
> 
>> In general, we cannot compare the two languages because they have 
>> different design ideals.
> 
> 
> We we _can_ compare them... but you are correct that we must take their 
> design considerations into account. Ada95 was design specifically to 
> support efficient, real-time safe environments (the OP of the original 
> thread question), C++ was designed to produce an object-orientated 
> extension to C.


C++ is not only an OO language, but it is a multiparadigm one.


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/6/2005 1:30:53 AM
In comp.realtime Martin Dowie <martin.dowie@btopenworld.com> wrote:
> Ludovico Brena wrote:
>> Most of Ada's syntax is inherited from Pascal.
> 
> I think Modula-3 was the prime inspiration but never having used it I 
> could be wrong! :-)

Modula-3 *post*dated Ada by some years; it was designed in the late 80s
and unfortunately "missed the bus" - Ada was (at the time) very expensive,
C++ was (at the time) immature and unstandardised, and for a while I
hoped that Modula-3 would become the language of choice for large-scale
maintstream OOP/procedural programming.

Ada-83's ancestry is, as many have observed, mostly Pascal. (IIRC, three
of the four languages that got to the DoD's bake-off were Pascal-based; 
a fourth was PL/1 based. Algol-68 was the other language identified as a
possible basis for the DoD's language, but no (directly) Algol-based
language made it that far.)

pete
-- 
pete@fenelon.com "Send lawyers, guns and money...."
0
pete6 (288)
3/6/2005 1:33:01 AM
Ioannis Vranos wrote:

> The above in a simple C++ program:
> 
> 
> #include <iostream>
> 
> 
> int main()
> {
>     struct SomeStruct
>     {
>            unsigned  Left_Button_Pressed:  1;
>            unsigned  Right_button_Pressed: 1;
>            unsigned  X_Movement_Sign:      1;
>            unsigned  Y_Movement_Sign:      1;
>            unsigned  X_Movement_Overflow:  1;
>            unsigned  Y_Movement_Overflow:  1;
>            unsigned  X_Movement_Magnitude: 8;
>            unsigned  Y_Movement_Magnitude: 8;
>     };

      SomeStruct obj= {1, 0, true, false, 1, 1, 16, 64};

>     if(obj.Left_Button_Pressed)
>       std::cout<<"It is pressed!\n";
> }
> 
> C:\c>temp
> It is pressed!
> 
> C:\c>


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/6/2005 1:35:40 AM
[Reposted because follow-ups had redirected it]

Jim Rogers wrote:

 >> C:\c>temp
 >> character: ⁿ
 >> character: =
 >> character: >
 >> character:
 >>
 >> 252 61 62 0
 >>
 >> 00111111
 >> 10111100
 >> 01111100
 >> 00000000
 >>
 >> C:\c>
 >>
 >
 > All this can be done in Ada.



It would be great if we saw the code and its output.



 > How good is C++ at exactly representing bit fields?
 >
 > Can C++ do this portably:



Some explanations with remarks in the code along with the output, would 
make things easier to understand.



 > type Byte is mod 2**8;
 > type Sign_Flag is mod 2;
 >
 > type Mouse_Status_Type is record
 >    Left_Button_Pressed  : Boolean;
 >    Right_Button_Pressed : Boolean;
 >    X_Movement_Sign      : Sign_Flag;
 >    Y_Movement_Sign      : Sign_Flag;
 >    X_Movement_Overflow  : Boolean;
 >    Y_Movement_Overflow  : Boolean;
 >    X_Movement_Magnitude : Byte;
 >    Y_Movement_Magnitude : Byte;
 > end record;
 >
 > for Mouse_Status_Type use record
 >    Left_Button_Pressed   at 0 range 0..0;
 >    Right_button_Pressed  at 0 range 1..1;
 >    X_Movement_Sign       at 0 range 4..4;
 >    Y_Movement_Sign       at 0 range 5..5;
 >    X_Movement_Overflow   at 0 range 6..6;
 >    Y_Movement_Overflow   at 0 range 7..7;
 >    X_Movement_Magnitude  at 1 range 0..7;
 >    Y_Movement_Magnitude  at 2 range 0..7;
 > end record;
 >
 > The type Mouse_Status_Type defines a data
 > structure that occupies three bytes.



I guess the C++ equivalent is:

struct SomeStruct
{
  unsigned  Left_Button_Pressed:  1;
  unsigned  Right_button_Pressed: 1;
  unsigned  X_Movement_Sign:      1;
  unsigned  Y_Movement_Sign:      1;
  unsigned  X_Movement_Overflow:  1;
  unsigned  Y_Movement_Overflow:  1;
  unsigned  X_Movement_Magnitude: 8;
  unsigned  Y_Movement_Magnitude: 8;
};


It is interesting to see that ADA supports this.





 > The
 > first 6 fields of the record occupy a single
 > bit each, with bits 2 and 3 unused.
 >
 > Furthermore, access to the individual fields of this record
 > are very direct, not requiring arcane bit masks.
 >
 > foo : Mouse_Status_Type;
 >
 >
 > if foo.Left_Button_Pressed then
 >   do_something;
 > end if;



The above in a simple C++ program:


#include <iostream>


int main()
{
     struct SomeStruct
     {
            unsigned  Left_Button_Pressed:  1;
            unsigned  Right_button_Pressed: 1;
            unsigned  X_Movement_Sign:      1;
            unsigned  Y_Movement_Sign:      1;
            unsigned  X_Movement_Overflow:  1;
            unsigned  Y_Movement_Overflow:  1;
            unsigned  X_Movement_Magnitude: 8;
            unsigned  Y_Movement_Magnitude: 8;
     };

     SomeStruct obj= {1, 0, true, false, 1, 1, 16, 64};

     if(obj.Left_Button_Pressed)
       std::cout<<"It is pressed!\n";
}

C:\c>temp
It is pressed!

C:\c>




 > On the contrary, Ada is frequently used for low level bit manipulation.
 > Ada was designed to be used in safety-critical hard real-time 
embedded systems.



It is interesting to hear that.


 > We are all free to have our own interests. I do ask that you look at
 > the capabilities of a language before you decide they are not in your
 > interest. Ada does not prevent you from doing unsafe things. It 
simply does not provide an unsafe behavior as its default.



Perhaps I will check it sometime in the future.



 >
 >
 >> Someone who places much hopes on the language to protect him from 
his mistakes, probably ADA is better than C++ on this.
 >
 >
 >
 > Programming is a human activity. All humans make mistakes. Some of those
 > mistakes are damned silly. Ada is designed to acknowledge that
 > programmers are human. Mistakes will be made. Ada attempts to identify
 > those mistakes as early in the development process as possible.
 > We all know that it is cheaper to fix mistakes early.



Yes, however I have the feeling that it does so by imposing several 
restrictions that apart from protecting from possible misuses, also 
prevent from flexible uses.

Again, this is just a feeling, I have not studied the language.


 > And there is no perfect language. Ada is not meant to satisfy the
 > desires of all programmers. It is meant to support programming as
 > a human activity with the goal of producing high quality programs
 > very efficiently.


OK.


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/6/2005 1:41:37 AM
Larry Elmore wrote:

> I'm afraid you don't know much about Ada and much of what you do know is 
>  not correct. That was one of the specific problem domains Ada was 
> designed for -- hard real-time embedded systems.


Yes, after some things I have read in the thread, Ada is upper in my 
interest scale.

I did not know that it was designed for low level stuff.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/6/2005 1:46:51 AM
Ioannis Vranos wrote:
> Mark Lorenzen wrote:
> 
>> You can do everything in Ada that you can in C and C++.
> 
> 
> 
> I suppose you mean in the application-programming domain. But I do not 
> think this is true in the systems programming domain, that is efficiency 
> under *severe* run-time and space constraints.

I'm afraid you don't know much about Ada and much of what you do know is 
  not correct. That was one of the specific problem domains Ada was 
designed for -- hard real-time embedded systems.

> Also I am not sure if ADA is suitable for library writing, or you will 
> have to switch to another language to do that.
> 
> I do not say this is bad, since the design ideals of ADA are different 
> from C++. In effect, we are comparing different things here.

No, you only think that's the case. I encourage you to learn more about 
Ada. You might be very surprised.

Also, it's spelled "Ada", not ADA (which in the US usually means the 
American Dental Association, or the Americans with Disabilities Act). 
It's not an acronym. It was named after a woman, Ada Augusta Lovelace. 
No one who knows anything about the language spells it ADA (unless 
they're on an ancient machine that has no lowercase letters) anymore 
than they spell "Pascal" as "PASCAL".

--Larry
0
ljelmore_ (59)
3/6/2005 1:49:27 AM
Martin Dowie wrote:
> Ludovico Brena wrote:
> 
>> Most of Ada's syntax is inherited from Pascal.
> 
> 
> I think Modula-3 was the prime inspiration but never having used it I 
> could be wrong! :-)

Definitely not Modula 3, which dates from the latter half of the 1980s. 
I remember the introduction to the original book published about it 
mentioning how they learned from errors made in the designs of Modula 2 
and Ada83. I've never used it, but I remember thinking it did have some 
good ideas (although they kept the damnable 'begin .. end' keywords and 
a couple of other things that I no longer remember instead of using 
Ada's much better syntax).

--Larry
0
ljelmore_ (59)
3/6/2005 1:59:09 AM
On Sun, 6 Mar 2005 01:03:30 +0000 (UTC), Martin Dowie
<martin.dowie@btopenworld.com> declaimed the following in comp.lang.ada:

> Ludovico Brena wrote:
> > Most of Ada's syntax is inherited from Pascal.
> 
> I think Modula-3 was the prime inspiration but never having used it I 
> could be wrong! :-)

	Considering that the Ada effort started in the mid-70s, I don't
even think Modula-2 was available. See
http://www.cs.fit.edu/~ryan/ada/ada-hist.html for dates.

	As I recall from my studies (the choice Green to become Ada
occurred in time for me to use it in a language report for a college
class) the four teams that competed in the proposal all chose Pascal as
their starting point.

-- 
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >           Home Page: <http://www.dm.net/~wulfraed/>            <
 >        Overflow Page: <http://wlfraed.home.netcom.com/>        <
0
wlfraed (4596)
3/6/2005 2:59:35 AM
Ioannis Vranos <ivr@remove.this.grad.com> wrote in news:1110072229.85604
@athnrd02:

> Jim Rogers wrote:
> 
>>>C:\c>temp
>>>character: ⁿ
>>>character: =
>>>character: >
>>>character:
>>>
>>>252 61 62 0
>>>
>>>00111111
>>>10111100
>>>01111100
>>>00000000
>>>
>>>C:\c>
>>>
>> 
>> All this can be done in Ada.
> 
> 
> It would be great if we saw the code and its output.
> 

Ok. That is certainly a fair requirement.

with Ada.Text_Io;
with Ada.Integer_Text_Io;
with System;

procedure String_Bits is
   S : String := "This is a text message";
   L : Natural := S'Size;
   type Bits_Array is array (1..L) of Boolean;
   pragma Pack (Bits_Array);
   Bits : Bits_Array;
   for Bits'Address use S'Address;
begin
   -- Display the bits of each character
   for I in Bits'range loop
      Ada.Integer_Text_Io.Put(Item => Boolean'Pos(Bits(I)), Width => 1);
      if I mod System.Storage_Unit = 0 then
         Ada.Text_Io.New_Line;
      end if;
   end loop;
end String_Bits;

The output is:
00101010
00010110
10010110
11001110
00000100
10010110
11001110
00000100
10000110
00000100
00101110
10100110
00011110
00101110
00000100
10110110
10100110
11001110
11001110
10000110
11100110
10100110

The program declares a string S initialized to "This is a text message".
It then declares an array type named Bits_Array. That array type is an
array of Boolean, with the number of elements equal to the number of 
bits in used by S. The variable L is set to equal the value returned
by the Size attribute of the String S. Ada reports size as the number
of bits, not the number of bytes.

A packed array of boolean allocates one storage element to each bit.
Therefore, the statement
   pragma Pack(Bits_Array);
causes all instances of Bits_Array to be a packed array.
The variable Bits is declared to be of the type Bits_Array.
The next statement forces Bits to overlay S. Both variables
are the same size and start at the same address.

The body of the procedure simply iterates through all the bits in
the Bits variable and prints the numeric value of each bit.
A new line is output whenever the loop control variable mod
System.Storage_Unit evaluates to 0. System.Storage_Unit is
provided by Ada so that the program will properly represent
each storage unit (sometimes called a byte) no matter what the
size of that unit is.

As you can clearly see, Ada can represent the bits of a
variable with very little difficulty.

Ada does not store a null at the end of a string. This is
why there is no indication of a null value for the last byte.

Jim Rogers

0
3/6/2005 3:11:49 AM
Ioannis Vranos <ivr@remove.this.grad.com> wrote in
news:1110072660.15684@athnrd02: 

> Martin Dowie wrote:
> 
>> It does NOT provide multi-tasking... or fixed-point numbers...
> 
> 
> C++ provides whatever the system it is used to provides. In Windows
> you can create multithreading applications for example.
> 

Of course it can, by calling C libraries such as pThreads.

Concurrency has been a native part of Ada since the 1983 standard.

> 
> 
>> 
>> 
>>> In general, we cannot compare the two languages because they have 
>>> different design ideals.
>> 
>> 
>> We we _can_ compare them... but you are correct that we must take
>> their design considerations into account. Ada95 was design
>> specifically to support efficient, real-time safe environments (the
>> OP of the original thread question), C++ was designed to produce an
>> object-orientated extension to C.
> 
> 
> C++ is not only an OO language, but it is a multiparadigm one.


I agree. One of the original goals of C++ was to produce a language
that extends C into the OO paradigm without loosing any of the 
inherited C capabilities. In 1996 C++ standardized generic programming
as another paradigm.

Ada is also a multi-paradigm language. In fact, it can be used in all
the paradigms familiar to C++. 

Jim Rogers

0
3/6/2005 3:20:12 AM
"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message 
news:1110055473.613245@athnrd02...
> You can also express constraints in templates. An important thing is this. 
> Are Ada's generics run-time or compile time?

Compile time with every Ada compiler I've used.

> It looks like they are run-time, and in C++ you can do all the above. 
> Actually Ada's compilers are probably written in C++.

GNAT is written in Ada.



0
3/6/2005 3:30:05 AM
"Pascal Obry" <pascal@obry.org> wrote in message 
news:ubr9xiyrg.fsf@obry.org...
> At least GNAT (GNU/Ada) is written in Ada and DEC Ada was written in Ada 
> IIRC.

Half right. GNAT is written in Ada, DEC Ada was written in Bliss.


0
3/6/2005 3:31:07 AM
Jim Rogers wrote:

> Of course it can, by calling C libraries such as pThreads.


Actually I am using .NET facilities (posted an example in another 
message in the thread).


> I agree. One of the original goals of C++ was to produce a language
> that extends C into the OO paradigm without loosing any of the 
> inherited C capabilities. In 1996 C++ standardized generic programming
> as another paradigm.
> 
> Ada is also a multi-paradigm language. In fact, it can be used in all
> the paradigms familiar to C++. 

OK.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/6/2005 3:53:18 AM
Jim Rogers wrote:

> The program declares a string S initialized to "This is a text message".
> It then declares an array type named Bits_Array. That array type is an
> array of Boolean, with the number of elements equal to the number of 
> bits in used by S. The variable L is set to equal the value returned
> by the Size attribute of the String S. Ada reports size as the number
> of bits, not the number of bytes.
> 
> A packed array of boolean allocates one storage element to each bit.
> Therefore, the statement
>    pragma Pack(Bits_Array);
> causes all instances of Bits_Array to be a packed array.
> The variable Bits is declared to be of the type Bits_Array.
> The next statement forces Bits to overlay S. Both variables
> are the same size and start at the same address.


Does this mean that Boolean always occupies 1 bit and has no padding bits?


> The body of the procedure simply iterates through all the bits in
> the Bits variable and prints the numeric value of each bit.
> A new line is output whenever the loop control variable mod
> System.Storage_Unit evaluates to 0. System.Storage_Unit is
> provided by Ada so that the program will properly represent
> each storage unit (sometimes called a byte) no matter what the
> size of that unit is.
> 
> As you can clearly see, Ada can represent the bits of a
> variable with very little difficulty.
> 
> Ada does not store a null at the end of a string. This is
> why there is no indication of a null value for the last byte.


While this is an interesting thing, I have the feeling that this 
approach does not print all bits, including padding bits, of a 
*user-defined type*.


In C++ you can read (and thus copy, print or anything) every byte of any 
type.

In the example you provided, I have the feeling that you allocated a 
character array (the string) and then treated is a boolean array 
(somewhat a hacking attempt to imitate the behaviour).


However what happens in the case of a user defined type (I suppose Ada 
supports OO programming) or a record. Can you print the byte 
implementation of such an object?


Also for a built in type, say a floating point, can you print its 
implementation bytes too (including padding bits)?


Consider this:

#include <iostream>
#include <bitset>
#include <limits>

int main()
{
     using namespace std;

     double obj= 0.45435;

     unsigned char *p= reinterpret_cast<unsigned char *>(&obj);


     p= reinterpret_cast<unsigned char *>(&obj);
     // Displays the decimal values of the
     // individual bytes that obj consists of.
     for(unsigned i=0; i<sizeof(obj); ++i)
       cout<<static_cast<unsigned>(p[i])<<" ";

     cout<<"\n\n";


     // Displays the bits of each byte that consist
     // this SomeClass object
      p= reinterpret_cast<unsigned char *>(&obj);
      for(unsigned i=0; i<sizeof(obj); ++i)
      {
           // A byte is not necessarily 8 bits
           // numeric_limits<unsigned char>::digits retrieves the number
           // of byte's bits, which *is* 8 usually.
           bitset<numeric_limits<unsigned char>::digits> bits(p[i]);

           for(unsigned j=0; j<bits.size(); ++j)
              cout<<bits[j];

           cout<<"\n";
      }
}


C:\c>temp
163 1 188 5 18 20 221 63

11000101
10000000
00111101
10100000
01001000
00101000
10111011
11111100

C:\c>



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/6/2005 4:09:00 AM
In article <FsqWd.103188$Vf.3970489@news000.worldonline.dk>, "Peter Koch Larsen" <pklspam@mailme.dk> writes:

> It's kind of like driving. You can get into a lot of trouble if you do not
> follow the traffic laws (you just have to obey the physicla ones ;-), but so
> long as you do driving is a fairly safe practice.

Although I attempt to drive safely, I also rely on seat belts and air bags.
0
Kilgallen (2738)
3/6/2005 4:47:55 AM
In article <d0dkq6$781$1@titan.btinternet.com>, Martin Dowie <martin.dowie@btopenworld.com> writes:

> Oh dear! That's a shocker!!!! Ada had generics back in Ada83 - and _all_ 
> Ada83 compiler supported it then! The debugger support back then was 
> pretty shabby,

Speak for your own compiler, VAX Ada has (and had) excellent debugger
support.
0
Kilgallen (2738)
3/6/2005 4:50:35 AM
Ioannis Vranos <ivr@remove.this.grad.com> wrote in
news:1110082147.830198@athnrd02: 

> Jim Rogers wrote:
> 
>> The program declares a string S initialized to "This is a text
>> message". It then declares an array type named Bits_Array. That array
>> type is an array of Boolean, with the number of elements equal to the
>> number of bits in used by S. The variable L is set to equal the value
>> returned by the Size attribute of the String S. Ada reports size as
>> the number of bits, not the number of bytes.
>> 
>> A packed array of boolean allocates one storage element to each bit.
>> Therefore, the statement
>>    pragma Pack(Bits_Array);
>> causes all instances of Bits_Array to be a packed array.
>> The variable Bits is declared to be of the type Bits_Array.
>> The next statement forces Bits to overlay S. Both variables
>> are the same size and start at the same address.
> 
> 
> Does this mean that Boolean always occupies 1 bit and has no padding
> bits? 
> 

No. A boolean usually occupies a byte. A packed array of boolean
is compressed so that each boolean element of the array occupies only 
one bit.

> 
>> The body of the procedure simply iterates through all the bits in
>> the Bits variable and prints the numeric value of each bit.
>> A new line is output whenever the loop control variable mod
>> System.Storage_Unit evaluates to 0. System.Storage_Unit is
>> provided by Ada so that the program will properly represent
>> each storage unit (sometimes called a byte) no matter what the
>> size of that unit is.
>> 
>> As you can clearly see, Ada can represent the bits of a
>> variable with very little difficulty.
>> 
>> Ada does not store a null at the end of a string. This is
>> why there is no indication of a null value for the last byte.
> 
> 
> While this is an interesting thing, I have the feeling that this 
> approach does not print all bits, including padding bits, of a 
> *user-defined type*.

The same approach will work for any type, including any padding
bits. The Size attribute reports the total number of bits used
by an object. 

> 
> 
> In C++ you can read (and thus copy, print or anything) every byte of
> any type.
> 
> In the example you provided, I have the feeling that you allocated a 
> character array (the string) and then treated is a boolean array 
> (somewhat a hacking attempt to imitate the behaviour).

I created a string, which is an array of character in Ada.
I also created an packed array of boolean with exactly the same
size as the array of character. I then specified that both 
variables will occupy the same space; one overlays the other.

> 
> 
> However what happens in the case of a user defined type (I suppose Ada
> supports OO programming) or a record. Can you print the byte 
> implementation of such an object?
> 
> 
> Also for a built in type, say a floating point, can you print its 
> implementation bytes too (including padding bits)?
> 

The following example starts with the creation of a generic package
for printing the byte and bit output of an object of any type.
The program then instantiates that package for a user-defined
type and for a long_float, which is equivalent to a C++ double.

generic
   type Target_Type is private;
   Target_Size : Natural;
package Bit_Utils is
   procedure Show_Bits(Item : Target_Type);
end Bit_Utils;
   

with Ada.Text_Io;
with Ada.Integer_Text_Io;
with System;
package body Bit_Utils is
   type Bits_Array is array(Positive range <>) of Boolean;
   pragma Pack(Bits_Array);

   type Byte is mod 2**8;
   type Byte_Array is array(Positive range <>) of Byte;
   package Mod_Io is new Ada.Text_IO.Modular_IO(Byte);
   
   procedure Show_Bits(Item : Target_Type) is
      Bit_View : Bits_Array(1..Target_Size);
      for Bit_View'Address use Item'Address;
      Byte_View : Byte_Array(1..Target_Size / Byte'Size);
      For Byte_View'Address use Item'Address;
   begin
      for I in Byte_View'range loop
         Mod_Io.Put(Item => Byte_View(I), Width => 4);
      end loop;
      Ada.Text_IO.New_Line(2);
      for I in Bit_View'range loop
         Ada.Integer_Text_Io.Put(Item => Boolean'Pos(Bit_View(I)), 
            Width => 1);
         if I mod System.Storage_Unit = 0 then
            Ada.Text_IO.New_Line;
         end if;
      end loop;
   end Show_Bits;
end Bit_Utils;

with Bit_Utils;
with Ada.Text_IO;

procedure Bit_Output is
   type My_Type is record
      Name   : String(1..4);
      Age    : Positive;
      Weight : Long_Float;
   end record;
   package My_Bits is new Bit_Utils(My_Type, My_Type'Size);
   package Flt_Bits is new Bit_Utils(Long_Float, Long_Float'Size);
   
   Mt : My_Type := ("Jim ", 55, 0.45435);
   D  : Long_Float := 0.45435;
begin
   Ada.Text_Io.Put_Line("Output of My_Type");
   My_Bits.Show_Bits(Mt);
   Ada.Text_Io.Put_Line("Output of Long_Float");
   Flt_Bits.Show_Bits(D);
end Bit_Output;


The output of this program is:

Output of My_Type
  74 105 109  32  55   0   0   0 163   1 188   5  18  20 221  63

01010010
10010110
10110110
00000100
11101100
00000000
00000000
00000000
11000101
10000000
00111101
10100000
01001000
00101000
10111011
11111100
Output of Long_Float
 163   1 188   5  18  20 221  63

11000101
10000000
00111101
10100000
01001000
00101000
10111011
11111100


Ada provides capabilities similar to C++ in the area of copying
and viewing data.

Jim Rogers

0
3/6/2005 6:12:02 AM
On Sat, 5 Mar 2005 23:44:56 +0100, Peter Koch Larsen wrote:

> "Ludovic Brenta" <ludovic.brenta@insalien.org> skrev i en meddelelse 
> news:87is4598pm.fsf@insalien.org...

>> This is the crux of the problem.  Assuming that the programmer "knows
>> the rules", "makes no mistakes" or "can be trusted" is a recipe for
>> disaster.  One of the principles in Ada's rationale is to make
>> everything explicit, rather than implicit.
> 
> Do you also require parenthesis when mixing addition and multiplication? I 
> do not like that degree of nannying - a matter of taste, surely.

That's the Ada's way. The following is also illegal without brackets:

+ - 2
A**+2 

Though they might look unambiguous, no sensible man would write something
like above.

As for addition and multiplication. The association rules of */+ differs
from ones of and/or:

x + (y * z) is not equivalent to (x + y) * (x + z)

So there is a canonic representation of algebraic expressions with */+. For
and/or the picture is different:

x and (y or z) = (x and y) or (x and z)
(x and y) or z = (x or z) and (y or z)

There is no dedicated representation: a normal disjunctive form is as good
as a normal conjunctive one.

>> type Weight is digits 8 range 0.0 .. 900.0;  -- 8 decimal digits of 
>> precision
>> type Length is digits 8 range 0.0 .. 1000.0;
>>
>> Now these types are incompatible.  If you want to mix them, you need
>> to define the semantics and provide the appropriate operators:
>>
>> type Weight_Length is digits 8 range 0.0 .. 900_000.0;
>>
>> function "*" (Left : in Weight; Right : in Length) return  Weight_Length;
>>
>> Since you don't provide "+", there is no way to add a weight to a
>> length.
>>
>> For a more general discussion of physical quantities in Ada, see:
>>
>> http://home.t-online.de/home/Christ-Usch.Grein/Ada/Universe.html
> 
> I believe I will prefer the C++ solution - a template that copes with all 
> this stuff.

Try to write a unit calculator using templates ...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/6/2005 7:54:12 AM
Martin Krischik wrote:

> But Ada is used for system programming language as well. Only it is not
> painfull. Most C/C++ programmers think that a language suitable for system
> programming must be painfull - but this is not true.
> 
> Well, there is a drawback: you have to type more. But then: once you typed
> it in it's easer to read - and most programms are read more then written.
> 
> The real difference is that Ada puts emphasis on "save" while C++ puts
> emphasis on "fast". C++ only becomes save by use of the STL.
> 
> And with the speed of the computers today "save" is better. I remember well
> the time when Blaster/32 infected my computer faster then I could download
> the fix (download the fix with Linux in the end - but that's another
> story).
>  
> That is indeed true. But the differences are not system vs application -
> both languages draw even here. Its save vs. fast, readabiltiy vs.
> writeablity and explicid vs implicid.
> 
> Of corse, having stessed the save vs. fast point: Most Ada compiler allow
> you to switch off the savety net with a compiler option.
> 
> Ada supports the same 4 paradigms and concurrent programming on top.
> 
> True. But C/C++ havn't got a monopoly/patent on that feature. 
> 
> Actualy Ada has templates since it's 1983 release. I don't think C++ had
> templates at the time.
> 
> True Ada is easy - but not restricted. You think one excludes the other -
> but that isn't true.
> 
> Ada can do more low level stuff then C++ - or have you ever seen 24 bit
> integer types in C++.
> 
> As I said, here you as mistaken. While Ada is indeed well suited for high
> level application development is is mostly used for low level embedded
> programming. Usualy in planes, railways, spacecraft and weapons.
> 
> I usualy read - at least - the wiki article before I say anything about a
> programming language:
> 
> http://en.wikipedia.org/wiki/Ada_programming_language


Certainly after the thread discussion, ADA has ascended a lot in my 
interest scale (I always try to be reasonable).


In that Wiki link I saw it is covering a subset of the procedural 
paradigm and recently also got support for OO. Also it supports generics.

The one remaining, does it support namespaces? :-) What subset of the 
procedural paradigm it does not support?


Also I saw that under severe constraints the run-time safety of the 
language is better to be switched off.


I do not know much on the language, but can one define general-purpose 
containers with Ada's generics that do range checking and throw an 
exception when there is an attempt to access outside the boundaries of 
the container, even if the aforementioned run-time safety is switched off?



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/6/2005 8:50:29 AM
"Larry Kilgallen" <Kilgallen@SpamCop.net> skrev i en meddelelse 
news:CU1wh2sMbcmG@eisner.encompasserve.org...
> In article <FsqWd.103188$Vf.3970489@news000.worldonline.dk>, "Peter Koch 
> Larsen" <pklspam@mailme.dk> writes:
>
>> It's kind of like driving. You can get into a lot of trouble if you do 
>> not
>> follow the traffic laws (you just have to obey the physicla ones ;-), but 
>> so
>> long as you do driving is a fairly safe practice.
>
> Although I attempt to drive safely, I also rely on seat belts and air 
> bags.

I hope we all do. What i meant to say was that using a seat belt isn't an 
excuse to drive on the wrong side of the road.

/Peter 


0
pklspam (199)
3/6/2005 9:22:48 AM
Peter Koch Larsen wrote:

> 
> "Larry Kilgallen" <Kilgallen@SpamCop.net> skrev i en meddelelse
> news:Q5TNweyx8scS@eisner.encompasserve.org...
>> In article <1110053977.478846@athnrd02>, Ioannis Vranos
>> <ivr@remove.this.grad.com> writes:
>>> Mark Lorenzen wrote:
>>>
>>>> You can do everything in Ada that you can in C and C++.
>>>
>>>
>>> I suppose you mean in the application-programming domain. But I do not
>>> think this is true in the systems programming domain, that is efficiency
>>> under *severe* run-time and space constraints.
>>
>> And what guesswork makes you think there would be efficiency problems
>> with Ada ?
>>
>>> Also I am not sure if ADA is suitable for library writing, or you will
>>> have to switch to another language to do that.
>>
>> Huh ?
>>
>> Again, what guesswork makes you suggest that ?
>>
>> It is even possible in Ada to make the calling convention be the
>> unsafe C-style interface (null terminated strings, etc.).  But for
>> better safety in all the languages that might call the library,
>> it is better to avoid those C conventions.
> 
> It is also possible to use zero-terminated strings in C++, but every
> knowledgeable person will advice that you use std::string. So what is the
> difference here?

The defaults (that is the i.E. the constant expression "Hello Word!"):

Default in Ada are save strings - zero terminated via extenral library
(Interfaces.C.Strings).

Default in C++ is zero terminated, save strings via external library
(std::string).

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

0
martin131 (308)
3/6/2005 9:40:44 AM
On Sun, 6 Mar 2005 10:22:48 +0100, Peter Koch Larsen wrote:

> "Larry Kilgallen" <Kilgallen@SpamCop.net> skrev i en meddelelse 
> news:CU1wh2sMbcmG@eisner.encompasserve.org...
>> In article <FsqWd.103188$Vf.3970489@news000.worldonline.dk>, "Peter Koch 
>> Larsen" <pklspam@mailme.dk> writes:
>>
>>> It's kind of like driving. You can get into a lot of trouble if you do 
>>> not
>>> follow the traffic laws (you just have to obey the physicla ones ;-), but 
>>> so
>>> long as you do driving is a fairly safe practice.
>>
>> Although I attempt to drive safely, I also rely on seat belts and air 
>> bags.
> 
> I hope we all do. What i meant to say was that using a seat belt isn't an 
> excuse to drive on the wrong side of the road.

Yes, in Britain (:-)) Ada compiler will ask you to apply
Unchecked_Conversion to the road sides, before you will be able to run the
engine ...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/6/2005 9:42:40 AM
Peter Koch Larsen wrote:

> It is not a question of prevention. C++ allows you to do some really
> dangerous things - in my mind rightfully so.

So does Ada. In fact Ada.Unchecked_Convertion will convert variables no C++
compiler will ever dare to convert. Yes I know, you can allways use a
reinterpret_cast <void*> in the middle.

http://en.wikibooks.org/wiki/Programming:Ada:Subtypes#Unchecked_Conversion

> When you do program in C++ 
> you must "constrain yourself" and not use the dangeous stuff - unless you
> need to do so, of course ;-)

In Ada you don't need to constrain yourself. I found that a very freeing
exprience - after 10+ years of C/C++ programming. And I can still use the
dangeous stuff when I need to.

And see the difference in our sentences here:

You: contrain, not use, unless - all so negative terms.
Me: don't contrain, still use, when - so more positive terms.

> It's kind of like driving. You can get into a lot of trouble if you do not
> follow the traffic laws (you just have to obey the physicla ones ;-), but
> so long as you do driving is a fairly safe practice.

Have you ever seen the traffic in a country where a 10 $ or 10 � note will
make any traffic policemen put is pen back into its pocket.

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

0
martin131 (308)
3/6/2005 9:57:03 AM
<ver�ffentlicht & per Mail versendet>

Paul E. Bennett wrote:

> Ludovic Brenta wrote:
> 
>> * when the compiler cannot check some code statically, it inserts
>>   run-time checks which are guaranteed to catch all errors by raising
>>   exceptions.  In C++ you must code these checks by hand, and of
>>   course at some point you'll forget one crucial check which will cost
>>   you days in debugging.
> 
> I think the fallacy of that statement has been proven already (in a very
> expensive way).

You mean the case where some managers decided to use some software written
for one pice of hardware on another - incompatible - pice of hardware -
without retesting?

In my book that was a management bug - If the managers had ordered to run
the testsuite only once the problem would have shown. The hardware was so
incompatible it would have failed all the time.

Last not least: Runtime check where disabled for that incident. So if
anything: this incident speak in favor of runtime checks.

Read up your facts: http://en.wikipedia.org/wiki/Ariane_5_Flight_501

Martin

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

0
martin131 (308)
3/6/2005 10:09:04 AM
Ioannis Vranos wrote:

> Martin Dowie wrote:
> 
>> It does NOT provide multi-tasking... or fixed-point numbers...

> C++ provides whatever the system it is used to provides.

If it is not in the ISO/IEC 14882 than it is not provided by the language
but only plugged on externaly.

> In Windows you 
> can create multithreading applications for example.

I have a multi-tastking Ada application which runs on OS/2, Windows XP and
Linux. Can you do that in C++ without the use of "#if". Here is the problem
of plugged on solution: they are not compatible between operating system
and compiler vendors.

And even if you find a lib who can all three - I just ask a Mac-OS and
Solaris user on comp.lang.ada to run a test - The Ada multithreading is
part of the ISO/IEC 8652 standart - you recompile it on the next system and
it runs.

> C++ is not only an OO language, but it is a multiparadigm one.

So is Ada only with a few more paradigms build in and not plugged onto by
external libraries.

Again "build in" means defined by "ISO/IEC" - everything else does not count
when comparing languages.

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

0
martin131 (308)
3/6/2005 10:28:29 AM
Ioannis Vranos wrote:

> Martin Krischik wrote:
 
>> I usualy read - at least - the wiki article before I say anything about a
>> programming language:
>> 
>> http://en.wikipedia.org/wiki/Ada_programming_language

> Certainly after the thread discussion, ADA has ascended a lot in my
> interest scale (I always try to be reasonable).

If your interest has been raised there is a larger Ada article on Wikibooks:

http://en.wikibooks.org/wiki/Programming:Ada
 
> In that Wiki link I saw it is covering a subset of the procedural
> paradigm and recently also got support for OO. Also it supports generics.
 
> The one remaining, does it support namespaces? :-) What subset of the
> procedural paradigm it does not support?

Yes, they are called packages and have been in Ada since 1983.

http://en.wikibooks.org/wiki/Programming:Ada:Packages

However they are move powerfull. For example generics are based on packages,
a bit like:

template <....> namespace Generic {};

> Also I saw that under severe constraints the run-time safety of the
> language is better to be switched off.

Which I never do. With activated optimizer the performance loss is so low
there is almost no point in switching run-time check of.
 
> I do not know much on the language, but can one define general-purpose
> containers with Ada's generics that do range checking and throw an
> exception when there is an attempt to access outside the boundaries of
> the container, even if the aforementioned run-time safety is switched off?

Shure, there are several container libs around, all doing that.

http://en.wikibooks.org/wiki/Programming:Ada:Libraries:Container

I have to confess that only the new Ada 2005 will have containers as a build
in features. With the current Ada 95 you have to use external libraries.

Martin

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

0
martin131 (308)
3/6/2005 10:43:47 AM
Ioannis Vranos <ivr@remove.this.grad.com> writes:

> The one remaining, does it support namespaces? :-) What subset of the
> procedural paradigm it does not support?

Yes, of course.

> I do not know much on the language, but can one define general-purpose
> containers with Ada's generics that do range checking and throw an
> exception when there is an attempt to access outside the boundaries of
> the container, even if the aforementioned run-time safety is switched
> off?

Yes, but there's no point, as turning off the automatic boundary
checks and then do manual boundary checks instead doesn't gain you
anything except pain. (In fact, the automatic boundary checks can be
more efficent since compilers might optimize away checks that aren't
needed.)

-- 
Leif Roar Moldskred
0
usenet98 (104)
3/6/2005 10:48:17 AM
Adrien Plisson wrote:

> Ludovic Brenta wrote:
>> The one thing that C++ supports that Ada doesn't is multiple
>> inheritance.  This feature was left out as unsafe.  Interface
>> inheritance � la Java is being added in Ada 2005.
 
> there is also one other thing i can think of: template specialization.
 
> this is an interresting construct, used a lot in C++, which gives the
> ability to write "traits". there may be a way to do it in Ada but i'm
> not aware of it (if there is, please tell me).

Yes traits would be tricky - but not impossible. Ada allows for both
procedures and packages as generic formal parameter:

http://www.adaic.org/standards/95lrm/html/RM-12-6.html
http://www.adaic.org/standards/95lrm/html/RM-12-7.html

However there are two important differences here which would make traits a
typing feast in Ada:

1) Ada generics work on procedures and packages but not classes. A bit like
template <...> namespace X {};

2) Ada genenrics only instanciate explicitly. Well it's a hole namespace
with all classes, prodedures, types and data after all.

But as I said, not impossible. I have a regex generic which can be
instanciated for character and wide character strings and basicly any other
descreed type you want to run regular expressing over.

With Regards

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

0
martin131 (308)
3/6/2005 10:57:48 AM
Peter Koch Larsen wrote:

> If you disregard the controversial "export" keyword, most recent compilers
> are close to being 100% conforming (but might not be so "out-of-the-box").

This is a good one: All Ada templates are export since 1983 and most C++
compiler still can't do it.

Same for the dynamic arrays in C99 which Ada also had since 1983.

> Do you also require parenthesis when mixing addition and multiplication? I
> do not like that degree of nannying - a matter of taste, surely.

No! See http://adaic.org/standards/95lrm/html/RM-4-5.html.

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

0
martin131 (308)
3/6/2005 11:21:57 AM
Martin Krischik wrote:

> <ver�ffentlicht & per Mail versendet>
> 
> Paul E. Bennett wrote:
> 
>> Ludovic Brenta wrote:
>> 
>>> * when the compiler cannot check some code statically, it inserts
>>>   run-time checks which are guaranteed to catch all errors by raising
>>>   exceptions.  In C++ you must code these checks by hand, and of
>>>   course at some point you'll forget one crucial check which will cost
>>>   you days in debugging.
>> 
>> I think the fallacy of that statement has been proven already (in a very
>> expensive way).
> 
> You mean the case where some managers decided to use some software written
> for one pice of hardware on another - incompatible - pice of hardware -
> without retesting?
> 
> In my book that was a management bug - If the managers had ordered to run
> the testsuite only once the problem would have shown. The hardware was so
> incompatible it would have failed all the time.
> 
> Last not least: Runtime check where disabled for that incident. So if
> anything: this incident speak in favor of runtime checks.
> 
> Read up your facts: http://en.wikipedia.org/wiki/Ariane_5_Flight_501
 
Yes, I have read that and the full report. However, I think my comment 
still stands. You stated "when the compiler cannot check some code 
statically, it inserts run-time checks which are guaranteed to catch all 
errors by raising exceptions". The code had to be compiled, for the new 
hardware, to be installed in the guidance system and hence should have had 
the run-time checks in place if static checking could not be done. You have 
admitted in your response that these checks were not active (by management 
decision) so the Ada compiler was circumvented and prohibited from adding 
these checks.

Considering that the proposition in this thread has been "Ada protects you 
from making silly mistakes" I consider that your take is counter to the 
evidence. I still maintain that language is immaterial to the safety of the 
system, relying on decent rigourously applied development processes, 
reviews and testing. Therefore, I tend to look at the development processes 
and their "real" CMM rating. I guess the Ariane team went down a few 
notches on that project.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************
0
peb (807)
3/6/2005 11:39:34 AM
Larry Kilgallen wrote:

> In article <FsqWd.103188$Vf.3970489@news000.worldonline.dk>, "Peter Koch
> Larsen" <pklspam@mailme.dk> writes:
> 
>> It's kind of like driving. You can get into a lot of trouble if you do
>> not follow the traffic laws (you just have to obey the physicla ones ;-),
>> but so long as you do driving is a fairly safe practice.
> 
> Although I attempt to drive safely, I also rely on seat belts and air
> bags.

It has often been commented that a sharp spike protruding from the centre 
of the steering wheel will elicit more safe driving than seatbelts or 
airbags. Getting used to having a safety net will tend to lead to the less 
cautious approach.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************
0
peb (807)
3/6/2005 11:44:41 AM
"Paul E. Bennett" <peb@amleth.demon.co.uk> writes:

[snip]

> 
> Considering that the proposition in this thread has been "Ada protects you 
> from making silly mistakes" I consider that your take is counter to the 
> evidence. I still maintain that language is immaterial to the safety of the 
> system, relying on decent rigourously applied development processes, 
> reviews and testing. Therefore, I tend to look at the development processes 
> and their "real" CMM rating. I guess the Ariane team went down a few 
> notches on that project.

Ah yes, that old "You can make correct programs in any langage"
statement. It is difficult to argue against it, since it is
theoretically correct. A few years ago I worked at a company where the
senior engineer completely refused to use any new tools or language,
since she didn't understand their use. She clinged to the old
low-level language with the argument that getting the software right
was just a question if code inspections and testing. And of course she
was right, but the cost of getting the code correct was so enormous
that the company closed the development office in
question. Fortunately I left the company before the blodshed.

Regards,
- Mark Lorenzen
0
3/6/2005 12:35:39 PM
Ioannis Vranos <ivr@remove.this.grad.com> writes:

[snip]

> Certainly after the thread discussion, ADA has ascended a lot in my
> interest scale (I always try to be reasonable).

I will give you some street respect for this and also for the fact
that the thread is actually informative and hasn't evolved into a
flamewar.

Regards,
- Mark Lorenzen
0
3/6/2005 12:45:46 PM
"Paul E. Bennett" <peb@amleth.demon.co.uk> writes:
 
> It has often been commented that a sharp spike protruding from the centre 
> of the steering wheel will elicit more safe driving than seatbelts or 
> airbags. 

Perhaps people would drive less hazardous, but there would still be
more deaths.

-- 
Leif Roar Moldskred
0
usenet98 (104)
3/6/2005 12:54:54 PM
Ed Falis writes:
> Ludovic Brenta writes:
>> That's what an unhandled exception results in.  In avionics, where
>> we have no operating system and no run-time system, exceptions
>> cannot propagate and thus always result in program termination.
>> When testing the program, we prove that no exception is ever
>> raised.
>
>
> There are certainly other strategies available.  For instance, in an
> "integrated modular avionics" architecture, an unhandled Ada
> exception in a single partition could be forwarded to a global
> health monitoring facility that may restart that partition, a set of
> partitions, or the whole system - or do something else for error
> recovery.  This implies that exception propagation is a quite
> flexible capability, and can be embedded in a system with even
> greater error handling flexibility in a comfortable way.

The software I'm currently working on is the "boot", or "BIOS" of our
hardware.  It allows us to upload an operating system onto the target
board.  The OS is then responsible for the partitioning that you
describe.  So, inside the "boot" software, we have absolutely nothing
we can use to propagate exceptions.  Every exception results in some
processor registers being set and a "jump" instruction to a fixed
address.  We can use the processor registers to easily find the point
where the exception was raised, but we cannot handle it.

In another project I worked on, there was only one partition, and
every exception would result in the watchdog restarting the software.

The mechanism you describe is indeed one possible solution for
software that runs on top of an operating system.

-- 
Ludovic Brenta.
0
3/6/2005 1:11:48 PM
In article <GZzWd.103220$Vf.3971363@news000.worldonline.dk>, "Peter Koch Larsen" <pklspam@mailme.dk> writes:
> 
> "Larry Kilgallen" <Kilgallen@SpamCop.net> skrev i en meddelelse 
> news:CU1wh2sMbcmG@eisner.encompasserve.org...
>> In article <FsqWd.103188$Vf.3970489@news000.worldonline.dk>, "Peter Koch 
>> Larsen" <pklspam@mailme.dk> writes:
>>
>>> It's kind of like driving. You can get into a lot of trouble if you do 
>>> not
>>> follow the traffic laws (you just have to obey the physicla ones ;-), but 
>>> so
>>> long as you do driving is a fairly safe practice.
>>
>> Although I attempt to drive safely, I also rely on seat belts and air 
>> bags.
> 
> I hope we all do. What i meant to say was that using a seat belt isn't an 
> excuse to drive on the wrong side of the road.

No, but despite always intending to drive on the proper side of the road,
I still wear a seat belt.  There might be an unintended incident, such as
a bee stinging me, in which case I want to be as safe as possible.
0
Kilgallen (2738)
3/6/2005 1:16:02 PM
"Paul E. Bennett" writes:
> Martin Krischik wrote:
>
>> <veröffentlicht & per Mail versendet>
>> 
>> Paul E. Bennett wrote:
>> 
>>> Ludovic Brenta wrote:
>>> 
>>>> * when the compiler cannot check some code statically, it inserts
>>>>   run-time checks which are guaranteed to catch all errors by raising
>>>>   exceptions.  In C++ you must code these checks by hand, and of
>>>>   course at some point you'll forget one crucial check which will cost
>>>>   you days in debugging.
>>> 
>>> I think the fallacy of that statement has been proven already (in a very
>>> expensive way).
>> 
>> You mean the case where some managers decided to use some software written
>> for one pice of hardware on another - incompatible - pice of hardware -
>> without retesting?
>> 
>> In my book that was a management bug - If the managers had ordered to run
>> the testsuite only once the problem would have shown. The hardware was so
>> incompatible it would have failed all the time.
>> 
>> Last not least: Runtime check where disabled for that incident. So if
>> anything: this incident speak in favor of runtime checks.
>> 
>> Read up your facts: http://en.wikipedia.org/wiki/Ariane_5_Flight_501
>  
> Yes, I have read that and the full report. However, I think my comment 
> still stands. You stated "when the compiler cannot check some code 
> statically, it inserts run-time checks which are guaranteed to catch all 
> errors by raising exceptions".

Martin didn't state that, I did.

> The code had to be compiled, for the new hardware, to be installed
> in the guidance system and hence should have had the run-time checks
> in place if static checking could not be done. You have admitted in
> your response that these checks were not active (by management
> decision) so the Ada compiler was circumvented and prohibited from
> adding these checks.

This is correct, and boils down to the fact that pointy-haired
managers can override even an Ada compiler.  Are you susprised?

But try that with a C++ compiler, and C++ programmers who have never
heard of automatic run-time checks.  Who would you blame?

> Considering that the proposition in this thread has been "Ada
> protects you from making silly mistakes" I consider that your take
> is counter to the evidence. I still maintain that language is
> immaterial to the safety of the system, relying on decent
> rigourously applied development processes, reviews and
> testing. Therefore, I tend to look at the development processes and
> their "real" CMM rating. I guess the Ariane team went down a few
> notches on that project.

Ada, *by default*, protects you against silly mistakes.  You or your
pointy-haired manager can override the protection.

C++, *by default*, does not protect you.  Nobody can add protection.

-- 
Ludovic Brenta.
0
3/6/2005 1:26:53 PM
"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:d0dkt2$781$2@titan.btinternet.com...

> I think Modula-3 was the prime inspiration but never having used it I
> could be wrong! :-)

One of the most fascinating computing documents ever written was the
"Rationale for the Design of the ADA programming Language" SIGPLAN Notices
6/79 (and yes, ADA was capitalized in that particular title, although if I
recall, in a later edition is was not.)

It is quite unusual to see such a complete treatment of what people were
thinking when they came up with a language.  Anyway, in the introduction:

"The main source of inspiration for the Green language is the programming
language Pascal and its later derivatives."

However, throughout the document, they reference Algol-60 and Algol-68 much
more frequently than Pascal.  That may make sense as Algol was seen as the
inspiration for Pascal, so many of Pascal's features appeared there first.
They also frequently make comparisons to Simula.  In a quick scan, I didn't
see any reference to Modula, let alone Modula-3 which came a lot later -
1992 maybe?.  Interestingly enough, Modula-2 also seems to have surfaced in
1979, and talks about safety-critical systems.  (I get the impression there
never was a just plain Modula).

If you can get hold of a copy of the Rationale, it is a very intresting
read.

...


0
3/6/2005 3:22:28 PM
In comp.realtime xpyttl <xpyttl_NOSPAM@earthling.net> wrote:
> 1979, and talks about safety-critical systems.  (I get the impression there
> never was a just plain Modula).

There was, we used an elderly Modula compiler for real-time courses in 
the late 80s. It was essentially Pascal with separate compilation, a
process abstraction (though I can't remember whether this was in the
language or achieved entirely through libraries), and proper abstract
data types. Modula-2 moved somewhat further from the Pascal roots (I
think mainly to make it a systems-programming language for the Lilith
workstation) then the paths forked. Modula-3 became a much bigger language;
Wirth got small with Oberon, which was a very compelling language (and
environment) that never really achieved critical mass.

pete
-- 
pete@fenelon.com "Send lawyers, guns and money...."
0
pete6 (288)
3/6/2005 3:38:23 PM
Ioannis Vranos <ivr@remove.this.grad.com> wrote in
news:1110099035.843154@athnrd02: 

> The one remaining, does it support namespaces? :-) What subset of the 
> procedural paradigm it does not support?
> 

Ada support the concept of namespaces, but there is no reserved word
"namespace". Ada uses packages to provide encapsulation and namespace.
Packages have been part of the Ada language since its earliest version.

Packages normally appear in two parts. The package specification defines
the interface to the package. The package body contains the 
implementation
of all subprograms, tasks, and protected objects declared in the
specification.

Here is a specification for a generic (aka template) package:

generic
   type Target_Type is private;
   Target_Size : Natural;
package Bit_Utils is
   procedure Show_Bits(Item : Target_Type);
end Bit_Utils;
   

We know this is a generic package because of the reserved word 
"generic". The two lines following "generic" define the
generic formal parameters for this package. In this case the
first parameter is a type and the second parameter is an
integer with a minimum value of 0. The package provides an
interface to a single procedure (similar to a function 
returning void in C++) named Show_Bits that takes a 
single parameter of the same type as the generic formal
type.

The body of this package is:

with Ada.Text_Io;
with Ada.Integer_Text_Io;
with System;
package body Bit_Utils is
   type Bits_Array is array(Positive range <>) of Boolean;
   pragma Pack(Bits_Array);

   type Byte is mod 2**8;
   type Byte_Array is array(Positive range <>) of Byte;
   package Mod_Io is new Ada.Text_IO.Modular_IO(Byte);
   
   procedure Show_Bits(Item : Target_Type) is
      Bit_View : Bits_Array(1..Target_Size);
      for Bit_View'Address use Item'Address;
      Byte_View : Byte_Array(1..Target_Size / Byte'Size);
      For Byte_View'Address use Item'Address;
   begin
      for I in Byte_View'range loop
         Mod_Io.Put(Item => Byte_View(I), Width => 4);
      end loop;
      Ada.Text_IO.New_Line(2);
      for I in Bit_View'range loop
         Ada.Integer_Text_Io.Put(Item => Boolean'Pos(Bit_View(I)), 
            Width => 1);
         if I mod System.Storage_Unit = 0 then
            Ada.Text_IO.New_Line;
         end if;
      end loop;
   end Show_Bits;
end Bit_Utils;

The first 3 lines begin with the reserved word "with".
Those lines declare a dependency upon the compilation units
following the word "with". In this case all three 
compilation units are pre-defined packages.
We and the compiler know that this is a package body because
of the use of the phrase "package body" on the line 4.
This package body contains the implementation of the procedure
Show_Bits. It also contains three type definitions and the
instantiation of the generic package Ada.Text_IO.Modular_IO for
type Byte. Since none of these types are delcaled in the
package specification, they are invisible to any calling
entity. They are equivalent to C++ private types.

This package was used in a program with the following "main"
procedure:

with Bit_Utils;
with Ada.Text_Io;

procedure Bit_Output is 
   type My_Type is 
      record 
         Name   : String (1 .. 4);  
         Age    : Positive;  
         Weight : Long_Float;  
      end record; 
   package My_Bits is new Bit_Utils(My_Type,
      My_Type'Size);
   package Flt_Bits is new Bit_Utils(Long_Float,
      Long_Float'Size);
   Mt : My_Type    := ("Jim ", 55, 0.45435);  
   D  : Long_Float := 0.45435;  
begin
   Ada.Text_Io.Put_Line("Output of My_Type");
   My_Bits.Show_Bits(Mt);
   Ada.Text_Io.Put_Line("Output of Long_Float");
   Flt_Bits.Show_Bits(D);
end Bit_Output;

The procedure Bit_Output serves the same purpose as does
"main" in C++. Note that Bit_Output is preceeded by two
context clauses. One declares a dependency on the Bit_Utils
package and the other declares a dependency on the
Ada.Text_IO package. Ada does not use a pre-processor.

The package Bit_Utils is instantiated for two different types
inside Bit_Output. Each instantiation is given a unique name,
prividing a unique namespace.

> 
> Also I saw that under severe constraints the run-time safety of the 
> language is better to be switched off.
> 

If the program has been proved to be correct without the safety elements,
and there is a sufficient performance improvement, yes you should turn
off the run-time safety elements. You have control of the elements you
want to turn of through simple pragma statements.

> 
> I do not know much on the language, but can one define general-purpose
> containers with Ada's generics that do range checking and throw an 
> exception when there is an attempt to access outside the boundaries of
> the container, even if the aforementioned run-time safety is switched
> off? 

Yes you can. You can always program in your own checks manually.
The drawback of doing that is that you cannot simply turn them off
with a pragma, nor can the compiler so effectively optimize those
checks out of your program when they are unneeded.

Jim Rogers

0
3/6/2005 4:13:40 PM
>By way of example, someone in this thread posted an example using a
>Day_of_Month type.  It would never occur to a C programmer that the day of
>the month was anything other than an integer.

C was the first language I used to write moderately large programs,
and I was always annoyed by the fact that the compiler could not help
me distinguish integers that represented different things. Maybe that
disqualifies me as a C programmer?


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 8:36:56 PM
>You can do everything in Ada that you can in C and C++. It is more
>work in Ada to "force" things together than in C++. So Ada is not as
>forgiving, when you have a bad design to begin with.

I am not sure I agree fully, but it sounds like a good thing: Ada as
bad-design filter!


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 8:38:06 PM
> You can do everything in Ada that you can in C and C++.

Computationally speaking you can do everything in 'real' serious
language. So for the above statement to have real meaning it needs to
be much moer specific.

> I suppose you mean in the application-programming domain. But I do not
> think this is true in the systems programming domain, that is
> efficiency under *severe* run-time and space constraints.

No problem with Ada.

> Also I am not sure if ADA is suitable for library writing, or you will
> have to switch to another language to do that.

I don't see why you would want to use another language?


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 8:40:31 PM
>Out of curiosiy, could you give some few examples where Ada catches faults 
>not found by a C++ compiler. I assume - of course - code written in modern 
>C++: no casts, functions instead of macroes, a limited use of pointers and 
>so on.

Your 'of course' requires some tool (preferrably automated) that
ensures that only the 'safe' subset of C++ is used. In effect this
creates a new language.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 8:45:08 PM
>My conclusion is that there are some nice ideas out there, but that they 
>mainly protect against the "sloppy" programmer.

You are absolutely right. 

The point that you are probably missing is that *everyone* is a sloppy
programmer every once in a while. The frequency of this sloppiness of
course varies, but it is never zero. So every sloppy mistake caught by
the compiler is a good thing.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 8:49:52 PM
>Once again, I have nothing against learning Ada, however personally I 
>like the most powerful languages. The next thing I am going to learn 
>after C++ (because I haven't learned it all yet), is probably some form 
>of assembly language.

If you want to realy broaden your perspective I would suggest
something in the lazy-functional field like Haskell.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 8:52:40 PM
>> What other mechanism would you suggest?
>
>Termination of the program. Some might argue that they can't tolerate such 
>an event. But can such an environment tolerate a faulty running program?

Imagine a space rocket 1 second after launch. Terminating the control
program means the rocket will probably topple and destroy the launch
site. And exception raised + caught can try to use and alternative
algorithm, or any other means to continue as best as possible.

Note: the first Ariane 5 launch was a failure roughly because the
(Ada!) code was (out of necessity) written without exception handling.
(The real story is a bit longer, and explains that this was *not* a
software failure - it was a mangagement misjudgement).


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 8:57:32 PM
>Ada can teach C++ how to do templates properly. 

I am definitely an Ada fan, but C++ templates are much much more
powerfull. AFAIK C++ is the only language in which you can create a
'unit' based type system that is almost fully compile-time checked.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 9:01:43 PM
>In my book that was a management bug - If the managers had ordered to run
>the testsuite only once the problem would have shown. The hardware was so
>incompatible it would have failed all the time.

I assume you do know that it was not the computer hardware but the
phyiscal paremeters (acceleration) of the rocket itself?

>Last not least: Runtime check where disabled for that incident. So if
>anything: this incident speak in favor of runtime checks.

They were disabled in the Ariane 4 software after it was *proven* that
the exceptions could simply not occur on an Ariane 4. If the runtime
checks were not disabled the software would not fit so the rocket
would not fly. I am not sure that's the preferrable alternative.

If this accident speaks for anything IMHO it speaks for sensible
management. Which is apparently a problem on both sides of the ocean
:(


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 9:09:36 PM
>It's kind of like driving. You can get into a lot of trouble if you do not 
>follow the traffic laws (you just have to obey the physicla ones ;-), but so 
>long as you do driving is a fairly safe practice.

Yet modern cars have many 'assist' features that try to prevent
dangerous behaviour of the driver. I know I have to brake
'oscillating' (forgive my language - feel free to try Dutch), but I am
glad my brake system will do it for me in the split second that I see
that car in front of me standing still.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 9:13:20 PM
>> Although I attempt to drive safely, I also rely on seat belts and air 
>> bags.
>
>I hope we all do. What i meant to say was that using a seat belt isn't an 
>excuse to drive on the wrong side of the road.

It think what you say translates to 'driving on the right side of the
road is a propper excuse for not using the seat belt'?


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 9:14:28 PM
>It has often been commented that a sharp spike protruding from the centre 
>of the steering wheel will elicit more safe driving than seatbelts or 
>airbags. Getting used to having a safety net will tend to lead to the less 
>cautious approach.

Following that line I assume you enter your programs in binary using
toggle switches? That will make you think twice (or a lot more!) times
before entering a mistake.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/6/2005 9:15:58 PM
Wouter van Ooijen (www.voti.nl) wrote:
>>Ada can teach C++ how to do templates properly. 
> 
> 
> I am definitely an Ada fan, but C++ templates are much much more
> powerfull. AFAIK C++ is the only language in which you can create a
> 'unit' based type system that is almost fully compile-time checked.

There is are various ways of doing this in Ada just now but they are not 
zero-cost. A new way nearly made it into the Ada2005 standard, but was 
going to take too long to 'get right' so it was dropped. Might be looked 
at again for the 5-year ISO 'mini' revision. I hope so anyway.

Cheers

-- Martin
0
3/6/2005 9:49:48 PM
Martin Krischik <martin@krischik.com> writes:

> I have a multi-tastking Ada application which runs on OS/2, Windows XP and
> Linux. Can you do that in C++ without the use of "#if". Here is the problem
> of plugged on solution: they are not compatible between operating system
> and compiler vendors.

And the proof to this is to look at the tasking runtime implementation for the
various compiler on different OS. There is a lot of code there to ensure
proper tasking semantic to the Ada runtime.

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
0
pascal27 (183)
3/6/2005 10:24:43 PM
"Wouter van Ooijen (www.voti.nl)" <wouter@voti.nl> skrev i en meddelelse 
news:422b6c80.1141685927@news.xs4all.nl...
> >My conclusion is that there are some nice ideas out there, but that they
>>mainly protect against the "sloppy" programmer.
>
> You are absolutely right.
>
> The point that you are probably missing is that *everyone* is a sloppy
> programmer every once in a while. The frequency of this sloppiness of
> course varies, but it is never zero. So every sloppy mistake caught by
> the compiler is a good thing.
>
>
> Wouter van Ooijen
>
> -- ------------------------------------
> http://www.voti.nl
> Webshop for PICs and other electronics
> http://www.voti.nl/hvu
> Teacher electronics and informatics

Which is why other means are needed for quality software. Rigorous testing 
and code reviews come to mind.

/Peter 


0
pklspam (199)
3/6/2005 11:09:07 PM
Frank J. Lhota wrote:
> "Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message 
> news:1110055473.613245@athnrd02...
> 
>>You can also express constraints in templates. An important thing is this. 
>>Are Ada's generics run-time or compile time?
> 
> Compile time with every Ada compiler I've used.

What do you both of you mean by compile-time?

Any compliant Ada-83 or Ada-95 compiler can have generics
nested inside of subprograms whose parameters vary according
to run-time parameters or computed values from a higher scope.

-- 
Wes Groleau

People would have more leisure time if it weren't
for all the leisure-time activities that use it up.
                        -- Peg Bracken
0
news31 (6772)
3/6/2005 11:16:11 PM
Peter Koch Larsen wrote:
> I hope we all do. What i meant to say was that using a seat belt isn't an 
> excuse to drive on the wrong side of the road.

<sarcasm type="parody>

But who the #$%^& would want to live anywhere
where somebody else tells you what side of the
road you HAVE to drive on?

And only an incompetent driver would buy a car
that was unable to drive on the wrong side of the road!

</sarcasm>

-- 
Wes Groleau
Free Genealogical Lookups:
http://groleau.freeshell.org/ref/lookups.shtml
0
news31 (6772)
3/6/2005 11:19:21 PM
Peter Koch Larsen wrote:
> "Wouter van Ooijen (www.voti.nl)" <wouter@voti.nl> skrev i en
meddelelse
> news:422b6c80.1141685927@news.xs4all.nl...
> > >My conclusion is that there are some nice ideas out there, but
that they
> >>mainly protect against the "sloppy" programmer.
> >
> > You are absolutely right.
> >
> > The point that you are probably missing is that *everyone* is a
sloppy
> > programmer every once in a while. The frequency of this sloppiness
of
> > course varies, but it is never zero. So every sloppy mistake caught
by
> > the compiler is a good thing.
[snip]
>
> Which is why other means are needed for quality software. Rigorous
testing
> and code reviews come to mind.

Ada does not replace rigorous testing or code reviews. It supplements
them. Code reviews are extremely helpful. They also consume a lot of
time for the development team when they are done well. It is best to
remove as many silly errors from the code through automatic analysis
before exposing the code to developers for review.

I have never worked in an organization where code was judged ready for
review if it had not already produced a clean compile, with no warnings
or errors. When doing C code this meant also passing lint with no
errors or warnings.

The Ada compiler effectively combines the error messages common to a
good C compiler with the error and warning messages common to a good
lint tool. When you get a clean compile from an Ada compiler you are
ready to expose your code to others for a code review.

Jim Rogers

0
3/6/2005 11:20:10 PM
Martin Krischik wrote:
> But as I said, not impossible. I have a regex generic which can be
> instanciated for character and wide character strings and basicly any other
> descreed type you want to run regular expressing over.

Is that for sale or open-source or not available?

-- 
Wes Groleau
   ----
   The man who reads nothing at all is better educated
   than the man who reads nothing but newspapers.
                             -- Thomas Jefferson
0
news31 (6772)
3/6/2005 11:26:20 PM
Peter Koch Larsen wrote:

> 
> "Wouter van Ooijen (www.voti.nl)" <wouter@voti.nl> skrev i en meddelelse
> news:422b6c80.1141685927@news.xs4all.nl...
>> >My conclusion is that there are some nice ideas out there, but that they
>>>mainly protect against the "sloppy" programmer.
>>
>> You are absolutely right.
>>
>> The point that you are probably missing is that *everyone* is a sloppy
>> programmer every once in a while. The frequency of this sloppiness of
>> course varies, but it is never zero. So every sloppy mistake caught by
>> the compiler is a good thing.

Even I admit to having my sloppy moments. Fortunately they don't last too 
long and reviews and/or testing catch those moments before they progress 
very far.
 
> Which is why other means are needed for quality software. Rigorous testing
> and code reviews come to mind.

Something that some people here seem not able to accept because they 
believe in the absolute protectiveness of their compiler.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************
0
peb (807)
3/6/2005 11:29:12 PM
jimmaureenrogers@worldnet.att.net wrote:

> Ada does not replace rigorous testing or code reviews. It supplements
> them. Code reviews are extremely helpful. They also consume a lot of
> time for the development team when they are done well. It is best to
> remove as many silly errors from the code through automatic analysis
> before exposing the code to developers for review.

Thanks for that Jim. At least you seem to have been the first (assumed) 
Ada user that has admitted that the compiler is not the final arbiter.
 
> I have never worked in an organization where code was judged ready for
> review if it had not already produced a clean compile, with no warnings
> or errors. When doing C code this meant also passing lint with no
> errors or warnings.
>
> The Ada compiler effectively combines the error messages common to a
> good C compiler with the error and warning messages common to a good
> lint tool. When you get a clean compile from an Ada compiler you are
> ready to expose your code to others for a code review.

At least code which passes such a hurdle is in a more reasonable state than 
code which has not passed this threshold. I would also hope that you are 
not waiting for all the code to pass this hurdle but are compiling, 
reviewing and testing on a fairly continuous basis, submitting the code 
that passes compile, review and unit testing into the stock for integration 
and system testing.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************
0
peb (807)
3/6/2005 11:42:00 PM
In article <d0g3lp$kuc$1$8302bc10@news.demon.co.uk>, "Paul E. Bennett" <peb@amleth.demon.co.uk> writes:
> Peter Koch Larsen wrote:

>> Which is why other means are needed for quality software. Rigorous testing
>> and code reviews come to mind.
> 
> Something that some people here seem not able to accept because they 
> believe in the absolute protectiveness of their compiler.

What evidence do you have for that assumption ?

Certainly the project on which I lobbied hard for formal inspection
was authorized/budgeted was written 50% in Ada.   The Ada half was
brand new code, but each half received formal inspection.
0
Kilgallen (2738)
3/7/2005 1:56:02 AM
In article <d0g4dp$og$1$8300dec7@news.demon.co.uk>, "Paul E. Bennett" <peb@amleth.demon.co.uk> writes:
> jimmaureenrogers@worldnet.att.net wrote:
> 
>> Ada does not replace rigorous testing or code reviews. It supplements
>> them. Code reviews are extremely helpful. They also consume a lot of
>> time for the development team when they are done well. It is best to
>> remove as many silly errors from the code through automatic analysis
>> before exposing the code to developers for review.
> 
> Thanks for that Jim. At least you seem to have been the first (assumed) 
> Ada user that has admitted that the compiler is not the final arbiter.

Assuming is a bad idea.

Typically the Ada compiler is the second arbiter (the first being
the programmer who types something into the editor).  You will find
that Ada programmers don't discuss subsequent steps that much since
they are a given.  The only regard in which they should differ from
C* reviews should be a lower number of trivial bugs remaining (with
more time available for considering serious defects).
0
Kilgallen (2738)
3/7/2005 2:01:10 AM
"Paul E. Bennett" <peb@amleth.demon.co.uk> wrote in
news:d0g4dp$og$1$8300dec7@news.demon.co.uk: 

> jimmaureenrogers@worldnet.att.net wrote:
> 
>> Ada does not replace rigorous testing or code reviews. It supplements
>> them. Code reviews are extremely helpful. They also consume a lot of
>> time for the development team when they are done well. It is best to
>> remove as many silly errors from the code through automatic analysis
>> before exposing the code to developers for review.
> 
> Thanks for that Jim. At least you seem to have been the first
> (assumed) Ada user that has admitted that the compiler is not the
> final arbiter. 

That is a fair assumption. I have been using Ada for over 10 years.

Ada compilers are extremely helpful in finding a lot of errors that
could be very time consuming to find during testing. One of the reasons
Ada compilers can find a lot of problems not found by compilers for
other languages is due to the syntax of Ada itself. The syntax,
when Ada is used as the language is intended to be used, provides
a very rich source of information about how you want to use various
types and objects.

For instance, in C++ you can create a bounded integer class. The 
compiler has no understanding of what you are trying to achieve.
You are responsible for writing all the range and validity 
checking routines.

Ada provides syntax understood by the compiler, for the 
definition of bounded integers. The compiler writes all the range
and validity checks for you. It also recognizes that two different
types are different. They are not to be mixed unless you explicitly
direct that mixing. This need to be explicit also makes code reviews
much easier. Any reviewer can clearly identify when you are mixing
types in a way that violates your own design.

Jim Rogers

0
3/7/2005 2:04:20 AM
On Sun, 06 Mar 2005 23:29:12 +0000, Paul E. Bennett  
<peb@amleth.demon.co.uk> wrote:

>> Which is why other means are needed for quality software. Rigorous  
>> testing
>> and code reviews come to mind.
> Something that some people here seem not able to accept because they
> believe in the absolute protectiveness of their compiler.
> --


That's just plain silly - or biased.  I would guess that an overwhelming  
number of Ada advocates also advocate testing, code reviews etc (eg I  
wrote AUnit).  The compiler is not a replacement for these processes, but  
a better compiler is certainly an aid in the effort.

- Ed
0
falis (298)
3/7/2005 4:06:31 AM
On Sun, 06 Mar 2005 23:42:00 +0000, Paul E. Bennett  
<peb@amleth.demon.co.uk> wrote:

> At least code which passes such a hurdle is in a more reasonable state  
> than
> code which has not passed this threshold. I would also hope that you are
> not waiting for all the code to pass this hurdle but are compiling,
> reviewing and testing on a fairly continuous basis, submitting the code
> that passes compile, review and unit testing into the stock for  
> integration
> and system testing.

My company has a regression suite of over 8000 tests that is run every  
night on our software on a dozen-plus host/target combinations.  And the  
software is 90% or better Ada.  Language is only part of the game of  
quality, but one that can have many good or bad effects.

- Ed
0
falis (298)
3/7/2005 4:10:55 AM
>>Also I am not sure if ADA is suitable for library writing, or you will
>>have to switch to another language to do that.

Neither the "American Dental Association" or the "American Disabilities 
Act" are really suitable computer computer languages for writing 
libraries or anything else for that matter. :-)

Ada, on the other hand is very suited to that task.  Ada is a name not 
an Acronym.  Ada is named for Ada Augusta Lady Lovelace.  She was the 
daughter of the poet Lord Byron and also was the worlds first computer 
programmer.  She wrote several sample programs intended for Charles 
Babbage's never built Analytical Engine.

-- 
mark@biggar.org
mark.a.biggar@comcast.net
0
mark8231 (28)
3/7/2005 6:14:56 AM
Paul E. Bennett wrote:
> jimmaureenrogers@worldnet.att.net wrote:
> 
> 
>>Ada does not replace rigorous testing or code reviews. It supplements
>>them. Code reviews are extremely helpful. They also consume a lot of
>>time for the development team when they are done well. It is best to
>>remove as many silly errors from the code through automatic analysis
>>before exposing the code to developers for review.
> 
> 
> Thanks for that Jim. At least you seem to have been the first (assumed) 
> Ada user that has admitted that the compiler is not the final arbiter.

I don't know and serious Ada user how _would_ think that!

We also use tools such as PolySpace (www.polyspace.com) and SPARK 
(http://www.praxis-his.com/) at our place.

Cheers

-- Martin
0
3/7/2005 7:00:05 AM
>Which is why other means are needed for quality software. Rigorous testing 
>and code reviews come to mind.

IMHO one word is missing: Which is why other means are *also* needed
for quality software. Rigorous testing and code reviews come to mind.

Needed (not exhaustive):
- a good definition (requirements etc)
- education
- reviews, brainstorms and other inter-person interactions
- sensible management
- sensible coding standards, *with a sensible escape mechanism*
- good checking tools (Compiler, even for Ada a subset verificator is
often used)
- automtated (regression) test tools
- test coverage check (somtimes even full path coverage check)
- unit tests, integration tests, system tests etc.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/7/2005 7:04:40 AM
>> Which is why other means are needed for quality software. Rigorous testing
>> and code reviews come to mind.
>
>Something that some people here seem not able to accept because they 
>believe in the absolute protectiveness of their compiler.

I think you don't want to hear that even Ada enthousiasts complement
the checking of the Ada compiler with much more (as most of them/us
repeatedly stated).


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
0
wouter3791 (49)
3/7/2005 7:06:00 AM
Wouter van Ooijen (www.voti.nl wrote:

>>In my book that was a management bug - If the managers had ordered to run
>>the testsuite only once the problem would have shown. The hardware was so
>>incompatible it would have failed all the time.
> 
> I assume you do know that it was not the computer hardware but the
> phyiscal paremeters (acceleration) of the rocket itself?
> 
>>Last not least: Runtime check where disabled for that incident. So if
>>anything: this incident speak in favor of runtime checks.

Yes, I do. I was just simplifying the hole rocket as "hardware".

> If this accident speaks for anything IMHO it speaks for sensible
> management. Which is apparently a problem on both sides of the ocean
> :(

Yes indeed.

With Regards

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

0
martin131 (308)
3/7/2005 9:58:09 AM
<ver�ffentlicht & per Mail versendet>

Paul E. Bennett wrote:

> reviews and testing. Therefore, I tend to look at the development
> processes and their "real" CMM rating. I guess the Ariane team went down a
> few notches on that project.

Only it was a contractors team and they where not there anymore to be asked
if the Ariane 4 software could be run on the Ariane 5.

That was one of the reaons why the testsuite was not run: The did not have
the personal to do it the they would have to hire and teach new contractors
to do it.

My point stands: management bug.

Martin

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

0
martin131 (308)
3/7/2005 10:03:46 AM
Wes Groleau wrote:

> Martin Krischik wrote:
>> But as I said, not impossible. I have a regex generic which can be
>> instanciated for character and wide character strings and basicly any
>> other descreed type you want to run regular expressing over.
> 
> Is that for sale or open-source or not available?

It's part of AdaCL: http://adacl.sourceforge.net

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

0
martin131 (308)
3/7/2005 10:06:18 AM
I would say, read

http://home.t-online.de/home/Christ-Usch.Grein/Ada/Dimension.html

> http://home.t-online.de/home/Christ-Usch.Grein/Ada/Universe.html


0
3/7/2005 11:03:07 AM
Pascal Obry wrote:

> "EventHelix.com" <eventhelix@gmail.com> writes:
> 
>> - It will be hard to find developers for Ada
> 
> This is generally not true. It is true that there is less Ada
> developers than C++ but there is enough for the demand. I have never
> had problems finding Ada developers for my projects.

In fact, it is much harder to actually find an Ada _job_.


Vinzent.
0
3/7/2005 11:45:22 AM
>
>
>> I am definitely an Ada fan, but C++ templates are much much more
>> powerfull. AFAIK C++ is the only language in which you can create a
>> 'unit' based type system that is almost fully compile-time checked.
>
>
> There is are various ways of doing this in Ada just now but they are 
> not zero-cost. A new way nearly made it into the Ada2005 standard, but 
> was going to take too long to 'get right' so it was dropped. Might be 
> looked at again for the 5-year ISO 'mini' revision. I hope so anyway. 


Which AI? I do hope you don't mean the Ada.Units Ada Issue (don't 
remember the number). This was a terrible proposal doomed to fail 
(albeit a clever one wrt. to Ada features used).

0
3/7/2005 2:30:25 PM
Vinzent 'Gadget' Hoefler <nntp-2005-03@t-domaingrabbing.de> writes:

> In fact, it is much harder to actually find an Ada _job_.

Indeed. And we need to get past the CV. Some developers do not write down Ada
as they think it is a dead language ! I've meet some, and when I told them
that I'm using Ada on some projects they are quite interested :)

Ada *is* alive!

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
0
pascal27 (183)
3/7/2005 7:01:19 PM
Christoph Grein wrote:
> Which AI? I do hope you don't mean the Ada.Units Ada Issue (don't 
> remember the number). This was a terrible proposal doomed to fail 
> (albeit a clever one wrt. to Ada features used).

Yes - although the last I heard Tucker was going to propose some method 
that used pragmas.

Cheers

-- Martin

0
3/7/2005 7:03:15 PM
"Paul E. Bennett" <peb@amleth.demon.co.uk> writes:

> Something that some people here seem not able to accept because they
> believe in the absolute protectiveness of their compiler.

Just cos it compiles doesn't mean it'll pass the unit tests.

Just cos it passes the unit tests doesn't mean it's right!

-- 
Simon Wright                               100% Ada, no bugs.
0
simon8285 (1465)
3/7/2005 8:10:20 PM
"Paul E. Bennett" writes:
>> Which is why other means are needed for quality software. Rigorous
>> testing and code reviews come to mind.
>
> Something that some people here seem not able to accept because they
> believe in the absolute protectiveness of their compiler.

I think I've already mentioned that, during *testing*, we prove that
no exception is ever raised in our software.  I just wanted to make it
clear that I consider testing to be an obvious and integral part of
development.  No compiler can be an excuse not to test.  That said,
Ada still helps us catch many silly mistakes even *before* testing.

And secondly, Ada is very legible.  Do you remember my blurb about
aliasing?  This is the kind of thing that *really* helps during code
review and inspection, and during maintenance.  The other things that
help a lot in this area are the fact that everything is explicit,
rather than implicit, and the ability we have to express *what* we are
doing in high-level, almost plain English terms.  The type system in
particular helps us speak in terms of the problem at hand rather than
in terms of computer-specific objects.  We effectively replace the
computer jargon with avionics jargon.  This is called a "high-level
language".

-- 
Ludovic Brenta.
0
3/7/2005 11:33:27 PM
Martin Krischik writes:
> <veröffentlicht & per Mail versendet>
>
> Paul E. Bennett wrote:
>
>> reviews and testing. Therefore, I tend to look at the development
>> processes and their "real" CMM rating. I guess the Ariane team went down a
>> few notches on that project.
>
> Only it was a contractors team and they where not there anymore to be asked
> if the Ariane 4 software could be run on the Ariane 5.
>
> That was one of the reaons why the testsuite was not run: The did not have
> the personal to do it the they would have to hire and teach new contractors
> to do it.
>
> My point stands: management bug.
>
> Martin

I thought it was because the telemetry data required to simulate a
launch was classified, and managers decided that the contractors
"didn't need to know" this data.  If it weren't for this secrecy, the
contractors would have found the bug on the first simulated run of the
software.

-- 
Ludovic Brenta.
0
3/7/2005 11:35:11 PM
"Peter Koch Larsen" <pklspam@mailme.dk> wrote in
message
news:y8lWd.103136$Vf.3969714@news000.worldonline.dk...

After reading some ideas about Ada,

> My conclusion is that there are some nice ideas
out there, but that they
> mainly protect against the "sloppy" programmer.
>
Actually, the inherent type safety, along with the
visibility rules in Ada
do a bit more than "protect against the 'sloppy'
programmer."   I wonder
there is real protection against a truly sloppy
programmer, in Ada or
elsewhere.

Then again, perhaps we are all a little sloppy now
and then.  I know I sometimes
make stupid mistakes while coding that the Ada
compiler brings to my attention.

The larger issue is how Ada scales up to
programming in the large for safety-critical
software.  Few other languages do scale up as well
as Ada.   For a small, one-person
job, I'm not sure it matters so much what
programming language you choose.  However,
when you are building a large team of programmers
and need high level of confirmability
wrt the inter-relationship of the varioius
modules, Ada serves much better than most
alternatives.

A key idea in Ada, one that I like much better
than in other languages (although this
aspect of Modula-3 is pretty good), is the model
for separate compilation.   Space
in this posting does not allow one to do full
credit to this capability, but it is one of
those features of the language that, when used as
it is supposed be used, makes the
team development process so much easier.

For real-time embedded systems, Ada allows easy
navigation from one level of abstraction
to another, and allows that navigation to be safe.
We can, and usually do, design our
programs at a high level of abstraction.
However, when it is required to descend to the
machine level, we can do, but with greater safety
(built-in rules) than one might do with
some other language.

Anyone who has ever made an mistake in pointer
arithmetic knows how entertaining
it is to spend long hours searching for the source
of some run-time fault.   Never made
that kind of mistake?   You only need to make it
once for it to be memorable.

Some find Ada to be a little difficult to learn at
first.  In particular, the rules that govern
something called "visibility" give new programmers
a bit of trouble.  For those programmers
who insist on fighting this feature, there is no
end of trouble.  I like to use the analogy of
the rotating-brush floor buffer.  When you flip
the switch on that buffer, you need to know
just how to control it or it will run away with
you.   Once you let the buffer have its way, you
can make subtle little movements to make it go
where you want it to go instead of dragging
you all over the floor.

The more persnickety features of Ada are a lot
like the floor buffer.   Once you learn how to
control them, use them to your advantage, and
understand their purpose, the language becomes
easy and fun to use.   The problem is that most
programmers fight those features and complain
because they refuse to abide by them.  Those who
do learn the visibility rules tend to build
excellent, dependable, and maintainable software,
and with much less sweat, tears, and blood
than the corresponding programmer in language X.
Or is the wrong end of the third-from-the-end
letter of the alphabet?

Richard Riehle



0
adaworks2 (748)
3/8/2005 4:50:22 AM
"Ioannis Vranos" <ivr@remove.this.grad.com> wrote
in message news:1110059861.560004@athnrd02...
> Once again, I have nothing against learning Ada,
however personally I
> like the most powerful languages. The next thing
I am going to learn
> after C++ (because I haven't learned it all
yet), is probably some form
> of assembly language.
>
Ada is every bit as powerful as C++.  Just a bit
safer.
>
> For example I like that I can do:
>
[snipped a bunch of code]

Everything you just coded in C++ is easily done,
but with slightly
different, and definitely safer, syntax.  We can
get to the bit level,
the byte level, or the word level for data.   In
at least one embedded
system, deployed on a bare-board using an Ada
run-time, that I
know quite well, we inserted actual machine code,
including some
code to disable interrupts temporarily.

Speaking of powerful languages, consider the power
of Ada to allow
you to build concurrent programs directly within
the language.  There
is no need to make separate Posix/Unix calls.
Moreover, Ada has,
at present, the most robust model for controlling
mutual exclusion
found in any non-experimental language.   If is
really power you need,
especially programming power, Ada will stand
against any competitor.

Richard Riehle


0
adaworks2 (748)
3/8/2005 4:59:56 AM
"Wouter van Ooijen (www.voti.nl)" <wouter@voti.nl>
wrote in message
news:422b6d49.1141887367@news.xs4all.nl...
>
> If you want to realy broaden your perspective I
would suggest
> something in the lazy-functional field like
Haskell.
>
Haskell has a lot to recommend it.  In fact, it is
sad that more programmers
are not schooled in the value of functional
languages.

However, we must select the right tool for the
right job.   There are problems
where Haskell would be preferred to Ada.
Large-scale, safety-critical software
systems developed by a team of programmers is not
the domain where I would
choose Haskell, or ML, or Scheme, or Lisp, or most
other functional  languages.

Where Ada is the right choice, nearly all the
time, is for large-scale software systems
that involve an equally large number of
developers, and where the software modules
developed by that team must snap together just
right -- no guesswork.   This is Ada's
strength. Few languages can compete in this
domain, although many programmers
do try to use less disciplined languages with some
modest success.   Eiffel might be
a good alternative, but my preference for that
kind of software is still Ada.

Consider a military commmand and control system, a
complex system with a lot
of requirementss built in.   Now, think of this
system in terms of its size: 4.5 million
lines of source code.   This is the kind of
project that is perfect for Ada.   In fact,
any software system over a half-million lines of
source code should be coded in
Ada.  Some authors have set that threshold at 100
KSLOC.

If you have a small, 20 KSLOC software system, go
ahead and use a different
language.   Just keep in mind that as that
software grows over time, you might
find yourself wishing you had chosen Ada in the
first place.

Richard Riehle


0
adaworks2 (748)
3/8/2005 5:12:04 AM
Ludovic Brenta wrote:

[ ... ]

> Yes, assembly is the most powerful and flexible language.  That's why
> all compilers emit assembler.

Not so -- machine language is clearly more flexible than asembly
language (especially on machines where an operation can be encoded in
more than one way). Not all compilers emit assemly language output
either. "Powerful" is meaningless WRT a langauge unless you define what
you mean by it in considerably more detail than I've seen thus far in
this thread (or any other, for that matter).

As an aside: an "assembler" is a program that takes input in "assembly
language" and produces an object file as output. Calling the language
"assembler" is roughly equivalent to referring to Ada as "compiler" --
wrong, and to anybody who isn't entirely clueless about the subject at
hand, downright stupid. I realize that for years IBM (among others)
abused the (English) language by referring to the language as
"assembler", but please avoid their mistake.

[ ... ]

> Here, Ada makes it explicit that unsafe programming is taking place.
> First, Obj must be declared as "aliased", which means that two or
> more paths can access it.  In our case, Obj and Obj_As_String are
> the two paths.  This is another of Ada's nice safety-related
> features.  Since aliasing must be made explicit, the reader of the
> program knows up front whether or not aliasing takes place.  The
> reader of a C++ program has no such knowledge.

Nonsense -- in C++ you use a reinterpret_cast, which is equally
explicit about what's being done. If somebody reading C++ doesn't
recognize what a reinterpret_cast means, then he simply doesn't know
C++.

> Also, the writer of the program must
> think twice, and understand the consequences if they make an object
> aliased.

Anybody who uses a reinterpet_cast without a second (and third) thought
simply isn't a programmer, and of he wrote Ada instead, it'd still be
garbage.

> Secondly, the representation clause for Obj_As_String ("for
> Obj_As_String'Address use ...") says exactly what is happening.

Anybody who thinks that (for example):

unsigned char *a = reinterpret_cast<char *>(&x);

doesn't state exactly what it happening, simply doesn't know C++.

Any language (programming or otherwise) is foreign to those who don't
know that language. It may well be that you don't realize what it
means, and that's perfectly fine -- but assuming it must be inexact
because you don't know exactly what it means is considerably less fine.

> I could make the code less verbose by using use clauses, similar to
> "using namespace std" which you seem fond of.  In avionics, our
> coding standards forbid that because we want everything to be
> explicit.

A poor idea. Just for example, consider writing a generic sorting
function. It needs to swap items that it's sorting. In well-written
C++, this will often be done with a using clause. Specifically, if the
type of items has provided its own specialized version of swap, then my
sorting functino should use that, but otherwise it should use std::swap
to swap them.

If I try to specify whatever_type::swap(x,y), then compilation will
fail if the type has not provided a swap function. Conversely, if I
specify std::swap(x,y), then the specialized swap function won't be
used for those types that provide one.

The solution is something like:

using namespace std;

template<class T>
void sort // ...

// ...
    swap(x,y);

and now, thanks to Koenig lookup, this will refer to a swap
specifically for the type of x and y if there is one, but will use the
swap in the standard library for those (many) types that don't provide
special swapping code.

[ ... ]

> > Someone who places much hopes on the language to protect him from
> > his mistakes, probably ADA is better than C++ on this.
>
> Hear, hear!

Actually, having used both (as well as Verilog and VHDL, which are
based fairly close on C and Ada respectively) I'm not particularly
convinced this is true.

Personally, I think the _vast_ majority of the safety of Ada is an
illusion. In the end, code that works well is a product of a good
programming doing his job well, NOT of a particular language.

Now, it's certainly true that people can (and frequently do) cite
statistics showing that code written in Ada has fewer bugs, etc., as
proving that the language is safer. Even assuming the citations are
correct (which I'm not sure is true, but for the moment, let's assume
they are), they don't necessarily prove that -- or much of anything
else, for that matter.

The problem is that the reputation of a language tends to become a
self-fulfilling prophecy. Managers who are running safety critical
projects often choose Ada because they "know" it's safer -- and then
run their projects in ways that would assure solid results, regardless
of implementation language.

Likewise, programmers who are strongly attracted toward disciplined
software engineering, will often be attracted to Ada because it has
that reputation (and to an extent, that "feeling" as well).

At the opposite extreme, the managers who are most interested in
pushing a product out the door in minimal time and don't mind bugs,
rarely choose Ada -- and run their projects in ways that would produce
buggy products regardless of language. Likewise, the "cowboy"
programmers never learn Ada at all -- as soon as they learn of its
reputation, they avoid it like the plague.

As such, showing causation (rather than mere correlation) becomes
essentially impossible at best -- and here in the real world, the truth
could even be exactly the opposite of what the statistics "prove."

Then again, all of the above should probably be taken with a large
grain of salt. That wouldn't necessary if what I'd been consuming for
the last couple of hours was salt, but thanks to Warren Winiarski, that
wasn't the case... :-)

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/8/2005 6:53:36 AM
adaworks@sbcglobal.net wrote:

[ ... ]

> However, we must select the right tool for the
> right job.   There are problems
> where Haskell would be preferred to Ada.
> Large-scale, safety-critical software
> systems developed by a team of programmers is not
> the domain where I would
> choose Haskell, or ML, or Scheme, or Lisp, or most
> other functional  languages.

Here, at least you're being real: you admit that this is what you would
choose.

[ ... ]

> In fact,
> any software system over a half-million lines of
> source code should be coded in
> Ada.
Here, however, you lose your grip on reality. This is NOT "in fact" --
it's purely an OPINION! It's certainly possible to find projects that
would involve more than a half-million lines of code for which Ada
would be _extremely_ poorly suited, at best.

> Some authors have set that threshold at 100 KSLOC.

Other authors have set Pi to 3 (exactly).

Clearly "some authors" can be quoted as saying just about anything you
want, no matter how stupid it might be.

> If you have a small, 20 KSLOC software system, go
> ahead and use a different
> language.   Just keep in mind that as that
> software grows over time, you might
> find yourself wishing you had chosen Ada in the
> first place.

This is true -- but remains at least equally so if you  exchange "Ada"
and "some other language"!

--
   Later,
   Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/8/2005 8:02:04 AM
Jerry Coffin wrote:

> Anybody who thinks that (for example):
> 
> unsigned char *a = reinterpret_cast<char *>(&x);

unsigned char *a = reinterpret_cast<unsigned char *>(&x);


I agree with most of the rest BTW. :-)


Also since Ada is more ancient than C++ in terms of a final standard, we 
can expect that some things are "more ancient", but it is still an 
interesting language since it can do low level stuff.


I am not sure it is "safer" than C++ too, I am suspicious of "safe" 
languages.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/8/2005 9:20:54 AM
On 8 Mar 2005, at 06:53, Jerry Coffin 'taught' us that the language is 
"assembly", not "assembler."

This is fad. Of the 1990's I think. "Assembler" is correct. By use. To 
this day. Personally I find the fad irritating. "Assembly" tried to fix 
terminology that does not need fixing. To avoid colision us stupid 
folks just call the compiler "translator".

0
amado.alves (488)
3/8/2005 11:21:59 AM
On Mon, 07 Mar 2005 22:53:36 -0800, Jerry Coffin wrote:

> Ludovic Brenta wrote:

>> Here, Ada makes it explicit that unsafe programming is taking place.
>> First, Obj must be declared as "aliased", which means that two or
>> more paths can access it.  In our case, Obj and Obj_As_String are
>> the two paths.  This is another of Ada's nice safety-related
>> features.  Since aliasing must be made explicit, the reader of the
>> program knows up front whether or not aliasing takes place.  The
>> reader of a C++ program has no such knowledge.
> 
> Nonsense -- in C++ you use a reinterpret_cast, which is equally
> explicit about what's being done. If somebody reading C++ doesn't
> recognize what a reinterpret_cast means, then he simply doesn't know
> C++.
> 
>> Also, the writer of the program must
>> think twice, and understand the consequences if they make an object
>> aliased.
> 
> Anybody who uses a reinterpet_cast without a second (and third) thought
> simply isn't a programmer, and of he wrote Ada instead, it'd still be
> garbage.

Isn't there some confusion here?

Surely the "aliasing" issue (ignored by C++ completely(?)) is largely
independent if the "reinterpret_cast"/"Unchecked_Conversion" issue?

The C++ programmer uses aliasing routinely and without thinking.
Ada makes the aliasing possibility explicit when necessary, but
prohibits it otherwise.

If we're talking about the "reinterpret_cast" issue, it is essentially
identical in Ada.
-- 
Adrian

0
amtw (199)
3/8/2005 11:47:47 AM
> support efficient, real-time safe environments

Can you explain the "real-time" part?

Reading this thread, it seems to me Ada's focus is on safety rather
than efficiency.
These safety constraints also tend to limit expressiveness. Not that
safety is bad, just that it's not free.

>C++ was designed to produce an object-orientated
>extension to C.

An all too common misconception.
Even if it was, it is used today in ways the designers could never have
foreseen or thought possible.

0
3/8/2005 12:14:30 PM
On Tue, 08 Mar 2005 04:14:30 -0800, Hans Malherbe wrote:

>>C++ was designed to produce an object-orientated
>>extension to C.
> 
> An all too common misconception.

enlighten us please!
-- 
Adrian

0
amtw (199)
3/8/2005 12:59:55 PM
Jerry Coffin wrote:
> A poor idea. Just for example, consider writing a generic sorting
> function. It needs to swap items that it's sorting. In well-written
> C++, this will often be done with a using clause. Specifically, if the
> type of items has provided its own specialized version of swap, then my=

> sorting functino should use that, but otherwise it should use std::swap=

> to swap them.
>=20
> If I try to specify whatever_type::swap(x,y), then compilation will
> fail if the type has not provided a swap function. Conversely, if I
> specify std::swap(x,y), then the specialized swap function won't be
> used for those types that provide one.
>=20
> The solution is something like:
>=20
> using namespace std;
>=20
> template<class T>
> void sort // ...
>=20
> // ...
>     swap(x,y);
>=20
> and now, thanks to Koenig lookup, this will refer to a swap
> specifically for the type of x and y if there is one, but will use the
> swap in the standard library for those (many) types that don't provide
> special swapping code.

I would put the "using namespace std;", or even better, just
"using std::swap;" into the "sort" function, at the scope of the
block from where the "swap" is called. This way, the precise purpose
of the "using" declaration becomes clear to both the human reader
and the compiler (because unwanted side effects due to name
collisions are avoided).
Furthermore, the implementer of "whatever_type" should consider to
put the specialisation of "swap" into the "std" namespace, which
is possible by =A7 17.4.3.1/1 of the Standard.

Falk
0
3/8/2005 1:02:52 PM
Dr. Adrian Wrigley wrote:

>>>C++ was designed to produce an object-orientated
>>>extension to C.
>>
>>An all too common misconception.
> 
> 
> enlighten us please!


C++ is a multiparadigm language and supports 4 paradigms. Each paradigm 
is supported *well* with optimal space and time efficiencies.

It does not enforce a specific paradigm, but allows the mixing of them 
as the programmer thinks it fits better for a specific problem.




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/8/2005 1:27:35 PM
On Tue, 8 Mar 2005 11:21:59 +0000, Marius Amado Alves  
<amado.alves@netcabo.pt> wrote:

>
> On 8 Mar 2005, at 06:53, Jerry Coffin 'taught' us that the language is  
> "assembly", not "assembler."
>
> This is fad. Of the 1990's I think. "Assembler" is correct. By use. To  
> this day. Personally I find the fad irritating. "Assembly" tried to fix  
> terminology that does not need fixing. To avoid colision us stupid folks  
> just call the compiler "translator".
>

My memory isn't what it used to be, but I think we called it assembly  
language (or interchangeably, assembler) back in the mid to late 70's.

- Ed
0
falis (298)
3/8/2005 2:06:55 PM
Falk Tannh=E4user wrote:

[ ... ]

> I would put the "using namespace std;", or even better, just
> "using std::swap;" into the "sort" function, at the scope of the
> block from where the "swap" is called.

Oh, of course. When you're making something visible, you nearly always
want to limit the visibility as much as practical.

> This way, the precise purpose
> of the "using" declaration becomes clear to both the human reader
> and the compiler (because unwanted side effects due to name
> collisions are avoided).
> Furthermore, the implementer of "whatever_type" should consider to
> put the specialisation of "swap" into the "std" namespace, which
> is possible by =A7 17.4.3.1/1 of the Standard.

A perfectly reasonable possiblity, but the sort function shouldn't
depend on it.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/8/2005 2:37:03 PM

Peter Koch Larsen wrote:
> "Ludovic Brenta" <ludovic.brenta@insalien.org> skrev i en meddelelse 
> news:87r7iu85lf.fsf@insalien.org...
> 
>>Peter Koch Larsen writes:
>>
>>>Out of curiosiy, could you give some few examples where Ada catches
>>>faults not found by a C++ compiler. I assume - of course - code
>>>written in modern C++: no casts, functions instead of macroes, a
>>>limited use of pointers and so on.
>>
>>Generally speaking, the very fact that you feel an urge to distinguish
>>between "C++" and "modern C++" is an indication that C++ is a poor
>>language containing many unsafe features, some of which you obligingly
>>enumerated above.  By contrast, there is no distinction between "Ada"
>>and "modern Ada".  Ada is safe by design, from the ground up.
> 
> 
> We agree here. C++ is a "hackers language", in part because of its C roots.
> 
> 
>>Now for one specific example, I wrote a buffer overflow in a C++
>>library a few years ago, and it took me and two other people 3 days to
>>find it.  The fix was, of course, trivial once the bug was found.  As
>>it turned out, this particular bug would have been impossible to write
>>in Ada.  I can't post the code, as it is proprietary and I don't have
>>it at hand anyway, but the gist of it is that, in Ada, loop variables
>>(a) are constants and (b) do not exist outside of the loop:
>>
>>procedure Proc (A : in String) is
>>begin
>>  for J in A'Range loop
>>     J := J + 4; -- illegal, J is constant inside the loop
>>  end loop;
>>  Do_Womething_With (J); -- illegal, J no longer exists
>>end Proc;
> 
> 
> This is inherited from Pascal if I remember correctly. Of course, good C++ 
> style is to declare your variable in the loop.
> 
>>Also notice that, in Ada, the "for" statement declares the loop
>>variable automatically.
>>
>>The bug in the C++ library was that I was mistakenly reusing the loop
>>variable after the loop, instead of the intended variable.  Of course,
>>the loop variable was an index pointing after the end of the buffer.
>>
>>Some other features that make Ada inherently safer than C++ are:
>>
>>* assignment is not an operator; it is an operation which does not
>> return a value.  Thus, bugs like "if (something = 0)" cannot exist.
>>
>>* case statements (Ada's equivalent of a switch in C++) are required
>> to handle all possible cases.  Thus it is impossible to forget one.
>> And, of course, there is no "break;" crap in Ada.
>>
>>* conditions cannot mix "and" and "or" without parentheses.  Thus
>> there is no possibility that the programmer make wrong assumptions
>> about precedence of operators or order of evaluation.
> 
> 
> This seems ridiculous. I would expect a programmer to know the precedence 
> rules or at least insert parentheses if they are in doubt.
> 
> 
>>* the type system, when used appropriately, makes it possible for the
>> compiler to find semantic errors in addition to just syntax errors.
>> For example, you can declare that Numers_Of_Apples and
>> Numers_Of_Oranges cannot be mixed.  This is not possible with C++'s
>> typedef.
> 
> 
> I like that idea. It is possible using templates, of course. Is it general 
> enough? If you replace "apples" with "weight" and "oranges" with "length", 
> is it then permissible to multiply a length with a weight but not add the 
> two together?
> 
> 
>>* conversions from floating point to integer types involve rounding.
>> The rounding is precisely and deterministically defined by the ISO
>> standard for the Ada language.  Similarly, floating-point and
>> fixed-point types can be declared with known, deterministic,
>> guaranteed precision.
> 
> 
> This point sounds as if it restricts the environments where Ada can be used.
> 
>>* pointer types cannot be converted to one another.  You cannot
>> convert a pointer-to-String to a pointer-to-random-object.
> 
> 
> You can't do so in C++ either. (C has the conversion to/from void*).
> 
> 
>>* accessibility rules are rather complex, but they are designed to
>> minimise the chance of mistakes.  Basically, the scope of a pointer
>> type must be included in the scope of the pointed-to type.  This
>> makes many mistakes impossible, such as returning a pointer to an
>> object which no longer exists.
> 
> 
> I like that one to.
> 
> 
>>* when the compiler cannot check some code statically, it inserts
>> run-time checks which are guaranteed to catch all errors by raising
>> exceptions.  In C++ you must code these checks by hand, and of
>> course at some point you'll forget one crucial check which will cost
>> you days in debugging.
> 
> 
> I sort of like this one as well - although raising an exception seems to be 
> to forgiving.
> My conclusion is that there are some nice ideas out there, but that they 
> mainly protect against the "sloppy" programmer.

Exactly - because not every programmer is well organized to keep all the 
  nuances in their head, and observe them when coding.  Furthermore, 
when components are integrated and one component talks to another is 
when the big debugging problems surface.  One has to look at the 
history/motivation of Ada development versus that of C/C++...Ada 
certified compilers and tools strictly enforce the semantics of the 
language.  It has been my experience that there is a lot of variability 
in C/C++ compilers in how through language semantics are adhered to.


> 
> 
>>-- 
>>Ludovic Brenta.
> 
> 
> Thanks for your answer
> Peter 
> 
> 
0
jhudak (21)
3/8/2005 2:51:29 PM

Ioannis Vranos wrote:

> Pascal Obry wrote:
> 
>>
>> And what about:
>>
>>  int main()
>>  {
>>    int i;
>>       for(i=0; i<10; ++i)
>>          ;
>>  
>>       i=7;
>>  }
>>
>> What is important for safety is not what a language permits but what
>> it forbids. As long as you have traps in a language you know that some
>> programmers will fall into it at some point.
> 
> 
> 
> Every variable is visible inside the scope that it was defined.
> 
> If you want to use i inside a for loop only, then define it in the for 
> loop.
> 
> 
> The restriction that you imply you desire, limits flexibility.
> 
> Once again, I have nothing against learning Ada, however personally I 
> like the most powerful languages. The next thing I am going to learn 
> after C++ (because I haven't learned it all yet), is probably some form 
> of assembly language.

What????????????????????????????????????????????????? Assembly language? 
powerful?  If you decide to write a X GUI interface in assembly, I'll 
check in on you in 20 years to see how your doing.... Higher level 
languages handle broader abstract concepts better than low level 
languages.  Assembly is great if you are optimizing device drivers or 
banging bits at the hardware register level...not good at implementing 
scientific algorithms, GUIs, databases, etc.   There are thousands of 
reasearch papers that extol the problems of assembly language approach 
to things, and yes, there are places and reasons to use it, but 
classifying it as a 'higher level language' and something more powerful 
is incorrect....
-John

> 
> 
> For example I like that I can do:
> 
> #include <iostream>
> #include <string>
> #include <bitset>
> #include <limits>
> 
> class SomeClass
> {
>       std::string s;
> 
>       public:
>              SomeClass()
>              {
>                         s="This is a text message";
>              }
> };
> 
> 
> int main()
> {
>     using namespace std;
> 
>     SomeClass obj;
> 
>     unsigned char *p= reinterpret_cast<unsigned char *>(&obj);
> 
>     // Displays the individual bytes that obj
>     // consists of as unsigned chars.
>     for(unsigned i=0; i<sizeof(obj); ++i)
>       cout<<"character: "<<p[i]<<"\n";
> 
>     cout<<"\n";
> 
> 
>     p= reinterpret_cast<unsigned char *>(&obj);
>     // Displays the decimal values of the
>     // individual bytes that obj consists of.
>     for(unsigned i=0; i<sizeof(obj); ++i)
>       cout<<static_cast<unsigned>(p[i])<<" ";
> 
>     cout<<"\n\n";
> 
> 
>     // Displays the bits of each byte that consist
>     // this SomeClass object
>      p= reinterpret_cast<unsigned char *>(&obj);
>      for(unsigned i=0; i<sizeof(obj); ++i)
>      {
>           // A byte is not necessarily 8 bits
>           // numeric_limits<unsigned char>::digits retrieves the number
>           // of byte's bits, which *is* 8 usually.
>           bitset<numeric_limits<unsigned char>::digits> bits(p[i]);
> 
>           for(unsigned j=0; j<bits.size(); ++j)
>              cout<<bits[j];
> 
>           cout<<"\n";
>      }
> }
> 
> 
> C:\c>temp
> character: ⁿ
> character: =
> character: >
> character:
> 
> 252 61 62 0
> 
> 00111111
> 10111100
> 01111100
> 00000000
> 
> C:\c>
> 
> 
> I am sure that many ADA developers will say that this one is not needed 
> (the ability to access the individual bytes of objects is needed in many 
> cases, e.g. to create low level exact copies of objects ) and it is 
> unsafe (yes it is, low level stuff are unsafe and it all depend on the 
> programmer knowing what he does).
> 
> 
> It is up to oneself to learn whatever languages fits his purposes. For 
> example, a "safe" language is not an interest for me.
> 
> Someone who places much hopes on the language to protect him from his 
> mistakes, probably ADA is better than C++ on this.
> 
> 
> There is no language that provides satisfies all people desires, just 
> because some desires are in contrast between them.
> 
> 
> 
0
jhudak (21)
3/8/2005 3:02:34 PM
Ioannis Vranos wrote:

[ ... ]

> > unsigned char *a = reinterpret_cast<char *>(&x);
>
> unsigned char *a = reinterpret_cast<unsigned char *>(&x);

Oops -- quite right. Fortunately, despite it's reputed lack of safety,
any properly-functioning C++ compiler would have caught my mistake had
it been in real code.

[ ... ]

> Also since Ada is more ancient than C++ in terms of a final standard,
> we can expect that some things are "more ancient", but it is still
> an interesting language since it can do low level stuff.

I'm not sure "ancient" applies to either -- at least the last time I
noticed, the most recent Ada standard was approved in 1995, which is
marginally older than the C++ standard. I'm not really sure this means
a lot though -- most of the basic ideas of C++ were fixed by then in
any case. Certainly there were changes in the text of the rules after
that point, but most of these were to get the rules to require what had
already been decided upon, not things that were intended to change the
language.

> I am not sure it is "safer" than C++ too, I am suspicious of "safe"
> languages.

The first problem is to define what you mean by safety. Bjarne has been
fairly explicit that most safety features in C++ are intended to
prevent accidents, not intentional subversion. It's always seemed to me
that Ada has had a rather muddled idea of the "threat model", so the
language features have never been entirely aligned to a single intent.
Some parts appear intended to prevent accidents, but are quite easy to
subvert when one wishes to do so. Other parts appear to have been
designed with the intent of preventing even intentional subversion, but
fail to do so, and simply render some things quite a bit uglier than
there seems to be good reason for.

In fairness, I should add that my personal experiece with Ada was
almost entirely with the 1983 version, so it's entirely possible that
at least some of these have been fixed -- OTOH, looking at the code
snippets posted to this thread, it looks like at least some of the
ugliness remains.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/8/2005 3:29:47 PM

Hans Malherbe wrote:
>>support efficient, real-time safe environments
> 
> 
> Can you explain the "real-time" part?
> 
> Reading this thread, it seems to me Ada's focus is on safety rather
> than efficiency.
> These safety constraints also tend to limit expressiveness. Not that
> safety is bad, just that it's not free.
> 

Actually, a close reading of the thread should have made it clear that 
the additional safety is indeed "free".  Since the majority of Ada's 
checks are compile time they do not impact on  run-time efficiency. 
Where Ada's goals can only be met by run-time checks these are no more 
expensive than equivalent manually-inserted checks in any other language 
(and are often less because Ada provides the compiler with more 
information by which to judge when they can safely be optimised away). 
They can, in any case be turned off if the user requires a different 
performance/safety tradeoff.

It should also have been clear from the thread that Ada imposes no 
limits on expressiveness.

Can you say what led you to the opposite conclusion?

Peter

0
peter.amey (87)
3/8/2005 3:31:22 PM
In article <1110284070.410136.205090@o13g2000cwo.googlegroups.com>, "Hans Malherbe" <hans.malherbe@gmail.com> writes:
>> support efficient, real-time safe environments
> 
> Can you explain the "real-time" part?
> 
> Reading this thread, it seems to me Ada's focus is on safety rather
> than efficiency.

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

> These safety constraints also tend to limit expressiveness. Not that
> safety is bad, just that it's not free.

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).
0
Kilgallen (2738)
3/8/2005 3:53:16 PM
On Tue, 08 Mar 2005 15:27:35 +0200, Ioannis Vranos wrote:

> Dr. Adrian Wrigley wrote:
> 
>>>>C++ was designed to produce an object-orientated
>>>>extension to C.
>>>
>>>An all too common misconception.
>> 
>> 
>> enlighten us please!
> 
> C++ is a multiparadigm language and supports 4 paradigms. Each paradigm 
> is supported *well* with optimal space and time efficiencies.
> 
> It does not enforce a specific paradigm, but allows the mixing of them 
> as the programmer thinks it fits better for a specific problem.

This is is well known.

I was asking for my misconception on what *C++ was designed for* to
be dispelled.
-- 
Adrian

0
amtw (199)
3/8/2005 6:06:11 PM
Peter Amey <peter.amey@praxis-cs.co.uk> writes:

> manually-inserted checks in any other language (and are often less because
> Ada provides the compiler with more information by which to judge when they
> can safely be optimised away). 

For example (if you ask):

   type Table is array (1 .. 10) of Integer;

   Data : Table;

   for K in Data'Range loop
      if Data (K) = 1 then
         ...
      end if;
   end loop;

There is no need to check K validity inside the loop as "Data (K)" is always
correct by definition (K in Data'Range). Just an example.

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
0
pascal27 (183)
3/8/2005 6:16:49 PM
Peter Amey wrote:
> 
> 
> Hans Malherbe wrote:
> 
>>> support efficient, real-time safe environments
>>
>>
>>
>> Can you explain the "real-time" part?
>>
>> Reading this thread, it seems to me Ada's focus is on safety rather
>> than efficiency.
>> These safety constraints also tend to limit expressiveness. Not that
>> safety is bad, just that it's not free.
>>
> 
> Actually, a close reading of the thread should have made it clear that 
> the additional safety is indeed "free". 

Free? Well, lets look at one particular issue:  pointers to arbitrary 
locations. In C, its a common idiom to do the following:
    foo(int * p)
    {
       int * z;
       for( i ... ) {
         ... p[i]...;
       }
       z = p;
    }

    ...
    foo( &x[lo] );
    ...

Now, how can *any* language check to see that p[i] is within bounds?

The usual solution is to pass p as a "handle"; basically, pass two 
pointers, one of which is the pointer to the descriptor of the 
containing "object" (which could be x or something containing x), or 
alternatively, pass a pointer to a record that contains x and p. z, in 
particular, will have to be a 2 element record, again containing x and p.

A dereference via z will have to become a double dereference; first load 
  p from z then load from p.

Not quite free.

> Since the majority of Ada's 
> checks are compile time they do not impact on  run-time efficiency. 
> Where Ada's goals can only be met by run-time checks these are no more 
> expensive than equivalent manually-inserted checks in any other language 
> (and are often less because Ada provides the compiler with more 
> information by which to judge when they can safely be optimised away).

Bullsh*t. In several ways, of which two are:
- Usually the checks will be added every place they are needed, and then 
the usual optimizations will be used to eliminate them. In other words, 
if one adds the checks manually, the compiler should eliminate them 
identically.
- Going back to the problem of finding the countaining object for some 
pointer. If one is adding the code by hand, one can use several options 
NOT available to a compiler.
	* what if z always points to objects inside x (but the compiler can't 
figure it out).
	* what if the containing object for p is always allocated on some 2^n 
byte boundary?

There are other interesting things one can do for safety that are less 
memory/CPU intensive than what a language can give you automatically.

Have a look at http://users.bestweb.net/~ctips for some of the ideas.

> They can, in any case be turned off if the user requires a different 
> performance/safety tradeoff.

Are you sure? Do I have to recompile the whole program in that case? Or 
reannotate the whole program? The above "handles" case is particularily 
pernicious. If a sub-program is compiled to not expect handles [because 
we just turned off that protection feature], but its caller is still 
passing handles, well - interesting things will ensue.

> It should also have been clear from the thread that Ada imposes no 
> limits on expressiveness.

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

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

> Can you say what led you to the opposite conclusion?
> 
> Peter
> 
0
ctips (287)
3/8/2005 6:33:33 PM
CTips <ctips@bestweb.net> writes:

> Free? Well, lets look at one particular issue:  pointers to arbitrary
> locations. In C, its a common idiom to do the following:
>     foo(int * p)
>     {
>        int * z;
>        for( i ... ) {
>          ... p[i]...;
>        }
>        z = p;
>     }
> 
>     ...
>     foo( &x[lo] );
>     ...
> 
> Now, how can *any* language check to see that p[i] is within bounds?

Good you asked! Let's code this example in Ada (using Ada and
not C/C++ style, in Ada for the above example we do not need a pointer):

   type T is array (Positive range <>) of Integer;

   procedure Foo (P : in out T) is
      Z : Positive;
   begin
      for I in P'Range loop
         ... P(i)...;
        --  Here P(i) is always within the bounds, no check needed.        
      end loop;
      Z := P'First;
   end Foo;

   ...

   Foo (X (Lo .. X'Last));

> Bullsh*t. In several ways, of which two are:

Given your assumption about maybe you just don't know Ada.

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
0
pascal27 (183)
3/8/2005 6:46:41 PM
John Hudak writes:
> What????????????????????????????????????????????????? Assembly
> language? powerful?  If you decide to write a X GUI interface in
> assembly, I'll check in on you in 20 years to see how your
> doing.... Higher level languages handle broader abstract concepts
> better than low level languages.  Assembly is great if you are
> optimizing device drivers or banging bits at the hardware register
> level...not good at implementing scientific algorithms, GUIs,
> databases, etc.   There are thousands of reasearch papers that extol
> the problems of assembly language approach to things, and yes, there
> are places and reasons to use it, but classifying it as a 'higher
> level language' and something more powerful is incorrect....
> -John

I think the problem is to define what everyone means by "powerful".

If by "powerful" I mean "I can do exactly anything I want", or "I can
get the most out of my hardware", then assembly is the most powerful
language.

If OTOH "powerful" means "I can program quickly", then assembly is not
powerful, but e.g. SQL or Delphi are.

-- 
Ludovic Brenta.
0
3/8/2005 7:13:46 PM
"Jerry Coffin" writes:
> In fairness, I should add that my personal experiece with Ada was
> almost entirely with the 1983 version, so it's entirely possible that
> at least some of these have been fixed -- OTOH, looking at the code
> snippets posted to this thread, it looks like at least some of the
> ugliness remains.

The "use type" feature of Ada 95 alone makes Ada 95 *much* more
pleasant to program with.  Check it out.  And yes, we allow it in our
coding standards :)

-- 
Ludovic Brenta.

0
3/8/2005 7:16:07 PM
Marius Amado Alves writes:
> On 8 Mar 2005, at 06:53, Jerry Coffin 'taught' us that the language is
> "assembly", not "assembler."
>
> This is fad. Of the 1990's I think. "Assembler" is correct. By
> use. To this day. Personally I find the fad irritating. "Assembly"
> tried to fix terminology that does not need fixing. To avoid
> colision us stupid folks just call the compiler "translator".

OK, since we Ada enthusiasts keep bickering about "Ada not ADA", I
understand and respect Jerry's distaste for "assembler" to denote a
language.  From now on, I will refer to the language as "assembly" and
use "assembler" to refer to the language processor for that language
(or, to be more precise, instance of this class of languages :) ).

-- 
Ludovic Brenta.
0
3/8/2005 7:18:10 PM
In article <112rs0bdr2aftdf@corp.supernews.com>, CTips <ctips@bestweb.net> writes:
> Peter Amey wrote:

>> They can, in any case be turned off if the user requires a different 
>> performance/safety tradeoff.
> 
> Are you sure? Do I have to recompile the whole program in that case?

At a maximum, recompile the module that has become performance critical.
0
Kilgallen (2738)
3/8/2005 7:24:19 PM
"Jerry Coffin" writes:
> Ludovic Brenta wrote:
>> I could make the code less verbose by using use clauses, similar to
>> "using namespace std" which you seem fond of.  In avionics, our
>> coding standards forbid that because we want everything to be
>> explicit.
>
> A poor idea. Just for example, consider writing a generic sorting
> function. It needs to swap items that it's sorting. In well-written
> C++, this will often be done with a using clause. Specifically, if
> the type of items has provided its own specialized version of swap,
> then my sorting functino should use that, but otherwise it should
> use std::swap to swap them.
>
> I try to specify whatever_type::swap(x,y), then compilation will
> fail if the type has not provided a swap function. Conversely, if I
> specify std::swap(x,y), then the specialized swap function won't be
> used for those types that provide one.

Ada requires explicit instanciation of all templates, so there is no
"default".  We do not have problems using fully-qualified names.

Ada 95's object-oriented features do not suffer from this either.

package P is
   type Base is tagged null record;

   procedure Method (B : in Base);
end P;


with P;
package Q is
   type Derived is new P.Base with private;

   procedure Method (B : in Derived); -- overloads P.Method
private
   -- omitted
end Q;


with P;
procedure Dynamic_Dispatch (B : in Base'Class) is
begin
  P.Method (B); -- [1]
end Dynamic_Dispatch;



The procedure Dynamic_Dispatch does not see package Q, yet it can call
Q.Derived if it receives an instance of Q.Derived as its parameter.
This, *even* without a use clause.

-- 
Ludovic Brenta.
0
3/8/2005 7:25:06 PM
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'Storage_Pool use My_Arena;

Here you are:

Ptr : Object_Ptr := new Object; -- This allocates it in My_Arena

Note that Object can still be allocated on the stack or in any other pool:

type Object_Universal_Ptr is access all Object;

This : Object;
            -- This allocates it on the stack
That : Object_Universal_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;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/8/2005 7:31:52 PM
Jerry Coffin wrote:
>>In fact,
>>any software system over a half-million lines of
>>source code should be coded in
>>Ada.
> 
> Here, however, you lose your grip on reality. This is NOT "in fact" --
> it's purely an OPINION! It's certainly possible to find projects that
> would involve more than a half-million lines of code for which Ada
> would be _extremely_ poorly suited, at best.

It's an opinion /nearly/ shared with P. J. Plauger of the ANSI-C 
committee (and Dinkumware) - only I believe he quoted 100 thousand lines 
as the point at which you should be using Ada. :-)

Cheers

-- Martin
0
3/8/2005 7:52:13 PM
Pascal Obry wrote:
> CTips <ctips@bestweb.net> writes:
> 
> 
>>Free? Well, lets look at one particular issue:  pointers to arbitrary
>>locations. In C, its a common idiom to do the following:
>>    foo(int * p)
>>    {
>>       int * z;
>>       for( i ... ) {
>>         ... p[i]...;
>>       }
>>       z = p;
>>    }
>>
>>    ...
>>    foo( &x[lo] );
>>    ...
>>
>>Now, how can *any* language check to see that p[i] is within bounds?
> 
> 
> Good you asked! Let's code this example in Ada (using Ada and
> not C/C++ style, in Ada for the above example we do not need a pointer):
> 
>    type T is array (Positive range <>) of Integer;
> 
>    procedure Foo (P : in out T) is
>       Z : Positive;
>    begin
>       for I in P'Range loop
>          ... P(i)...;
>         --  Here P(i) is always within the bounds, no check needed.        
>       end loop;
>       Z := P'First;

Nope, not z = p[0], z = p; Z is a _pointer_ to int, not an int.

>    end Foo;
> 
>    ...
> 
>    Foo (X (Lo .. X'Last));
> 
> 
>>Bullsh*t. In several ways, of which two are:
> 
> 
> Given your assumption about maybe you just don't know Ada.

Try again. Show me how sizeof(z) != 8 in Ada.

> 
> Pascal.
> 
0
ctips (287)
3/8/2005 8:10:34 PM
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'Storage_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?

> 
> Note that Object can still be allocated on the stack or in any other pool:
> 
> type Object_Universal_Ptr is access all Object;
> 
> This : Object;
>             -- This allocates it on the stack
> That : Object_Universal_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.
0
ctips (287)
3/8/2005 8:13:20 PM
In article <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote:

>> 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;

In other words, the code generator within the Ada compiler takes care
of the load-locked store-conditional aspects of the architecture.

What Dmitry has shown is how the programmer accesses that capability.
0
Kilgallen (2738)
3/8/2005 8:23:23 PM
CTips wrote:
> 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.

If you need that particular assembler then you'd best write it yourself. 
I don't know of any language that could guarentee what assembler is 
produced following a compilation.

Cheers

-- Martin
0
3/8/2005 8:38:50 PM
CTips <ctips@bestweb.net> writes:

> Nope, not z = p[0], z = p; Z is a _pointer_ to int, not an int.

Look at your program. You do nothing with Z so my solution is equivalent.
That's the point.

> Try again. Show me how sizeof(z) != 8 in Ada.

Sorry I don't parse this one. I don't care about the size of Z! I care about
what my application has to do. So if you tell us what you want to achieve we'll
provide the solution using Ada not Ada-Transtaled-From-C++ one. It is always a
mistake to copy the solution word for word when translating from one language
to another.

        chauve-souris /= bald-mouse

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
0
pascal27 (183)
3/8/2005 8:44:00 PM
CTips wrote:
> Dmitry A. Kazakov wrote:

>> type Object is ...;
>> type Object_Ptr is access Object;
>> for Object_Ptr'Storage_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?

My_Arena is a storage pool, storage pool is a term
defined by the language.

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

For how many concurrently executing threads
of control, each invoking the incrementing function,
will this work? (Without any addition that is, as in
the Ada example)

Georg 
0
bauhaus1 (735)
3/8/2005 8:54:03 PM
On Tue, 08 Mar 2005 15:13:20 -0500, CTips wrote:

> 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'Storage_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?

It is completely up to you. My_Arena has to be derived from
System.Storage_Pools.Root_Storage_Pool. Which is the abstract base of all
storage pools. The implementation of Allocate and Deallocate is at your
discretion. For an arena the pool may contain a statically allocated array
organized as a stack. Deallocate could be then void, or it can pop
everything above it as in mark'n'release. A more advanced application could
allocate memory in segments at request etc. For a sample implementation of
a segmented stack pool see:

http://www.dmitry-kazakov.de/ada/components.htm#Pools_etc 

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

Ask your compiler vendor. Though it wouldn't be necessarily polling. Also
usually protected objects are not used for so utterly fine-grained mutual
exclusion/locking. Atomic integer increment is normally just a small part
of some larger (but not lengthy) operation. For example, placing something
in a queue. Therefore spinning for a lock (which probably would be the
implementation) will likely be less expensive than some tricky guards
attached to each and every instruction. Note also that at such a low level
it would be very difficult if possible to maintain data consistency.
Compiler simply does not know what is related to what and will try to cope
with the worst case scenario. Protected types in Ada are to describe this
sort of semantics. So in the end atomic integers are pretty useless, no
matter how efficient they could be implemented.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/8/2005 8:59:33 PM
CTips <ctips@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.

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);

In this case it would be nice to see the generated code.

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
0
pascal27 (183)
3/8/2005 9:07:16 PM
> ...  From now on, I will refer to the language as "assembly" and
> use "assembler" to refer to the language processor...

This is a fine example of a 'fix' introducing (potential for) a new 
bug: if you say just "assembly" you're in error; you must say "assembly 
language" in full. Or else just keep the good old word "assembler" and 
be bug-free :-)

0
amado.alves (488)
3/8/2005 9:16:50 PM
CTips wrote:
>>>       int * z;
 
> Try again. Show me how sizeof(z) != 8 in Ada.

I'm not sure I understand. On an x86 system,

   type Tiny is range 0 .. 31;
   -- stored in an 8 bits register unless I demand otherwise

   Type TP is access all Tiny;
   for TP'Size use 32;  -- in bits.

Ask for more bits for the pointer if you like. E.g.,

   for TP'Size use 128; 

In this case you get a compiler warning about unused bits. Then,
without any optimization, I get diffs of this sort, reflecting
the difference in the sizes of the pointer types TP:

<       subl    $8, %esp
---
>       subl    $40, %esp
32,33c32,33
<       leal    -1(%ebp), %eax
<       movl    %eax, -8(%ebp)
---
>       leal    -9(%ebp), %eax
>       movl    %eax, -40(%ebp)
0
bauhaus1 (735)
3/8/2005 9:21:38 PM
CTips wrote:

> Nope, not z = p[0], z = p; Z is a _pointer_ to int, not an int.

Well, yes. Nothing stops you from passing a pointer to an int
in Ada, in both read-only and read-write mode.
And you can of course have pointers to arbitraty locations but you
have to use language to express this fact, using for example

   for X'Adress use ...;

Or use the adressing types and operations in the System hierarchy.

You can also use any bit pattern to represent anything as long as
you explicitly ask for a new interpretation. Isn't this slightly more
permissive than what can be expressed using reinterpret_cast in C++?

Also, Unchecked_Conversion is neither casting, nor the usual type
conversion.
If I wanted the bits of a 32 bits float of value 3.14 to stand for an
integer, type conversion will give 3, an instance of Unchecked_Conversion
will give 1078523331.

Georg 
0
bauhaus1 (735)
3/8/2005 9:48:52 PM
Falk Tannh�user wrote:

> Furthermore, the implementer of "whatever_type" should consider to
> put the specialisation of "swap" into the "std" namespace, which
> is possible by � 17.4.3.1/1 of the Standard.

Too tricky, can become bad habit.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/8/2005 11:29:00 PM
John Hudak wrote:

> What????????????????????????????????????????????????? Assembly language? 
> powerful?  If you decide to write a X GUI interface in assembly, I'll 
> check in on you in 20 years to see how your doing.... Higher level 
> languages handle broader abstract concepts better than low level 
> languages.  Assembly is great if you are optimizing device drivers or 
> banging bits at the hardware register level...not good at implementing 
> scientific algorithms, GUIs, databases, etc.   There are thousands of 
> reasearch papers that extol the problems of assembly language approach 
> to things, and yes, there are places and reasons to use it, but 
> classifying it as a 'higher level language' and something more powerful 
> is incorrect....


Actually I think if you use the platform's APIs it is taking much less. 
For example I think one may use Win32 API with assembly.


Also the assembly that I have primarily in mind is the one of .NET.


..NET is a CLI VM and here is a book about .NET's (CLI) VM assembly language:

http://www.amazon.com/exec/obidos/tg/detail/-/0735615470/qid=1091414100/sr=1-7/ref=sr_1_7/102-2992266-3703320?v=glance&s=books



CLI assembly language is defined in the freely available CLI standard, 
so you can view in the specification how it looks like:

http://www.ecma-international.org/publications/standards/Ecma-335.htm



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/8/2005 11:40:39 PM
John Hudak wrote:

> Exactly - because not every programmer is well organized to keep all the 
>  nuances in their head, and observe them when coding.  Furthermore, when 
> components are integrated and one component talks to another is when the 
> big debugging problems surface.  One has to look at the 
> history/motivation of Ada development versus that of C/C++...Ada 
> certified compilers and tools strictly enforce the semantics of the 
> language.  It has been my experience that there is a lot of variability 
> in C/C++ compilers in how through language semantics are adhered to.


There is no variability concerning ISO C++ features these days.


A question: With .NET facilities, when one performs an invalid operation 
like accessing an array out of its bounds an exception is thrown and the 
program terminates indicating what was the problem.


This is the kind of run-time safety Ada provides or is there something else?


int main()
{
     using namespace System;

     array<int> ^someArray= {1,2,3,4,5,6,7,8,9,0};

     someArray[10]= 7;
}


C:\c>temp

Unhandled Exception: System.IndexOutOfRangeException: Index was outside 
the bounds of the array.
    at main()

C:\c>



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/9/2005 12:02:29 AM
Dr. Adrian Wrigley wrote:

> This is is well known.
> 
> I was asking for my misconception on what *C++ was designed for* to
> be dispelled.


It began as "C with classes", but this does not mean "it was designed 
for" that only.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/9/2005 12:05:13 AM
Pascal Obry wrote:

> For example (if you ask):
> 
>    type Table is array (1 .. 10) of Integer;
> 
>    Data : Table;
> 
>    for K in Data'Range loop
>       if Data (K) = 1 then
>          ...
>       end if;
>    end loop;
> 
> There is no need to check K validity inside the loop as "Data (K)" is always
> correct by definition (K in Data'Range). Just an example.


Pascal, this looks like Pascal.


The C++ equivalent:


#include <vector>

// ...


using namespace std;

vector<int> Data(10);

for(vector<int>::size_type i=0; i<Data.size(); ++i)
{
     if (Data[i]== 1)
     {
         // ...
     }
}


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/9/2005 12:44:36 AM
Larry Kilgallen wrote:

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


Don't confuse verbose with being comprehensible. Myself that do not know 
Ada, I cannot understand much when I see Ada code, apart from some 
Pascal style declarations of variables, procedures and records, and this 
because I have used Pascal.  :-)



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/9/2005 12:57:03 AM
CTips <ctips@bestweb.net> wrote in
news:112rs0bdr2aftdf@corp.supernews.com: 

> Peter Amey wrote:
>> 
>> 
>> Hans Malherbe wrote:
>> 
>>>> support efficient, real-time safe environments
>>>
>>>
>>>
>>> Can you explain the "real-time" part?
>>>
>>> Reading this thread, it seems to me Ada's focus is on safety rather
>>> than efficiency.
>>> These safety constraints also tend to limit expressiveness. Not that
>>> safety is bad, just that it's not free.
>>>
>> 
>> Actually, a close reading of the thread should have made it clear
>> that the additional safety is indeed "free". 
> 
> Free? Well, lets look at one particular issue:  pointers to arbitrary 
> locations. In C, its a common idiom to do the following:
>     foo(int * p)
>     {
>        int * z;
>        for( i ... ) {
>          ... p[i]...;
>        }
>        z = p;
>     }
> 
>     ...
>     foo( &x[lo] );
>     ...
> 
> Now, how can *any* language check to see that p[i] is within bounds?

This is one of the unsafe idioms in C.
The fact that you can declare a formal parameter as a pointer and then
use that parameter as an array is unsafe. This can only be done
safely if you either assume the existence of meta-data in the array
to indicate the end of usable data (as in the \0 at the end of a string),
or you must pass a second parameter telling you how long the array should
be. Of course, that second parameter must be handled carefully. Improper
values in the second parameter will cause you to skip array components
or will create a bounds violation. Array bounds violations have for years
been one of the most frequent C programming errors, and a boon to
virus writers.

Ada arrays are not so closely related to pointers.
One can create an access type that "points" to an array.


type int_array is array(1..10) of integer;
type int_ptr is access int_array;

Note that int_ptr is not a pointer to an integer, 
but a pointer to an array of integers.

procedure foo(p : int_ptr) is
begin
   for I in p.all'range loop
       ... p(I)...
   end loop;
end foo;

ip : int_ptr := new int_array;

foo(ip);

All this works without a problem in Ada.

Jim Rogers

0
3/9/2005 1:18:03 AM
Martin Dowie wrote:

[ ... ]

> It's an opinion /nearly/ shared with P. J. Plauger of the ANSI-C
> committee (and Dinkumware) - only I believe he quoted 100 thousand
> lines as the point at which you should be using Ada. :-)

Which is utterly irrelevant to the original point, which was about
stating opinions as facts, not about who holds what opinion.

I am curious though: how do you make a meaningful comparison? If I
write something that takes only two thousand lines of SQL, it's almost
certain to take _well_ over that 100 thousand lines of Ada and might
well be closer to a million.

To me, using Ada in that situation sounds insane. Richard Reihle might
think it's the right thing to do, but I'm fairly certain that P.J.
Plaugar would disagree. I certainly don't have to think very hard to
guess at what my boss would say.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/9/2005 1:48:53 AM
Dr. Adrian Wrigley wrote:

[ ... ]

> Isn't there some confusion here?
>
> Surely the "aliasing" issue (ignored by C++ completely(?)) is largely
> independent if the "reinterpret_cast"/"Unchecked_Conversion" issue?

Yes -- he started by mentioning aliasing, but mostly seemed to be
talking about type punning, so that was what I replied to. The
discussion centered around safety, which is essentially orthogonal to
aliasing.

> The C++ programmer uses aliasing routinely and without thinking.

Aliasing is used frequently in C++, that much is true. IMO, the claim
that it's done "without thinking" is nothing more or less than flame
bait. I think you're capable of better.

> Ada makes the aliasing possibility explicit when necessary, but
> prohibits it otherwise.

Aliasing is almost certainly more common in C++, but ultimately it only
ever happens explicitly in either language. In fact, I think "explicit"
is virtually meaningless in discussing a programming language -- the
processor is not an intelligent being that makes decisions on its own
unless explicitly directed. As such, nothing in code is really
implicit. What most people call "implicit" is simply the rules of the
language doing their job. Even those who push explicitness as a virtue
rarely do things like parenthesizing a+(b*c). Even those who argue most
strongly for explicitness generally agree that this would be silly, at
least in "obvious" cases like the one above.

The "implicit" behavior I've seen Ada programmers complain about in C++
is equally codified in the rules of the language, and the fact that Ada
programmers think it's somehow implicit mostly just reflects the fact
that they don't know those rules. That's fine, but condemning the
language simply because they don't know it is much less so.

> If we're talking about the "reinterpret_cast" issue, it is
> essentially identical in Ada.

....and this is what actually affects safety. Aliasing mostly just makes
it more difficult to generate efficient code. Despite this, most claims
that C and/or C++ produce particularly poor code show little more than
defects in the testing.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/9/2005 2:43:05 AM
Martin Dowie wrote:
> CTips wrote:
> 
>> 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.
> 
> 
> If you need that particular assembler then you'd best write it yourself. 
> I don't know of any language that could guarentee what assembler is 
> produced following a compilation.
> 
> Cheers
> 
> -- Martin

But isn't it interesting that Ada can't express this?

Roughly speaking, Ada provides synchronous message passing and 
(non-nested?) monitors as first class constructs. This means that
  - it doesn't support asynchronous communication
  - it doesn't support any number of lock-free algorithms
Also, Ada's only scheduling/queing discipline is FIFO with priorities 
(and priorities are only available if the RT annex is actually 
implemented). If I want to do earliest-deadline first, well, how do I go 
about doing it?

Note that in most C compilers (NOT C++), it is possible to write the 
atomic increment code using inline assembler for the lwlock and stwcond 
and expect the code to be compiled correctly, and for the optimizations 
to optimize the code "correctly" (where correctly means that they'll do 
stuff like constant propagation etc. but won't change the atomic nature 
of the increment).

Also, its possible to use the full power of C and still co-exist with 
libraries that provide threading models of various kinds (e.g. POSIX).
0
ctips (287)
3/9/2005 2:43:47 AM
Dmitry A. Kazakov wrote:

> On Tue, 08 Mar 2005 15:13:20 -0500, CTips wrote:
> 
> 
>>Dmitry A. Kazakov wrote:
>>
>>
>>>On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote:

>>>
>>>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.
> 
> 
> Ask your compiler vendor. Though it wouldn't be necessarily polling. Also
> usually protected objects are not used for so utterly fine-grained mutual
> exclusion/locking. Atomic integer increment is normally just a small part
> of some larger (but not lengthy) operation   For example, placing something
> in a queue. 

Umm...can be done without locking. See wait-free/lock-free algorithms.

Therefore spinning for a lock (which probably would be the
> implementation) will likely be less expensive than some tricky guards
> attached to each and every instruction.

You *REALLY* should see what can be done with lwlock/stwcond. You'll be 
suprised how cheap synchronization can be.

> Note also that at such a low level
> it would be very difficult if possible to maintain data consistency.
> Compiler simply does not know what is related to what and will try to cope
> with the worst case scenario. 

So, what escapes does the language provide to let you do this? None?

>Protected types in Ada are to describe this
> sort of semantics. So in the end atomic integers are pretty useless, no
> matter how efficient they could be implemented.
> 

That is one reason *NOT* to learn Ada; it restricts both choices and 
thinking.
0
ctips (287)
3/9/2005 2:51:00 AM
CTips <ctips@bestweb.net> wrote in
news:112sonip5v4dca6@corp.supernews.com: 

> Martin Dowie wrote:
>> CTips wrote:
>> 
>>> 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.
>> 
>> 
>> If you need that particular assembler then you'd best write it
>> yourself. I don't know of any language that could guarentee what
>> assembler is produced following a compilation.
>> 
>> Cheers
>> 
>> -- Martin
> 
> But isn't it interesting that Ada can't express this?
> 
> Roughly speaking, Ada provides synchronous message passing and 
> (non-nested?) monitors as first class constructs. This means that
>   - it doesn't support asynchronous communication
>   - it doesn't support any number of lock-free algorithms
> Also, Ada's only scheduling/queing discipline is FIFO with priorities 
> (and priorities are only available if the RT annex is actually 
> implemented). If I want to do earliest-deadline first, well, how do I
> go about doing it?

I think you are missing some Ada capabilities.
While Ada does provide synchronous message passing and monitors,
it also provides the ability to declare objects as atomic and
volatile.

Atomic objects can be used instead of monitors (what Ada calls
protected objects) for inter-task communication. You can then
define your own schemes including lock-free algorithms or 
dcl.

If you want different scheduling policies you write them, just as 
in C or C++.

How, using C or C++, would you create a threaded program and
ensure that signals are handled by a specified thread, and not
simply by the thread that is currently running when the signal
is received? How will you handle general OS signals in this
manner and not only the specialized signals provided by
pThreads?

You seem to assume that Ada only allows you to use features
provided by the language while preventing you from creating
your own features. That idea just doesn't make any sense.

Linked lists are not implemented as native syntax in either
Ada or C, yet they are used frequently in both languages.
How can that be?

Jim Rogers

0
3/9/2005 4:34:44 AM
Jim Rogers wrote:

> CTips <ctips@bestweb.net> wrote in
> news:112sonip5v4dca6@corp.supernews.com: 
> 
> 
>>Martin Dowie wrote:
>>
>>>CTips wrote:
>>>
>>>
>>>>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.
>>>
>>>
>>>If you need that particular assembler then you'd best write it
>>>yourself. I don't know of any language that could guarentee what
>>>assembler is produced following a compilation.
>>>
>>>Cheers
>>>
>>>-- Martin
>>
>>But isn't it interesting that Ada can't express this?
>>
>>Roughly speaking, Ada provides synchronous message passing and 
>>(non-nested?) monitors as first class constructs. This means that
>>  - it doesn't support asynchronous communication
>>  - it doesn't support any number of lock-free algorithms
>>Also, Ada's only scheduling/queing discipline is FIFO with priorities 
>>(and priorities are only available if the RT annex is actually 
>>implemented). If I want to do earliest-deadline first, well, how do I
>>go about doing it?
> 
> 
> I think you are missing some Ada capabilities.
> While Ada does provide synchronous message passing and monitors,
> it also provides the ability to declare objects as atomic and
> volatile.
> 
> Atomic objects can be used instead of monitors (what Ada calls
> protected objects) for inter-task communication. You can then
> define your own schemes including lock-free algorithms or 
> dcl.

No you can't. How do you think atomicity is guaranteed (in general)? By 
providing a lock for the atomic object! Try and write code in Ada on a 
machine that supports either CAS or lwlock/stwcond to do an atomic 
increment that can generate the optimal code.

> If you want different scheduling policies you write them, just as 
> in C or C++.

Right - and then what's the advantage of the built-in features of Ada 
over and

> How, using C or C++, would you create a threaded program and
> ensure that signals are handled by a specified thread, and not
> simply by the thread that is currently running when the signal
> is received? 

What do you mean "handled by a thread"? How can you distinguish which 
thread is actually interrupted? More importantly, why do you care?

[If you're using pthreads, the answer is that about the only way you can 
make out that there is a difference is by looking at thread private 
data, and you want to use pthread_kill() to deliver a signal to a 
specific thread, or see below]

> How will you handle general OS signals in this
> manner and not only the specialized signals provided by
> pThreads?

Again you're assuming that C thread library == pthreads. And OS == 
POSIX-compliant. There are alternate OSes and mechanisms. Also POSIX 
signals are process oriented, not thread oriented, so they, in my 
opinoin, are kind of broken.

  However, in POSIX, you can do it by using pthread_sigmask() to disable 
delivery of the signal to all threads other than the handling one.

> You seem to assume that Ada only allows you to use features
> provided by the language while preventing you from creating
> your own features. That idea just doesn't make any sense.

Nope, I didn't say that - what I said was that Ada (particularily the 
concurrent part of Ada) is fairly retarted, particularily if you want to 
get performance. In fact, to get the performance similar to that which 
can be obtained in C, one would pretty much have to write in the C 
subset of Ada [i.e. turn off most of the checking, use libraries written 
in C + asm]. And even there I'd have my doubts - given the additional 
features that Ada compilers have to deal with, I doubt that they would 
have focused as much on the optimizations.

Actually, I can verify that: if I look at the computer shootout 
http://shootout.alioth.debian.org/great/, I find that gcc C beats gnat 
Ada pretty much across the board; actually, Ada's performance sucks 
pretty much across the board. One of gcc C or Intel C is generally among 
the top few programs, while with a couple of exceptions, Gnat Ada is 
around the middle. In matrix multiply it gets beaten by LISP, Java, and 
Python!!! (How can you get beaten by Python? The mind boggles!)

> Linked lists are not implemented as native syntax in either
> Ada or C, yet they are used frequently in both languages.
> How can that be?

And their C implemenations are faster.
> Jim Rogers
> 
0
ctips (287)
3/9/2005 5:46:08 AM
CTips wrote:
> Actually, I can verify that: if I look at the computer shootout 
> http://shootout.alioth.debian.org/great/, I find that gcc C beats gnat 
> Ada pretty much across the board; actually, Ada's performance sucks 
> pretty much across the board. One of gcc C or Intel C is generally among 
> the top few programs, while with a couple of exceptions, Gnat Ada is 
> around the middle. In matrix multiply it gets beaten by LISP, Java, and 
> Python!!! (How can you get beaten by Python? The mind boggles!)

It's very easy when you don't switch on _any_ optimizations! :-)

GNAT is being compiled with the equivalent of "-O0" and GCC C is getting 
"-O3".

NB: Ada2005 will be faster still now that copy-on-function-return isn't 
going to be necessary.

Cheers

-- Martin
0
3/9/2005 6:48:02 AM
Ioannis Vranos wrote:
> John Hudak wrote:
> 
>> Exactly - because not every programmer is well organized to keep all 
>> the  nuances in their head, and observe them when coding.  
>> Furthermore, when components are integrated and one component talks to 
>> another is when the big debugging problems surface.  One has to look 
>> at the history/motivation of Ada development versus that of 
>> C/C++...Ada certified compilers and tools strictly enforce the 
>> semantics of the language.  It has been my experience that there is a 
>> lot of variability in C/C++ compilers in how through language 
>> semantics are adhered to.
> 
> 
> 
> There is no variability concerning ISO C++ features these days.

You've been lucky then... ;-)

The last time I tried to port any C++ was between VxWorks and Borland... 
complete nightmare! And that wasn't so long ago...

But YMMV.

Cheers

-- Martin
0
3/9/2005 6:53:25 AM
Jerry Coffin wrote:
> Martin Dowie wrote:
> 
> [ ... ]
> 
> 
>>It's an opinion /nearly/ shared with P. J. Plauger of the ANSI-C
>>committee (and Dinkumware) - only I believe he quoted 100 thousand
>>lines as the point at which you should be using Ada. :-)
> 
> 
> Which is utterly irrelevant to the original point, which was about
> stating opinions as facts, not about who holds what opinion.

Hey! I did add a smiley! I just thought it was an opinion from a 
reputable source that tied in with the post. :-) :-)


> I am curious though: how do you make a meaningful comparison? If I
> write something that takes only two thousand lines of SQL, it's almost
> certain to take _well_ over that 100 thousand lines of Ada and might
> well be closer to a million.
> 
> To me, using Ada in that situation sounds insane. Richard Reihle might
> think it's the right thing to do, but I'm fairly certain that P.J.
> Plaugar would disagree.

Would I be allowed to use embedded SQL in the Ada code (GNADE)? Or a 
binding to Postgres or MySQL (APQ) or similar (ODBC)?


> I certainly don't have to think very hard to guess at what my boss would say.

Sorry, I don't know your boss.

Cheers

-- Martin
0
3/9/2005 7:00:04 AM
Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Pascal, this looks like Pascal.

Agreed.

> The C++ equivalent:
> 
> 
> #include <vector>
> 
> // ...
> 
> 
> using namespace std;
> 
> vector<int> Data(10);
> 
> for(vector<int>::size_type i=0; i<Data.size(); ++i)
> {
>      if (Data[i]== 1)

And no C++ compiler will check that Data[i] is valid. That's the point. If you
add the check explicitly no C++ compiler will be able to remove it. In the Ada
case the compiler knows lot more about the program and can decide to remove
the check if it knows that the index will never be outside the object
range. This is always the case for:

   for K in Data'Range loop
      ... Data(k)...

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
0
pascal27 (183)
3/9/2005 8:52:13 AM
On Tue, 08 Mar 2005 21:51:00 -0500, CTips wrote:

> Umm...can be done without locking. See wait-free/lock-free algorithms.

Honestly, I don't care. You know, I am not developing integer incrementers,
am developing software...

>> Therefore spinning for a lock (which probably would be the
>> implementation) will likely be less expensive than some tricky guards
>> attached to each and every instruction.
> 
> You *REALLY* should see what can be done with lwlock/stwcond. You'll be 
> suprised how cheap synchronization can be.
> 
>> Note also that at such a low level
>> it would be very difficult if possible to maintain data consistency.
>> Compiler simply does not know what is related to what and will try to cope
>> with the worst case scenario. 
> 
> So, what escapes does the language provide to let you do this? None?

As I said it provides protected objects, which in a real-life concurrent
application will be more efficient, far more safe and maintainable, and yet
portable as compared with your inlined assembler in C. I saw much too much
of embedded C code programmed in the style you seem to favor. The main
problem with such code, is that it's a garbage which simply does not
fulfill the requirements, including the time constraints as well.

BTW, if you are so eager to have assembly code insertions, then Ada does
have them. See ARM 13.8.

>> Protected types in Ada are to describe this
>> sort of semantics. So in the end atomic integers are pretty useless, no
>> matter how efficient they could be implemented. 
> 
> That is one reason *NOT* to learn Ada; it restricts both choices and 
> thinking.

How does Ada restrict choices? As for thinking that's up to you.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/9/2005 9:00:12 AM
CTips <ctips@bestweb.net> writes:

> Actually, I can verify that: if I look at the computer shootout
> http://shootout.alioth.debian.org/great/, I find that gcc C beats gnat Ada
> pretty much across the board; actually, Ada's performance sucks pretty much
> across the board. One of gcc C or Intel C is generally among the top few
> programs, while with a couple of exceptions, Gnat Ada is around the
> middle. In matrix multiply it gets beaten by LISP, Java, and Python!!! (How
> can you get beaten by Python? The mind boggles!)

Let me answer. Because you are giving credits to something that you don't
even understand! This makes me regards your other posts differently now.

Did you really expect GNAT/Ada to be slower than Python, Java and LISP ??? Did
you really or did you use this argument because you had nothing better!

It is always tricky to compare speed of language implementations, but when the
guys doing it are incompetent (or trying to play with the result?), what
should we think!

$ /opt/intel_cc_80/bin/icc -O3 -ipo -static matrix.c -o matrix.icc_run

$ /usr/bin/gcc -pipe -Wall -O3 -fomit-frame-pointer -funroll-loops matrix.c -o matrix.gcc_run

$ /usr/bin/gnatmake -f -u matrix.adb

Why did they used all these fancy optimizations for intel C and GCC/C and
not for GNAT/Ada!!!!!

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
0
pascal27 (183)
3/9/2005 9:08:37 AM
CTips <ctips@bestweb.net> writes:

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

BTW, do you know a C compiler that generates such code ? Why Ada should be
different ? I think there is no way to tell compilers in any language about
somthing like that. I doubt that even the Ada "pragma Atomic" can be used to
generate such code. And as others have posted it is always possible to use
inline assembly. I don't think it is a good idea in the long term but maybe
for very specialized applications...

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
0
pascal27 (183)
3/9/2005 9:12:42 AM
On Wed, 09 Mar 2005 01:18:03 GMT, Jim Rogers wrote:

> This is one of the unsafe idioms in C.
> The fact that you can declare a formal parameter as a pointer and then
> use that parameter as an array is unsafe.

It is also unusable with small and packed data types in which case the
array elements may have no valid machine addresses.

The bottom line: array is an interface.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/9/2005 9:14:45 AM
Martin Dowie wrote:
> CTips wrote:
>> Actually, I can verify that: if I look at the computer shootout
>> http://shootout.alioth.debian.org/great/, I find that gcc C beats
>> gnat Ada pretty much across the board; actually, Ada's performance
>> sucks pretty much across the board. One of gcc C or Intel C is
>> generally among the top few programs, while with a couple of
>> exceptions, Gnat Ada is around the middle. In matrix multiply it
>> gets beaten by LISP, Java, and Python!!! (How can you get beaten by
>> Python? The mind boggles!)
>
> It's very easy when you don't switch on _any_ optimizations! :-)
>
> GNAT is being compiled with the equivalent of "-O0" and GCC C is
> getting "-O3".

AdaCore (who maintain GNAT) have long claimed that equivilent Ada
and C code will produce identical results and that they have such examples.
The problem is in generating /equivilent/ programs to start with. E.g. in
the
matrix multiplication test, the writer of the Ada program has chosen to
result
arrays (by value!) from his functions, where as the C program uses
pointer-to-pointer-to-int. A better idiom for the Ada version would have
been
to use a procedure with an 'out' parameter rather than functions.

Cheers

-- Martin



0
3/9/2005 9:24:47 AM
Martin Dowie wrote:

>> There is no variability concerning ISO C++ features these days.
> 
> 
> You've been lucky then... ;-)
> 
> The last time I tried to port any C++ was between VxWorks and Borland... 
> complete nightmare! And that wasn't so long ago...
> 
> But YMMV.


The first C++ standard has been relatively recent (1998). In the 
contrary Ada's has been probably around since the '80s. :-)


So it makes some sense that only the last couple of years we are getting 
 >98% conformance. Also to not forget the fact that C++ is a large language.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/9/2005 9:43:31 AM
In comp.lang.ada Jerry Coffin <jcoffin@taeus.com> wrote:
> rarely do things like parenthesizing a+(b*c). Even those who argue most
> strongly for explicitness generally agree that this would be silly, at
> least in "obvious" cases like the one above.

No, it is not silly.
It shows professionality, even when not in doubt.
There is no compelling reason to learn those many priority rules
for Ada expressions to achieve secondary bulk knowledge.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)
0
ica2ph (88)
3/9/2005 9:44:53 AM
Pascal Obry wrote:

>>The C++ equivalent:
>>
>>
>>#include <vector>
>>
>>// ...
>>
>>
>>using namespace std;
>>
>>vector<int> Data(10);
>>
>>for(vector<int>::size_type i=0; i<Data.size(); ++i)
>>{
>>     if (Data[i]== 1)
> 
> 
> And no C++ compiler will check that Data[i] is valid. That's the point. If you
> add the check explicitly no C++ compiler will be able to remove it. In the Ada
> case the compiler knows lot more about the program and can decide to remove
> the check if it knows that the index will never be outside the object
> range. This is always the case for:
> 
>    for K in Data'Range loop
>       ... Data(k)...
> 
> Pascal.



I suppose this run-time check is something like the one provided by .NET 
(mentioned in another message of mine).


ISO C++ speaking, one may use vector::at() which provides boundary 
checking, however the aforementioned way is *always* 100% safe as well 
as the following:


#include <vector>

// ...


using namespace std;

vector<int> Data(10);


for(vector<int>::iterator p= Data.begin(); p!=Data.end(); ++p)
{
     if (*p== 1)
     {
         // ...
     }
}



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/9/2005 9:49:02 AM
Ioannis Vranos <ivr@remove.this.grad.com> writes:

> I suppose this run-time check is something like the one provided by .NET
> (mentioned in another message of mine).

Yes. It seems we have some difficulties to understand each others. We were
discussing about wether the checks could be removed automatically by the
compiler if possible. The Ada type systems gives more information to the
compiler, the compiler can then make some more optimizations.

> 
> ISO C++ speaking, one may use vector::at() which provides boundary checking,
> however the aforementioned way is *always* 100% safe as well as the
> following:

*You* know that, but no compiler in the world knows. Static analysis is not
possible in this case.

....

> for(vector<int>::iterator p= Data.begin(); p!=Data.end(); ++p)

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
0
pascal27 (183)
3/9/2005 10:07:10 AM
Ioannis Vranos wrote:
> The first C++ standard has been relatively recent (1998). In the
> contrary Ada's has been probably around since the '80s. :-)

Unless you count Stroustrup 1st edition as a standard (a la K&R) in
which case that's circa 1986! ;-)

Initial Ada draft standard are probably pre-1980 - but we as both are
ISO standards they are simply as old as their last standard, so one is
always going to be 'newer' than the other.

One nice point for Ada is that the ISO standard is available for $0, so
in one sense Ada is cheaper than C++! ;-)


> So it makes some sense that only the last couple of years we are
>  getting >98% conformance. Also to not forget the fact that C++ is a
> large language.

Yet it doesn't include so many things! ;-)



0
3/9/2005 10:11:33 AM
Ioannis Vranos wrote:
> Pascal Obry wrote:

>>> The C++ equivalent:

>>> for(vector<int>::size_type i=0; i<Data.size(); ++i)
>>> {
>>>     if (Data[i]== 1)

>>    for K in Data'Range loop
>>       ... Data(k)...
>> 
> ISO C++ speaking, one may use vector::at() which provides boundary 
> checking, however the aforementioned way is *always* 100% safe

The loop happens to be "safe" but not by the scope and range
of i. The loops aren't equivalent, strictly speaking, because
the loop counter doesn't act as a constant.
Disciplined use of iterators/pointers/indices is not the same
thing as a constant loop index:

  for (vector<int>::size_type i=0; i<Data.size(); ++i) {
    if (Data.at(i)== 1) 
      i = 100;
  }

This text is compiled without complaint as should be, because it _might_
have been the programmer's intention to set the index to some value off
bounds, and he/she _might_ not have wanted a while loop instead of a for
loop.

Some languages provide language facilities to express this difference.
A constant loop index can make some proofs easier.

Georg 
0
bauhaus1 (735)
3/9/2005 11:17:37 AM
Pascal Obry wrote:

> Yes. It seems we have some difficulties to understand each others. We were
> discussing about wether the checks could be removed automatically by the
> compiler if possible. The Ada type systems gives more information to the
> compiler, the compiler can then make some more optimizations.
 >
> *You* know that, but no compiler in the world knows. Static analysis is not
> possible in this case.


OK, I recognise that some (probably all) Ada features provide strong 
guarantees, but it is certain that they can get in the way of the 
programmer.


The index being a constant, can be used in the style array(100-i)= array(i);




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/9/2005 11:32:58 AM
CTips wrote:

> In fact, to get the performance similar to that which 
> can be obtained in C, one would pretty much have to write in the C 
> subset of Ada [i.e. turn off most of the checking, use libraries written 
> in C + asm].

Is there any significant evidence for this other than
special cases for any of the languages discussed?

And why on earth should translators for programming languages
be so dumb as to produce fast code only when the input language
is like "the C subset"?
If a compiler knows about enum values and can use them in the
construction of objects matching hardware, or of arrays of bytes,
or whatever, why should the enum values incur a speed penalty?
Because the compiler checks that there is static matching
at compile time?

> And even there I'd have my doubts - given the additional 
> features that Ada compilers have to deal with, I doubt that they would 
> have focused as much on the optimizations.

Given that the language provides
  pragma Optimize (Time/Space/Off)
I doubt that this general doubt can be justified.

> (How can you get beaten by Python? The mind boggles!)

Easy. You are not actually beaten by Python, but by a highly
optimized C matrix library which is bound to python as an
extension.
If you're interested, for Ada 2005, ISO vector and matrix
subprograms are added to the language standard.


Georg 
0
bauhaus1 (735)
3/9/2005 11:42:42 AM
Georg Bauhaus <bauhaus@futureapps.de> writes:

> Easy. You are not actually beaten by Python, but by a highly
> optimized C matrix library which is bound to python as an
> extension.

That's not the only problem, see my other post. It is very hard to have a good
benchmark but in this very case the data have been falsified!

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
0
pascal27 (183)
3/9/2005 12:06:43 PM
Ada is not all about safety - although that is a factor in its design. 
Some of it is intended to help one organize one's thoughts about the 
programming problem and encourage abstraction. If one thinks in terms of 
zeros and ones instead of higher level abstractions (such as 
enumerations or numerical types associated with the thing they are 
counting, etc.) one might find themselves "fighting the compiler". While 
Ada is perfectly good at getting down to the bits and bytes and in some 
ways better than C++ - (can C++ provide representation clauses on data 
structures to control exactly how bits are packed and ordered?) a lot of 
Ada is aimed at abstracting you away from the zeros and ones, Partly for 
portability across platforms but mostly to encourage you to think about 
the problem differently.

When programming in Ada, you can't think "C++" and try to do exactly 
what you do in C++ only in Ada syntax. The same would be true in the 
other direction. You have to work with the language rather than try to 
fight what it is. Doing so, you'll likely realize the benefits intended 
by the designers of the language.

MDC

Jerry Coffin wrote:
> 
> The first problem is to define what you mean by safety. Bjarne has been
> fairly explicit that most safety features in C++ are intended to
> prevent accidents, not intentional subversion. It's always seemed to me
> that Ada has had a rather muddled idea of the "threat model", so the
> language features have never been entirely aligned to a single intent.
> Some parts appear intended to prevent accidents, but are quite easy to
> subvert when one wishes to do so. Other parts appear to have been
> designed with the intent of preventing even intentional subversion, but
> fail to do so, and simply render some things quite a bit uglier than
> there seems to be good reason for.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================
0
nobody47 (676)
3/9/2005 12:54:49 PM

Ioannis Vranos wrote:
[snip]
> OK, I recognise that some (probably all) Ada features provide strong 
> guarantees, but it is certain that they can get in the way of the 
> programmer.
> 
> 
> The index being a constant, can be used in the style array(100-i)= 
> array(i);
> 

I think this is intended as a question.  If so, the answer is "of 
course".  The fact that i is a constant doesn't stop you using it in 
expressions or assigning it to things, it just stops you changing it.

Peter

0
peter.amey (87)
3/9/2005 1:34:56 PM
>> Reading this thread, it seems to me Ada's focus is on safety rather
>> than efficiency.
>> These safety constraints also tend to limit expressiveness. Not that
>> safety is bad, just that it's not free.

>Actually, a close reading of the thread should have made it clear that
>the additional safety is indeed "free".  Since the majority of Ada's
>checks are compile time they do not impact on  run-time efficiency.
>.
>.
>.
>Can you say what led you to the opposite conclusion?

I wouldn't call it a conclusion, but here goes...

Somewhere in this thread Loduvic writes:

* in Ada, loop variables (a) are constants and (b) do not exist outside
of the loop

This is safer, but limiting.
In C++ may want to declare the variable outside the loop,
break out early and use the loop variable. Let me guess: You can't
break out early in Ada, right?

 * assignment is not an operator; it is an operation which does not
  return a value.  Thus, bugs like "if (something = 0)" cannot exist.

I like this, but it prevents chaining assignments, limiting
expressiveness slightly since chaining says "equalize" as opposed to
"assign, assign, assign".

* case statements (Ada's equivalent of a switch in C++) are required
  to handle all possible cases.  Thus it is impossible to forget one.
  And, of course, there is no "break;" crap in Ada.

Prevents fall through.

* the type system, when used appropriately, makes it possible for the
  compiler to find semantic errors in addition to just syntax errors.
  For example, you can declare that Numers_Of_Apples and
  Numers_Of_Oranges cannot be mixed.  This is not possible with C++'s
  typedef.

This is more in the C++ tradition. The programmer has choice.
In C++ you can extend the type system to achieve this and more
(someone mentioned dimensional analysis), just not with typedef.

* accessibility rules are rather complex, but they are designed to
  minimise the chance of mistakes.  Basically, the scope of a pointer
  type must be included in the scope of the pointed-to type.  This
  makes many mistakes impossible, such as returning a pointer to an
  object which no longer exists.

This looks like a limitation, but I'm not sure I understand correctly.
Example please!

A few other questions:

Do you have nested functions like Pascal have? Can you access local
variables? Can you pass pointers to these functions around?

Can you pass non-type parameters (like the number 3.14) to templates?

Can templates recurse?

Can you program "const correct"? Eg. if you declare a member function
as const the compiler will help you not mutate the object or call any
functions that do. Also, if you pass a parameter as a const reference,
you will not be able to mutate the object the parameter references.

0
3/9/2005 2:07:40 PM
Georg Bauhaus wrote:
> Ioannis Vranos wrote:
>> Pascal Obry wrote:
>>>    for K in Data'Range loop
>>>       ... Data(k)...
>>>
>> ISO C++ speaking, one may use vector::at() which provides boundary 
>> checking, however the aforementioned way is *always* 100% safe
> 
> The loop happens to be "safe" but not by the scope and range
> of i. The loops aren't equivalent, strictly speaking, because
> the loop counter doesn't act as a constant.
> Disciplined use of iterators/pointers/indices is not the same
> thing as a constant loop index:
> 
>  for (vector<int>::size_type i=0; i<Data.size(); ++i) {
>    if (Data.at(i)== 1)      i = 100;
>  }
> 
> This text is compiled without complaint as should be, because it _might_
> have been the programmer's intention to set the index to some value off
> bounds, and he/she _might_ not have wanted a while loop instead of a for
> loop.
> 
> Some languages provide language facilities to express this difference.
> A constant loop index can make some proofs easier.

Perhaps the closest way you can get to this in C++ is

   std::vector<foo_type> Data;
....
   std::for_each(Data.begin(), Data.end(), DoSomething);

where "DoSomething" evaluates to a so-called "function object"
having an "operator()" accepting a (reference to) "foo_type".

Such function objects can be of dedicated classes, or can be constructed
"on the fly" (even it the latter possibility is sometimes a bit awkward
due to the lack of closures / lambda expressions in the language - btw,
does Ada have something like that?).

Falk
0
3/9/2005 2:24:57 PM
Peter Hermann wrote:
> In comp.lang.ada Jerry Coffin <jcoffin@taeus.com> wrote:
> > rarely do things like parenthesizing a+(b*c). Even those who argue
most
> > strongly for explicitness generally agree that this would be silly,
at
> > least in "obvious" cases like the one above.
>
> No, it is not silly.
> It shows professionality, even when not in doubt.
> There is no compelling reason to learn those many priority rules
> for Ada expressions to achieve secondary bulk knowledge.

Gosh, that just doesn't seem very professional to me -- after all, it's
missing the comments to remind the reader that '+' does addition, '*'
does multiplication, parentheses can be used to override the default
precedence, 'a', 'b' and 'c' are variables (and what their types are)
and so on.

To be both professional and efficient, how about if we just paste in
the entire text of the LRM before each statement? That would leave
nobody room for _any_ doubt about what the code means. Oh...well,
you're probably right: to go with, we'd better paste in the entire text
of a real dictionary, and (just in case) a complete set of books
teaching how to read English. The people you're obviously targeting as
reading the code undoubtedly need that -- after all, every word in
"Language Reference Manual" has three whole syllables!

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/9/2005 2:32:25 PM
On Wed, 09 Mar 2005 00:46:08 -0500, CTips <ctips@bestweb.net> wrote:

> Actually, I can verify that: if I look at the computer shootout  
> http://shootout.alioth.debian.org/
> great/, I find that gcc C beats gnat Ada pretty much across the board;  
> actually, Ada's performance sucks pretty much across the board.


I also noticed that the gcc examples were build with -O3, while no  
optimization was used for gnat.
0
falis (298)
3/9/2005 2:47:15 PM
Hans Malherbe wrote:
> * in Ada, loop variables (a) are constants and (b) do not exist
> outside of the loop
>
> This is safer, but limiting.
> In C++ may want to declare the variable outside the loop,
> break out early and use the loop variable. Let me guess: You can't
> break out early in Ada, right?

Of course you can!


> * case statements (Ada's equivalent of a switch in C++) are required
>   to handle all possible cases.  Thus it is impossible to forget one.
>   And, of course, there is no "break;" crap in Ada.
>
> Prevents fall through.

Call a common function/procedure


> A few other questions:
>
> Do you have nested functions like Pascal have?

Yes


> Can you access local variables?

Don't understand what you mean.


> Can you pass pointers to these functions around?

Yes, you can pass 'pointers' to functions around - this is being enhanced
futher in Ada2005, so that at compile time you can guarentee never to
pass a 'NULL' value.


> Can you pass non-type parameters (like the number 3.14) to templates?

Yes, you can pass nearly anything.


> Can you program "const correct"? Eg. if you declare a member function
> as const the compiler will help you not mutate the object or call any
> functions that do. Also, if you pass a parameter as a const reference,
> you will not be able to mutate the object the parameter references.

Yes but Ada does not require the programmer to define what parameter
passing mechanism to use. It instead defines parameter 'modes' that
basically
indicate the 'logical flow' of the data being passed. Parameters of mode
'In'
can only be read.

Cheers

-- Martin




0
3/9/2005 2:52:44 PM
"Hans Malherbe" <hans.malherbe@gmail.com> writes:

> This looks like a limitation, but I'm not sure I understand correctly.

Agreed. All this is somehow limiting. That's the trade off for the
safetly. But when you are used to it, this limitations are not so bad, and
quickly you can't live without them.

> Example please!
> 
> A few other questions:
> 
> Do you have nested functions like Pascal have?

Yes.

> Can you access local variables?

Of course yes. Otherwise what would local variables will be useful for?

> Can you pass pointers to these functions around?

Around no! The rules are strict here.

This case is ok, P1 same level as PA.

<<
procedure Demo is

   type PA is access procedure;

   procedure P (Proc : in PA) is
   begin
      null;
   end P;

   procedure P1 is
   begin
      null;
   end P1;

   procedure P2 is
   begin
      P (P1'Access);
   end P2;

begin
   null;
end Demo;
>>

This is not ok, P3 deeper than PA.

<<
procedure Demo is

   type PA is access procedure;

   procedure P (Proc : in PA) is
   begin
      null;
   end P;

   procedure P1 is
   begin
      null;
   end P1;

   procedure P2 is
      procedure P3 is
      begin
         null;
      end P3;
   begin
      P (P3'Access);
   end P2;

begin
   null;
end Demo;
>>

Here is what GNAT reports for example:

   $ gnatmake demo
   gcc -c demo.adb
   demo.adb:22:10: subprogram must not be deeper than access type
   gnatmake: "demo.adb" compilation error

No dangling pointers.

> Can you pass non-type parameters (like the number 3.14) to templates?

Yes. We can pass types, packages, procedure, functions, variables and
constants.

> Can templates recurse?

Yes.

> Can you program "const correct"? Eg. if you declare a member function
> as const the compiler will help you not mutate the object or call any
> functions that do. Also, if you pass a parameter as a const reference,
> you will not be able to mutate the object the parameter references.

Not sure to understand everything. But yes, if you have:

   Value : constant String := "whatever";

It will never be able to mutate Value.

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
0
pascal27 (183)
3/9/2005 2:55:38 PM
Falk Tannh=C3=A4user wrote:

> Such function objects can be of dedicated classes, or can be constructe=
d
> "on the fly" (even it the latter possibility is sometimes a bit awkward=

> due to the lack of closures / lambda expressions in the language - btw,=

> does Ada have something like that?).

Ada 2005 adds downward closures. They have been available in GNAT/GCC
for a number of years now.
For pure Ada 95 there is a workaround using dispatching.

Is a function object similar to a downward closure?

Georg=20
0
bauhaus1 (735)
3/9/2005 2:56:31 PM
Martin Dowie wrote:
> Hans Malherbe wrote:

>>Can you pass pointers to these functions around?
> 
> 
> Yes, you can pass 'pointers' to functions around - this is being enhanced
> futher in Ada2005, so that at compile time you can guarentee never to
> pass a 'NULL' value.

This is something I don't fully understand. IFAIK,

procedure Proc (Blah : access Some_Type);

access parameters raise an excepcion if null. So I don't get what adds 
to the language the

Blah : not null access ...

construct.
0
devnull2904 (402)
3/9/2005 3:20:14 PM
* Alex R. Mosteo wrote:
> This is something I don't fully understand. IFAIK,
>
> procedure Proc (Blah : access Some_Type);
>
> access parameters raise an excepcion if null. So I don't get what adds 
> to the language the
>
> Blah : not null access ...
>
> construct.

procedure Proc(Blah : in out Some_Type);
0
lutz8272 (211)
3/9/2005 3:20:58 PM
On 09 Mar 2005 15:55:38 +0100, Pascal Obry <pascal@obry.org> wrote:

>> Can you program "const correct"? Eg. if you declare a member function
>> as const the compiler will help you not mutate the object or call any
>> functions that do. Also, if you pass a parameter as a const reference,
>> you will not be able to mutate the object the parameter references.


Ada supports the first functionality - not modifying the parameter itself  
(since it is of mode "in" or "access").  This is for all parameters to  
functions (as distinct from procedures).

Ada does not support the idea of a const reference, though: if the  
function parameter is of an access type, or mode "access", the reference  
to the object cannot be changed, but the contents of the referenced object  
can be.
0
falis (298)
3/9/2005 3:23:30 PM
Hans Malherbe wrote:
> Can you program "const correct"? Eg. if you declare a member function
> as const the compiler will help you not mutate the object or call any
> functions that do. Also, if you pass a parameter as a const reference,
> you will not be able to mutate the object the parameter references.

well, this one seems problematic to non-C++ users, and especially to 
Ada users, so i will explain a bit further:

let's have a C++ class:

class T
{
public:
     void dummy() const;
     void dummy2();

protected:
     int field;
};

T myObject;
myObject.dummy(); // here, myObject.field will not change
                   // because dummy is const
myObject.dummy2(); // here, myObject.field may change...

in C++, dummy() should not be able to call dummy2() since dummy2() is 
not const, so it may change the state of the object, which is not 
allowed because dummy() is const.


let's see it the Ada way: we dont use the dotted notation. instead we 
explicitly pass the oject as a parameter, specifying a mode which 
tells what we want to do with the object:

type T is tagged record
     Field : Integer;
end record;

procedure Dummy( This : in T );
procedure Dummy_2( This : in out T );

My_Object : T;
Dummy( My_Object );
Dummy2( My_Object );

since the "This" parameter in "Dummy" is declared with mode "in", we 
cant assign a value to any field of "This": "This" will then be 
constant. also, "Dummy" cannot call "Dummy_2" passing it its "This" 
parameter: "Dummy_2" requires to be able to assign to "This", but 
"This" is constant in "Dummy".

so the answer is : yes, we can enforce constness in Ada. we can even 
express more since we have many parameter passing modes available:
- with in mode, we cant assign to the parameter
- with out mode, we should only assign a value to the parameter (not 
rely on its initial value)(this one is missing in C++)
- with in out mode, we may read and assign the parameter
- with access mode, well, this is a reference passing mode (i find it 
hard to explain the difference with the other modes, someone else may 
take up on this one)

-- 
rien
0
3/9/2005 3:23:46 PM
Hans Malherbe wrote:
 
> * in Ada, loop variables (a) are constants and (b) do not exist outside
> of the loop
> 
> This is safer, but limiting.
> In C++ may want to declare the variable outside the loop,
> break out early and use the loop variable. Let me guess: You can't
> break out early in Ada, right?

No, there is all kind of loop control,

     loop_statement ::=
             [loop_statement_identifier:]
                [iteration_scheme] loop
                   sequence_of_statements
                end loop [loop_identifier];

Inside the loop (sequence_of_statements) you can break out
using for example

     exit [loop_name] [when condition];

(And you can start a new nested block inside a loop with a package in it
with a task type in it etc. if that makes sense in a program.)

> * case statements (Ada's equivalent of a switch in C++) are required
>   to handle all possible cases.  Thus it is impossible to forget one.
>   And, of course, there is no "break;" crap in Ada.
> 
> Prevents fall through.

Yes, no fall through in "case ... end case", which is why case and
switch are not exactly equivalent. There is nice grouping of cases.
You can write fall through switches though, when necessary,
or desirable, only they won't look like a case distinction.


> A few other questions:
> 
> Do you have nested functions like Pascal have? Can you access local
> variables? Can you pass pointers to these functions around?

Yes. There are restrictions on pointers to locally allocated objects used
in an outer scope. The restricted items include local functions,
e.g. there are no full upward closures.


> Can you pass non-type parameters (like the number 3.14) to templates?

Yes, formal template parameters include floating point types and values.
 
> Can templates recurse?

No. (Though you can mix recursive subprograms, nesting, and template
instantiation.)

I think that it is *this* fact ("recursive templates"), the "programmability
of a C++ compiler via templates", that allows a C++ programmer to do many
things that otherwise aren't available in the language.
For example, the
  Can_Copy, Can_This, Can_That
idiom is built into Ada, Eiffel, etc. via constraint genericity,
and so doesn't require a "template computing compiler" for constraining.
OTOH, this is a limitation, even though there is a richt set of
"parameter things" in Ada, including types, interface types, values,
subprograms, and packages (templates parameterized by other templates).


> Can you program "const correct"? Eg. if you declare a member function
> as const the compiler will help you not mutate the object or call any
> functions that do.

The const-mechanics are slightly different.
In order to preclude modifications of the object, use parameter modes,
see below.
The analog of the this pointer is passed to a primitive operation,
i.e. a member function. Ada 2005 adds dotted notation in addition to passing
a this-like value. Now,
if a subprogram's parameter modes disallow modifying the "this parameter",
you can't modify the object's state in the subprogram body
(without trickery that is).

> Also, if you pass a parameter as a const reference,
> you will not be able to mutate the object the parameter references.

The passing modes are, in, in out, and out.
They are logical and indeed separate from direct or indirect access to
the values at the processor instruction level. The compiler usually
chooses what it thinks is best when the language leaves this open.

Georg 
0
bauhaus1 (735)
3/9/2005 3:33:11 PM
Martin Dowie wrote:
> CTips wrote:
> 
>> Actually, I can verify that: if I look at the computer shootout 
>> http://shootout.alioth.debian.org/great/, I find that gcc C beats gnat 
>> Ada pretty much across the board; actually, Ada's performance sucks 
>> pretty much across the board. One of gcc C or Intel C is generally 
>> among the top few programs, while with a couple of exceptions, Gnat 
>> Ada is around the middle. In matrix multiply it gets beaten by LISP, 
>> Java, and Python!!! (How can you get beaten by Python? The mind boggles!)
> 
> 
> It's very easy when you don't switch on _any_ optimizations! :-)
> 
> GNAT is being compiled with the equivalent of "-O0" and GCC C is getting 
> "-O3".
> 
> NB: Ada2005 will be faster still now that copy-on-function-return isn't 
> going to be necessary.
> 
> Cheers
> 
> -- Martin
Any chance you could post the numbers with -O3 equivalent on some 
compiler(s)? All the codes are available on that site.

Thanks!
0
ctips (287)
3/9/2005 3:39:32 PM
Georg Bauhaus <bauhaus@futureapps.de> writes:

> > Can templates recurse?
> 
> No. (Though you can mix recursive subprograms, nesting, and template
> instantiation.)

Hum, since you answered "no" and I answered "yes" it seems there is something
about "templates recurse" that I did not understand. In short what is a
recursive template in C++ ?

Thanks,
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
0
pascal27 (183)
3/9/2005 3:39:45 PM
Ed Falis wrote:
> On 09 Mar 2005 15:55:38 +0100, Pascal Obry <pascal@obry.org> wrote:
> 
>>> Can you program "const correct"? 

> Ada does not support the idea of a const reference, though: if the  
> function parameter is of an access type, or mode "access", the 
> reference  to the object cannot be changed, but the contents of the 
> referenced object  can be.

Although with "access constant" types, a similar idea is supported:

   type R is record
      v: Natural;
   end record;

   type CP is access constant R;

   procedure proc(t: CP) is
   begin
      t.v := 4;
   end proc;

$ compiling...

    23.       t.v := 4;
              |
        >>> left hand side of assignment must be a variable

Georg 
0
bauhaus1 (735)
3/9/2005 3:55:38 PM
Hans Malherbe wrote:
> Somewhere in this thread Loduvic writes:
>
> * in Ada, loop variables (a) are constants and (b) do not exist
outside
> of the loop
>
> This is safer, but limiting.
> In C++ may want to declare the variable outside the loop,
> break out early and use the loop variable. Let me guess: You can't
> break out early in Ada, right?

I see your problem, and I think I see where you have been
misled. Ada provides three looping forms. Only one, the "for"
loop, uses an automatically created local loop variable.

Ada does allow you to break out of a loop early. In fact,
one of the looping forms normally depends on that ability.

The looping forms in Ada are:

Simple loop ->

   loop
      some actions;
   end loop;

While loop ->

   while condition loop
      some actions;
   end loop;

For loop ->

   for I in some_range loop
      some actions;
   end loop;

The simple loop will always be an infinite loop unless
you break out early. The Ada reserved word used to
break out of a loop is "exit". In Ada "exit" does not
exit the program, only the enlcosing loop.

The Ada exit command is commonly used in response to
some condition:

   if condition then
      exit;
   end if;

   This usage is so common that Ada provides a short-hand
   syntax to achieve the same ends:

   exit when condition;

The exit command can be used in any of the loop forms.

The simple loop is often used to provide a loop with the
conditional test in the middle or at the bottom of the loop.
The conditional test is the condition controlling the exit
command.

The while loop works just like you would expect in many
other languages.

The for loop is somewhat like a foreach loop in C and C++.
It iterates through a discrete range of values. The loop
control variable in the for loop is local to the loop
and is read-only within the loop body.

You should probably choose either the simple loop or the
while loop if you want to use the value of a loop control
variable outside the body of the loop. The only way to use
that value outside the body of a "for" loop is to copy the
value to a variable having a scope outside the loop.

>
>  * assignment is not an operator; it is an operation which does not
>   return a value.  Thus, bugs like "if (something = 0)" cannot exist.
>
> I like this, but it prevents chaining assignments, limiting
> expressiveness slightly since chaining says "equalize" as opposed to
> "assign, assign, assign".

You have that correct.

>
> * case statements (Ada's equivalent of a switch in C++) are required
>   to handle all possible cases.  Thus it is impossible to forget one.
>   And, of course, there is no "break;" crap in Ada.
>
> Prevents fall through.

The Ada case statement is a little more useful than might appear
from the description above.

The general form of the Ada case statement is:

   case discrete_value is
      when value_list =>
         ... some set of statements ...
      when others =>
         ... some set of statements ...
   end case;

The value_list can be in the form of:
   * a single value (i.e. 255)

   * a range of values (i.e. 1..5)

   * a discontinuous set of values (i.e. 1 | 3 | 5 | 17)

The Ada case statement requires that there be a when clause
for every possible value of the type being tested. This works
because Ada also allows you to define your own discrete types
and subtypes, including their valid value ranges.

   subtype Menu_Options is character range 'a'..'c';

   option : Menu_Options;

   case option in
      when 'a' =>
         do_action_a;
      when 'b' =>
         do_action_b;
      when 'c' =>
         do_action_c;
   end case;

If, in the example above, I left out the "when 'c' =>"
part the compiler will issue an error.

The "when others =>" option is equivalent to the "default"
option in C and C++.

>
> * the type system, when used appropriately, makes it possible for the
>   compiler to find semantic errors in addition to just syntax errors.
>   For example, you can declare that Numers_Of_Apples and
>   Numers_Of_Oranges cannot be mixed.  This is not possible with C++'s
>   typedef.
>
> This is more in the C++ tradition. The programmer has choice.
> In C++ you can extend the type system to achieve this and more
> (someone mentioned dimensional analysis), just not with typedef.
>

True. C++ provides strong type separation through the use of
classes.

> * accessibility rules are rather complex, but they are designed to
>   minimise the chance of mistakes.  Basically, the scope of a pointer
>   type must be included in the scope of the pointed-to type.  This
>   makes many mistakes impossible, such as returning a pointer to an
>   object which no longer exists.
>
> This looks like a limitation, but I'm not sure I understand
correctly.
> Example please!

Ada does not provide any generic pointer type equivalent to void*.
You must define each pointer type you want to use. Objects of that
pointer type must be placed within the scope of the definition of
their type. Outside that scope the type does not exist.

This rule does not prevent all attempts to deallocate a null pointer.
Null pointers can be found in any scope and are not only found
when a type goes out of scope.

>
> A few other questions:
>
> Do you have nested functions like Pascal have? Can you access local
> variables? Can you pass pointers to these functions around?

Yes, Ada does allow nested functions, procedures, tasks, and
even packages. A function can access any local visible local
variable. Variables declared in an enclosing scope are visible
within the nested function.

You can create pointers to functions. This is yet another type
of pointer you can create. Pointers to nested functions are
only valid within the enclosing scope of the nested function.

>
> Can you pass non-type parameters (like the number 3.14) to templates?

Yes, Ada generics allow values to be passed, including floating
point values. The generic formal parameter for the value specifies
what type the value can be.

>
> Can templates recurse?
>

Once a generic is instantiated it behaves like any other
compilation unit. Recursion is allowed within generic
subprograms.

> Can you program "const correct"? Eg. if you declare a member function
> as const the compiler will help you not mutate the object or call any
> functions that do. Also, if you pass a parameter as a const
reference,
> you will not be able to mutate the object the parameter references.

Ada syntax for defining what most other languages call classes is a
bit unique. Ada does not use the term "class" like other languages.
The Ada package is used for encapsulation and namespace. A package
specification contains an implicit public part and an explicit
private part. A package may contain more than one type definiton.

Extensible types in Ada are called tagged types. They were introduced
in Ada 95 as an extension of the Ada 83 record syntax.

Ada does not use the dot notation for calling member methods for
tagged types.

For example, if you define a dog class in C++ or Java, and provide
a feed() member function, you call the function as:

  dog d;

  d.feed();

In Ada you can create a dog tagged type, and in the same package
specification you can define a procedure to feed the dog.
The procedure specification would look like:

   procedure feed(The_Dog : out dog);

The procedure would be called as:

   d : dog;

   feed(d);

or, using named notation:

   feed(The_Dog => d);

The procedure specification is the key to "const correctness".
Procedure parameters have a passing mode. Three options are
possible for the passing mode:

  IN  --- Parameter is treated as a const (read-only) value
          within the procedure or function. Function parameters
          can only be IN mode.
  OUT --- Parameter is both readable and writeable within the
          procedure, but there is not guarantee of an intial
          value for the parameter
  IN OUT - Parameter is both readable and writeable within
           the procedure. Parameter retains the value passed
           in from the actual parameter.

Jim Rogers

0
3/9/2005 3:56:08 PM
Pascal Obry wrote:

> CTips <ctips@bestweb.net> writes:
> 
> 
>>Actually, I can verify that: if I look at the computer shootout
>>http://shootout.alioth.debian.org/great/, I find that gcc C beats gnat Ada
>>pretty much across the board; actually, Ada's performance sucks pretty much
>>across the board. One of gcc C or Intel C is generally among the top few
>>programs, while with a couple of exceptions, Gnat Ada is around the
>>middle. In matrix multiply it gets beaten by LISP, Java, and Python!!! (How
>>can you get beaten by Python? The mind boggles!)
> 
> 
> Let me answer. Because you are giving credits to something that you don't
> even understand! This makes me regards your other posts differently now.
> 
> Did you really expect GNAT/Ada to be slower than Python, Java and LISP ??? Did
> you really or did you use this argument because you had nothing better!
> 
> It is always tricky to compare speed of language implementations, but when the
> guys doing it are incompetent (or trying to play with the result?), what
> should we think!
> 
> $ /opt/intel_cc_80/bin/icc -O3 -ipo -static matrix.c -o matrix.icc_run
> 
> $ /usr/bin/gcc -pipe -Wall -O3 -fomit-frame-pointer -funroll-loops matrix.c -o matrix.gcc_run
> 
> $ /usr/bin/gnatmake -f -u matrix.adb
> 
> Why did they used all these fancy optimizations for intel C and GCC/C and
> not for GNAT/Ada!!!!!

Cause the people who submitted it cared enough (in C) to actually submit 
a decent of options. The maintainer of the site has little to do with 
options selection.

> Pascal.
> 
Nope, I didn't look at the compile parameters. My bad. I just assumed 
that whoever submitted the examples would have tried to make themselves 
look as good as possible. That, of course, is a result of my C mindset - 
I can't think of anyone submitting code to a performance site without 
first making sure I was getting as much performance out of it. It 
appears that the Ada mindset is different. Or is it because GNAT is 
known to produce buggy code at higher optimization levels?

BTW: any chance someone might be tempted into actually submitting a run 
with appropriate optimization parameters?
0
ctips (287)
3/9/2005 4:09:39 PM
CTips <ctips@bestweb.net> writes:

> I can't think of anyone submitting code to a performance site without first
> making sure I was getting as much performance out of it. It appears that the
> Ada mindset is different. Or is it because GNAT is known to produce buggy
> code at higher optimization levels?

You amused me :)

> BTW: any chance someone might be tempted into actually submitting a run with
> appropriate optimization parameters?

With a code far closer (not yet identical as in C the array is allocated) to
the C equivalent:

<<
with Text_IO, Ada.Command_Line;

procedure Matrix is

   use Ada;

   Size : constant Natural := 30;

   type Int is new Integer;
   type Int_Matrix is array (1 .. Size, 1 .. Size) of Int;

   procedure Mk_Matrix (NRows, NCols : Natural; M : out Int_Matrix) is
      Count : Int := 1;
   begin
      for I in M'Range (1) loop
         for J in M'Range (2) loop
            M (I, J) := Count;
            Count := Count + 1;
         end loop;
      end loop;
   end Mk_Matrix;

   procedure M_Mult (M1, M2 : Int_Matrix; MM : in out Int_Matrix) is
      Sum : Int;
   begin
      for I in M1'Range (1) loop
         for J in M2'Range (2) loop
            Sum := 0;
            for KK in M1'Range (2) loop
               Sum := Sum + M1 (I, KK) * M2 (KK, J);
            end loop;
            MM (I, J) := Sum;
         end loop;
      end loop;
   end M_Mult;

   M1, M2, MM : Int_Matrix;
   N          : Positive := 1;

begin
   begin
      N := Positive'Value (Ada.Command_Line.Argument (1));
   exception
      when Constraint_Error => null;
   end;

   Mk_Matrix (Size, Size, M1);
   Mk_Matrix (Size, Size, M2);

   for Iter in 1 .. N loop
      M_Mult (M1, M2, MM);
   end loop;

   Text_IO.Put_Line
     (Int'Image (MM (1, 1)) & Int'Image (MM (3, 4)) &
        Int'Image (MM (4, 3)) & Int'Image (MM (5, 5)));
end Matrix;
>>

compiled for the C code using:

$ gcc -o c_matrix -O2 matrix.c

compiled for the Ada code using:

$ gnatmake -f -O2 -gnatp matrix.adb -bargs -static

(-bargs -static to use the static runtime, this is what C does in this case).

I get:

$ time matrix 100
 270165 1061760 1453695 1856025

real    0m0.033s
user    0m0.010s
sys     0m0.020s

$ time c_matrix 100
270165 1061760 1453695 1856025

real    0m0.033s
user    0m0.010s
sys     0m0.010s

I see identical results here, this is on a Windows box using GCC 3.4.4
and GNAT 5.03a. Of course this is no surprise since GNAT share the very same
backend! Yet this means just nothing. A good benchmark is done on real
applications. At least I hope it will dismiss the idea that Ada is inherently
slow. There is nothing in Ada that is designed to be slow, a good compiler for
Ada as a good compiler for any language should generate good code, that's all.

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
0
pascal27 (183)
3/9/2005 4:33:38 PM
CTips <ctips@bestweb.net> writes:

> Any chance you could post the numbers with -O3 equivalent on some
> compiler(s)? All the codes are available on that site.

I forgot to say that I have also identical results for 10_000 loops instead
of 100 (read I did not choose 100 because it was showing what I wanted to :)
Just in case...

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
0
pascal27 (183)
3/9/2005 4:37:05 PM
On 9 Mar 2005, at 15:39, Pascal Obry wrote:

> Georg Bauhaus <bauhaus@futureapps.de> writes:
>
>>> Can templates recurse?
>>
>> No. (Though you can mix recursive subprograms, nesting, and template
>> instantiation.)
>
> Hum, since you answered "no" and I answered "yes" it seems there is 
> something
> about "templates recurse" that I did not understand.

Same here.  Maybe Georg was thinking of the limitation that you cannot 
instantiate a generic unit inside itself.  This is so probably because 
it was deemed impossible to write a terminal condition.  But I'm not 
sure about that.  And I suspect that with the new bag of tricks of Ada 
2005 notably interfaces you can do it.  But yes, let's hear it from the 
C++ experts.  Can you create an instance of a template inside itself?

0
amado.alves (488)
3/9/2005 4:43:46 PM
Pascal Obry wrote:
> Why did they used all these fancy optimizations for intel C and GCC/C and
> not for GNAT/Ada!!!!!

btw, i looked at the specifications for the "threads" benchmark.

for me, it should output 2999 for N=3000. for the spec, it should 
output 3000. (3000 thread, the first gets 0 as a message and sends 1 
to the second thread, the seconds gets 1 and sends 2 to the third 
thread... the last thread just output the value it gets)

or i don't understand fully the spec, or the spec is wrong. in case 
the spec is wrong, it means that all implementations of this benchmark 
are wrong... so, those benchmarks become a little bit more dubious...

can anybody confirm this ?

-- 
rien
0
3/9/2005 4:48:15 PM
On Wed, 09 Mar 2005 16:55:38 +0100, Georg Bauhaus <bauhaus@futureapps.de>  
wrote:

> Although with "access constant" types, a similar idea is supported:


Right, I remembered that construct after the fact.
0
falis (298)
3/9/2005 4:59:03 PM
Pascal Obry wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> 
>>>Can templates recurse?
>>
>>No. (Though you can mix recursive subprograms, nesting, and template
>>instantiation.)
> 
> 
> Hum, since you answered "no" and I answered "yes" it seems there is something
> about "templates recurse" that I did not understand. In short what is a
> recursive template in C++ ?

In Ada, you cannot instantiate a generic within itself (as Marius
has said elsewhere). In C++, you can, and you should provide
termination lest the instantiation loop exhausts something (at
link time, I believe):

template<typename T> 
struct G {
  G<G> r;
};

Georg 
0
bauhaus1 (735)
3/9/2005 5:00:07 PM
> CTips wrote:
> > Actually, I can verify that: if I look at the computer shootout 
> > http://shootout.alioth.debian.org/great/, I find that gcc C beats gnat 
> > Ada pretty much across the board; actually, Ada's performance sucks 
> > pretty much across the board. One of gcc C or Intel C is generally among 
> > the top few programs, while with a couple of exceptions, Gnat Ada is 
> > around the middle. In matrix multiply it gets beaten by LISP, Java, and 
> > Python!!! (How can you get beaten by Python? The mind boggles!)

Martin Dowie:

> It's very easy when you don't switch on _any_ optimizations! :-)
> 
> GNAT is being compiled with the equivalent of "-O0" and GCC C is getting 
> "-O3".

Where are the GNAT options stored indeed (I scanned the CVS tree in vain) ?
The correct GNAT options for a shootout should be at least
-O2
-funroll-loops
-gnatp (suppress all checks)
-gnatn (cross-unit inlining for pragma Inline)
______________________________________________________________
Gautier     --     http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!
0
3/9/2005 5:01:35 PM
In article <1110377260.350158.58730@z14g2000cwz.googlegroups.com>, "Hans Malherbe" <hans.malherbe@gmail.com> writes:

> Somewhere in this thread Loduvic writes:
> 
> * in Ada, loop variables (a) are constants and (b) do not exist outside
> of the loop
> 
> This is safer, but limiting.
> In C++ may want to declare the variable outside the loop,
> break out early and use the loop variable. Let me guess: You can't
> break out early in Ada, right?

You can, but if I want to export the loop variable I use something like:

    for each_fluvark in fluvark_array'range loop
        ...
        if some_value = 42
        then
          last_value_of_fluvark_index := fluvark_index;
          exit;
        end if;
        ...
    end loop;

making quite explicit the difference between the changing value of the
index and the final value at which we exited the loop.

> A few other questions:
> 
> Do you have nested functions like Pascal have?

Even Bliss has nested functions.  What Ada has that Pascal has in addition
to nested functions is uplevel addressing, allowing an inner function to
access data declared in outer scopes.
0
Kilgallen (2738)
3/9/2005 5:03:14 PM
Pascal Obry wrote:
> Hum, since you answered "no" and I answered "yes" it seems there is something
> about "templates recurse" that I did not understand. In short what is a
> recursive template in C++ ?

One example in C++:

   template<unsigned N> struct factorial
   {
     static unsigned const value = N * factorial<N-1>::value;
   };

   // Partial template specialisation to terminate the recursion:
   template<> struct factorial<0>
   {
     static unsigned const value = 1;
   };

With this, 'factorial<7>::value' will be a compile time constant equal to 5040.

Another example:

   template<typename T> struct pointer_info
   {
     typedef T base_type;
     static unsigned const indir_level = 0;
   };

   // Partial template specialisation for types that are pointers:
   template<typename T> struct pointer_info<T*>
   {
     typedef typename pointer_info<T>::base_type base_type;
     static unsigned const indir_level = pointer_info<T>::indir_level + 1;
   };

With this, suppose that you have
   typedef int***** foo_t;
Then 'pointer_info<foo_t>::base_type' is a typedef (alias) for 'int' and
'pointer_info<foo_t>::indir_level' is a compile time constant equal to 5.

Falk
0
3/9/2005 5:31:52 PM
Hyman Rosen <hyrosen@mail.com> writes:

> Keeping in mind that all template instantiations in C++
> are static and done at compile time, the answer is yes.
> Here's a little example.

Hard to understand. This looks like a template which instanciate other
templates. No recusive definitions here.

>      #include <typeinfo>
>      #include <iostream>
>      #include <ostream>
> 
>      struct NIL { };

   type Nil is null record;

>      template <typename HEAD, typename TAIL> struct CONS { };

   generic
      type HEAD is private;
      type TAIL is private;
   package CONS_PKG is

      type CONS is null record;

   end CONS_PKG;


>      template <typename T> struct x;

   generic
      type T is private;
   package X_PKG is

      type X is null record;

   end X_PKG;

>      template <> struct x<NIL> { static void f() { } };

   generic
   package X_NIL_PKG is 
      type X_NIL is new X_PKG (Nil);

      procedure f;

   end X_NIL_PKG;

>      template <typename HEAD, typename TAIL> struct x< CONS<HEAD,TAIL> >
>      {
>          static void f()
>          {
>              std::cout << typeid(HEAD).name() << "\n";
>              x<TAIL>::f();
>          }
>      };

   generic
      type HEAD is private;
      type TAIL is private;
   package X_CON_PKG is 

      package CONS_HT is new CONS_PKG (HEAD, TAIL);

      package X_CONS is new X_PKG (CONS_HT.CONS);

      procedure F;

   end X_NIL_PKG;


>      int main()
>      {
>          x< CONS<int, CONS<int, CONS<double, CONS<char, NIL> > > > >::f();
>      }

My C++ is a bit rusty, let me know if I got something wrong...

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
0
pascal27 (183)
3/9/2005 5:40:47 PM
Martin Dowie wrote:

[ ... ]

> Hey! I did add a smiley! I just thought it was an opinion from a
> reputable source that tied in with the post. :-) :-)

Sorry -- I rarely add an explicit smiley. Regardless of how my messages
might read, I rarely take much of it _terribly_ seriously.

[ ... ]

> Would I be allowed to use embedded SQL in the Ada code (GNADE)? Or a
> binding to Postgres or MySQL (APQ) or similar (ODBC)?

For the question at hand, I'd postulate that an embedded SQL
implementation simply wouldn't do the job. Binding to MySQL or using
ODBC would undoubtedly work, but using MySQL, Oracle, MS SQL Server,
etc., puts us back in the situation where we basically just have SQL
talking to a server written in C.

Now, I have no problem with that at all -- but it certainly doesn't
seem to be in keeping with what Richard was advocating.

Then again, your headers indicate that you post with Mozilla
Thunderbird running on Windows, connecting through BT Internet. What
percentage of the millions of lines of code used to write and transmit
your message do you suppose was written in Ada, and what percentage in
C and C++? :-)

Ada advocate: "The world WOULD be better if you used Ada."
C++ advocate: "The world IS better because of the cool code I wrote."

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/9/2005 5:41:37 PM
Falk Tannh�user <falk.tannhauser@crf.canon.fr> writes:

> One example in C++:
> 
>    template<unsigned N> struct factorial
>    {
>      static unsigned const value = N * factorial<N-1>::value;
>    };
> 
>    // Partial template specialisation to terminate the recursion:
>    template<> struct factorial<0>
>    {
>      static unsigned const value = 1;
>    };
> 
> With this, 'factorial<7>::value' will be a compile time constant equal to
> 5040.

Ok, thanks. This is definitly a recursive definition. AFAIK there is no such
thing in Ada.

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
0
pascal27 (183)
3/9/2005 5:43:47 PM
Jerry Coffin wrote:
> Ada advocate: "The world WOULD be better if you used Ada."
> C++ advocate: "The world IS better because of the cool code I wrote."

about Air Traffic Control:

C++ Advocate: "The world WOULDN'T be safer if they used C++"
Ada Advocate: "The world IS safer, because of the cool system we wrote"


about buffer overflows:

Ada advocate: "Networks WOULD be more secure if you used Ada"
C++ advocate: "Networks WOULD be more secure if we used Ada"


-- 
rien

0
3/9/2005 5:53:12 PM
Jerry Coffin wrote:
> Martin Dowie wrote:
>>Hey! I did add a smiley! I just thought it was an opinion from a
>>reputable source that tied in with the post. :-) :-)
> 
> 
> Sorry -- I rarely add an explicit smiley. Regardless of how my messages
> might read, I rarely take much of it _terribly_ seriously.

I'll bare that in mind...



....did you see my implicit smiley!



> For the question at hand, I'd postulate that an embedded SQL
> implementation simply wouldn't do the job. Binding to MySQL or using
> ODBC would undoubtedly work, but using MySQL, Oracle, MS SQL Server,
> etc., puts us back in the situation where we basically just have SQL
> talking to a server written in C.

Not necessarily, esp in the fields that Richard comes across day-in-day 
out. I did have a link at work that was for a web page for a Relational 
Database written in Ada that Lockhead(?) had developed.


> Then again, your headers indicate that you post with Mozilla
> Thunderbird running on Windows, connecting through BT Internet. What
> percentage of the millions of lines of code used to write and transmit
> your message do you suppose was written in Ada, and what percentage in
> C and C++? :-)

I have no idea - quite possibly 0% but there are plenty of Ada apps 
around - just not mass public market ones (that I know of). On the other 
had there is a chance the packets that delivered this email went through 
some Ada...

http://www.linuxjournal.com/article/3675


> Ada advocate: "The world WOULD be better if you used Ada."
> C++ advocate: "The world IS better because of the cool code I wrote."

What on earth would the C advocate say!! ;-)

Cheers

-- Martin
0
3/9/2005 6:04:25 PM
Jerry Coffin wrote:
> Martin Dowie wrote:
>>Hey! I did add a smiley! I just thought it was an opinion from a
>>reputable source that tied in with the post. :-) :-)
> 
> 
> Sorry -- I rarely add an explicit smiley. Regardless of how my messages
> might read, I rarely take much of it _terribly_ seriously.

I'll bare that in mind...



....did you see my implicit smiley!



> For the question at hand, I'd postulate that an embedded SQL
> implementation simply wouldn't do the job. Binding to MySQL or using
> ODBC would undoubtedly work, but using MySQL, Oracle, MS SQL Server,
> etc., puts us back in the situation where we basically just have SQL
> talking to a server written in C.

Not necessarily, esp in the fields that Richard comes across day-in-day 
out. I did have a link at work that was for a web page for a Relational 
Database written in Ada that Lockheed(?) had developed.


> Then again, your headers indicate that you post with Mozilla
> Thunderbird running on Windows, connecting through BT Internet. What
> percentage of the millions of lines of code used to write and transmit
> your message do you suppose was written in Ada, and what percentage in
> C and C++? :-)

I have no idea - quite possibly 0% but there are plenty of Ada apps 
around - just not mass public market ones (that I know of). On the other 
had there is a chance the packets that delivered this email went through 
some Ada...

http://www.linuxjournal.com/article/3675


> Ada advocate: "The world WOULD be better if you used Ada."
> C++ advocate: "The world IS better because of the cool code I wrote."

What on earth would the C advocate say!! ;-)

Cheers

-- Martin
0
3/9/2005 6:04:45 PM
On Wed, 9 Mar 2005 18:04:45 +0000 (UTC), Martin Dowie wrote:

> Jerry Coffin wrote:

>> Ada advocate: "The world WOULD be better if you used Ada."
>> C++ advocate: "The world IS better because of the cool code I wrote."
> 
> What on earth would the C advocate say!! ;-)

C advocate: "The world WILL be better with the next cool patch for the cool
code I'm keep on writing."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/9/2005 6:41:50 PM
"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:d0ndrs$4cs$1@titan.btinternet.com...

> What on earth would the C advocate say!! ;-)

Leave me alone, I've got work to do!

...


0
3/9/2005 6:52:08 PM
CTips wrote:
> Jim Rogers wrote:
>
> > CTips <ctips@bestweb.net> wrote in
> > news:112sonip5v4dca6@corp.supernews.com:
> > If you want different scheduling policies you write them, just as
> > in C or C++.
>
> Right - and then what's the advantage of the built-in features of Ada

> over and
>

The advantage of the built-in features are that they are a very
good implementation of a tasking model. You seem to have two
standards. C is good because you can do what you want while
Ada is bad because it does not do everything for you.

> > How, using C or C++, would you create a threaded program and
> > ensure that signals are handled by a specified thread, and not
> > simply by the thread that is currently running when the signal
> > is received?
>
> What do you mean "handled by a thread"? How can you distinguish which

> thread is actually interrupted? More importantly, why do you care?

I mean, how do you determine which thread actually does the
actions to respond to a signal? Signals are asynchronous. You cannot
predict which thread will be executing when the signal is received.
You can determine which thread does the work of responding to
a signal.

Ada treats signals (or, as they call them, interrupts) as
a form of asynchronous thread communication. Since Ada 95, all
Ada interrupt handling has been handled in the following manner.

A protected object is created to receive the interrupt.
Ada provides pragmas to designate the protected object as
an interrupt receiver, and to associate a particular signal
with the protected object. You typically want a protected object
with a parameter-less procedure and an entry.

protected handler is
   procedure Set;
   entry Release;
   pragma Interrupt_Handler(Set);
   pragma Attach_Interrupt(Set, SIGINT);
private
   Counter : Natural := 0;
end handler;

protected body handler is
   procedure Set is
   begin
      Counter := Counter + 1;
   end Set;
   entry Release when Counter > 0 is
   begin
      Counter := Counter - 1;
   end Release;
end handler;

Using the example above:

A task is created to handle the interrupt.
That task calls Release and is suspended because the condition
evaluates to FALSE.

When the designated signal is received the procedure Set is
called, causing Counter to be incremented. This immediately
changes the condition on the Release entry, causing the
counter to be decremented and the suspended task to be scheduled.

This ensures that only the task I have designated actually handles
the interrupt, and that the interrupt handling behaves exactly like
any other task in the system.

>
>   However, in POSIX, you can do it by using pthread_sigmask() to
disable
> delivery of the signal to all threads other than the handling one.
>
> > You seem to assume that Ada only allows you to use features
> > provided by the language while preventing you from creating
> > your own features. That idea just doesn't make any sense.
>
> Nope, I didn't say that - what I said was that Ada (particularily the

> concurrent part of Ada) is fairly retarted, particularily if you want
to
> get performance. In fact, to get the performance similar to that
which
> can be obtained in C, one would pretty much have to write in the C
> subset of Ada [i.e. turn off most of the checking, use libraries
written
> in C + asm]. And even there I'd have my doubts - given the additional

> features that Ada compilers have to deal with, I doubt that they
would
> have focused as much on the optimizations.

Interesting. Ada compilers written for a POSIX compliant system
usually implement concurrency through the POSIX libraries.
Ada compilers written for other systems, such as WIN32 implement
their concurrency using the thread libraries native to that
system. It is extremely easy to call C libraries from an Ada
program.

The primary advantages of the Ada approach are that concurrency
is implemented natively when the OS supports threads, and the
Ada source code is highly portable from one system to the other.
The only non-portable features will be the names of interrupts
across systems.

> > Linked lists are not implemented as native syntax in either
> > Ada or C, yet they are used frequently in both languages.
> > How can that be?
>
> And their C implemenations are faster.

Is that true in all cases? I suspect not.
For instance, I responded to a thread on Comp.Programming
concerning an algorithm to identify the first bit set in
a 32 bit integer. My Ada solution, in its worst case, runs
in about 3 microseconds on a WIN XP system, and I do a
linear search of the bits.

Jim Rogers

0
3/9/2005 7:27:57 PM
"Alex R. Mosteo" <devnull@mailinator.com> writes:

> This is something I don't fully understand. IFAIK,
> 
> procedure Proc (Blah : access Some_Type);
> 
> access parameters raise an excepcion if null. So I don't get what adds
> to the language the
> 
> Blah : not null access ...
> 
> construct.

When using the "not null" access type, it is the responsibility of the
caller to ensure that the parameter value is not null. This way the
compiler can optimise away checks for a null value in the subprogram
in question ("Proc" in your case)

Note that it is still the run-time system (and not the programmer),
that performs the check, but it is only done once - before calling the
subprogram. Often the check can be optimised away.

Regards,
- Mark Lorenzen
0
3/9/2005 7:51:13 PM
"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:1110378745.155345.221890@g14g2000cwa.googlegroups.com...
....
> To be both professional and efficient, how about if we just paste in
> the entire text of the LRM before each statement? That would leave
> nobody room for _any_ doubt about what the code means. Oh...well,
> you're probably right: to go with, we'd better paste in the entire text
> of a real dictionary, and (just in case) a complete set of books
> teaching how to read English. The people you're obviously targeting as
> reading the code undoubtedly need that -- after all, every word in
> "Language Reference Manual" has three whole syllables!

That's certainly the process it takes to write a language standard; you have
to decide what every word means, or even specify the dictionary to use if
the word isn't defined in the standard. Ada programmers do care about such
things. It's not unusual to put a reference to the standard (or nowdays, a
link to the standard) into comments of Ada code.

There is an art to how much needs to be explicit, but if in doubt (and when
it comes to non-obvious language rules like precidence or visibility, it's
always in doubt), it is always better to err on the side of explicitness.

>Ada advocate: "The world WOULD be better if you used Ada."

And the world IS better because of the various rock solid programs I wrote
in Ada. I suspect that many of the people in comp.lang.ada could and would
say the same.

OTOH, there is a lot of "cool" code out there that crashes systems and adds
security holes. Those things are much less likely in Ada code (certainly not
impossible, of course, especially since we have to sit on top of C-based
OSes).

                         Randy Brukardt


It's not unusual



0
randy42 (2049)
3/9/2005 10:26:16 PM
"Jerry Coffin" writes:
> Dr. Adrian Wrigley wrote:
>
> [ ... ]
>
>> Isn't there some confusion here?
>>
>> Surely the "aliasing" issue (ignored by C++ completely(?)) is
>> largely independent if the
>> "reinterpret_cast"/"Unchecked_Conversion" issue?
>
> Yes -- he started by mentioning aliasing, but mostly seemed to be
> talking about type punning, so that was what I replied to. The
> discussion centered around safety, which is essentially orthogonal
> to aliasing.

No, I did insist on aliasing as the main point, and then briefly about
the representation clause that caused two objects to be overlaid.

Aliasing is definitely *not* orthogonal to safety.  The coding
standards I have reviewed for avionics, as well as the "Guide for the
use of the Ada programming language in High Integrity Systems" [1] all
discuss how aliasing adversely affects safety.  It is important, in
safty-critical software, to understand aliasing: what it is, when it
takes place, and what the consequences are.  Performance in this
context is a minor concern compared to predictability of the software.

[1] http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf

-- 
Ludovic Brenta.
0
3/9/2005 10:29:02 PM
"CTips" <ctips@bestweb.net> wrote in message
news:112sonip5v4dca6@corp.supernews.com...
....
> Also, Ada's only scheduling/queing discipline is FIFO with priorities
> (and priorities are only available if the RT annex is actually
> implemented). If I want to do earliest-deadline first, well, how do I go
> about doing it?

pragma Task_Dispatching_Policy (EDF_Across_Priorities);

will do the trick, presuming you have an Ada 2005 compiler that supports it.
Ada 2005 adds a number of additional scheduling policies.

                            Randy Brukardt, Editor ISO/IEC
8652:1995:AMD.1:200x




0
randy42 (2049)
3/9/2005 10:30:56 PM
Pascal Obry writes:
> compiled for the C code using:
>
> $ gcc -o c_matrix -O2 matrix.c
>
> compiled for the Ada code using:
>
> $ gnatmake -f -O2 -gnatp matrix.adb -bargs -static
>
> (-bargs -static to use the static runtime, this is what C does in this case).
>
> I get:
>
> $ time matrix 100
>  270165 1061760 1453695 1856025
>
> real    0m0.033s
> user    0m0.010s
> sys     0m0.020s
>
> $ time c_matrix 100
> 270165 1061760 1453695 1856025
>
> real    0m0.033s
> user    0m0.010s
> sys     0m0.010s
>
> I see identical results here, this is on a Windows box using GCC 3.4.4
> and GNAT 5.03a. Of course this is no surprise since GNAT share the very same
> backend! Yet this means just nothing. A good benchmark is done on real
> applications. At least I hope it will dismiss the idea that Ada is inherently
> slow. There is nothing in Ada that is designed to be slow, a good compiler for
> Ada as a good compiler for any language should generate good code, that's all.

Out of curiosity, could you try with:

gnatmake -O2 -gnatVa -gnato matrix.adb

and see if, with all checks turned on, there is a significant difference?

-- 
Ludovic Brenta.
0
3/9/2005 10:34:48 PM
"Alex R. Mosteo" <devnull@mailinator.com> wrote in message
news:422F142E.9050909@mailinator.com...
> This is something I don't fully understand. IFAIK,
>
> procedure Proc (Blah : access Some_Type);
>
> access parameters raise an excepcion if null.

Not in Ada 2005. That restriction makes it very difficult to do C
interfacing, among other things. Moreover, keeping the restriction would
have made the expansion of anonymous access types to most contexts unusable
(you need a null value sometimes!). The only case where "not null" is
implicit is if the parameter is controlling (that's necessary for
compatibility - I think most of us hate it, but there doesn't seem to be an
alternative).

> So I don't get what adds
> to the language the
>
> Blah : not null access ...
>
> construct.

Because it (a) makes the restriction explicit, and (b) you can use it
anywhere: on named access types, on variables and components, in generic
formals, etc.

   type Acc is access Some_Type;
   procedure Proc (P : in not null Acc);

                               Randy Brukardt



0
randy42 (2049)
3/9/2005 10:43:11 PM
<jimmaureenrogers@worldnet.att.net> wrote in message
news:1110383768.773379.61780@o13g2000cwo.googlegroups.com...
....
> Ada does not use the dot notation for calling member methods for
> tagged types.

You mean "Ada 95 does not use...".

Ada 2005 provides "prefixed name" notation for calling methods as an option.
This unifies the syntax for tagged type calls, protected type calls, and
task entry calls (and interfaces which can be implemented by any of those
unifies it further).

                      Randy Brukardt




0
randy42 (2049)
3/9/2005 10:52:03 PM
Ludovic Brenta wrote:

[ ... ]

> No, I did insist on aliasing as the main point, and then briefly
> about the representation clause that caused two objects to be
> overlaid.

Well, I just went back and reread your post, and I still don't see it,
but if you think that's what you said, so be it.

> Aliasing is definitely *not* orthogonal to safety.  The coding
> standards I have reviewed for avionics, as well as the "Guide for the
> use of the Ada programming language in High Integrity Systems" [1]
> all discuss how aliasing adversely affects safety.  It is important,
> in safty-critical software, to understand aliasing: what it is, when
> it takes place, and what the consequences are.  Performance in this
> context is a minor concern compared to predictability of the
> software.
>
> [1] http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf

I read through the reference above, and what it says about aliasing is
basically "We've built a program verification system that doesn't
understand aliasing, so attempting to use our system on code that uses
aliasing won't work."

Perhaps you intended to post some other link?

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/9/2005 10:53:24 PM
"Jerry Coffin" writes:
> Ludovic Brenta wrote:
>> [1] http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf
>
> I read through the reference above, and what it says about aliasing
> is basically "We've built a program verification system that doesn't
> understand aliasing, so attempting to use our system on code that
> uses aliasing won't work."
>
> Perhaps you intended to post some other link?

You seem to have mastered techniques to read faster than light :)

The document does not assume any tools to exist; it does not even
mandate the use of any tools.  All it says is that aliasing makes
"information flow analysis" and "symbolic execution" difficult.  In
other words, it makes it more difficult to prove the correctness of
software.  And provability of software is the single most important
concern in safety-critical applications.

In other application domains, of course, aliasing is not so frowned
upon.  But this thread is about safety and, as others like Ioannis
have noted, safty does have a cost, e.g. in terms of flexibility.

-- 
Ludovic Brenta.
0
3/9/2005 11:11:43 PM
Adrien Plisson wrote:

[ ... ]

> about Air Traffic Control:
>
> C++ Advocate: "The world WOULDN'T be safer if they used C++"

But they did, and do use C++ on regular basis.  E.g.:

http://www.barco.com/airtrafficcontrol/en/products/product.asp?element=1833

> Ada Advocate: "The world IS safer, because of the cool system we
wrote"

Right -- that's why things like this:

http://www.computing.co.uk/news/1130528

never happen!

Serously though, if you think the ATC system is written exclusively or
even primarily in Ada, you're simply mistaken. It's certainly true that
for some time now, SOME of the new development has been done in Ada,
but it's also true that some of the new development has been done in
C++. It's also true that there's LOTS of ancient code written in things
like JOVIAL.

> about buffer overflows:
>
> Ada advocate: "Networks WOULD be more secure if you used Ada"
> C++ advocate: "Networks WOULD be more secure if we used Ada"

So far, no C++ advocate seems to have said anything similar to what you
claim, but in a way you're probably right. If we depended on Ada to do
the job, the Internet (for one) would be drastically more secure,
though only because nobody used it! :-) (<- explicit smiley for those
who seem to need them...)

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/9/2005 11:12:38 PM
Jerry Coffin wrote:
> But they did, and do use C++ on regular basis.  E.g.:
> 
> http://www.barco.com/airtrafficcontrol/en/products/product.asp?element=1833

But the link you give does not say that C++ was used - perhaps it was 
(it actually says "...ODS Toolbox does not require special programming 
skills in C/C++...").

But it Ada is used on all sorts of traffic systems from air to rail to 
GPS. A list of such systems is available at:

http://www.act-europe.fr/aa_lookwho.php

Cheers

-- Martin
0
3/9/2005 11:36:04 PM
Ludovic Brenta wrote:

> You seem to have mastered techniques to read faster than light :)

Do you believe that the document was unavailable before you posted the
link to it? In fairness, I'm not sure I'd read this exact version
previously though, so when I have a bit more time, I'll probably reread
it more carefully. Having Ada in the title doesn't _necessarily_ rule
out its containing useful information. :-)

[ ... ]

> The document does not assume any tools to exist; it does not even
> mandate the use of any tools.

Sorry -- I probably should have said "techniques" rather than "tools",
though I _hope_ anybody using these techniques uses tools to do so --
I'm reasonably certain that on any more than a truly trivial system,
doing the job by hand would be exceptionally error prone.

In any case, the "problem" with aliasing isn't in safety per se, but in
verification. Better verification techniques might eliminate the
problem.

Likewise, it should be added that these techniques have problems with a
number of other perfectly valid and legitimate types of programming
that are not necessarily unsafe either.

> All it says is that aliasing makes
> "information flow analysis" and "symbolic execution" difficult.  In
> other words, it makes it more difficult to prove the correctness of
> software.  And provability of software is the single most important
> concern in safety-critical applications.

I doubt that, but if it really was true, Ada should almost certainly be
avoided as well -- pure functional programming makes verification
_considerably_ easier (and only in part because eliminating assignments
eliminates the issue of aliasing).

> In other application domains, of course, aliasing is not so frowned
> upon.  But this thread is about safety and, as others like Ioannis
> have noted, safty does have a cost, e.g. in terms of flexibility.

I don't agree that safety necessarily has to have a cost in
flexibility. Certainly if Ada was the only way to achieve safety, the
cost would be extreme, but I remain convinced there are other ways.

In fact, much of language design is a matter of not merely balancing
the two (which Ada does reasonably well) but of finding real solutions
that allow flexibility without losing safety. Unfortunately, when Ada
was being designed, the two seem to have been seen as direct tradeoffs,
where increasing one necessarily reduced the other. In some cases, it
looks to me like flexibility was constricted on the simple assumption
that doing so _must_ improve safety, even if nobody knew how.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/10/2005 12:12:34 AM
Pascal Obry wrote:
> I see identical results here, this is on a Windows box using GCC 3.4.4
> and GNAT 5.03a. Of course this is no surprise since GNAT share the very same
> backend! Yet this means just nothing. A good benchmark is done on real

And notice that Pascal did NOT have to suppress safety checks
in Ada to make it just as fast as the C which doesn't have them.
(Or were they hand-coded in the C?)

-- 
Wes Groleau
Can we afford to be relevant?
http://www.cetesol.org/stevick.html
0
news31 (6772)
3/10/2005 12:57:44 AM
Martin Dowie wrote:
> Jerry Coffin wrote:
>> Ada advocate: "The world WOULD be better if you used Ada."
>> C++ advocate: "The world IS better because of the cool code I wrote."
> 
> What on earth would the C advocate say!! ;-)

"Oops. Sorry, I'll fix that in a jiffy!"

-- 
Wes Groleau
    "Lewis's case for the existence of God is fallacious."
"You mean like circular reasoning?"
    "He believes in God.  Therefore, he's fallacious."
0
news31 (6772)
3/10/2005 1:03:14 AM
Georg Bauhaus wrote:

> CTips wrote:
> 
>> In fact, to get the performance similar to that which can be obtained 
>> in C, one would pretty much have to write in the C subset of Ada [i.e. 
>> turn off most of the checking, use libraries written in C + asm].
> 
> 
> Is there any significant evidence for this other than
> special cases for any of the languages discussed?

Don't have something specific to Ada, but I've seen work on PL.8, which 
had similar dynamic bounds checking. They observed, *on the average* 
about 8%, but this was on a machine with a special trap instruction for 
bounds checking. It would be closer to 15-20% if the check had to be 
done using subtract/compares/branches.

Also, other work done on bounds checking ~1990 (maybe by Rajiv Gupta) 
has numbers between 0 and 50% slowdown. And these, by the way, IIRC dont 
actually count the cost of having to use handles vs. pointers, just the 
cost of the raw access.

You can measure the slowdown yourself. Try running the following loop in 
Ada:
    void do_perm(int a[], int perm[])
    {
    int i;
    for( i = 0; i < VERY_LARGE_NUMBER; i++ )
       a[perm[i]] = i;
    }

where perm[i] is a dynamically created array, such as:
    void setup_perm(int perm[])
    {
    int i;
    for( i = 0; i < VERY_LARGE_NUMBER; i++ )
      perm[i] = i;
    }
Run the codes with and without bounds checking and see the difference.

> And why on earth should translators for programming languages
> be so dumb as to produce fast code only when the input language
> is like "the C subset"?

Because the run-time check code required by the language will require 
extra work.

> If a compiler knows about enum values and can use them in the
> construction of objects matching hardware, or of arrays of bytes,
> or whatever, why should the enum values incur a speed penalty?
> Because the compiler checks that there is static matching
> at compile time?

Compile time checks are for free ... sometimes. Be careful that you 
aren't really adding runtime checks. For instance,
    int foo(index_type i, int a[index_type'range])
    {
       ... a[i] ...
     }
will have no check, since it is guaranteed that the size of a is equal 
to the range of values of i.

However, if we now invoke this using
     int i;
     ...
     foo( (index_type)i, a);
then we (may) have to add a run-time check to see whether i is in the 
range of index_type.

There is a secondary, but fairly important affect. Compiler resources 
are finite, and compilers also suffer from "bit-rot". Roughly, you can 
only cram in so much effort into a compiler before its run-time or 
bug-rates or heuristic-balancing effort become unacceptable. In the case 
of a feature rich language like Ada (or C++), much of the effort goes 
into getting all the features right. In C, almost all the effort goes 
into the optimizations. Even when people appear to use the same backend, 
in practice, there are various optimizations which get disabled for 
non-C languages because they break at various corner cases in other 
languages.


>> And even there I'd have my doubts - given the additional features that 
>> Ada compilers have to deal with, I doubt that they would have focused 
>> as much on the optimizations.
> 
> 
> Given that the language provides
>  pragma Optimize (Time/Space/Off)
> I doubt that this general doubt can be justified.

<grin> and you are speaking from how many years of compiler development...?

>> (How can you get beaten by Python? The mind boggles!)
> 
> 
> Easy. You are not actually beaten by Python, but by a highly
> optimized C matrix library which is bound to python as an
> extension.
> If you're interested, for Ada 2005, ISO vector and matrix
> subprograms are added to the language standard.
> 
> 
> Georg
0
ctips (287)
3/10/2005 1:47:02 AM
jimmaureenrogers@worldnet.att.net wrote:

> CTips wrote:
> 
>>Jim Rogers wrote:
>>
>>
>>>CTips <ctips@bestweb.net> wrote in
>>>news:112sonip5v4dca6@corp.supernews.com:
>>>If you want different scheduling policies you write them, just as
>>>in C or C++.
>>
>>Right - and then what's the advantage of the built-in features of Ada
> 
> 
>>over and
>>
> 
> 
> The advantage of the built-in features are that they are a very
> good implementation of a tasking model. You seem to have two
> standards. C is good because you can do what you want while
> Ada is bad because it does not do everything for you.

Nope, I'm not saying that. What I am saying is that:
  - the safety features of Ada can come with a significant run-time cost
  - you're going to end up escaping out of Ada for a lot of things 
(particularily in systems programming).

C doesn't have that cost. However, if you want to have similar levels of 
checking, you have to roll your own run-time checks. On the other hand, 
because you're rolling your own, the run-time checks are a lot less 
expensive.

Also, since a lot of interesting things require escaping from the core 
language and bending the rules of the language, you have two options:
   - you can write it all in assembly
   - or you can write in a language where you can reasonably expect that 
your bending of the rules won't make the compiler do something you 
didn't expect.
I'd rather use C for this purpose.
0
ctips (287)
3/10/2005 2:09:16 AM
>>This is safer, but limiting.
>>In C++ may want to declare the variable outside the loop,
>>break out early and use the loop variable. Let me guess: You can't
>>break out early in Ada, right?
> 
> 
> Of course you can!


Can this be done in Ada?


#include <iostream>
#include <vector>
#include <ctime>
#include <algorithm>


int main()
{
     using namespace std;

     vector<int> vec(1000);

     // Seeds the random number generator
     srand(time(0));

     // Use rand() to fill vector with values
     // As you see the operation is entirely safe.
     generate(vec.begin(), vec.end(), rand);

     vector<int>::size_type i;

     // Finds the first index where a value is smaller than 1000
     // in low level style
     for(i=0; i<vec.size(); ++i)
       if(vec[i]<1000)
         break;

     i==vec.size()? cout<<"No number <1000 was found\n"
                  :cout<<"Number <1000 found at index "<<i<<"\n";
}



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 2:30:37 AM
CTips wrote:
> jimmaureenrogers@worldnet.att.net wrote:
>
> > CTips wrote:
> >
> >>Jim Rogers wrote:
> > The advantage of the built-in features are that they are a very
> > good implementation of a tasking model. You seem to have two
> > standards. C is good because you can do what you want while
> > Ada is bad because it does not do everything for you.
>
> Nope, I'm not saying that. What I am saying is that:
>   - the safety features of Ada can come with a significant run-time
cost
>   - you're going to end up escaping out of Ada for a lot of things
> (particularily in systems programming).

I am not sure exctly what you mean by escaping out of a language.
This reminds me of escaping from the vi editor to run another
program.

Ada is quite capable of doing bit manipulations without resorting
to C or Assembly. On the other hand, most operating system libraries
are currently written in C, so you might want to call them from
an Ada program. This is no worse than calling them from C++.

My little program described earlier does not break out into
other languages, and it appears to have beaten a number of C
programmers who were using this exercise to explore optimizations.

-- Highest bit set
with Ada.Text_Io;
with Ada.Calendar; use Ada.Calendar;

procedure Highest_Bit_Set is
   Num : Integer;
   type Index_Type is mod 32;
   type Bit_Array is array(Index_Type) of Boolean;
   pragma Pack(Bit_Array);
   Overlay : Bit_Array;
   for Overlay'Address use Num'Address;
   Start, Stop : Time;
begin
   Start := Clock;
   Num := 0;
   for X in 1..100_000 loop
	   for I in reverse Overlay'range loop
	      if Overlay(I) then
	         Ada.Text_Io.Put_Line("Highest bit set is bit" &
                                       Index_Type'Image(I));
	         exit;
	      end if;
	   end loop;
	end loop;
   Stop := Clock;
   Ada.Text_IO.Put_Line("Execution time: " & Duration'Image(Stop -
Start));
end Highest_Bit_Set;

On my AMD 64 pc running Win XP this program ran, with 100,000
iterations in 0.02 seconds. This calculates to an average time
per iteration of 0.0000002 seconds.

My choice of calculating for a value of 0 gives worst case
performance, and does not slow the program to do I/O. This
combination gives what I think is a fair measure of the
performance of the program.

I did not disable any Ada run-time checking. I believe the
compiler took care of those issues automatically.

>
> C doesn't have that cost. However, if you want to have similar levels
of
> checking, you have to roll your own run-time checks. On the other
hand,
> because you're rolling your own, the run-time checks are a lot less
> expensive.
>

I am not sure I agree that this is always true. If it were, then
I would not trust any of the code generated by a compiler to be
efficient. My experience is that a good compiler in almost any
language produces more efficient object code than most humans
can produce. If this were not so, then we should all be using
only Assembly.

> Also, since a lot of interesting things require escaping from the
core
> language and bending the rules of the language, you have two options:
>    - you can write it all in assembly
>    - or you can write in a language where you can reasonably expect
that
> your bending of the rules won't make the compiler do something you
> didn't expect.

What sort of things will the compiler do that I do not expect?
I assume you have an example in mind, but right now I cannot think
of one.

Jim Rogers

0
3/10/2005 2:35:08 AM
Martin Dowie wrote:

[ ... ]

> But the link you give does not say that C++ was used

If I made the kind of unfair generalizations sometimes made by some Ada
advocates, I'd say that Ada programmers only look at the surface, and
don't consider the deeper meaning of things. :-)

Look past the toolbox itself, and consider the systems on which it
runs. To save you the trouble of looking it up again, I'll point it
out: X running on top of either Windows or UNIX.

Now do you suppose some C and C++ might be involved?

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/10/2005 2:39:14 AM
Martin Dowie wrote:

> But the link you give does not say that C++ was used - perhaps it was 
> (it actually says "...ODS Toolbox does not require special programming 
> skills in C/C++...").
> 
> But it Ada is used on all sorts of traffic systems from air to rail to 
> GPS. A list of such systems is available at:
> 
> http://www.act-europe.fr/aa_lookwho.php


Bottom line is both C++ and Ada are used for mission critical systems. 
Also it is easy to write safe code in C++ just by using its high level 
facilities, with no overflows, not anything.


For example consider this simple bullet-proof code for string input and 
processing:


#include <iostream>
#include <string>

int main()
{
     using namespace std;

     string s;

     while(cin)
     {
         getline(cin,s);

         /*Do things with s */;
     }
}



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 2:47:23 AM
Hans Malherbe wrote:
> * case statements (Ada's equivalent of a switch in C++) are required
>   to handle all possible cases.  Thus it is impossible to forget one.
>   And, of course, there is no "break;" crap in Ada.
> 
> Prevents fall through.

And it prevents forgetting to put in the break--an error
so common that the feature was explicitly prohibited in
the Ada specs.

> This is more in the C++ tradition. The programmer has choice.
> In C++ you can extend the type system to achieve this and more
> (someone mentioned dimensional analysis), just not with typedef.

In C++ and Java, you can do a heck of a lot to program
type safety and abstraction.  Problem is that it _is_
a heck of a lot -- for example, to emulate what Ada does
with things like

    type Possible_Speed is                range 0.0 .. 140.0;
    constant Speed_Limit is 55.0;
    subtype Legal_Speed is Possible_Speed range 0.0 ..  Speed_Limit;
    type Direction is mod 360;

    V : Legal_Speed;
    C, D : Direction;

Before you say it doesn't take much, remember your solution
should allow

    V := Speed_Limit - 15.0;

raise an exception on
    .....
    V := 55.1;

and it should refuse to compile the typo

    V := D;

Another problem is that because of the work involved in
enforcing abstractions with classes, most Java programmers
(probably C++, too) would rather just say

    double V;
    double C, D;

-- 
Wes Groleau

A pessimist says the glass is half empty.

An optimist says the glass is half full.

An engineer says somebody made the glass
        twice as big as it needed to be.
0
news31 (6772)
3/10/2005 3:26:16 AM
jimmaureenrogers@worldnet.att.net wrote:
> The simple loop will always be an infinite loop unless
> you break out early. The Ada reserved word used to
> break out of a loop is "exit". In Ada "exit" does not
> exit the program, only the enlcosing loop.

Or (for nested loops), each loop can have a name,
and the exit statement can exit out of two or more nested
loops by using the name of the level to get out of.

Java has a construct that can do something like that.
Does C++ ?

-- 
Wes Groleau
    "Would the prodigal have gone home if
     the elder brother was running the farm?"
                       -- James Jordan
0
news31 (6772)
3/10/2005 3:36:00 AM
Larry Kilgallen wrote:
> In article <1110052142.832650@athnrd02>, Ioannis Vranos <ivr@remove.this.grad.com> writes:
> 
>>Ludovic Brenta wrote:
> 
> 
>>>The bug in the C++ library was that I was mistakenly reusing the loop
>>>variable after the loop, instead of the intended variable.  Of course,
>>>the loop variable was an index pointing after the end of the buffer.
>>
>>
>>It looks like the code was not ISO C++ compliant.
> 
> 
> In that case, it looks like the compiler failed to detect that shortcoming.

A real man's compiler

http://somewhere.fscked.org/rmcc/

:)
0
3/10/2005 3:47:31 AM
CTips wrote:
> Nope, I'm not saying that. What I am saying is that:
>  - the safety features of Ada can come with a significant run-time cost

You have said it, but you haven't been very convincing.

>  - you're going to end up escaping out of Ada for a lot of things 
> (particularily in systems programming).

I'm not convinced here, either.  Some people are
so unconvinced that they are trying to write an
entire operating system in Ada.  There is a X-server
(or is it just an X11R6 client library?) written
in Ada which I've heard is quite efficient and robust.

> Also, since a lot of interesting things require escaping from the core 
> language and bending the rules of the language, you have two options:
>   - you can write it all in assembly
>   - or you can write in a language where you can reasonably expect that 
> your bending of the rules won't make the compiler do something you 
> didn't expect.

!?!  If you are truly "bending the rules," how can you
expect anything but surprises?  What exactly _is_ a
"rule" in this usage?

Ada rules are quite clear:

  A {some set of constructs} will never compile.
  B {another set of constructs} is explicitly
             stated to have unpredictable results.
  C {another set} has the results of each clearly defined.
  D {another very small set} might exist, things that
             just didn't get thought of.

"bending the rules" puts you in group A.
"following the rules" puts you in group C.
"being stupid" puts you in group B.

One advantage of Ada and languages like it
is that sets B and D are much smaller.

-- 
Wes Groleau
    ------
    "The reason most women would rather have beauty than brains is
     they know that most men can see better than they can think."
                                -- James Dobson
0
news31 (6772)
3/10/2005 3:59:23 AM
Wes Groleau wrote:

[ ... ]

> Or (for nested loops), each loop can have a name,
> and the exit statement can exit out of two or more nested
> loops by using the name of the level to get out of.
>
> Java has a construct that can do something like that.
> Does C++ ?

Thankfully, no. IMO, both Java and Ada would be improved by elimination
of this misfeature. Even though C++'s 'break' is simpler, I'd say less
than 10% of the time I see it used to exit loops is justified. That's
not to say that there's NO good use for it, only that it's used FAR
more often than justified.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

0
jcoffin (2241)
3/10/2005 4:00:39 AM
Jerry Coffin wrote:
> Thankfully, no. IMO, both Java and Ada would be improved by elimination
> of this misfeature. Even though C++'s 'break' is simpler, I'd say less
> than 10% of the time I see it used to exit loops is justified. That's
> not to say that there's NO good use for it, only that it's used FAR
> more often than justified.

Interesting.  Ada is bad because you _think_ it won't let you do what
you want to do.  But it would be better if it prevented other people
from doing something you think they shouldn't do.

-- 
Wes Groleau
   "To know what you prefer, instead of humbly saying
    Amen to what the world tells you you should prefer,
    is to have kept your soul alive."
                          -- Robert Louis Stevenson
0
news31 (6772)
3/10/2005 4:08:12 AM
Pascal Obry wrote:

> Ok, thanks. This is definitly a recursive definition. AFAIK there is no such
> thing in Ada.


This is compile-time "template metaprogramming". An entire field of its own.


There are two kinds of recursion with templates, run-time instance 
recursion (as usual) and compile-time recursion.




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 4:12:08 AM
Wes Groleau wrote:

> Or (for nested loops), each loop can have a name,
> and the exit statement can exit out of two or more nested
> loops by using the name of the level to get out of.
> 
> Java has a construct that can do something like that.
> Does C++ ?


There is no need for such a thing, and you *can* do this and other ugly 
stuff in C++ by using goto.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 4:16:58 AM
Ioannis Vranos <ivr@remove.this.grad.com> wrote in news:1110421853.766292
@athnrd02:

>>>This is safer, but limiting.
>>>In C++ may want to declare the variable outside the loop,
>>>break out early and use the loop variable. Let me guess: You can't
>>>break out early in Ada, right?
>> 
>> 
>> Of course you can!
> 
> 
> Can this be done in Ada?
> 
> 
> #include <iostream>
> #include <vector>
> #include <ctime>
> #include <algorithm>
> 
> 
> int main()
> {
>      using namespace std;
> 
>      vector<int> vec(1000);
> 
>      // Seeds the random number generator
>      srand(time(0));
> 
>      // Use rand() to fill vector with values
>      // As you see the operation is entirely safe.
>      generate(vec.begin(), vec.end(), rand);
> 
>      vector<int>::size_type i;
> 
>      // Finds the first index where a value is smaller than 1000
>      // in low level style
>      for(i=0; i<vec.size(); ++i)
>        if(vec[i]<1000)
>          break;
> 
>      i==vec.size()? cout<<"No number <1000 was found\n"
>                   :cout<<"Number <1000 found at index "<<i<<"\n";
> }

The idioms are somewhat different. For instance, the Ada for loop
does not iterate one past the end of the array, nor is the
value of the loop control variable visible outside the loop.

I did not see where you set the range of values for your
random number type. I am generating integer values in the
range of 0 through 10,000.

with Ada.Text_Io;
with Ada.Numerics.Discrete_Random;

procedure Random_Fill is
   type Rand_Values is range 0..10_000;
   package My_Rand is new Ada.Numerics.Discrete_Random(Rand_Values);

   Seed : My_Rand.Generator;
   subtype Index_Type is Natural range 1..1000;
   Vec : array(Index_Type) of Rand_Values;
   Found : Natural := 0;
begin
   My_Rand.Reset(Seed); -- seeds the random number generator
      
   -- fill the array with random values in the range of 0
   -- through 10,000
   for I in Vec'range loop
      Vec(I) := My_Rand.Random(Seed);
   end loop;
   
   -- finds first index where a value is less than 1000
   for I in Vec'range loop
      if Vec(I) < 1000 then
         Found := I;
         exit;
      end if;
   end loop;
   if Found > 0 then
      Ada.Text_Io.Put_Line("Number < 1000 found at index" &
         Natural'Image(Found));
   else
      Ada.Text_Io.Put_Line("No number < 1000 was found");
   end if;
end Random_Fill;

Jim Rogers

0
3/10/2005 4:25:36 AM
Falk Tannh�user wrote:

> Perhaps the closest way you can get to this in C++ is
> 
>   std::vector<foo_type> Data;
> ...
>   std::for_each(Data.begin(), Data.end(), DoSomething);
> 
> where "DoSomething" evaluates to a so-called "function object"
> having an "operator()" accepting a (reference to) "foo_type".



Yes you can write completely safe, bullet-proof code in C++ and without 
sacrificing efficiency  (and some times even improving it!) by using the 
high level C++ constructs. Examples are: find family (which includes 
find_if etc), search family, generate, fill, for_each, count, mismatch, 
equal, transform, copy, swap, replace, remove, unique, rotate, sort, 
bound, merge, partition, includes, set (like set_union), heap (like 
make_heap - makes sequences behave as heaps), comparisons (like min, 
max, lexicographical_compare), permutation, etc families.


We can say it is an entirely completely safe, high level language of its 
own, and in this way you may never use loops for most things!




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 4:31:33 AM
Jim Rogers wrote:

>>#include <iostream>
>>#include <vector>
>>#include <ctime>
>>#include <algorithm>
>>
>>
>>int main()
>>{
>>     using namespace std;
>>
>>     vector<int> vec(1000);
>>
>>     // Seeds the random number generator
>>     srand(time(0));
>>
>>     // Use rand() to fill vector with values
>>     // As you see the operation is entirely safe.
>>     generate(vec.begin(), vec.end(), rand);
>>
>>     vector<int>::size_type i;
>>
>>     // Finds the first index where a value is smaller than 1000
>>     // in low level style
>>     for(i=0; i<vec.size(); ++i)
>>       if(vec[i]<1000)
>>         break;
>>
>>     i==vec.size()? cout<<"No number <1000 was found\n"
>>                  :cout<<"Number <1000 found at index "<<i<<"\n";
>>}
> 
> 
> The idioms are somewhat different. For instance, the Ada for loop
> does not iterate one past the end of the array, nor is the
> value of the loop control variable visible outside the loop.
> 
> I did not see where you set the range of values for your
> random number type. I am generating integer values in the
> range of 0 through 10,000.


I used the default range.


> with Ada.Text_Io;
> with Ada.Numerics.Discrete_Random;
> 
> procedure Random_Fill is
>    type Rand_Values is range 0..10_000;
>    package My_Rand is new Ada.Numerics.Discrete_Random(Rand_Values);
> 
>    Seed : My_Rand.Generator;
>    subtype Index_Type is Natural range 1..1000;
>    Vec : array(Index_Type) of Rand_Values;
>    Found : Natural := 0;
> begin
>    My_Rand.Reset(Seed); -- seeds the random number generator
>       
>    -- fill the array with random values in the range of 0
>    -- through 10,000
>    for I in Vec'range loop
>       Vec(I) := My_Rand.Random(Seed);
>    end loop;
>    
>    -- finds first index where a value is less than 1000
>    for I in Vec'range loop
>       if Vec(I) < 1000 then
>          Found := I;
>          exit;
>       end if;
>    end loop;
>    if Found > 0 then
>       Ada.Text_Io.Put_Line("Number < 1000 found at index" &
>          Natural'Image(Found));
>    else
>       Ada.Text_Io.Put_Line("No number < 1000 was found");
>    end if;
> end Random_Fill;


Yes but what happens if you want to use the indexed found with the 
associated value (ot could be inside a string for example) in an 
associative container like a map?

That is, find the index and then use the index to add the value in a 
map. I suppose you would create a separate procedure for this in which 
you would pass the array along with the container and perhaps along with 
the item to be found, just for one such operation!



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 4:41:00 AM
Ioannis Vranos wrote:

> Yes you can write completely safe, bullet-proof code in C++ and without 
> sacrificing efficiency  (and some times even improving it!) by using the 
> high level C++ constructs. Examples are: find family (which includes 
> find_if etc), search family, generate, fill, for_each, count, mismatch, 
> equal, transform, copy, swap, replace, remove, unique, rotate, sort, 
> bound, merge, partition, includes, set (like set_union), heap (like 
> make_heap - makes sequences behave as heaps), comparisons (like min, 
> max, lexicographical_compare), permutation, etc families.
> 
> 
> We can say it is an entirely completely safe, high level language of its 
> own, and in this way you may never use loops for most things!


More accurately described as "entirely completely safe, high level world 
of its own".




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 4:42:16 AM
In article <422fc352$1@news.alphalink.com.au>, Song Yun Zhao <mr_songyunzhao@yahoo.com.au> writes:
> Larry Kilgallen wrote:
>> In article <1110052142.832650@athnrd02>, Ioannis Vranos <ivr@remove.this.grad.com> writes:
>> 
>>>Ludovic Brenta wrote:
>> 
>> 
>>>>The bug in the C++ library was that I was mistakenly reusing the loop
>>>>variable after the loop, instead of the intended variable.  Of course,
>>>>the loop variable was an index pointing after the end of the buffer.
>>>
>>>
>>>It looks like the code was not ISO C++ compliant.
>> 
>> 
>> In that case, it looks like the compiler failed to detect that shortcoming.
> 
> A real man's compiler
> 
> http://somewhere.fscked.org/rmcc/
> 
> :)

The VMS primitive debugger Delta (used to debug the system bootstrap
but not much else) is famous for having just one error message:

	Eh ?

At one point somebody inside DEC created a fake Delta support Notes
conference with various questions about the way Delta works, each
receiving the response:

	Eh ?
0
Kilgallen (2738)
3/10/2005 4:53:44 AM
Jerry Coffin wrote:
> If I made the kind of unfair generalizations sometimes made by some Ada
> advocates, I'd say that Ada programmers only look at the surface, and
> don't consider the deeper meaning of things. :-)
> 
> Look past the toolbox itself, and consider the systems on which it
> runs. To save you the trouble of looking it up again, I'll point it
> out: X running on top of either Windows or UNIX.
> 
> Now do you suppose some C and C++ might be involved?

Sorry, but if you make a link to a news item /about/ a particular tool, 
at least /I/ am going to believe that you are making a point about the 
tool and not the OS it works on! Why not provide a link directly to a 
page about X running on top of either Windows or UNIX?! :-)

Cheers

-- Martin
0
3/10/2005 7:01:20 AM
Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> Out of curiosity, could you try with:
> 
> gnatmake -O2 -gnatVa -gnato matrix.adb
> 
> and see if, with all checks turned on, there is a significant difference?

Yes there is:

$ time matrix 100
 270165 1061760 1453695 1856025

real    0m0.081s
user    0m0.020s
sys     0m0.000s

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
0
pascal27 (183)
3/10/2005 7:19:59 AM
Wes Groleau <groleau+news@freeshell.org> writes:

> And notice that Pascal did NOT have to suppress safety checks

I did: -gnatp.

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
0
pascal27 (183)
3/10/2005 7:24:24 AM
Ioannis Vranos <ivr@remove.this.grad.com> wrote in news:1110429670.232319
@athnrd02:

> 
> Yes but what happens if you want to use the indexed found with the 
> associated value (ot could be inside a string for example) in an 
> associative container like a map?
> 
> That is, find the index and then use the index to add the value in a 
> map. I suppose you would create a separate procedure for this in which 
> you would pass the array along with the container and perhaps along with 
> the item to be found, just for one such operation!
> 

I assume the container type is already defined, including a procedure
to insert new values into the container. I would simply call the
insert or add procedure for that container, passing in the 
appropriate information. This is no different than calling a
member function for a class in C++.

Jim Rogers

0
3/10/2005 8:05:30 AM
Goeie dag Georg

Thanks for all the replies, I'll stop wasting bandwith with trivial
questions and go find out myself.

Groete
Hans

0
3/10/2005 8:23:17 AM
xpyttl wrote:
> "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
> news:d0ndrs$4cs$1@titan.btinternet.com...
>
>> What on earth would the C advocate say!! ;-)
>
> Leave me alone, I've got work to do!

Surely...

Leave me alone, I've got debugging to do!

;-)


0
3/10/2005 9:33:07 AM
Jim Rogers wrote:

> I assume the container type is already defined, including a procedure
> to insert new values into the container. I would simply call the
> insert or add procedure for that container, passing in the 
> appropriate information. This is no different than calling a
> member function for a class in C++.


How can this be done in Ada?


As it can be seen here, the bullet-proof high level facilities are used. :-)


#include <iostream>
#include <vector>
#include <ctime>
#include <algorithm>
#include <functional>
#include <map>


int main()
{
     using namespace std;

     vector<int> vec(1000);

     map<int, int> iimap;

     // Seeds the random number generator
     srand(time(0));

     // Use rand() to fill vector with values
     // As you see the operation is entirely safe.
     generate(vec.begin(), vec.end(), rand);


     // Finds the first occurrence of an int smaller than 1000
     vector<int>::const_iterator p= find_if(vec.begin(), vec.end(),
                                         bind2nd(less<int>(), 1000) );

     int index= p-vec.begin();

     // Stores the index and the value in a map
     iimap[index]= *p;


     cout<<index<<":\t"<<iimap[index]<<"\n";
}





-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 9:40:42 AM
Mark Lorenzen wrote:
> "Alex R. Mosteo" <devnull@mailinator.com> writes:
> 
> 
>>This is something I don't fully understand. IFAIK,
>>
>>procedure Proc (Blah : access Some_Type);
>>
>>access parameters raise an excepcion if null. So I don't get what adds
>>to the language the
>>
>>Blah : not null access ...
>>
>>construct.
> 
> 
> When using the "not null" access type, it is the responsibility of the
> caller to ensure that the parameter value is not null. This way the
> compiler can optimise away checks for a null value in the subprogram
> in question ("Proc" in your case)
> 
> Note that it is still the run-time system (and not the programmer),
> that performs the check, but it is only done once - before calling the
> subprogram. Often the check can be optimised away.

Thanks for the explanation.
0
devnull2904 (402)
3/10/2005 10:11:05 AM
Wes Groleau wrote:
> jimmaureenrogers@worldnet.att.net wrote:
>> The simple loop will always be an infinite loop unless
>> you break out early. The Ada reserved word used to
>> break out of a loop is "exit". In Ada "exit" does not
>> exit the program, only the enlcosing loop.
> Or (for nested loops), each loop can have a name,
> and the exit statement can exit out of two or more nested
> loops by using the name of the level to get out of.
> 
> Java has a construct that can do something like that.
> Does C++ ?

No. However, a 'return' from the middle of a function
(even from within the deepest nested loops) is possible.

Another way, especially designed for error handling, are
exceptions which allow "returning" from many function call
levels while cleaning up and leaving the program in a well-
defined, clean state through calling the destructors of all
stack-based objects on the way. However this requires some
care from the programmer - you have to code in an "exception-
safe" manner.
 I believe Ada also has exceptions, but I don't know if
they work in the same manner. Does Ada have some equivalent
of C++ constructors and destructors?

Falk
0
3/10/2005 10:11:45 AM
Randy Brukardt wrote:
> "Alex R. Mosteo" <devnull@mailinator.com> wrote in message
> news:422F142E.9050909@mailinator.com...
> 
>>This is something I don't fully understand. IFAIK,
>>
>>procedure Proc (Blah : access Some_Type);
>>
>>access parameters raise an excepcion if null.
> 
> 
> Not in Ada 2005. 

Ahhh. Here is the trick :)

I must re-read the gnat advance on 2005 features. There are a lot of 
exciting changes coming.

> That restriction makes it very difficult to do C
> interfacing, among other things. Moreover, keeping the restriction would
> have made the expansion of anonymous access types to most contexts unusable
> (you need a null value sometimes!). The only case where "not null" is
> implicit is if the parameter is controlling (that's necessary for
> compatibility - I think most of us hate it, but there doesn't seem to be an
> alternative).
> 
> 
>>So I don't get what adds
>>to the language the
>>
>>Blah : not null access ...
>>
>>construct.
> 
> 
> Because it (a) makes the restriction explicit, and (b) you can use it
> anywhere: on named access types, on variables and components, in generic
> formals, etc.
> 
>    type Acc is access Some_Type;
>    procedure Proc (P : in not null Acc);
> 
>                                Randy Brukardt
0
devnull2904 (402)
3/10/2005 10:13:20 AM
Ioannis Vranos wrote:

> How can this be done in Ada?

The same way, using the random number generator and the
STL-like containers. (See Ada 95 for the genertors, and
AI-302 or Ada 2005 for the STL-like container library.)

Functions are passed to a passive iterator like in

    ...
    procedure some_proc (e: int);
    ...
    iterate(some_vec, some_proc'access);


Georg
0
sb463ba3 (41)
3/10/2005 10:28:46 AM
Georg Bauhaus wrote:
> Falk Tannh=C3=A4user wrote:
>> Such function objects can be of dedicated classes, or can be construct=
ed
>> "on the fly" (even it the latter possibility is sometimes a bit awkwar=
d
>> due to the lack of closures / lambda expressions in the language - btw=
,
>> does Ada have something like that?).
> Ada 2005 adds downward closures. They have been available in GNAT/GCC
> for a number of years now.
> For pure Ada 95 there is a workaround using dispatching.
>=20
> Is a function object similar to a downward closure?

Well, I tried to google what Ada "downward closures" are but since I
don't know the language, I'm not sure I properly understood how they
work (shame on me!).

An example of using a C++ standard function object to find the index
of the first element in a vector being greater than 666 looks like

   std::vector<int> vec;
=2E..
   std::vector<int>::iterator it =3D std::find_if(vec.begin(), vec.end(),=

                                                std::bind2nd(std::greater=
<int>(), 666));
   if(it =3D=3D vec.end())
     std::cout << "Not found!\n";
   else
     std::cout << "Found at index " << (it - vec.begin()) << ", value =3D=
 " << *it << '\n';

Of course, it would be nicer, easier and more flexible if you could write=

something like (syntax totally hypothetical!):
   std::vector<int>::iterator it =3D std::find_if(vec.begin(), vec.end(),=

                                                lambda{x; x>666} );

Adding something like this to C++ is currently under discussion / pre-stu=
dy
and it is not yet clear how the result will look like...

Falk
0
3/10/2005 10:45:30 AM
Georg Bauhaus wrote:

> The same way, using the random number generator and the
> STL-like containers. (See Ada 95 for the genertors, and
> AI-302 or Ada 2005 for the STL-like container library.)
> 
> Functions are passed to a passive iterator like in
> 
>    ...
>    procedure some_proc (e: int);
>    ...
>    iterate(some_vec, some_proc'access);


Has Ada this level of abstraction and compile-time safety? (the same 
code made more high-level):


#include <iostream>
#include <vector>
#include <ctime>
#include <algorithm>
#include <functional>
#include <map>
#include <iterator>


int main()
{
     using namespace std;

     vector<int> vec(1000);

     map<int, int> iimap;

     // Seeds the random number generator
     srand(time(0));

     // Use rand() to fill vector with values
     // As you see the operation is entirely safe.
     generate(vec.begin(), vec.end(), rand);


     // Finds the first occurrence of an int smaller than 1000
     vector<int>::iterator p= find_if(vec.begin(), vec.end(),
                                             bind2nd(less<int>(), 1000) );

     int index= distance(vec.begin(), p);

     // Stores the index and the value in a map
     iimap[index]= *p;


     cout<<"index: "<<index<<"\tValue: "<<iimap[index]<<"\n";
}


C:\c>temp
index: 32       Value: 169

C:\c>



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 10:51:14 AM
Ioannis Vranos wrote:

> For example consider this simple bullet-proof code for string input and 
> processing:
> 
> 
> #include <iostream>
> #include <string>
> 
> int main()
> {
>     using namespace std;
> 
>     string s;
> 
>     while(cin)
>     {
>         getline(cin,s);
> 
>         /*Do things with s */;
>     }
> }

When I run your program and have it read the null
device, it stops after reading 536870883 bytes if s.length()
is right. This number is 29 bytes less than 2^29; however,
s.max_size() is printed as 1073741820, which is 4 bytes less
than 2^30.
There is 1G of memory in the system. Is this an implementation
detail/system specific? I'm not now expecting a compiler for
any language to read past 512M, but I'd like to know what
is going on.

I noticed

   size_type max_size () const
     { return (npos - 1)/sizeof (charT); }               // XXX

in the header file for string, the XXX is in the original.
0
sb463ba3 (41)
3/10/2005 11:29:03 AM
Georg Bauhaus wrote:

> Ioannis Vranos wrote:
> 
>> For example consider this simple bullet-proof code for string input 
>> and processing:
>>
>>
>> #include <iostream>
>> #include <string>
>>
>> int main()
>> {
>>     using namespace std;
>>
>>     string s;
>>
>>     while(cin)
>>     {
>>         getline(cin,s);
>>
>>         /*Do things with s */;
>>     }
>> }
> 
> 
> When I run your program and have it read the null
> device, it stops after reading 536870883 bytes if s.length()
> is right. This number is 29 bytes less than 2^29; however,
> s.max_size() is printed as 1073741820, which is 4 bytes less
> than 2^30.

The program should read

  #include <iostream>
  #include <istream>
  #include <string>

  int main()
  {
    std::string s;
    while(std::getline(std::cin, s))
    {
      // Do things with s
    }
    return 0;
  }

so that the loop body is not executed after failing of getline().
However, even the original version, while reading from /dev/null,
should execute the loop only once and leave the string 's' empty
since End Of File should be detected on the first attempt to
read a character. Could it be there is something seriously wrong
with your compiler / standard library installation?

Falk
0
3/10/2005 11:57:14 AM
> > 
> > It looks like the code was not ISO C++ compliant.
> 
> In that case, it looks like the compiler failed to detect that shortcoming.

Well, it's time for me to join the 'American Dentist Association vs
C++' flame war:

1. Is Ada case-insensitive as Pascal? In that case, Ada==ADA

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

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)

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.

5. In fact, there are standard mechanisms (STL) to handle these array
bound checking issues with ease.

6. I don't know what's the point with "aDA being used in avionics or
rocket science". Planes and rockets are falling from the sky from time
to time; a few satellites are lost, too; NASA once failed to mix SI
units and British unit system (where's the stronger type and range
checking here?)...

Regards,

[1] "The C++ Programming Language" 3rd Special Edition, Bjarne
Stroustrup, 24.2

[2] "The C++ Programming Language" 3rd Special Edition, Bjarne
Stroustrup, 1.4

P.S.: For the next battle, I suggest comp.lang.ada vs
comp.lang.visualbasic.
0
azdo_b (18)
3/10/2005 11:59:47 AM
Ioannis Vranos wrote:
> Georg Bauhaus wrote:
> 
>> The same way, using the random number generator and the
>> STL-like containers. (See Ada 95 for the genertors, and
>> AI-302 or Ada 2005 for the STL-like container library.)
>>
>> Functions are passed to a passive iterator like in
>>
>>    ...
>>    procedure some_proc (e: int);
>>    ...
>>    iterate(some_vec, some_proc'access);
> 
> 
> 
> Has Ada this level of abstraction and compile-time safety? (the same 
> code made more high-level):

The starting point of the aforementioned AI-302/Ada 2005 container
library is Charles, which is STL in Ada, including a rich set
of algorithms. But I don't think that a comparison of language
facilities is best served by concentrating on algorithms written
in the language to overcome some of the languages shortcomings.
That's cheating.

Notice how you use e.g. distance to work around things that
are more present in Ada than in C++ "proper". Notice also that
template metaprogramming is a lot more present in C++ than in Ada.

Now if the basis of C++ can and should be overcome as you demonstrate,
why stick to the baiss of C++ when obviously all the value is in STL?
Glad we have D at least :-)

And yes, all sorts of compile time checking is done with Ada 2005
containers. Only many of the checks have to do with the Ada language
"proper". Given there is little template metaprogramming in Ada,
different things are checked at other levels.


>     // Use rand() to fill vector with values
>     // As you see the operation is entirely safe.
>     generate(vec.begin(), vec.end(), rand);


As an Ada example

    package int_Vectors is new Ada.Containers.Vectors(C.int);
        -- supplies type Vector of int, i.e. "std::vector<int>"

    vec: Vector;
    ...
    procedure rand (i: Cursor);
      -- stores a random value in the element at cursor i

    iterate(vec, rand'access);


I think you recognize the idiom. But we are in a sense no longer
talking about programming *languages*, this is about libraries,
so I'd rather stop here.

0
sb463ba3 (41)
3/10/2005 12:04:43 PM
Alberto wrote:
> Well, it's time for me to join the 'American Dentist Association vs
> C++' flame war:

it is "American DentAL Association", so if you want to flame, at least 
flame with exactitude...

> P.S.: For the next battle, I suggest comp.lang.ada vs
> comp.lang.visualbasic.

this one would be very fun...

-- 
rien
0
3/10/2005 12:05:48 PM
Alberto wrote:
> 6. I don't know what's the point with "aDA being used in avionics or
> rocket science". Planes and rockets are falling from the sky from time
> to time; 

Ada is also used in particular rockets called missiles, and its job 
inside is just to make them fall... but fall gracefully.

-- 
rien
0
3/10/2005 12:09:22 PM
Georg Bauhaus wrote:

> The starting point of the aforementioned AI-302/Ada 2005 container
> library is Charles, which is STL in Ada, including a rich set
> of algorithms. But I don't think that a comparison of language
> facilities is best served by concentrating on algorithms written
> in the language to overcome some of the languages shortcomings.
> That's cheating.


Actually these are the high-level facilities of C++ (yes its library) 
which can be implemented with the language itself by the way.

This is the preferred way of programming in C++, and I am going to move 
to that way (I am still learning C++).


> 
> Notice how you use e.g. distance to work around things that
> are more present in Ada than in C++ "proper". Notice also that
> template metaprogramming is a lot more present in C++ than in Ada.


Template metaprogramming is a very useful field. I am not sure if you 
are mentioning it as an advantage or disadvantage, it is about turning 
run-time operations to compile-time.



> 
> Now if the basis of C++ can and should be overcome as you demonstrate,
> why stick to the baiss of C++ when obviously all the value is in STL?


This is the recommended way of programming in C++. The low level parts 
are to be used only when we can't do otherwise.


These standard library facilities get also much inlined, thus producing 
even more efficient code than the use of the low level parts!



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 12:18:11 PM
Alberto wrote:
>>>It looks like the code was not ISO C++ compliant.
>>
>>In that case, it looks like the compiler failed to detect that shortcoming.
> 
> 
> Well, it's time for me to join the 'American Dentist Association vs
> C++' flame war:

Boh, the flaming here has been pretty low. In fact I'm getting very 
interesting info from both fronts and both languages.

> 1. Is Ada case-insensitive as Pascal? In that case, Ada==ADA

Here, you're the one being insensitive :P

  > 6. I don't know what's the point with "aDA being used in avionics or
> rocket science". Planes and rockets are falling from the sky from time
> to time; a few satellites are lost, too; NASA once failed to mix SI
> units and British unit system (where's the stronger type and range
> checking here?)...

I suppose the point is that people programming things which may cause 
human deaths (I see the jokes coming...) see Ada as a better tool than 
others, for reasons we can argue indefinitely...
0
devnull2904 (402)
3/10/2005 12:37:17 PM
Ioannis Vranos wrote:

> Template metaprogramming is a very useful field. I am not sure if you 
> are mentioning it as an advantage or disadvantage, it is about turning 
> run-time operations to compile-time.

I'm mentioning it as an advantage, in spite of the time that the
translation tool chain needs to execute the template metaprograms,
and in spite of the not so helpful error messages you get, currently.

It is interesting though that programmers are fond of the new
programming language called templates. A clever trick to achieve
cognitive consonance that lets people maintain both the view that
C++ is great (because of templates) and that C++ should be avoided
(because of the low level parts).

Georg
0
sb463ba3 (41)
3/10/2005 1:13:47 PM
In article <1110429102.189423@athnrd02>, Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Yes you can write completely safe, bullet-proof code in C++ and without 
> sacrificing efficiency  (and some times even improving it!) by using the 
> high level C++ constructs. Examples are: find family (which includes 
> find_if etc), search family, generate, fill, for_each, count, mismatch, 
> equal, transform, copy, swap, replace, remove, unique, rotate, sort, 
> bound, merge, partition, includes, set (like set_union), heap (like 
> make_heap - makes sequences behave as heaps), comparisons (like min, 
> max, lexicographical_compare), permutation, etc families.
> 
> 
> We can say it is an entirely completely safe, high level language of its 
> own, and in this way you may never use loops for most things!

Are there compilers for it ?

By which I mean, compilers that will balk at compiling when users fail
to make those careful choices of high-level constructs.
0
Kilgallen (2738)
3/10/2005 1:16:50 PM
In article <e39403d5.0503100359.5c975706@posting.google.com>, azdo_b@yahoo.es (Alberto) writes:
>> > 
>> > It looks like the code was not ISO C++ compliant.
>> 
>> In that case, it looks like the compiler failed to detect that shortcoming.
> 
> Well, it's time for me to join the 'American Dentist Association vs
> C++' flame war:
> 
> 1. Is Ada case-insensitive as Pascal? In that case, Ada==ADA

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.

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

> 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.
0
Kilgallen (2738)
3/10/2005 1:24:45 PM
In article <423038f2$0$14970$ba620e4c@news.skynet.be>, Adrien Plisson <aplisson-news@stochastique.net> writes:
> Alberto wrote:
>> 6. I don't know what's the point with "aDA being used in avionics or
>> rocket science". Planes and rockets are falling from the sky from time
>> to time; 
> 
> Ada is also used in particular rockets called missiles, and its job 
> inside is just to make them fall... but fall gracefully.

Gracefully is a matter of perspective, depending on whether it is
falling in your own neighborhood.
0
Kilgallen (2738)
3/10/2005 1:25:41 PM
> Template metaprogramming is a very useful field.

Yes. Generic programming. This is a worth discussing issue in a an Ada 
v.s C++ battle.

(Forget libraries being or not being implemented in the language, 
forget inlining, these are trivial issues. Of course Ada.Containers is 
written in Ada, and of course the crucial operations are inlined.)

Now, generics.

We should keep in mind that the STL begun life as an Ada library.  See 
the famous Stepanov interview at 
http://www.sgi.com/tech/stl/drdobbs-interview.html  His contact with 
Ada generics was crucial for the development of C++ templates and the 
STL.  He move to C/C++ for career reasons and basically he (consulting 
with Stroutstrup) created C++ templates because he needed generics in 
C++ to do there what he had done in Ada!

Of course along the way C++ generics was made very different from 
Ada's. In general more powerful.  Less safe?  I don't know.

Two limitations of Ada 95 generics are: a generic cannot be 
instantiated inside itself; the generic formal types must match, not 
just the actuals.  I think Ada 2005 did not change this directly, but 
she has a couple of new tricks e.g. interfaces that might help 
circumvent it.

0
amado.alves (488)
3/10/2005 1:32:10 PM
On 10 Mar 2005 03:59:47 -0800, Alberto wrote:

> 1. Is Ada case-insensitive as Pascal? In that case, Ada==ADA

Well, Ada is not English. So Ada's rules about names are not applicable to
Ada's name. BTW, with C++ it is even worse: "C++" isn't a valid C++ name!
Though it nicely reflects the semantic of its usage: use what we have now,
it will be better later! (:-))

> 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:

1. 

exception
   when A => ...
   when B => ...

is strictly equivalent to

exception
   when B => ...
   when A => ...

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

class BaseException
{
public :
   virtual void TellStories () = 0;
};

try
{
   ...
   { // Nested
      int I = 123; 
      class NewException : public BaseException
      {
      public
         void TellStories () { printf ("%d", I); }
      };
      throw NewException ();
   }
   ...
}
catch (BaseException& Error)
{
   Error.TellStories ();
}

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

> 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)

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.

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

> 5. In fact, there are standard mechanisms (STL) to handle these array
> bound checking issues with ease.

They cannot be so effective as in Ada.

1. See above about constraining.
2. C++ is unable to allocate objects of indefinite size on the stack.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/10/2005 1:42:52 PM
Georg Bauhaus wrote:

> I'm mentioning it as an advantage, in spite of the time that the
> translation tool chain needs to execute the template metaprograms,
> and in spite of the not so helpful error messages you get, currently.
> 
> It is interesting though that programmers are fond of the new
> programming language called templates.

It is a paradigm. Given that most languages support only one paradigm 
(and many times *not* well - e.g. Java and OO paradigm, no complete 
multiple inheritance support), one may tend to describe templates as a 
"language" of its own, but it is one the four paradigms supported *well* 
(=completely) by C++.


> A clever trick to achieve
> cognitive consonance that lets people maintain both the view that
> C++ is great (because of templates) and that C++ should be avoided
> (because of the low level parts).

It is better to say that C++ is *both* a high level and a low level 
language, and unless one can't do otherwise, he should stick with the 
high level part of it.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys
0
ivr208 (995)
3/10/2005 1:44:18 PM
Falk Tannhäuser wrote:

> Well, I tried to google what Ada "downward closures" are but since I
> don't know the language, I'm not sure I properly understood how they
> work (shame on me!).

I believe downward closures are not at all Ada-specific.

In Ada, you pass a function f as a parameter to another
function g(..., f) *even* when f is declared at a place more
deeply nested than the declaration of g.
So f has access to objects up the nesting level, i.e. to
its environment, g has not.

For example, the Ada container library provides procedures
"iterate", consuming a container and a procedure pointer.
In abbreviated peudo-notation:

container library:

   procedure iterate(a container X, a procedure P);
     -- invoke P for every element in X

your program:

   procedure work (a container X) {
      ... local declarations

      procedure f (a cursor K) {
         -- local procedure with access to X's element a K,
         -- and to the local declarations
         ...
      }

      iterate(a container, f);
   }

When iterate executes, both the local declarations and f still
exist, they are accessible. But iterate is declared somewhere
else, f is more nested.

The accessibility rules imply that iterate can only invoke f, or
pass it on to other procedures, but f cannot for example be
assigned to a global variable because when work has executed,
f becomes inaccessible.

Here is a small and simple Ada 2005 example that I think comes
fairly close to the (here named) lambda expression you have given.

procedure find_gt_666 is

    vec: Vector;  -- of integers
    here: Cursor := No_Element;  -- end()

    procedure first_gt_666(x: Cursor) is
    begin
       if not Has_Element(here) and then Element(x) > 666 then
          here := x;
       end if;
    end first_gt_666;

begin
    ... populate vec

    iterate(vec, first_gt_666'access);

    ... use Element(here)
end find_gt_666;


> Of course, it would be nicer, easier and more flexible if you could write
> something like (syntax totally hypothetical!):
>   std::vector<int>::iterator it = std::find_if(vec.begin(), vec.end(),
>                                                lambda{x; x>666} );

Eiffel agents might come even closer to this as they can be defined
in place.

Georg
0
sb463ba3 (41)
3/10/2005 2:25:32 PM
Georg Bauhaus wrote:

 >  procedure work (a container X) {
>         ...
>      }
> 
>      iterate(a container, f);

        iterate(X, f);
0
sb463ba3 (41)
3/10/2005 2:31:45 PM
CTips wrote:
>  - the safety features of Ada can come with a significant run-time cost

I am willing to sacrifice the run-time cost for proven safety.

> C doesn't have that cost. However, if you want to have similar levels of 
> checking, you have to roll your own run-time checks. On the other hand, 
> because you're rolling your own, the run-time checks are a lot less 
> expensive.

And a lot more fragile.  Will we ever get away from the 'rolling your 
own' mentality?

> Also, since a lot of interesting things require escaping from the core 
> language and bending the rules of the language, you have two options:
>   - you can write it all in assembly
>   - or you can write in a language where you can reasonably expect that 
> your bending of the rules won't make the compiler do something you 
> didn't expect.

> I'd rather use C for this purpose.

And I would rather not use your 'rolled' stuff for safety critical 
systems.

0
3/10/2005 2:34:56 PM
CTips wrote:

> You can measure the slowdown yourself. Try running the following loop in 
> Ada:
>    void do_perm(int a[], int perm[])
>    {
>    int i;
>    for( i = 0; i < VERY_LARGE_NUMBER; i++ )
>       a[perm[i]] = i;
>    }
> 
> where perm[i] is a dynamically created array, such as:
>    void setup_perm(int perm[])
>    {
>    int i;
>    for( i = 0; i < VERY_LARGE_NUMBER; i++ )
>      perm[i] = i;
>    }
> Run the codes with and without bounds checking and see the difference.

Done. You might be disappointed by the results. In short:
< 1%, < 3%; and < 8% for a different program, really.

  [...]

If I run your program as an Ada program, I must use unconstrained
arrays to get a significant difference at all. And in this case I am
no longer copying the meaning of the C program. If I use arrays of known
sizes, and turn all checks ON, the Ada/C ratio is near 1.03.
Still this is certainly *not* using the C subset of Ada because the
compiler sees Ada arrays of integers, not C int[]s, it is compiling
Ada programs, using Ada rules, semantics, optimizations, passing
modes etc..

If I turn checks off then there is no more significant difference.

If I rewrite your program and actually implement a different algorithm,
as outlined in your post (unconstrained arrays),
then indeed this program runs with a slowdown of 7-8%.

But same speed of Ada and C programs doesn't mean "C subset",
since to run at about the same speed, I don't have to turn off
the checks, and I don't loos all language constructs.
If you think that a factor of 0.03 generally is an inacceptable
slowdown so no checks please etc, then I don't know what to say.
Except that marketing works this way.

gcc -W -O2 -ansi -pedantic  (C)
gnatmake -O2 -gnato -gnatE -gnatVa -fstack-check -gnatwa (Ada, checks)
gnatmake -O2 -gnatp -gnatwa  (Ada, no checks)

GCC 4.0.0, 20050215 in all cases

Here is the slow version, that is, the different algorithm, really.
The near same speed version can be obtained by shifting three
comments.

with Perms;

procedure perm_a is
    use Perms;

    perm: constant PA_Ptr := new Perm_Array(0 .. VERY_LARGE_NUMBER - 1);
    other: constant PA_Ptr := new Perm_Array(0 .. VERY_LARGE_NUMBER - 1);
    --perm: constant PA_Ptr := new Perm_Array;
    --other: constant PA_Ptr := new Perm_Array;

begin
    setup_perm(perm.all);
    do_perm(other.all, perm.all);
end Perm_A;

package Perms is

    VERY_LARGE_NUMBER: constant := 100_000_000;

    type Perm_Array is array(Natural range <>)  of Integer;
    --type Perm_Array is array(0 .. VERY_LARGE_NUMBER - 1)  of Integer;

    type PA_Ptr is access Perm_Array;

    procedure do_perm(a: out Perm_Array; perm: in Perm_Array);
    procedure setup_perm(perm: in out Perm_Array);

end Perms;


package body Perms is

    procedure do_perm(a: out Perm_Array; perm: in Perm_Array) is
    begin
       for i in perm'range loop
          a(perm(i)) := i;
       end loop;
    end do_perm;

    procedure setup_perm(perm: in out Perm_Array) is
    begin
       for i in perm'range loop
          perm(i) := i;
       end loop;
    end setup_perm;

end Perms;


> In the case 
> of a feature rich language like Ada (or C++), much of the effort goes 
> into getting all the features right. In C, almost all the effort goes 
> into the optimizations. Even when people appear to use the same backend, 
> in practice, there are various optimizations which get disabled for 
> non-C languages because they break at various corner cases in other 
> languages.

Seems not to apply here, but this is just one case. Is there
evidence of significant optimization superiority of C in the general
case?

Georg
0
sb463ba3 (41)
3/10/2005 4:39:47 PM
Alberto wrote:

> 1. Is Ada case-insensitive as Pascal? In that case, Ada==ADA

What does an Air Defense Artillery unit have to do with this? :)
0
no.spam9 (2339)
3/10/2005 4:40:17 PM
Ioannis Vranos <ivr@remove.this.grad.com> writes:

> How can this be done in Ada?
> 
> As it can be seen here, the bullet-proof high level facilities are used. :-)

Ok, you want to play this game :) I like it...

How would you implement this (100% Ada, no external libraries as used in
your C++ example):

   package API is
      pragma Remote_Call_Interface;

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

Seriously, we are not going to build thousands of examples for C++ and Ada,
right ?

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
0
pascal27 (183)
3/10/2005 5:35:38 PM
azdo_b@yahoo.es (Alberto) writes:

> Well, it's time for me to join the 'American Dentist Association vs
> C++' flame war:

You've probably not read the whole thread. It seems to me that we are far from
a language flame war. At least I found (being on the Ada side) some very
interresting messages about C++ here.

Or maybe you are trying to start one!

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
0
pascal27 (183)
3/10/2005 5:54:11 PM
"Alex R. Mosteo" <devnull@mailinator.com> writes:

> Boh, the flaming here has been pretty low. In fact I'm getting very
> interesting info from both fronts and both languages.

Exactly, the C++ meta-template programming seems quite interesting.

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
0
pascal27 (183)
3/10/2005 5:55:26 PM
Turamnvia Suouriviaskimatta <TS@ada-france.org> wrote on 05/03/2005 (14:00) :
> 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?

It is not hard at all, but one thing you must do and that is:

   Never demand that the way you do something in C/C++ is the correct
   way to do it in Ada. :-) The Ada way is different because the Ada
   language is different.

   First thing you will notice is that the use for pointers in Ada is
   very small compered to C/C++.

Some links:

http://www.adahome.com/Ammo/cpp2ada.html

(Note! This site is dead, meaning no longer updated, but the tutorial
can give you a nice start)

Use these sites to learn more:

http://www.adapower.com/
http://www.adaworld.com/

There are several on-line books available. I can recommened:

Ada distilled (great for people who knows programming)

Ada 95: The Craft of Object-Oriented Programming

and

Object-oriented Software Design in Ada 95 2nd Ed.
(this latter book is considered too C++ flavoured to be a "the Ada way"
book, but it may be useful)

You'll find them on the sites above...

Good luck! (not that you'll need it ;-) )

Preben
0
cla5302 (38)
3/10/2005 6:25:33 PM
"EventHelix.com" <eventhelix@gmail.com> wrote on 05/03/2005 (14:20) :
> What specific features are you missing in C++. Before moving
> to Ada consider this:
> 
> - It will be hard to find developers for Ada
> - You might end up making more mistakes with Ada because of
>    inexperience with Ada.
> - Ada tools will fall short of the extensive set of C++ related tools.

Nice little troll you are. Pity you are so stupid and ignorant though!

Preben
0
cla5302 (38)
3/10/2005 6:26:49 PM
Peter Koch Larsen <pklspam@mailme.dk> wrote on 05/03/2005 (16:35) :
> I sort of like this one as well - although raising an exception seems to be 
> to forgiving.
> My conclusion is that there are some nice ideas out there, but that they 
> mainly protect against the "sloppy" programmer.

Only ignorant morons claim that they are infallible. Yes read it the way
I said it.

"When Roman engineers built a bridge, they had to stand under it while
 the first legion  marched across.  If programmers today  worked under
 similar  ground rules,  they might well find  themselves getting much
 more interested in Ada!"                              -- Robert Dewar

I would like to see you as a test object for a pacemaker, new airline
etc... written in C++ by and infallible programmer.


Preben
0
cla5302 (38)
3/10/2005 6:32:38 PM
On 2005-03-05, Ioannis Vranos <ivr@remove.this.grad.com> wrote:
> With Ada aside (I find no reason why one should not learn it), C++ is a 
> powerful and systems programming language, and power implies painful low 
> level details. However it also provides all major high level facilities, 
> and if you stick in high level programming it is very safe, while it 
> maintains the maximum space and run-time efficiency principle.


C++ programmers will claim to their death that they are infallible and
everybody else isn't. However, none of them seem to understand how ignorant
they are...

If C++ is safe, then so is a bog.

Preben
0
3/10/2005 6:39:18 PM
"Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
message news:42309456$1@news.broadpark.no...

> C++ programmers will claim to their death that they are infallible and
> everybody else isn't. However, none of them seem to understand how
ignorant
> they are...

And this is different from Ada programmers how?

There are obviously two groups here.  First, there are the Ada guys who seem
to think that modern C++ is the same language Dennis Ritchie invented 30
years ago.  Then there are the C++ guys who view Ada as a sort of military
style Cobol.

The two camps are equally close to the truth.

...


0
3/10/2005 8:55:17 PM
On Thu, 10 Mar 2005 15:55:17 -0500, xpyttl <xpyttl_NOSPAM@earthling.net>  
wrote:

> The two camps are equally close to the truth.

Fortunately, it mostly hasn't been that bad as language debates go ;-)

- Ed
0
falis (298)
3/10/2005 9:15:37 PM
"xpyttl" <xpyttl_NOSPAM@earthling.net> writes:

> There are obviously two groups here.  First, there are the Ada guys who seem
> to think that modern C++ is the same language Dennis Ritchie invented 30
> years ago.  Then there are the C++ guys who view Ada as a sort of military
> style Cobol.
> 
> The two camps are equally close to the truth.

Right, both statements are certainly wrong.

Yet, Preben point was that Ada has been designed from the start to be safe
were C++ was not. As many have pointed out there is different C++, one based on
templates, STL... and is safer... but yet a programmer is a programmer. What we
are saying on the Ada side is that at some point you'll exit the safe side for
some reasons (I'm sure nobody will say this impossible, we are just human) and
the compiler will never tell. Code review will certainly help. But again this
is costly.

Most of us on the Ada side are considering that what is important in a
language is not what it permits but what it prohibits for just this reason. We
will all step on the wrong side at some point, we want the language and the
compiler to be able to warn us. Of course this can look frustrating but it is
invaluable in the long run.

I can't speak for the whole Ada community, so if you do not share this view,
feel free speak up :)

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

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
0
pascal27 (183)
3/10/2005 9:18:52 PM
"Alex R. Mosteo" <devnull@mailinator.com> writes:

> Mark Lorenzen wrote:
> > "Alex R. Mosteo" <devnull@mailinator.com> writes:
> >
> >>This is something I don't fully understand. IFAIK,
> >>
> >>procedure Proc (Blah : access Some_Type);
> >>
> >>access parameters raise an excepcion if null. So I don't get what adds
> >>to the language the
> >>
> >>Blah : not null access ...
> >>
> >>construct.
> > When using the "not null" access type, it is the responsibility of
> > the
> > caller to ensure that the parameter value is not null. This way the
> > compiler can optimise away checks for a null value in the subprogram
> > in question ("Proc" in your case)
> > Note that it is still the run-time system (and not the programmer),
> > that performs the check, but it is only done once - before calling the
> > subprogram. Often the check can be optimised away.
> 
> Thanks for the explanation.

You're welcome. But Randy (a language lawyer) put it in perspective
with the Ada 2005 standard in another posting, much better than what I
could do.


Regards,
- Mark Lorenzen
0
3/10/2005 9:22:09 PM
* Pascal Obry wrote:
> "Alex R. Mosteo" <devnull@mailinator.com> writes:
>> Boh, the flaming here has been pretty low. In fact I'm getting very
>> interesting info from both fronts and both languages.
>
> Exactly, the C++ meta-template programming seems quite interesting.

Of course, it's an interesting Lisp implementation.
Unfortunly it does only generate C++ code.
0
lutz8272 (211)
3/10/2005 9:26:36 PM
"Alex R. Mosteo" <devnull@mailinator.com> writes:

> Boh, the flaming here has been pretty low. 

Yes.  That's refreshing.

>...In fact I'm getting very
> interesting info from both fronts and both languages.
  ^^^^^^^^^^^^^^^^

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

- Bob
0
bobduff (1543)
3/10/2005 10:15:32 PM
xpyttl wrote:

> "Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
> message news:42309456$1@news.broadpark.no...
> 
>> C++ programmers will claim to their death that they are infallible and
>> everybody else isn't. However, none of them seem to understand how
> ignorant
>> they are...
> 
> And this is different from Ada programmers how?
> 
> There are obviously two groups here.  First, there are the Ada guys who
> seem to think that modern C++ is the same language Dennis Ritchie invented
> 30
> years ago.  Then there are the C++ guys who view Ada as a sort of military
> style Cobol.
> 
> The two camps are equally close to the truth.

I fall into the third camp. 

Now, I know a lot of people who do use C, C++, Ada and Java in mission 
critical systems and do so successfully. Most of them use some form of 
checking tools (even the Ada guys). It is certainly a long way from the "if 
it compiles it is right" attitude that has seemed to have been purported by 
just a very few of the Ada crowd here.

I have always held that the language used is immaterial to the safety of 
final product (I certainly stated it often enough here and in c.a.e). I 
acknowledge that some things can be made easier or harder by language 
choice. However, it is mainly in the development process you use where the 
integrity of the product is nurtured and the evidence of successful 
development is produced.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************
0
peb (807)
3/10/2005 10:18:38 PM
Pascal Obry wrote:
> Wes Groleau <groleau+news@freeshell.org> writes:
> 
>>And notice that Pascal did NOT have to suppress safety checks
> 
> I did: -gnatp.

oops, I thought that was something else.  How do it do with checks on?

-- 
Wes Groleau

    Nobody believes a theoretical analysis -- except the guy who did it.
    Everybody believes an experimental analysis -- except the guy who 
did it.
                                  -- Unknown
0
news31 (6772)
3/10/2005 10:22:52 PM
Pascal Obry wrote:
> Wes Groleau <groleau+news@freeshell.org> writes:
> 
>>And notice that Pascal did NOT have to suppress safety checks
> 
> I did: -gnatp.
oops.  Might be interesting (if somebody has too much time
on his hands) to explicitly write all the checks into the
C that are automatic in Ada and compare times.  Ada will win
because the compiler can optimize out more of the checks
when they are not explicit.

Also, the compiler is less likely to make typos on the checks
it does not optimize away!

-- 
Wes Groleau

Answer not a fool according to his folly,
    lest thou also be like unto him.
Answer a fool according to his folly,
    lest he be wise according to his own conceit.
                         -- Solomon

Are you saying there's no good way to answer a fool?
                         -- Groleau
0
news31 (6772)
3/10/2005 10:28:05 PM
xpyttl wrote:
> "Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
> message news:42309456$1@news.broadpark.no...
> 
>>C++ programmers will claim to their death that they are infallible and
>>everybody else isn't. However, none of them seem to understand how
> ignorant
>>they are...
> 
> And this is different from Ada programmers how?

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.

-- 
Wes Groleau
-----------
I've been framed! ...
http://www.useit.com/alertbox/9612.html
0
news31 (6772)
3/10/2005 10:35:49 PM
Jim Rogers <jimmaureenrogers@att.net> writes:

> Yes you can. You can always program in your own checks manually.
> The drawback of doing that is that you cannot simply turn them off
> with a pragma, nor can the compiler so effectively optimize those
> checks out of your program when they are unneeded.

Ada compilers can optimize away manually-programmed checks as well as
built-in checks.  Whether it can do so in any particular situation
depends on the code -- how much information is available to allow the
compiler to prove things -- but not so much on whether the checks are
built in.

Likewise, C++ compilers can optimize away manually-programmed checks in
some cases.

- Bob
0
bobduff (1543)
3/10/2005 10:36:09 PM
"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:1110409958.685759.249420@g14g2000cwa.googlegroups.com...
....
> So far, no C++ advocate seems to have said anything similar to what you
> claim, but in a way you're probably right. If we depended on Ada to do
> the job, the Internet (for one) would be drastically more secure,
> though only because nobody used it! :-) (<- explicit smiley for those
> who seem to need them...)

With or without the smiley, your comment is just the kind of unsupported
anti-Ada stuff that we see all the time. Why would the Internet not be used?
Ada is a fully general purpose programming language, and if the Internet was
mostly written in Ada, the applications and uses would be pretty much the
same (just with fewer trivial bugs).

The web server and search engine we run are completely written in Ada; our
mail server is partially written in Ada. As a client, you won't notice any
difference (other than the slowness of being behind a fairly slow Internet
connection).

                       Randy Brukardt



0
randy42 (2049)
3/10/2005 10:38:35 PM
"Ed Falis" <falis@verizon.net> wrote in message
news:opsnfw9nx75afhvo@localhost...
> On Thu, 10 Mar 2005 15:55:17 -0500, xpyttl <xpyttl_NOSPAM@earthling.net>
> wrote:
>
> > The two camps are equally close to the truth.
>
> Fortunately, it mostly hasn't been that bad as language debates go ;-)
>
> - Ed

I have been following this thread with great interest.  C++ is by far my
favorite language, but use Ada almost exclusively at work.  I love C++, but
I would not relish creating a large-scale, fault-tolerant system in it,
especially involving a large team with varying levels of skill.  This thread
has been surprisingly civil with only one or two individuals using childish
attacks and half-truth to argue their side (I won't say which).  Though, I
had to cringe when some in the C++ camp attempted to argue its safety vs.
Ada.  I would not, myself, attempt that argument.  I think its a great
language, and gives you a lot of flexibility that you can build safety upon,
but does not inherently come that way.  On the other hand, it takes effort
to write an Ada program that will crash.  If it compiles, it will usually
run.  It may not do what you intended, of course, but it won't "core dump"
or cause a reboot, etc.  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.  Can someone explain why they chose the
package as the encapsulation level for a class?

Ada features I would love to have in C++:
* "new types" and sub-ranges
* runtime template instantiation (I think being able to instantiate generics
dynamically is the coolest thing!)
* subprograms inside subprograms.  I think it would be great for use with
the STL (i.e., using a local function with std::foreach)
* packages.  namespaces are nice, but packages make modularity of very large
system a lot easier.  Especially now with "use type"
* representation specifications!!!!

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


0
bogus752 (110)
3/10/2005 10:39:13 PM
CTips <ctips@bestweb.net> writes:

> - Usually the checks will be added every place they are needed, and then
> the usual optimizations will be used to eliminate them. In other words,
> if one adds the checks manually, the compiler should eliminate them
> identically.

That's true in cases where the manual checks are equivalent to the
built-in checks.  But there are important cases where they're not.  For
example, if you pass an integer as a parameter, and inside the called
procedure use that as an array index, it is typically natural to declare
the integer parameter as a subrange whose bounds match the array bounds
(even if those bounds are dynamic).  So the array-indexing check can be
optimized away.  C++ has no integer subranges, so if you did the
equivalent in C++, with a manual check, the compiler could not normally
optimize it away.

OTOH, I suppose you could program integer subranges in C++ using
templates.

You are correct that Ada's run-time checks are not entirely free in all
cases.  In order to check the bounds, the bounds must be stored in
memory, which is a cost.  And even if the checks are suppressed, I don't
know of any Ada compiler that will avoid storing the bounds.  This is
partly because in Ada you can query those bounds (Some_Array'Length, for
example).  On the other hand, if you're querying the bounds, the
equivalent in C++ would have to store the bounds, too.

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

Pretty straightforward.  You write a package containing a "storage pool
type", with operations like Allocate (which returns an Address).
You then attach your storage pool to particular pointer types,
and then the generated code will call your operations instead of the
compiler-provided ones.  Inside your storage pool code, you will no
doubt have to do all kinds of low-level stuff -- address arithmetic,
perhaps.  Ada has plenty of support for that level of coding.

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

Use a machine-code insert.  Same way you'd do it in any language, I
suppose.  And wrap it in an abstraction layer so you can have some hope
of porting to a machine without those instructions.

- Bob
0
bobduff (1543)
3/10/2005 11:04:06 PM
"CTips" <ctips@bestweb.net> wrote in message
news:112v9p788s1684d@corp.supernews.com...
....
> Don't have something specific to Ada, but I've seen work on PL.8, which
> had similar dynamic bounds checking. They observed, *on the average*
> about 8%, but this was on a machine with a special trap instruction for
> bounds checking. It would be closer to 15-20% if the check had to be
> done using subtract/compares/branches.

The vast majority of dynamic checks are eliminated in modern Ada compilers.
Our compiler provides an option to turn that checking off, in case something
imported or uninitialized is causing problems, but it's hardly ever used.

....
> There is a secondary, but fairly important affect. Compiler resources
> are finite, and compilers also suffer from "bit-rot".

Maybe if they're written in C. :-)_ We haven't observed this effect in our
compiler (which is written in Ada, of course).

> Roughly, you can
> only cram in so much effort into a compiler before its run-time or
> bug-rates or heuristic-balancing effort become unacceptable.

I agree; which is one of the advantages of usi