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

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

[Turamnvia Suouriviaskimatta]

I 'm following various posting in "comp.lang.ada,  comp.lang.c++ , 
comp.realtime, comp.software-eng" groups regarding selection of a 
programming language of C, C++ or Ada  for safety critical real-time 
applications. The majority of expert/people recommend Ada for safety 
critical real-time applications. I've many years of experience in C/C++ (and 
Delphi) but no Ada knowledge.

May I ask if it is too difficult to move from C/C++ to Ada?
What is the best way of learning Ada for a C/C++ programmer?

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

[Ludovic Brenta]

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

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

[EventHelix.com]

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

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

[Ludovic Brenta]

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

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

[Dmitry A. Kazakov]

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

[OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

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

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

[Matthias Kaeppler]

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

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

[Jeff C]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Mark Lorenzen]

"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

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

[Mark Lorenzen]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"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 

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

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

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

[Pascal Obry]

"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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

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

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

[Ed Falis]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

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

[Larry Kilgallen]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

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 ?

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Mark Lorenzen]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

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

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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.

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

[Mark Lorenzen]

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

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

[xpyttl]

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

..

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

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

[Ludovic Brenta]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Simon Wright]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Adrien Plisson]

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

-- 
rien

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pascal Obry]

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

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

[Paul E. Bennett]

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/
********************************************************************

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pascal Obry]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Adrien Plisson]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Adrien Plisson]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Paul E. Bennett]

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/
********************************************************************

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

[Larry Kilgallen]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"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 

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

[Peter Koch Larsen]

"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 

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"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 

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jim Rogers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4932 bytes --]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ed Falis]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

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! :-)

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252; format=flowed, Size: 4227 bytes --]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pete Fenelon]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252; format=flowed, Size: 4362 bytes --]

[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

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

[Ioannis Vranos]

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

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

[Larry Elmore]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Elmore]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jim Rogers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2542 bytes --]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jim Rogers]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Frank J. Lhota]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Frank J. Lhota]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jim Rogers]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"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 

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

[Martin Krischik]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

<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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Leif Roar Moldskred]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Paul E. Bennett]

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/
********************************************************************

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Paul E. Bennett]

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/
********************************************************************

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Mark Lorenzen]

"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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Mark Lorenzen]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Leif Roar Moldskred]

"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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[xpyttl]

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

..

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pete Fenelon]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jim Rogers]

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

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

[Wouter van Ooijen (www.voti.nl)]

>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

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

[Wouter van Ooijen (www.voti.nl)]

>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

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

[Wouter van Ooijen (www.voti.nl)]

> 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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.nl)]

>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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.nl)]

>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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.nl)]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.nl)]

>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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.nl)]

>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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.nl)]

>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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.nl)]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.nl)]

>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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pascal Obry]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"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 

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

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

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

[jimmaureenrogers]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Paul E. Bennett]

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/
********************************************************************

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

[Paul E. Bennett]

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/
********************************************************************

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

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.

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

[Larry Kilgallen]

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

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

[Jim Rogers]

"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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ed Falis]

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

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

[Ed Falis]

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

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

[Mark A. Biggar]

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

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

[Martin Dowie]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.nl)]

>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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wouter van Ooijen (www.voti.nl)]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

<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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Christoph Grein]

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

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

[Vinzent 'Gadget' Hoefler]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Christoph Grein]

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

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

[Pascal Obry]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Simon Wright]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[adaworks]

"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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[adaworks]

"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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[adaworks]

"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

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

[Jerry Coffin]

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.

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

[Jerry Coffin]

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.

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

[Ioannis Vranos]

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

[OT] Assembler vs. assembly

[Marius Amado Alves]

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

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

[Dr. Adrian Wrigley]

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

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

[Hans Malherbe]

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

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

[Dr. Adrian Wrigley]

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

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

[Falk Tannhäuser]

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

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 § 17.4.3.1/1 of the Standard.

Falk

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

[Ioannis Vranos]

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

Re: [OT] Assembler vs. assembly

[Ed Falis]

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

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

[Jerry Coffin]

Falk Tannhäuser 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 § 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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[John Hudak]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[John Hudak]

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

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

[Jerry Coffin]

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.

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

[Peter Amey]

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

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

[Larry Kilgallen]

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

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

[Dr. Adrian Wrigley]

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

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

[Pascal Obry]

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

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

[CTips]

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
> 

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

[Pascal Obry]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta]

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.

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

[Ludovic Brenta]

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

Re: [OT] Assembler vs. assembly

[Ludovic Brenta]

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.

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

[Larry Kilgallen]

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.

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

[Ludovic Brenta]

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

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

[Dmitry A. Kazakov]

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

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

[Martin Dowie]

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

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

[CTips]

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

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

[CTips]

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.

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

[Larry Kilgallen]

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.

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

[Martin Dowie]

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

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

[Pascal Obry]

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

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

[Georg Bauhaus]

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 

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

[Dmitry A. Kazakov]

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

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

[Pascal Obry]

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

Re: [OT] Assembler vs. assembly

[Marius Amado Alves]

> ...  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 :-)

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

[Georg Bauhaus]

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)

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

[Georg Bauhaus]

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 

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

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

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

[Ioannis Vranos]

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

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

[Ioannis Vranos]

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

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

[Ioannis Vranos]

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

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

[Jim Rogers]

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

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

[Jerry Coffin]

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.

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

[Jerry Coffin]

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.

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

[CTips]

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

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

[CTips]

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.

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

[Jim Rogers]

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

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

[CTips]

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
> 

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

[Martin Dowie]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

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

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

[Martin Dowie]

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

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

[Pascal Obry]

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

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

[Dmitry A. Kazakov]

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

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

[Pascal Obry]

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

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

[Pascal Obry]

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

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

[Dmitry A. Kazakov]

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

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

[Martin Dowie]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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

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

[Peter Hermann]

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)

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

[Ioannis Vranos]

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

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

[Pascal Obry]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

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! ;-)

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

[Georg Bauhaus]

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 

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

[Ioannis Vranos]

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

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

[Georg Bauhaus]

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 

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

[Pascal Obry]

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

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

[Marin David Condic]

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

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

[Peter Amey]

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

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

[Hans Malherbe]

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

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

[Falk Tannhäuser]

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

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

[Jerry Coffin]

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.

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

[Ed Falis]

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.

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

[Martin Dowie]

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

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

[Pascal Obry]

"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

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

[Georg Bauhaus]

Falk Tannhäuser wrote:

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

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 

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

[Alex R. Mosteo]

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.

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

[Lutz Donnerhacke]

* 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);

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

[Ed Falis]

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.

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

[Adrien Plisson]

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

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

[Georg Bauhaus]

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 

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

[CTips]

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!

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

[Pascal Obry]

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

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

[Georg Bauhaus]

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 

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

[jimmaureenrogers]

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

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

[CTips]

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?

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

[Pascal Obry]

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

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

[Pascal Obry]

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

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

[Marius Amado Alves]

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?

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

[Adrien Plisson]

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

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

[Ed Falis]

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.

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

[Georg Bauhaus]

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 

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

[Gautier]

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

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

[Larry Kilgallen]

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.

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

[Falk Tannhäuser]

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

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

[Pascal Obry]

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

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

[Jerry Coffin]

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.

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

[Pascal Obry]

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

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

[Adrien Plisson]

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

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

[Martin Dowie]

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

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

[Martin Dowie]

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

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

[Dmitry A. Kazakov]

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

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

[xpyttl]

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

..

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

[jimmaureenrogers]

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

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

[Mark Lorenzen]

"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

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

[Randy Brukardt]

"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

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

[Ludovic Brenta]

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

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

[Randy Brukardt]

"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

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

[Ludovic Brenta]

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.

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

[Randy Brukardt]

"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

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

[Randy Brukardt]

<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

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

[Jerry Coffin]

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.

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

[Ludovic Brenta]

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

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

[Jerry Coffin]

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.

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

[Martin Dowie]

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

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

[Jerry Coffin]

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.

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

[Wes Groleau]

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

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

[Wes Groleau]

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

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

[CTips]

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

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

[CTips]

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.

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

[Ioannis Vranos]

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

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

[jimmaureenrogers]

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

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

[Jerry Coffin]

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.

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

[Ioannis Vranos]

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

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

[Wes Groleau]

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.

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

[Wes Groleau]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Song Yun Zhao]

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/

:)

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

[Wes Groleau]

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

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

[Jerry Coffin]

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.

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

[Wes Groleau]

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

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

[Ioannis Vranos]

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

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

[Ioannis Vranos]

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

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

[Jim Rogers]

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

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

[Ioannis Vranos]

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

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

[Ioannis Vranos]

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

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

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

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 ?

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

[Martin Dowie]

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

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

[Pascal Obry]

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

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

[Pascal Obry]

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

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

[Jim Rogers]

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

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

[Hans Malherbe]

Goeie dag Georg

Thanks for all the replies, I'll stop wasting bandwith with trivial
questions and go find out myself.

Groete
Hans

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

[Martin Dowie]

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!

;-)

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

[Ioannis Vranos]

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

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

[Alex R. Mosteo]

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.

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

[Falk Tannhäuser]

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

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

[Alex R. Mosteo]

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

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

[Georg Bauhaus]

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

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

[Falk Tannhäuser]

Georg Bauhaus wrote:
> Falk Tannhäuser wrote:
>> 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?).
> 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?

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;
...
   std::vector<int>::iterator it = std::find_if(vec.begin(), vec.end(),
                                                std::bind2nd(std::greater<int>(), 666));
   if(it == vec.end())
     std::cout << "Not found!\n";
   else
     std::cout << "Found at index " << (it - vec.begin()) << ", value = " << *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 = std::find_if(vec.begin(), vec.end(),
                                                lambda{x; x>666} );

Adding something like this to C++ is currently under discussion / pre-study
and it is not yet clear how the result will look like...

Falk

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

[Ioannis Vranos]

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

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

[Georg Bauhaus]

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.

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

[Falk Tannhäuser]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Alberto]

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

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

[Georg Bauhaus]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Adrien Plisson]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Adrien Plisson]

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

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

[Ioannis Vranos]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Alex R. Mosteo]

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

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

[Georg Bauhaus]

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

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

[Larry Kilgallen]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

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.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

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.

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

[Marius Amado Alves]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

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

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

[Ioannis Vranos]

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

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

[Georg Bauhaus]

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

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

[Georg Bauhaus]

Georg Bauhaus wrote:

 >  procedure work (a container X) {
>         ...
>      }
> 
>      iterate(a container, f);

        iterate(X, f);

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

[Arnold]

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.

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

[Jerry Coffin]

Martin Dowie wrote:

[ ... ]

> 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?! :-)

"Think before you ask these questions Mitch."

The subject at hand was the use of C++ in the air traffic control
system.

As such, X running on top of Windows and/or UNIX becomes relevant ONLY
when tied to the development of air traffic control software. This page
shows exactly that. A page only about X on Windows or UNIX would not.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Georg Bauhaus]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[red floyd]

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

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

[Pascal Obry]

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

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

[Martin Dowie]

Jerry Coffin wrote:
> The subject at hand was the use of C++ in the air traffic control
> system.
> 
> As such, X running on top of Windows and/or UNIX becomes relevant ONLY
> when tied to the development of air traffic control software. This page
> shows exactly that. A page only about X on Windows or UNIX would not.

Well, I don't think this is *big* news to anyone! I wasn't expecting 
these things to run bare-board machines. (Actually I do know a /little/ 
about ATC, as my brother worked for years at West Drayton, the control 
centre for Heathrow).

Cheers

-- Martin

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pascal Obry]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pascal Obry]

"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

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

[Preben Randhol]

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

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

[Preben Randhol]

"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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Preben Randhol]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Preben Randhol]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[xpyttl]

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

..

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ed Falis]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pascal Obry]

"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

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

[Mark Lorenzen]

"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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Lutz Donnerhacke]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Robert A Duff]

"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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Paul E. Bennett]

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/
********************************************************************

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

[Wes Groleau]

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

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

[Wes Groleau]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Robert A Duff]

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

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

[Randy Brukardt]

"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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

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

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

[Robert A Duff]

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

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

[Randy Brukardt]

"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 using Ada. You put that effort
toward getting the design and features right, not into debugging. That's why
OOP was such a big win for most people: they discovered the advantages of
encapsulation (which of course Ada programmers had been using since the
early 80s).

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

Well, that's certainly not been the case with our compiler, and I doubt it
is with any commercial compiler: you have to be at least competitive or you
won't have customers for long. Ada compiler vendors (including GNAT) put a
lot of effort into runtime checking optimizations; the vast majority of
checks are eliminated. And code can be written to move the ones that remain
to places where they have little effect on performance -- by declaring
objects with appropriate constraints, for instance.

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

I won't speak for Georg, but I've been working on Ada compilers since 1980.
So that would be about 24 years (although I should admit that I haven't done
a lot of compiler development in the last 5 years or so, although I do
continue to maintain Janus/Ada).

In one sense, you are right, though. The Ada language provides a lot of
information to the compiler that other languages don't have. That should
allow Ada compiler optimizers to generate *better* code than C compiler
optimizers, where that same information has to be inferred. But that hasn't
been taken advantage of, possibly because of lack of resources, and probably
because of concerns about breaking poorly written Ada 83 code.

                      Randy Brukardt

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

[Randy Brukardt]

"Jim Rogers" <jimmaureenrogers@att.net> wrote in message
news:4%PXd.358789$w62.304065@bgtnsc05-news.ops.worldnet.att.net...
Jim Rogers wrote:

I would have done this program somewhat differently.

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

Much better to use an aggregate here:

     Vec := (others => My_Rand.Random(Seed));

The random function will get called once for each component. Let the
compiler write the loop; it can't do a worse job, and it might actually do
better.

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

I generally stick a test for 'Last into the loop. But that's more because
I'm lazy.

   -- finds first index where a value is less than 1000
   for I in Vec'range loop
      if Vec(I) < 1000 then
         Ada.Text_Io.Put_Line("Number < 1000 found at index" &
             Natural'Image(I));
             exit;
     elsif I = Vec'Last then
        Ada.Text_Io.Put_Line("No number < 1000 was found");
        exit;
     end if;
   end loop;

But in this case, you really ought to not use a for loop at all:

   declare
      I : Index_Type'Base := Vec'First;
   begin
      while I <= Vec'Last loop
          if Vec(I) < 1000 then
             Ada.Text_Io.Put_Line("Number < 1000 found at index" &
                Natural'Image(I));
             exit;
         end if;
         I := I + 1;
     end loop;
     if I <= Vec'Last then
       Ada.Text_Io.Put_Line("Number < 1000 found at index" &
          Natural'Image(I));
    else
       Ada.Text_Io.Put_Line("No number < 1000 was found");
    end if;
  end;

But of course this is a bit more prone to errors.

The best plan is to use a container function that does the searching, so you
don't have to.

That's probably more on this topic than anyone wanted to know. :-)

> end Random_Fill;

                     Randy Brukardt

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

xpyttl wrote:
> Then there are the C++ guys who view Ada as a sort of military
> style Cobol.

COBOL _was_ military...well Navy at least :-)

http://www.greatwomen.org/women.php?action=viewone&id=79

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Georg Bauhaus]

Martin Dowie wrote:
> xpyttl wrote:
> 
>> Then there are the C++ guys who view Ada as a sort of military
>> style Cobol.
> 
> 
> COBOL _was_ military...well Navy at least :-)

The inventor of COBOL reports basket ball as a major
influence (passing indiretly). And the effect of
private account balancing on the choice of number
systems (Oops, summed the spendings in octal...).


Georg

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Georg Bauhaus]

REH wrote:


> C++ features I would to have in Ada:

> * The STL!!! (though I hear something similar is coming?)

See, for example,
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-20302.TXT

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

[fmdf]

Alberto wrote:

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

Do you think C++ is more performing at range checking? When you don't
anymore need checkings in a Ada program you can use "Pragma
Suppress()". What can you do in a C++ program? I suppose you can only
rewrite that code.

Suppose you want a class type to hold a value in range -100 .. 100, I
think you have to code a lot to build a class that can't be mistakenly
used to hold absolut greater values.

Please compare the following two simple programs each of them have a
bug overflowing a value. I am sure that they can be better coded, or
that better solutions can be implemented as I'm not either a C++ or Ada
professional programmer, yet the C++ code is not as expressive and
compact as the Ada counterpart.

// over.cpp

#include <iostream>

using std::cout;
using std::ostream;

class Range_Error
{
public:
    Range_Error()
            : message( "raised \"Out of Range\"" ) {}
    const char* what() const { return message; }
private:
    const char* message;
};

class Var_T
{
 public:
     Var_T( const int& i = int() )
     {
         assign( i );
     }
     Var_T& operator++( )
     {
         assign( ++Var );
         return *this;
     }
     bool assign( const int& i )
     {
         if ( i >= 0 && i <= 100 )
             Var = i;
         else throw Range_Error();
         return true;
     }
     friend std::ostream& operator<<( std::ostream& out, const Var_T&
obj )
     {
         out << obj.Var;
         return out;
     }
 private:
     int Var;
 };

int main()
{
    Var_T Var( 0 );
    try
    {
        for ( int i = 0; i <= 100; ++i ) // range check error expected
            ++Var;
        cout << Var << '\n';
    }
    catch( Range_Error ERR )
    {
        cout << ERR.what() << '\n';
    }
    return 0;
}


-- over.adb

with Ada.Text_IO;
use Ada.Text_IO;

procedure Over is
-- Pragma Suppress( Range_Check );
type Var_T is range 0 .. 100;
package Var_IO is new Ada.Text_IO.Integer_IO( Var_T );
Var : Var_T := 0;

begin
    for Index in 0 .. 100 loop -- range check failing is expected
        Var := Var + 1;
    end loop;
    Var_IO.Put ( Var );
    New_Line;
exception
    when Constraint_Error =>
        Put_Line ( "Constrained Error" );
    when others =>
        Put_Line ( "Unknown Error" );
end Over;


Ada example is less than half longer than C++, it is most expressive,
it catches all exceptions (not only out of range) and it suppresses all
range checks when uncommenting "Pragma".

What dou you think of this kind of Ada unefficient and too many lines
of code example?

Ciao,

fabio de francesco

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

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.


I agree about the interesting info for both languages myself too. Just 
to be accurate, it is "template metaprogramming".



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Ioannis Vranos wrote:

> I agree about the interesting info for both languages myself too. Just 
> to be accurate, it is "template metaprogramming".


Two interesting links:

http://home.earthlink.net/~joshwalker1/writing/TemplateMetaprogramming.html

http://www.codeproject.com/cpp/crc_meta.asp


Again, it is a whole field of its own with many books about it. It is 
about turning *any* run-time operation to compile time (and the output 
can be the compiler messages).



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[fmdf]

f...@tiscali.it wrote:
> Alberto wrote:
>
> > 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)
>
> Do you think C++ is more performing at range checking? When you don't
> anymore need checkings in a Ada program you can use "Pragma
> Suppress()". What can you do in a C++ program? I suppose you can only
> rewrite that code.
>
> Suppose you want a class type to hold a value in range -100 .. 100, I
> think you have to code a lot to build a class that can't be
mistakenly
> used to hold absolut greater values.
>
> Please compare the following two simple programs each of them have a
> bug overflowing a value. I am sure that they can be better coded, or
> that better solutions can be implemented as I'm not either a C++ or
Ada
> professional programmer, yet the C++ code is not as expressive and
> compact as the Ada counterpart.
>
> // over.cpp
>
> #include <iostream>
>
> using std::cout;
> using std::ostream;
>
> class Range_Error
> {
> public:
>     Range_Error()
>             : message( "raised \"Out of Range\"" ) {}
>     const char* what() const { return message; }
> private:
>     const char* message;
> };
>
> class Var_T
> {
>  public:
>      Var_T( const int& i = int() )
>      {
>          assign( i );
>      }
>      Var_T& operator++( )
>      {
>          assign( ++Var );
>          return *this;
>      }
>      bool assign( const int& i )
>      {
>          if ( i >= 0 && i <= 100 )
>              Var = i;
>          else throw Range_Error();
>          return true;
>      }
>      friend std::ostream& operator<<( std::ostream& out, const Var_T&
> obj )
>      {
>          out << obj.Var;
>          return out;
>      }
>  private:
>      int Var;
>  };
>
> int main()
> {
>     Var_T Var( 0 );
>     try
>     {
>         for ( int i = 0; i <= 100; ++i ) // range check error
expected
>             ++Var;
>         cout << Var << '\n';
>     }
>     catch( Range_Error ERR )
>     {
>         cout << ERR.what() << '\n';
>     }
>     return 0;
> }
>
>
> -- over.adb
>
> with Ada.Text_IO;
> use Ada.Text_IO;
>
> procedure Over is
> -- Pragma Suppress( Range_Check );
> type Var_T is range 0 .. 100;
> package Var_IO is new Ada.Text_IO.Integer_IO( Var_T );
> Var : Var_T := 0;
>
> begin
>     for Index in 0 .. 100 loop -- range check failing is expected
>         Var := Var + 1;
>     end loop;
>     Var_IO.Put ( Var );
>     New_Line;
> exception
>     when Constraint_Error =>
>         Put_Line ( "Constrained Error" );
>     when others =>
>         Put_Line ( "Unknown Error" );
> end Over;
>
>
> Ada example is less than half longer than C++, it is most expressive,
> it catches all exceptions (not only out of range) and it suppresses
all
> range checks when uncommenting "Pragma".

Sorry for my English... Please read:

Ada example is more than a half shorter than C++ one, it is more
expressive, it ...

>
> What dou you think of this kind of Ada unefficient and too many lines
> of code example?

:-)

> 
> Ciao,
> 
> fabio de francesco

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

In article <d0qh1a$90t$1$8302bc10@news.demon.co.uk>, "Paul E. Bennett" <peb@amleth.demon.co.uk> writes:

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

If I understand where the various posters are coming from, there have not
been any Ada users saying "if it compiles it is right", but rather "if it
fails to compile, it is wrong" and "Ada will fail to compile on a larger
number of errors than many other languages".

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

In article <mailman.11.1110479574.23655.comp.lang.ada@ada-france.org>, Preben Randhol <randhol+cla@pvv.org> writes:
> 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.
                             ^
                             ^
                             ^
I don't normally like to draw attention to typographic errors people
make, but somehow this seems relevant in a discussion of whether any
programmer is infallible.

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

[fmdf]

Pascal Obry wrote:
> Ioannis Vranos <ivr@remove.this.grad.com> writes:
>

> [cut]

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

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

Is it true, isn't it?

fabio de francesco

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

[fabio de francesco]

Pascal Obry wrote:

> 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 think you made a big mistake by thinking you had equal results for
matrix and c_matrix execution times. Don't look at "real" value,
because it mostly depends on how much your computer is loaded while
executing programs your're timing. That is the "real" time difference
between start and end of program that is spent also in executing other
tasks by your computer. You should only look at "user" and "sys" times
that represent how much CPU time is spent for the particular program.
"user" is time spent while executing in user address space, while "sys"
is time spent while executing in kernel space on behalf of the program.

Furthermore you'd better take times after a second execution in order
to have both programs already in memory, so times are not affected by
seeking disks and some othr operations.

Ciao,

fabio de francesco

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

[Ioannis Vranos]

fmdf@tiscali.it wrote:

> -- over.adb
> 
> with Ada.Text_IO;
> use Ada.Text_IO;
> 
> procedure Over is
> -- Pragma Suppress( Range_Check );
> type Var_T is range 0 .. 100;
> package Var_IO is new Ada.Text_IO.Integer_IO( Var_T );
> Var : Var_T := 0;
> 
> begin
>     for Index in 0 .. 100 loop -- range check failing is expected
>         Var := Var + 1;
>     end loop;
>     Var_IO.Put ( Var );
>     New_Line;
> exception
>     when Constraint_Error =>
>         Put_Line ( "Constrained Error" );
>     when others =>
>         Put_Line ( "Unknown Error" );
> end Over;
> 
> 
> Ada example is less than half longer than C++, it is most expressive,



Your C++ code in a bit better shape (and more spaces, I like to add 
spaces to make the code more readable):


#include <iostream>
#include <stdexcept>


class Var_T
{
  public:
      Var_T( const int& i = int() )
      {
          if ( i >= 0 && i <= 100 )
              Var = i;

          else throw std::out_of_range("raised \"Out of Range\"");
      }

      Var_T& operator++( )
      {
          assign( ++Var );

          return *this;
      }

      bool assign( const int& i )
      {
          if ( i >= 0 && i <= 100 )
              Var = i;

          else throw std::out_of_range("raised \"Out of Range\"");

          return true;
      }

      int rvalue() const { return Var; }


  private:
      int Var;
  };



inline std::ostream& operator<<( std::ostream &out, const Var_T &obj )
{
     out << obj.rvalue();

     return out;
}


int main() try
{
     Var_T Var;

     for ( int i = 0; i <= 100; ++i ) // range check error expected
          ++Var;

     std::cout << Var << "\n";
}

catch(std::exception &ERR)
{
     std::cerr << ERR.what() << "\n";
}












> it catches all exceptions (not only out of range) and it suppresses all
> range checks when uncommenting "Pragma".
> 
> What dou you think of this kind of Ada unefficient and too many lines
> of code example?


At first personally I do not think Ada is inefficient, but I have the 
feeling that C++ is more powerful.

About the run-time checks one can easily implement a macro mechanism to 
disable checks too, with the definition of a constant like before the 
compilation like:


#define NOCHECKS


Second, templates can be used for compile-time constraints, but I do not 
know these stuff yet, so perhaps someone may provide this. And then one 
could provide such a checking mechanism via templates (not of course to 
mention once again template metaprogramming where an increment operation 
could become compile-time).



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jim Rogers]

red floyd <no.spam@here.dude> wrote in news:RL_Xd.16208$OU1.14935
@newssvr21.news.prodigy.com:

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

 It is just possible the fire control system was written in Ada :-)

Jim Rogers

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

[fabio de francesco]

fabio de francesco wrote:
> Pascal Obry wrote:
>
> > 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 think you made a big mistake by thinking you had equal results for
> matrix and c_matrix execution times. Don't look at "real" value,
> because it mostly depends on how much your computer is loaded while
> executing programs your're timing. That is the "real" time difference
> between start and end of program that is spent also in executing
other
> tasks by your computer. You should only look at "user" and "sys"
times
> that represent how much CPU time is spent for the particular program.
> "user" is time spent while executing in user address space, while
"sys"
> is time spent while executing in kernel space on behalf of the
program.
>
> Furthermore you'd better take times after a second execution in order
> to have both programs already in memory, so times are not affected by
> seeking disks and some othr operations.

Even doing so you won't get reliable results because "user" and "sys"
times can be a lot different from an execution to the other due to
context switches that can change in number. What I want to say is that
here too times depend on computer load, what is in cache after
returning from the latest context switch, hardware interrupts and a lot
of other different variables. Maybe you can get a quite reliable
statistics over a hundreds of executions, better if the two programs
are simulaneously executed with some kind of shell script.

Nothing scientific in these methods, I'm afraid.

Ciao,

fabio de francesco
 

> 
> Ciao,
> 
> fabio de francesco

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

[Ioannis Vranos]

Pascal Obry wrote:

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


What is it doing?



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Pascal Obry wrote:

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


Please do not start a real flame! Java is far behind C++. It is a silver 
bullet. Check this interesting article about silver bullets:


http://www.itworld.com/AppDev/710/lw-02-stroustrup/page_1.html


Also do not confuse the language with its framework. It is a language 
using a closed to other languages framework.


When I compare C++ to Java, I compare C++ on .NET vs Java on Java framework.

Java *loses* in both areas regarding facilities.


Regarding Ada I think it is interesting language, with about the same 
design ideals (a bias to systems programming) with C++, and this time my 
opinion is that both languages provide some advantages and disadvantages 
  between them.

In general we can say they are the same "powerful" (=expressiveness, low 
level abilities, high level abilities), and with C++ providing more 
paradigms and complete paradigm support, and Ada providing more implicit 
safety.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[fabio de francesco]

Ioannis Vranos wrote:

> Your C++ code in a bit better shape (and more spaces, I like to add
> spaces to make the code more readable):
>
>
> #include <iostream>
> #include <stdexcept>

> [cut]

> Ioannis Vranos

Thank you for your reply and for introducing me to "stdexcept" and
"std::out_of_range". I didn't know those features so I want to learn
some more about them.

B.Stroustrup wrote in his "C++ Programming Language" that He was partly
inspired by Ada (and by a misterious to me "Clu") in creating C++
templates and exceptions. Does it mean these languages are closer than
everyone would expect?

Ciao,

fabio de francesco


Ciao,

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

[Jerry Coffin]

Pascal Obry wrote:

[ ... ]

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

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

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

Thinking of Java as a safer C++ betrays misundertanding of one (or
probably) both languages. Comparisons between Ada and C++ are at least
somewhat reasonable -- while they approach the problems from entirely
different directions, both attempt to address roughly similar problem
spaces. In particular, both attempt to provide the ability to work at
nearly any level from direct bit-bashing, up to relatively high-level
expression of algorithms and their applications to collections of
objects and such.

Java differs substantially from either of these by eliminating not only
the lowest level of access, but the top levels as well. While it's
possible that the original _reason_ for inventing Java was safety
(personally, I doubt it, but I don't claim to be a mind-reader to be
able to say for sure), the result is considerably different. In point
of fact, I don't think of Java as particularly closely related to C or
C++ at all. Once you look past the syntax (I.e. the superficial parts
of the language) Java isn't much like C or C++ at all -- under the
skin, it strikes me as much more of a Smalltalk with odd syntax than C
(or C++) with modified features. Don't get me wrong -- Java isn't
really like Smalltalk either, but IMO, it's closer to Smalltalk than to
C++.

I should add that I happen to rather like Smalltalk, so that's not
entirely bad. Unfortunately, I think Smalltalk is a lot better off with
Smalltalk syntax. While I can believe that borrowing C's syntax
contributed heavily to the success of Java, I'm personally of the
opinion that C's syntax is probably its weakest point, while
Smalltalk's is a major strength.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Since it appears that several people out here are making some very basic 
mistakes when they report benchmark numbers, I thought I'd write a small 
note on how to do benchmarking.

Disclaimer: this stuff applies primarily to micro-benchmarks. It does 
not apply where the measurement is being done via a tool that uses 
built-in performance registers.

Feel free to disregard the following recommendations if you know your 
system (OS+hardware+compiler) well enough to know when to break these rules.

1. Make sure your benchmark runs for at least 0.1 sec, and preferably 
1.0.sec.
   - The timing method may only be accurate to 0.01 sec, in which case 
smaller numbers may have inaccuracies of > 10%
   - You will absorb any start-up costs [e.g., under cygwin, time 
reports that the null program takes 0.03s]

2. When running the benchmark program,
   * use an unloaded machine (i.e. as little else as possible running),
   * do multiple (3-5) runs
   * report the minimum time
  - The first couple of runs will warm the memory hierarchy, so cache 
misses/page misses don't add to the run-time.
  - Using an unloaded machine prevents pollution from other programs
  - If after multiple runs, the times do not settle down, consult an expert.

3. If you are investigating cache effects as part of your benchmarking 
efforts, make sure that you flush the cache between runs. This is best 
done by:
   * if there is an instruction that can flush the cache at one shot, 
use that.
   * if there is an instruction that can flush cache sets, figure out 
how to flush all sets in the cache.
   * otherwise just write to a large [2M+] array, and then read back 
from  it. This is _NOT_ guaranteed to flush the cache, but should do a 
decent job.

4. Make sure that the compiler has not done something really smart, like 
figuring out that the benchmark code is dead, and then eliminating the 
entire function.
   * *Always* look at a disassembly of your function.
   * In C, the best way to avoid this is to
     - put the benchmark in one file
     - repeatedly call the benchmark function from a main() that is in a 
separate file
      - compile the two files separately.

5. Do not do any I/O in your code.
   - The cost of I/O can vary unpredictably across runs
   - It can dominate the cost of the run (i.e. in a 1 sec run, the I/O 
might be 0.999s)
  * Instead of reading data from a file, use a const array.
  * Instead of printing out values, xor them together and return them 
from main.

6. Replace the benchmark function with the null function, and time the code
   * This tells you how much overhead you have.
   * Subtract this number to get the benchmark number.

7. If you're using arrays make sure you vary the size of the arrays.
   - you should see performance abruptly change as you grow past the 
sizes of the L1/L2 caches.
   - you MAY see the odd situation when you have multiple arrays (or 
multple references within the same array) where the performance for size 
N is much worse than the performance for N-16 or N+16. This may be 
because the references in the same iteration of the loop all map to the 
same cache set, and there are more references than associativity

8. If you've got branchy code, make sure that you choose input to 
appropriately exercise the branch predictor.
   - if you have actual input sequences, use those
   - if you have actual input values, but not sequences, you may want to 
randomize the order in which they are used.
   - you can report the best and worst case numbers separately.
     * for best case, send the same input multiple times, before 
switching to the next input.
     * for worst case, successive inputs should exercise different paths 
[Theres more to it, but this should suffice].

9. Check for sanity by varying the number of times the benchmark 
function is called
   * I like to call it 0.5x,2x, and 10x the base number
   * if the the time does not scale almost linearly with the number of 
calls, talk to an expert

10. Make sure that your numbers are reproducible: report
   - your times
   - your hardware
   - your system
     * OS (with version)
     * compiler (with version)
    - the compiler flags used

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[red floyd]

Jim Rogers wrote:
> red floyd <no.spam@here.dude> wrote in news:RL_Xd.16208$OU1.14935
> @newssvr21.news.prodigy.com:
> 
> 
>>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? :)
>>
>>
> 
> 
>  It is just possible the fire control system was written in Ada :-)
> 
> Jim Rogers
> 

That's quite possible.  In my artillery control software days, we tended 
to use C (systems: LTACFIRE and IFSAS), partly because we had a custom 
hardware platform without a validated compiler, and the second system 
was a port of the first.

I knew Ada, but I never admitted it if at all possible, because I hated 
Ada 83 with a passion.  Ada 95 has cleaned up most of the warts.

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

[Jerry Coffin]

Martin Dowie wrote:
> Jerry Coffin wrote:
> > The subject at hand was the use of C++ in the air traffic control
> > system.
> >
> > As such, X running on top of Windows and/or UNIX becomes relevant
> > ONLY when tied to the development of air traffic control software.
> > This page shows exactly that. A page only about X on Windows or
> > UNIX would not.
>
> Well, I don't think this is *big* news to anyone!

Perhaps not -- but the strong implication that C++ was NOT used in such
systems, seems to leave only two possible conclusions: the person who
made the implication was either ignorant or lying.

I prefer to think this WAS big news, meaning the implication was simply
an honest mistake rather than an outright lie, or the result of such a
shallow view as to ignore the majority of the system.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[fabio de francesco]

Ioannis Vranos wrote:

> [skip]

> About the run-time checks one can easily implement a macro mechanism
to
> disable checks too, with the definition of a constant like before the

> compilation like:
>
>
> #define NOCHECKS

I think that you have to heavily modify the program code, isn't true?
Instead by means of "pragma suppress();" you can leave your code as it
is, so when you have finished with all tests you do on it you can
suppress checks with only one statement. It means that every time you
come back to updating that code you can easily turn all checks on anew
every time you need it. (With pragma suppress(...) the program will
print "101" and go normally to the end).

> Second, templates can be used for compile-time constraints, but I do
not
> know these stuff yet, so perhaps someone may provide this. And then
one
> could provide such a checking mechanism via templates (not of course
to
> mention once again template metaprogramming where an increment
operation
> could become compile-time).
>
> Ioannis Vranos

If there is anyone who may provide such a checking mechanism via
templates it would be appreciated.

Ciao,

fabio de francesco

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

[CTips]

Georg Bauhaus wrote:


> Done. You might be disappointed by the results. In short:
> < 1%, < 3%; and < 8% for a different program, really.

I'm not disappointed at all, in fact the numbers are way worse than I 
expected, given that you used:

>    VERY_LARGE_NUMBER: constant := 100_000_000;

You're using 800MB of memory, and unless you have at least 1GB, you're 
probably swapping in and out. Also you're probably trashing your TLB. 
You're *definitely* thrashing all levels of cache.

The other point is that the branch prediction table is primed (i.e. it 
will always go to the dont-fail case). In a real program, the 
branch-predictor would mispredict more often.

If, after all that, the effects of the check are at all visible, it 
means that the checks are probably significant.

Try again with smaller numbers that yield arrays 1/8 the size of your L1 
and 1/4 the size of your L2. E.g., If you've got a 64 KB  L1 and a 1MB 
L2, make VERY_LARGE_NUMBER 1000 and 64000. Call this benchmark 
repeatedly till you get to a total run-time of about 1sec.

I checked; on my machine, if I run the C code below with 100k entries vs 
50k entries the performance is 4.7s vs. 0.7s ~ 6.5x slowdown vs 2x 
change in size [I'm using time under cygwin on a Xeon 3.06GHz 
dual-processor system]. This indicates that I have a 512KB L2-cache.

Now, I added the bounds check. At 50k, there is a 27% slowdown, at 100k 
there is about a 1% slowdown.

You have to be *very* careful that what you're measuring isn't hidden 
behind some other effect.

----------------------------------------------------------

#define N 50000

void
setup_perm(
         int     perm[]
         )
{
   int   i;
   for( i = 0; i < N; i++ ) {
     perm[i] = i;
   }
}

void
do_perm(
         int     perm[],
         int     val[]
         )
{
   int   i;
   for( i = 0; i < N; i++ ) {
     /*
     if( perm[i] >= N ) {
       abort();
     }
     */
     val[perm[i]] = i;
   }
}

int     perm[N];
int     val[N];

int
main(void)
{
   int   i;

   setup_perm(perm);
   for( i = 0; i < 10000; i++ ) {
     do_perm(perm, val);
   }
   return 0;
}

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

[Jerry Coffin]

Randy Brukardt wrote:

[ ... ]

> Why would the Internet not be used?

Two major reasons, plus a third upon which I'll elucidate further
below.

First of all, work on ARPAnet started out around the mid-1960's, but it
only became available to most of the public around the early 1990's or
so. Had development been delayed for 20 years or so until Ada compilers
were available, we'd be waiting another five years or so before it
became available to most of its current users.

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

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

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

The third reason: if you look closely at most internet protocols, you
quickly realize that they have a distinctly "hackish" character. Most
work "well enough", but have massive defects from a theoretical
viewpoint.

The mindset that embraces Ada simply would never have designed things
that way. Heck, I'm clearly on the C++ side of the fence, and I stil
find many of them at least mildly distasteful. Had they been designed
by Ada programmers, the hackish character would be gone. Instead, the
system would be designed to operate in harmony as a coordinated system.
To ensure that, connecting to this system would only be allowed after
passing an extensive (and expensive) certification process, and only
one OS in existence would be capable of passing -- and it wouldn't be
from a bunch of hackers like Microsoft either. It would be from some
place thoroughly professional, with a thoroughly professional license
fee (i.e. well out of reach of over 99% of the people who currently use
the Internet).

Its users would all be ecstatic about how well it worked, and would be
able to tell each other about the other day when they ran it under a
simulated load, and it showed so little degradation that they just KNOW
it'll still work beautifully when it has grown to over a thousand
users!

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Pascal Obry]

Wes Groleau <groleau+news@freeshell.org> writes:

> How do it do with checks on?

See my other post.

Pascal.

-- 

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

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

[Ioannis Vranos]

fabio de francesco wrote:

> Thank you for your reply and for introducing me to "stdexcept" and
> "std::out_of_range". I didn't know those features so I want to learn
> some more about them.


There are a lot of great things to learn in C++, if you have TC++PL 3, 
take a look at chapter 19 for example (myself have "paused" in the 
beginning of chapter 19 since more than a year ago, so as to learn some 
.NET-specific programming).


> B.Stroustrup wrote in his "C++ Programming Language" that He was partly
> inspired by Ada (and by a misterious to me "Clu") in creating C++
> templates and exceptions. Does it mean these languages are closer than
> everyone would expect?


One thing is sure, in this discussion thread with Ada programmers, I 
"feel like home", and Ada people provide examples based on facts.

I had not thought to look in TC++PL for Ada, but indeed it looks like 
there are some references:


"A programmer coming from a different language (say C, Fortran, 
Smalltalk, Lisp, ML, Ada, Eiffel, Pascal, or Modula2) should realize 
that to gain the benefits of C++, they must spend time learning and 
internalizing programming styles and techniques suitable to C++. The 
same applies to programmers used to an earlier and less expressive 
version of C++."


"Templates were partly inspired by Ada�s generics (both their strengths 
and their weaknesses) and partly by Clu�s parameterized modules. 
Similarly, the C++ exception-handling mechanism was inspired
partly by Ada [Ichbiah,1979], Clu [Liskov,1979], and ML [Wikstr� 
m,1987]. Other developments in the 1985 to 1995 time span � such as 
multiple inheritance, pure virtual functions, and namespaces � were 
primarily generalizations driven by experience with the use of C++ 
rather than ideas imported from other languages."


"[Ichbiah,1979]

Jean D. Ichbiah, et al.: Rationale for the Design of the ADA Programming 
Language. SIGPLAN Notices. Vol. 14 No. 6. June 1979."



"For many people trained in languages such as C, Pascal, Modula2, and 
Ada, there is an almost irresistible urge to organize software as a set 
of switch-statements. This urge should usually be resisted. Use virtual 
functions (2.5.5, 12.2.6) rather than RTTI to handle most cases when 
run-time discrimination based on type is needed."




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Pascal Obry]

"Jerry Coffin" <jcoffin@taeus.com> writes:

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

Just plain wrong, there is data (a PHD) see
http://www.adaic.com/whyada/ada-vs-c/cada_art.html

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

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

[Ioannis Vranos]

fabio de francesco wrote:

> If there is anyone who may provide such a checking mechanism via
> templates it would be appreciated.


I also note here that apart from "template metaprogramming" there is 
also the support of "lambda expressions", another field of its own as 
far as I know.

A C++ library providing high-level support for them is Boost:

http://www.boost.org/doc/html/lambda.html


If you download the library you can check its C++ source code.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Pascal Obry]

"fabio de francesco" <fmdf@tiscali.it> writes:

> Pascal Obry wrote:
> 
> > 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 think you made a big mistake by thinking you had equal results for
> matrix and c_matrix execution times. Don't look at "real" value,

No I did not. This is under Windows/Cygwin, here only the real value is really
meaningful and moreover the result here is the minimum found after 3 run.

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

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

[Pascal Obry]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Pascal Obry wrote:
> 
> > 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 ?
> 
> 
> What is it doing?

Create stub/skeleton and a partition* that can be called from another one.

In the context of Annex - E (Distributed Programming) partition is an
executable part of a complete application.

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

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

[Pascal Obry]

"Jerry Coffin" <jcoffin@taeus.com> writes:

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

We have already had a long thread about that!

> Thinking of Java as a safer C++ betrays misundertanding of one (or

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

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pascal Obry]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Pascal Obry wrote:
> 
> > Note that it is for this very reason that Java was born (a safer C++). Java
> > has indeed removed lot of unsafe constructs from C++.
> 
> 
> Please do not start a real flame! Java is far behind C++. It is a silver

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

Pascal.

-- 

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

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

[Ioannis Vranos]

Pascal Obry wrote:

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


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

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


You may download the latest draft from here:

http://www.plumhall.com/C++-CLI%20draft%201.8.pdf


With C++/CLI and VC++ 2005, C++ becomes the systems programming language 
of CLI (and .NET):


You may take a look at these:

http://msdn.microsoft.com/msdnmag/issues/05/01/COptimizations/default.aspx

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

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

http://www.accu.org/conference/presentations/Sutter_-_Is_C++_Relevant_on_Modern_Environments_%28keynote%29.pdf


And a page of mine:

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



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

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



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Alberto]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message 
> Nobody objects to someone using the name ADA in a program written in Ada.
> The comments are about someone using improper capitalization in text
> written in English, a language which is case-sensitive.

As many people on this thread noticed, it was only a (bad?) joke. I
simply wanted to remark that I was somewhat tired of reading the same
story of Ada L. when some innocent soul dared to write "ADA" :)

> > 3. Many of you want us to believe that ADa performs ra nge checking
> > without loss of performance: it can be true at compile time with fixed
> > ranges, but it can't definitely be done without chechinkg array bounds
> > every time data is accessed if we don't know these bounds before
> > compiling (e.g.: typical cases where dynamic allocation of memory is
> > used)
> 
> As has been stated, it is _much_ more efficient that do-it-yourself
> range checking written in C++, because the compiler has more data.
> For those who insist on _no_ range checking (compute intensive inner
> loops), turn off the range checking if it gets in the way for that
> one area of code.  But be certain it gets in the way first - it
> is common to make bad guesses about whether range checking will
> affect overall performance.  Ada programmers are better able than
> C* programmers to know that, because in Ada it is easier to turn
> range checking on and off.

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

> 
> > mechanisms, only interfaces (pure virtual classes)[2]. To me, it
> > sounds reasonable to work with the last version of a compiler when
> > possible.
> 
> That does not seem so reasonable to people working on a mission-critical
> 30 year project.  In many cases such circumstances warrant working with
> the compiler originally used for the project.

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

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

[Hans Malherbe]

>"Interesting", indeed.  ;-)  Unfortunately, about half of this
>information is complete nonsense -- about both languages!

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Alberto]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<1lr611thktbau$.1dj95z21h7l5v.dlg@40tude.net>...
> > 2. The C++ exception mechanism should be very similar to aDa's,
> > because it was inspired partially from it [1].
> 
> Yes, but there is a sufficient difference. Ada's exceptions are values of
> same predefined type. It has advantages and disadvantages. Being on Ada's
> side I start with advantages and leave disadvantages to you:
 
> 2. C++ has no truly dynamic classes. But if it some time will, then how
> would it deal with:
> 
[snip example]

I have never done or needed to do this, but I'll make a few tests with
the compiler anyway...
 
> 3. The size of all exception objects has an upper bound.

What is the advantage here? :)

> But even then bounds checking is not needed for every access. Example:
> 
> procedure Dynamic (A : Some_Array) is
>    subtype Index is Array_Index range A'Range;
>    J : Index := A'First;
> 
>    for I in A'Range loop
>       A (I) := .. -- No checks
>       ...
>       J := I;
>    end loop;
>    A (J) := ... -- Still no checks
> 
> C++ completely lacks the notion of constrained subtypes which makes the
> above possible.

If Some_Array is any array supplied at run-time, how can the compiler
know what values are stored in A'Range? (I mean, what the bounds of
the array are) It *has* to check these bounds at run-time. This
behaviour is also easily done with C++, creating a 'bounds' class,
similar to A'Range. The only difference is that it is a mechanism
provided by the user and not the compiler.
 
> > 4. Also, some people wrote that C++ is bad because it is difficult
> > (but not imposible, see Comeau C++) to follow 100% the Standard. The
> > same can be said to adA, because at least if we own a compiler of the
> > '83 Standard, we can't have the derivation a virtual function
> > mechanisms, only interfaces (pure virtual classes)[2]. To me, it
> > sounds reasonable to work with the last version of a compiler when
> > possible.
> 
> As long as you have only one compiler vendor...

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

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

Well, we have alloca() for this ;)

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

[Hans Malherbe]

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

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

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

Groete
Hans

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Alex R. Mosteo]

Robert A Duff wrote:
> "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.

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

Regards!

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

[Adrien Plisson]

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

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

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

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

-- 
rien

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Hermann]

In comp.lang.ada Pascal Obry <pascal@obry.org> wrote:
> ... It seems to me that we are far from a language flame war.

indeed: the c-- bigots are keeping astonishingly quiet this time.

> At least I found (being on the Ada side) some very
> interresting messages about C++ here.

indeed: food for thought for the Ada programmer.

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

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

[Peter Koch Larsen]

"Larry Kilgallen" <Kilgallen@SpamCop.net> skrev i en meddelelse 
news:7xbqRcXz6sXs@eisner.encompasserve.org...
> 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).

I see no reason for verbosity here ;-)

/Peter 

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On 11 Mar 2005 00:05:06 -0800, Alberto wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<1lr611thktbau$.1dj95z21h7l5v.dlg@40tude.net>...

>> 3. The size of all exception objects has an upper bound.
> 
> What is the advantage here? :)

You can catch the exception Storage_Error! (:-))

>> But even then bounds checking is not needed for every access. Example:
>> 
>> procedure Dynamic (A : Some_Array) is
>>    subtype Index is Array_Index range A'Range;
>>    J : Index := A'First;
>> 
>>    for I in A'Range loop
>>       A (I) := .. -- No checks
>>       ...
>>       J := I;
>>    end loop;
>>    A (J) := ... -- Still no checks
>> 
>> C++ completely lacks the notion of constrained subtypes which makes the
>> above possible.
> 
> If Some_Array is any array supplied at run-time, how can the compiler
> know what values are stored in A'Range? (I mean, what the bounds of
> the array are)

The bounds are in the array dope.

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

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

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

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

>> 2. C++ is unable to allocate objects of indefinite size on the stack.
> 
> Well, we have alloca() for this ;)

Try to return such object from a function. Ada can

declare
   Object : T'Class := Read_It_From_File;

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

declare
   Line : String := Read_Source_Line (File);

Or even:

   Put_Line (Read_Source_Line (File));

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Amey]

Wes Groleau wrote:
> 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.
> 

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

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

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

Peter

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> skrev i en meddelelse 
news:97kpu5gkgo1r$.kc4nx7cxjziw$.dlg@40tude.net...
> On 11 Mar 2005 00:05:06 -0800, Alberto wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
>> news:<1lr611thktbau$.1dj95z21h7l5v.dlg@40tude.net>...
>
>>> 3. The size of all exception objects has an upper bound.
>>
>> What is the advantage here? :)
>
> You can catch the exception Storage_Error! (:-))

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

>
>>> But even then bounds checking is not needed for every access. Example:
>>>
>>> procedure Dynamic (A : Some_Array) is
>>>    subtype Index is Array_Index range A'Range;
>>>    J : Index := A'First;
>>>
>>>    for I in A'Range loop
>>>       A (I) := .. -- No checks
>>>       ...
>>>       J := I;
>>>    end loop;
>>>    A (J) := ... -- Still no checks
>>>
>>> C++ completely lacks the notion of constrained subtypes which makes the
>>> above possible.
>>
>> If Some_Array is any array supplied at run-time, how can the compiler
>> know what values are stored in A'Range? (I mean, what the bounds of
>> the array are)
>
> The bounds are in the array dope.
>
>> It *has* to check these bounds at run-time. This
>> behaviour is also easily done with C++, creating a 'bounds' class,
>> similar to A'Range. The only difference is that it is a mechanism
>> provided by the user and not the compiler.
>
> No, the difference is that the compiler *statically* knows that both I and
> J will be in the bounds at run-time. There is no way (except for dirty
> tricks with casting) how they might become out of the bounds. Therefore 
> the
> compiler can safely omit any checks.
>
>>>> 4. Also, some people wrote that C++ is bad because it is difficult
>>>> (but not imposible, see Comeau C++) to follow 100% the Standard. The
>>>> same can be said to adA, because at least if we own a compiler of the
>>>> '83 Standard, we can't have the derivation a virtual function
>>>> mechanisms, only interfaces (pure virtual classes)[2]. To me, it
>>>> sounds reasonable to work with the last version of a compiler when
>>>> possible.
>>>
>>> As long as you have only one compiler vendor...
>>
>> Sorry, I don't understand you very well here.
>
> If your code depends on the compiler version, and you have to compile it
> under gcc, Borland, MSVC, then you are in trouble man!

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

>
>>> 2. C++ is unable to allocate objects of indefinite size on the stack.
>>
>> Well, we have alloca() for this ;)
>
> Try to return such object from a function. Ada can
>
> declare
>   Object : T'Class := Read_It_From_File;
>
> Here neither the specific type, nor the size of the object are known at
> compile time. Another example:
>
> declare
>   Line : String := Read_Source_Line (File);
>
> Or even:
>
>   Put_Line (Read_Source_Line (File));

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


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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

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

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

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

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

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

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

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

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

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

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

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> skrev i en meddelelse 
> news:97kpu5gkgo1r$.kc4nx7cxjziw$.dlg@40tude.net...

>>>> 2. C++ is unable to allocate objects of indefinite size on the stack.
>>>
>>> Well, we have alloca() for this ;)
>>
>> Try to return such object from a function. Ada can
>>
>> declare
>>   Object : T'Class := Read_It_From_File;
>>
>> Here neither the specific type, nor the size of the object are known at
>> compile time. Another example:
>>
>> declare
>>   Line : String := Read_Source_Line (File);
>>
>> Or even:
>>
>>   Put_Line (Read_Source_Line (File));
> 
> The solution is simple here - just allocate your memory on the heap.

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

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

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

[Marius Amado Alves]

On 11 Mar 2005, at 04:53, fabio de francesco wrote:

> B.Stroustrup wrote in his "C++ Programming Language" that He was partly
> inspired by Ada (and by a misterious to me "Clu") in creating C++
> templates and exceptions. Does it mean these languages are closer than
> everyone would expect?

You seem to have missed my previous post, which reveals the historical 
relationship.

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> Pascal Obry wrote:
> 

>>    package API is
>>       pragma Remote_Call_Interface;
>>
>>       procedure Call_Me (Str : in String);
>>    end API;
>>

> What is it doing?

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

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

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

Georg

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Dmitry A. Kazakov wrote:

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


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

About stack. Strictly speaking, C++ standard does not define any stack 
apart from a stack container , but "automatic storage" and "dynamic 
storage".


It is common though the first to be called "stack" and the second "heap" 
or "free store".


It is an implementation's/platform's job to provide stack and heap.


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


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




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Jean-Pierre Rosen]

CTips a �crit :
> 
> Since it appears that several people out here are making some very basic 
> mistakes when they report benchmark numbers, I thought I'd write a small 
> note on how to do benchmarking.
> 
[lots of good stuff deleted]

You are absolutely right, but there is one thing that this benchmark 
*proves*:

Blindly claiming that C is faster than Ada is not supported by hard figures.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Alex R. Mosteo]

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

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Ioannis Vranos wrote:

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


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


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


In summary RAII is a technique which is used to encapsulate resources 
(as vector does for memory and is used as a general array, and string 
also and is used as a string type), with the constructor allocating the 
resources and the destructor releasing them, and thus producing 
bullet-proof code.


When an exception is thrown or the object reaches the end of its scope, 
the object gets destroyed releasing the resources via its destructor.


RAII can be used for any kind of resources, IP connections, memory, 
files, etc. All standard library containers use RAII.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

In article <e39403d5.0503102350.11bbf66c@posting.google.com>, azdo_b@yahoo.es (Alberto) writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message 

Somebody no longer attributed wrote:

>> > mechanisms, only interfaces (pure virtual classes)[2]. To me, it
>> > sounds reasonable to work with the last version of a compiler when
>> > possible.
>> 
>> That does not seem so reasonable to people working on a mission-critical
>> 30 year project.  In many cases such circumstances warrant working with
>> the compiler originally used for the project.
> 
> You are right: if something works, it is usually better not to touch
> it, but in this case, you are stuck with Ada83!

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

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> skrev i en meddelelse 
news:qehxli3ofpnd.1n3ma1ro7drgt$.dlg@40tude.net...
> On Fri, 11 Mar 2005 10:42:51 +0100, Peter Koch Larsen wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> skrev i en meddelelse
>> news:97kpu5gkgo1r$.kc4nx7cxjziw$.dlg@40tude.net...
>
>>>>> 2. C++ is unable to allocate objects of indefinite size on the stack.
>>>>
>>>> Well, we have alloca() for this ;)
>>>
>>> Try to return such object from a function. Ada can
>>>
>>> declare
>>>   Object : T'Class := Read_It_From_File;
>>>
>>> Here neither the specific type, nor the size of the object are known at
>>> compile time. Another example:
>>>
>>> declare
>>>   Line : String := Read_Source_Line (File);
>>>
>>> Or even:
>>>
>>>   Put_Line (Read_Source_Line (File));
>>
>> The solution is simple here - just allocate your memory on the heap.
>
> Heap is far slower than stack. Also stack is much safer, because objects
> allocated on the stack have visible scopes, as compared to adventures with
> pointers. Do you want to add one more indirection layer - smart pointers,
> or do it even worse by using GC?

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

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"Alex R. Mosteo" <devnull@mailinator.com> skrev i en meddelelse 
news:42318D84.1020401@mailinator.com...
> Ioannis Vranos wrote:
>> Usually the stack is limited in comparison to the heap, and it sounds 
>> strange to me that in Ada there is a large stack. My guess is that you 
>> are using the heap for data storage implicitly(?) and you think you are 
>> using the stack.
>
> Nope. And you can control in portable Ada how big the stack for a given 
> task must be.

But you do not know the size of the object so how does that help you setting 
the stack-size?

/Peter 

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Fri, 11 Mar 2005 14:12:14 +0200, Ioannis Vranos wrote:

> Dmitry A. Kazakov wrote:
> 
>> Heap is far slower than stack. Also stack is much safer, because objects
>> allocated on the stack have visible scopes, as compared to adventures with
>> pointers. Do you want to add one more indirection layer - smart pointers,
>> or do it even worse by using GC?
> 
> Regarding Storage_Error exception, C++'s one is bad_alloc, which is 
> guaranteed to *never fail* in case of memory starvation.

Even if exception object is 100GB large?

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

Stack here means LIFO. It is not necessarily the machine stack, though in
most cases it will be. I think there is no need to explain why LIFO
allocation / deallocation strategy is in order of magnitude more efficient
than heap? Neither should I explain why local to task (thread) memory is
better than the global heap in any concurrent program and especially in
ones running on multi-processor machines...

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

= smart pointers. Yes. It is a widely used technique to regain the safety
lost while switching from stack to heap. It adds additional performance /
space penalty to what heap already has.

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Alex R. Mosteo]

Peter Koch Larsen wrote:
> "Alex R. Mosteo" <devnull@mailinator.com> skrev i en meddelelse 
> news:42318D84.1020401@mailinator.com...
> 
>>Ioannis Vranos wrote:
>>
>>>Usually the stack is limited in comparison to the heap, and it sounds 
>>>strange to me that in Ada there is a large stack. My guess is that you 
>>>are using the heap for data storage implicitly(?) and you think you are 
>>>using the stack.
>>
>>Nope. And you can control in portable Ada how big the stack for a given 
>>task must be.
> 
> 
> But you do not know the size of the object so how does that help you setting 
> the stack-size?

I'm not sure what you want to imply here. The thing is that while in 
stack terrain you're free of all dynamic memory additional 
hazards/overheads, which in certain realtime environments is seen as 
desirable. As parent said, stacks tend to be smaller than heaps, and in 
Ada you can control that without going non-portable.

If we're talking of unknown sized objects, either a stack or a heap can 
be too small. ?

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

[Robert A Duff]

"Hans Malherbe" <hans.malherbe@gmail.com> writes:

> >"Interesting", indeed.  ;-)  Unfortunately, about half of this
> >information is complete nonsense -- about both languages!
> 
> I would like to believe that people like you would point out the
> nonsense preventing people like me from consuming it.

A fair comment.

I *did* post a few notes in this thread trying to set some things
straight.  And I might post a few more, if I have time.  But how do you
know whether to trust what *I* say over what anyone else says?  ;-)

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

- Bob

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Jean-Pierre Rosen wrote:

> CTips a �crit :
> 
>>
>> Since it appears that several people out here are making some very 
>> basic mistakes when they report benchmark numbers, I thought I'd write 
>> a small note on how to do benchmarking.
>>
> [lots of good stuff deleted]
> 
> You are absolutely right, but there is one thing that this benchmark 
> *proves*:
> 
> Blindly claiming that C is faster than Ada is not supported by hard 
> figures.
> 

Actually, it is.

In most cases, it is possible to get close to assembly performance out 
of C [one major case where it isn't is when you want to use 
labels-as-addresses]. In fact, it is _NOT_ possible to beat that number 
using any language. If there are any run-time checks added by the Ada 
compiler, then the performance will not be the assembly level 
performance. Consequently, either one must program so that no checks 
need to be added OR one must disable all run-time checking.

BTW - all the psuedo-benchmarking people have done on this thread so far 
has provided meaningless numbers - too small run-times, performance 
dominated by cache misses etc.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Willem]

Jean-Pierre wrote:
) You are absolutely right, but there is one thing that this benchmark 
) *proves*:
)
) Blindly claiming that C is faster than Ada is not supported by hard figures.

Given that the only ADA code I saw in this thread was a linear search,
which could easily have been a binary one, there's no way you can back up
that claim.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Dmitry A. Kazakov wrote:

> Even if exception object is 100GB large?


I am talking about the exception class bad_alloc whatever the sizes of 
other objects (even exceptions) are. It is guaranteed that there is 
always free memory for bad_alloc.


> Stack here means LIFO. It is not necessarily the machine stack, though in
> most cases it will be. I think there is no need to explain why LIFO
> allocation / deallocation strategy is in order of magnitude more efficient
> than heap? Neither should I explain why local to task (thread) memory is
> better than the global heap in any concurrent program and especially in
> ones running on multi-processor machines...


Although I know the general difference between stack and heap (the last 
storing things in a messy way), I have no knowledge about them in terms 
of program's space (that is how the heap can be rearranged in the 
background), so it is better someone else to answer this.

However in general what I know is that the additional time-cost of 
dynamic storage in comparison to the automatic storage can be described 
as the additional cost of new and delete calls.


>>Are you familiar with "Resource Acquisition is Initialisation" (RAII) 
>>technique? This is supported by C++ and used by all standard library 
>>containers.
> 
> 
> = smart pointers. Yes. It is a widely used technique to regain the safety
> lost while switching from stack to heap. It adds additional performance /
> space penalty to what heap already has.


Smart pointers, as also containers, but even for resources other than 
memory.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Fri, 11 Mar 2005 14:28:26 +0100, Peter Koch Larsen wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> skrev i en meddelelse 
> news:qehxli3ofpnd.1n3ma1ro7drgt$.dlg@40tude.net...
>> On Fri, 11 Mar 2005 10:42:51 +0100, Peter Koch Larsen wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> skrev i en meddelelse
>>> news:97kpu5gkgo1r$.kc4nx7cxjziw$.dlg@40tude.net...
>>
>>>>>> 2. C++ is unable to allocate objects of indefinite size on the stack.
>>>>>
>>>>> Well, we have alloca() for this ;)
>>>>
>>>> Try to return such object from a function. Ada can
>>>>
>>>> declare
>>>>   Object : T'Class := Read_It_From_File;
>>>>
>>>> Here neither the specific type, nor the size of the object are known at
>>>> compile time. Another example:
>>>>
>>>> declare
>>>>   Line : String := Read_Source_Line (File);
>>>>
>>>> Or even:
>>>>
>>>>   Put_Line (Read_Source_Line (File));
>>>
>>> The solution is simple here - just allocate your memory on the heap.
>>
>> Heap is far slower than stack. Also stack is much safer, because objects
>> allocated on the stack have visible scopes, as compared to adventures with
>> pointers. Do you want to add one more indirection layer - smart pointers,
>> or do it even worse by using GC?
> 
> I believed the object might have to be returned? Read the post once again. 
> If this is so, you can not allocate it on the stack without having to copy 
> when you return the object. Surely the copy must be more expensive than the 
> allocation?

The compiler can use multiple stacks so that arguments and the result might
be allocated on different stacks.

> Ordinary heap-based speed is not so slow and if you need to get the last 
> cpu-cycle away, you can simply use an arena for your allocation.

Yes, some Ada compilers would probably use discontiguous object
representation and arenas for variable parts. The difference is that it is
still not the global heap. And it is controlled by the compiler which
exactly knows the scope of objects.

> Also you will of course use a smart pointer in the situation above. A C++ 
> programmer with respect for himself only rarely uses new without putting the 
> result in some kind of smart pointer. Personally, I do not remember when i 
> did that last.

I'd be happy if all C++ programmers would be ready and willing to
compensate deficiencies of the language through more careful and thoughtful
design. Actually, we are doing a lot of developing in C++, and due to my
job responsibilities time to time I have to review C++ code...

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

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

[T Beck]

Adrien Plisson wrote:
> 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

Would that happen to include the now-infamous Patriot Missles (the ones
that couldn't hit a barn after they'd been on for a while due to a
bug?)

--T Beck

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

[Jerry Coffin]

Pascal Obry wrote:
> "Jerry Coffin" <jcoffin@taeus.com> writes:
>
> > Your claim of fewer bugs is just the sort of unsupported anti-C
> > comment we see all the time.
>
> Just plain wrong, there is data (a PHD) see
> http://www.adaic.com/whyada/ada-vs-c/cada_art.html

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

By 1990 or so when compilers conforming reasonably closely with the C
standard became available, it appears likely that essentially all new
development was being done in Ada. Under the circumstances, it would be
rather surprising if the C code was ever rewritten into standard C.

In short, this is not a comparison to the C language as it exists
today, or has existed in well over a decade.

He also mentions C++ in passing, but (again, based on the timing) he
was clearly looking at C++ when it was still in an embryonic stage.
Worse, the understanding and use of the language were, if anything,
well behind the development of the language itself. The language itself
was clearly inferior to todays, but it's use was inferior by an even
larger margin.

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

It's true that Ada has also been updated in the meantime, but the
changes in Ada have been _drastically_ smaller than those in C or C++.
Ada 83 already had generics, already had type-checking on the same
general order as that introduced into C with function prototypes, etc.
With Ada 95 you can probably expect a fairly substantialy improvement
in reuse, but only rather minor improvements elsewhere.

By contrast, comparing modern C++ to the pre-standard C shows _large_
improvements in nearly all areas. This is due in part to the changes in
the language itself, but perhaps even more so to improved understanding
of how to use the language.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

Lutz Donnerhacke <lutz@iks-jena.de> writes:

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

C++ templates don't even come within a Hubble Telescope's viewing
range of Lisp macros.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Ioannis Vranos wrote:
> 
> > I agree about the interesting info for both languages myself
> > too. Just to be accurate, it is "template metaprogramming".
> 
> 
> Two interesting links:
> 
> http://home.earthlink.net/~joshwalker1/writing/TemplateMetaprogramming.html
> 
> http://www.codeproject.com/cpp/crc_meta.asp
> 
> 
> Again, it is a whole field of its own with many books about it. It is
> about turning *any* run-time operation to compile time (and the output
> can be the compiler messages).

Sigh.  If you really want to know how potent this sort of angle can
really be, you should spend some time looking at the real thing.  Here
are a couple vastly more interesting links:

http://www.gigamonkeys.com/book/macros-standard-control-constructs.html

http://www.paulgraham.com/onlisp.html


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Jean-Pierre Rosen]

Willem a �crit :
> Jean-Pierre wrote:
> ) You are absolutely right, but there is one thing that this benchmark 
> ) *proves*:
> )
> ) Blindly claiming that C is faster than Ada is not supported by hard figures.
> 
> Given that the only ADA code I saw in this thread was a linear search,
> which could easily have been a binary one, there's no way you can back up
> that claim.
> 
Did you read my (carfully phrased) sentence? I am just claiming that 
*some* tests have exhibited comparable behaviour, and therefore that you 
cannot claim *blindly* that C is faster. If you want to support that 
position, you need to provide strong, measured, evidence.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

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

[Jerry Coffin]

Adrien Plisson wrote:
> Jerry Coffin wrote:
> > Second, if the work had been done exclusively or primarily in
> > a language the DoD considered its own, I suspect opening it up
> > to the public would have taken even longer, if it was ever
> > allowed to happen at all.
>
> but still ARPA-net was created by the United States Defense Advanced
> Research Project Agency, part of... the DoD !

That was exactly my point: it started out as a DoD-funded project. The
question is about what happened then -- how willing the DoD was to open
the project to the public at large. As it was, the project was done
with DoD funding, but was really done at and by universities. While it
is openly acknowledged to have fulfilled its original intent extremely
well, nearly every choice in its design and implementation was about as
UN-military as possible. Despite this, it took 20+ years before it was
really open to the general public.

Had even ONE element in the design or implementation fit even slightly
more closely with the military mind-set, I doubt it would have been
opened up to the public yet, or possibly ever.

> > To ensure that, connecting to this system would only be allowed
> > after passing an extensive (and expensive) certification process,
> > and only one OS in existence would be capable of passing -- and
> > it wouldn't be from a bunch of hackers like Microsoft either. It
> > would be from some place thoroughly professional, with a
> > thoroughly professional license fee (i.e. well out of reach of
> > over 99% of the people who currently use the Internet).
>
> I don't remember running UNIX (implemented in C) was cheap at the
> time ARPA-net was born ! also, one of the major Ada compiler is
> available for free, so why would it be so expensive ?

Prices for computing in general were much higher at the time, but UNIX
was cheaper than most.

It seems difficult to believe that anybody would believe or even imply
that the cost of the compiler determines the cost of the final product.

Even ignoring that for the moment, you're using cirular logic -- you're
assuming the 'net would be built with GNAT, ignoring the fact that the
free availability of GNAT is largely a _result_ of the 'net's
existence.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Jerry Coffin]

Robert A Duff wrote:

[ ... ]

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

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

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

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Thu, 10 Mar 2005 17:39:13 -0500, REH wrote:
> Ada features I would love to have in C++:
> * "new types" and sub-ranges

Agree strongly. (with compiler-generated checking!)

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

This would be nice!

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

Agree strongly.

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

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

>* representation specifications!!!!

Agree.

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

Sometimes useful but is it more than "syntactic sugar"?

> * actually having a class object encapulating the data and methods.

Yes.  It might help if packages were first class objects instead

>* reference (in out) types in functions (without resorting to
> access types)

procedures usually suffice.  The "Rosen Trick" works in most
cases.  I'd like to be able to identify functions as "pure",
like in VHDL, and allow the compiler to discard or memoize
calls to functions marked as pure.

> * meta-templates.  very neat stuff.  ugly, but neat.

I think I prefer Ada generics.  I have yet to see how Meta-templates
really contribute to a program design.

>* The STL!!! (though I hear something similar is coming?)

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

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

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

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

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

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

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

Portability without resorting to preprocessor directives
and conditional compilation
--------------------------------------------------------------
My list of C++ features I would love to have in Ada adds:

simple and direct interfacing to C/C++ header files - a *big*
drawback of Ada :(

template specialization

extra parameters with "new"
--------------------------------------------------------------
But what of features not present in either?

Introspection

Dynamic compilation/interpretation

parallel execution constructs (see Cilk, Occam's "par")
coroutines

configurations (from VHDL)

associative arrays (from Perl)

What else?
-- 
Adrian

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> skrev i en meddelelse 
news:u0xp3u9rradw$.v3dzz0eotkpx.dlg@40tude.net...
> On Fri, 11 Mar 2005 14:28:26 +0100, Peter Koch Larsen wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> skrev i en meddelelse
>> news:qehxli3ofpnd.1n3ma1ro7drgt$.dlg@40tude.net...
>>> On Fri, 11 Mar 2005 10:42:51 +0100, Peter Koch Larsen wrote:
>>>
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> skrev i en meddelelse
>>>> news:97kpu5gkgo1r$.kc4nx7cxjziw$.dlg@40tude.net...
>>>
>>>>>>> 2. C++ is unable to allocate objects of indefinite size on the 
>>>>>>> stack.
>>>>>>
>>>>>> Well, we have alloca() for this ;)
>>>>>
>>>>> Try to return such object from a function. Ada can
>>>>>
>>>>> declare
>>>>>   Object : T'Class := Read_It_From_File;
>>>>>
>>>>> Here neither the specific type, nor the size of the object are known 
>>>>> at
>>>>> compile time. Another example:
>>>>>
>>>>> declare
>>>>>   Line : String := Read_Source_Line (File);
>>>>>
>>>>> Or even:
>>>>>
>>>>>   Put_Line (Read_Source_Line (File));
>>>>
>>>> The solution is simple here - just allocate your memory on the heap.
>>>
>>> Heap is far slower than stack. Also stack is much safer, because objects
>>> allocated on the stack have visible scopes, as compared to adventures 
>>> with
>>> pointers. Do you want to add one more indirection layer - smart 
>>> pointers,
>>> or do it even worse by using GC?
>>
>> I believed the object might have to be returned? Read the post once 
>> again.
>> If this is so, you can not allocate it on the stack without having to 
>> copy
>> when you return the object. Surely the copy must be more expensive than 
>> the
>> allocation?
>
> The compiler can use multiple stacks so that arguments and the result 
> might
> be allocated on different stacks.

Okay. If the Ada concept of a "stack" is the same as my hardware-oriented 
one, I doubt i would have much trust to the performance of a such a type of 
programming.

>
>> Ordinary heap-based speed is not so slow and if you need to get the last
>> cpu-cycle away, you can simply use an arena for your allocation.
>
> Yes, some Ada compilers would probably use discontiguous object
> representation and arenas for variable parts. The difference is that it is
> still not the global heap. And it is controlled by the compiler which
> exactly knows the scope of objects.
>
>> Also you will of course use a smart pointer in the situation above. A C++
>> programmer with respect for himself only rarely uses new without putting 
>> the
>> result in some kind of smart pointer. Personally, I do not remember when 
>> i
>> did that last.
>
> I'd be happy if all C++ programmers would be ready and willing to
> compensate deficiencies of the language through more careful and 
> thoughtful
> design. Actually, we are doing a lot of developing in C++, and due to my
> job responsibilities time to time I have to review C++ code...

If I were to review code with a regular use of new and delete, I would send 
the code right back - and the responsible programmer on a course - hoping 
for a substantial improvement in style.

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

/Peter 

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

[Pascal Obry]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

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

Right. I agree. Don't get my message wrong. I never said that Java was
better. I just stated the original goal as expressed by Sun.

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> skrev i en 
meddelelse 
news:pan.2005.03.11.18.01.45.684764@linuxchip.demon.co.uk.uk.uk...
> On Thu, 10 Mar 2005 17:39:13 -0500, REH wrote:
>> Ada features I would love to have in C++:
>> * "new types" and sub-ranges
>
> Agree strongly. (with compiler-generated checking!)

This can be implemented mostly with templates.

>
>> * runtime template instantiation (I think being able to instantiate
>> generics dynamically is the coolest thing!)
>
> This would be nice!

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

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

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

>
>>* packages.  namespaces are nice, but packages make modularity of very
>> large system a lot easier.  Especially now with "use type"
>
> Vital!  C++ and C suffer a lot from not enforcing encapsulation,
> allowing headers to break stuff etc.  Better control of scope
> and visibility.  Better separation of interface and implementation
>
>>* representation specifications!!!!
>
> Agree.

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


>
>> 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.
>
> Sometimes useful but is it more than "syntactic sugar"?
>
>> * actually having a class object encapulating the data and methods.
>
> Yes.  It might help if packages were first class objects instead
>
>>* reference (in out) types in functions (without resorting to
>> access types)
>
> procedures usually suffice.  The "Rosen Trick" works in most
> cases.  I'd like to be able to identify functions as "pure",
> like in VHDL, and allow the compiler to discard or memoize
> calls to functions marked as pure.
>
>> * meta-templates.  very neat stuff.  ugly, but neat.
>
> I think I prefer Ada generics.  I have yet to see how Meta-templates
> really contribute to a program design.
>
>>* The STL!!! (though I hear something similar is coming?)
>
> Yes. Agree strongly.
> -------------------------------------------------------------
> My list of Ada features I would love to have in C++ adds:
>
> Concurrency.  Tasks. Protected objects.
> Distributed programs. Persistent variables.

I doubt that this should be part of the standard. What is needed is 
specification of low-level features in e.g. multiprocessor environments.
>
> Eliminate large swathes of the C++ standard which leaves
> the semantics up to the compiler!

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

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

I do not see the purpose of the out-parameter. Why not simply return the 
value(s)?
As for named parameter associations, these can again be implemented in a 
library.

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

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

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

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

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

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

>
> Portability without resorting to preprocessor directives
> and conditional compilation

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

> --------------------------------------------------------------
> My list of C++ features I would love to have in Ada adds:
>
> simple and direct interfacing to C/C++ header files - a *big*
> drawback of Ada :(
>
> template specialization
>
> extra parameters with "new"
> --------------------------------------------------------------
> But what of features not present in either?
>
> Introspection
>
> Dynamic compilation/interpretation
>
> parallel execution constructs (see Cilk, Occam's "par")
> coroutines
>
> configurations (from VHDL)
>
> associative arrays (from Perl)

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

>
> What else?
> -- 
> Adrian
>
>
/Peter 

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Willem]

Jean-Pierre wrote:
) Willem a �crit :
)> Jean-Pierre wrote:
)> ) You are absolutely right, but there is one thing that this benchmark 
)> ) *proves*:
)> )
)> ) Blindly claiming that C is faster than Ada is not supported by hard figures.
)> 
)> Given that the only ADA code I saw in this thread was a linear search,
)> which could easily have been a binary one, there's no way you can back up
)> that claim.
)> 
) Did you read my (carfully phrased) sentence? I am just claiming that 
) *some* tests have exhibited comparable behaviour, and therefore that you 
) cannot claim *blindly* that C is faster. If you want to support that 
) position, you need to provide strong, measured, evidence.

In that case your sentence makes no sense, because you are saying that
'claiming blindly' means 'claiming without strong, measured, evidence'.
'hard figures' are 'strong, measured evidence', so therefore your
sentence can be rephrased as follows:

Claiming that C is faster than Ada without strong measured evidence
is not supported by strong measured evidence.

Which, as I said before, makes no sense.  It's a tautology at best.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Falk Tannhäuser]

Dr. Adrian Wrigley wrote:
> But what of features not present in either?
[...]
> associative arrays (from Perl)

Wouldn't that be std::map in C++?

Falk

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Pascal Obry]

CTips <ctips@bestweb.net> writes:

> Since it appears that several people out here are making some very basic
> mistakes when they report benchmark numbers, I thought I'd write a small note
> on how to do benchmarking.

Thanks a lot :)

Did you see my note that a good benchmark had to be done on the real
application ? I pretty well know that a stupid benchmark like this means
nothing. But well, you did (I think it was you, sorry if not) use this
argument by bindly say that Ada was slow. This just because an unknown web
site with very bad code (at least for the Ada part) was showing that Ada was
lot slower!

At least I have showed that a decent Ada implementation (very close to the C++
one) is running at the same speed. But I have not hours to spend to provide
all the data as described in your post.

Pascal.

-- 

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

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Pascal Obry]

CTips <ctips@bestweb.net> writes:

> BTW - all the psuedo-benchmarking people have done on this thread so far has
> provided meaningless numbers - too small run-times, performance dominated by
> cache misses etc.

And the pseudo results from http://shootout.alioth.debian.org/great/ were fine
to you some days ago :)

> 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!)

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> wrote in message
news:pan.2005.03.11.18.01.45.684764@linuxchip.demon.co.uk.uk.uk...
> > 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.
>
> Sometimes useful but is it more than "syntactic sugar"?
>
No, probably not but unlike a lot of my colleagues, I like syntactic sugar.
That's why I love being able to overload operators in both languages.  I can
add to the language, and make my new constructs look like they are part of
the language.

> >* reference (in out) types in functions (without resorting to
> > access types)
>
> > * meta-templates.  very neat stuff.  ugly, but neat.
>
> I think I prefer Ada generics.  I have yet to see how Meta-templates
> really contribute to a program design.
The reason I prefer template (their power, not looks) is their ability to
"store" information using the type system.  For example, recently on a
(personal) project, I had a set of object I wanted to be able to act upon
(like std::foreach does) and filter for various criteria.  Using templates I
created a function to traverse the objects.  This function takes two
template parameters, the operation to be perfomed, and the filter.  I have
template classes for filters and operators for the boolean operators to
combine and build more advanced filters on-the-fly without creating functors
each time.  Something like:

traverse_objects(objects, operation, filter1(stuff) && filter2(other-stuff)
|| !filter3());

This has to be done with templates and class types because the boolean
operations can't be done now, but "deferred" until called by operation.  As
an example, this is a simplicist version of the "and" filter:

template<class A, class B>
struct and_filter {
    and_filter(const A& a, const B& b) : m_a(a), m_b(b) {}
    bool operator() (Object& o) {return m_a(o) && m_b(o);}
    A m_a;
    B m_b;
};

template<class A, class B>
inline and_filter<A, B> operator&& (const A& a, const B& b)
{
    return and_filter<A, B>(a, b);
}

I know its less safe, but I like that I can use "anything" for the template
parameters that "fit" the syntax (i.e., using functions or class objects
that have the () operator defined).

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

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

Yes, arrays are first-class objects!
>

> Strong(er) typing, better enumerations, fixed point types,
> modular types *and* non-modular types. Basic type attributes.
I love that Ada enumeration don't pollute the global namespace and allow
fully qualified names.  I wish I could do enum_name::element in C++ without
wrapping the enum declaration in a namespace.

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

> associative arrays (from Perl)
I assume you want more than that offered by std::map?

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Peter Koch Larsen" <pklspam@mailme.dk> wrote in message
news:2vlYd.104136$Vf.3990994@news000.worldonline.dk...
> >> * runtime template instantiation (I think being able to instantiate
> >> generics dynamically is the coolest thing!)
> >
> > This would be nice!
>
> How would you do that without "compiling on the fly"?
Ada generics can do this without compiling on the fly.  I think its a nice
feature.

> >>* representation specifications!!!!
> >
> > Agree.
>
> Why? What is the purpose - if not to restrict portability?
Actually rep. specs. enhance portability by explicitly defining the actual
sizes of types, the internal layout of records, etc.  The only aspect (I
believe) that is implementation specific, it bit ordering (though, didn't
they add pragmas for this?)

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Pascal Obry wrote:
> CTips <ctips@bestweb.net> writes:
> 
> 
>>Since it appears that several people out here are making some very basic
>>mistakes when they report benchmark numbers, I thought I'd write a small note
>>on how to do benchmarking.
> 
> 
> Thanks a lot :)
> 
> Did you see my note that a good benchmark had to be done on the real
> application ? I pretty well know that a stupid benchmark like this means
> nothing. But well, you did (I think it was you, sorry if not) use this
> argument by bindly say that Ada was slow. This just because an unknown web
> site with very bad code (at least for the Ada part) was showing that Ada was
> lot slower!
> 
> At least I have showed that a decent Ada implementation (very close to the C++
> one) is running at the same speed. But I have not hours to spend to provide
> all the data as described in your post.
> 
> Pascal.
> 

Nope; your run-time was way too small for the number to be at all 
reliable. Try running the null program:
int main(void) { return 0; }
under cygwin/windows. On my machine, the best of 5 returns:
real    0m0.017s
user    0m0.030s
sys     0m0.000s

Contrast this with the matrix code [I removed the printf()]
real    0m0.018s
user    0m0.030s
sys     0m0.015s

In other words, the startup code dominates all the numbers, and you 
can't judge anything from it.

All you've proved is that you don't understand how to benchmark 
programs, which means that you've never had to *really* worry about 
performance.

Based on this thread, I think most of the Ada advocates here (and maybe 
most Ada programmers)
- don't know how a processor works
- don't know how to measure performance
- don't know how to program for performance
- don't know where Ada will hurt performance
- don't really care about performance

This is pretty much in line with my experience. The Ada advocates (I've 
known several) don't really know how to program for performance. All the 
people I know who program for performance pick C (if they have the choice).

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

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


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


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


Consider std::complex as a complex type, rather than a built in complex 
type.


>>* runtime template instantiation (I think being able to instantiate
>>generics dynamically is the coolest thing!)
> 
> 
> This would be nice!


 From my (perhaps limited) experience of .NET where run-time generics 
are also available to C++ (with the upcoming C++/CLI, .NET 2 and VC++ 
2005 - currently Beta), run-time generics are more limited than 
compile-time templates. Also since they are run-time they are less 
efficient.

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


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


> My list of Ada features I would love to have in C++ adds:
> 
> Concurrency.


Will be available in C++0x. Today is platform-specific, but there is 
also a standard about C++, OpenMP (see below).



> Tasks. Protected objects.
> Distributed programs. Persistent variables.
> 
> Eliminate large swathes of the C++ standard which leaves
> the semantics up to the compiler!
> 
> Named parameter association. Proper parameter modes
> "out" and "in out" modes
> 
> clarity over arrays.  C++ gives you choice of pointers
> C arrays, vectors.  This is one example of where the
> 'C' facilities were too limited, and C++ added
> alternatives, rather fhan fixing what existed in C.
> (and char *, char arrays, string etc)
> 
> Strong(er) typing, better enumerations, fixed point types,
> modular types *and* non-modular types. Basic type attributes.
> 
> More robust, more readable, less terse syntax, particularly
> for complex templates (really!)


I assume you are right, concerning newcomers, but for me Ada's syntax is 
the bizarre one (apart from the Pascal "subset"). :-)


> Portability without resorting to preprocessor directives
> and conditional compilation


These are used essentially for system-oriented code.


> --------------------------------------------------------------
> My list of C++ features I would love to have in Ada adds:
> 
> simple and direct interfacing to C/C++ header files - a *big*
> drawback of Ada :(
> 
> template specialization
> 
> extra parameters with "new"
> --------------------------------------------------------------
> But what of features not present in either?
> 
> Introspection
> 
> Dynamic compilation/interpretation


This is against the systems programming bias of C++. Also there are C++ 
interpreters out there. Here is a nice, small one:

http://home.mweb.co.za/sd/sdonovan/underc.html


> parallel execution constructs (see Cilk, Occam's "par")
> coroutines


Today there is OpenMP:

http://www.openmp.org/drupal


> configurations (from VHDL)
> 
> associative arrays (from Perl)


I am not sure if you mean this, however standard C++ library provides 
map and multimap.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Pascal Obry wrote:

> CTips <ctips@bestweb.net> writes:
> 
> 
>>BTW - all the psuedo-benchmarking people have done on this thread so far has
>>provided meaningless numbers - too small run-times, performance dominated by
>>cache misses etc.
> 
> 
> And the pseudo results from http://shootout.alioth.debian.org/great/ were fine
> to you some days ago :)

He's done it right:
  - he's running them on a Linux machine, which is more accurate than 
cygwin for measuring performance (and where sys/user really mean something).
   - he's using the improved times() which gives better resolution
   - he's controlling for the startup overhead.
   - he's using best of 4 runs.
   - he's picked data sizes that will not blow the cache
   - he's picked data sizes that will give decent run-times.

Like I said, if one knows what one is doing (which he does) then one can 
disregard the rules. If one does not know what one is doing (which you 
don't) then one should follow the rules.

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

[Ioannis Vranos]

Pascal Obry wrote:

> Right. I agree. Don't get my message wrong. I never said that Java was
> better. I just stated the original goal as expressed by Sun.


An interesting (perhaps a bit old) view of Java is included in this 
interview by Alexander Stepanov (the inventor of C++ templates):

http://www.stlport.org/resources/StepanovUSA.html


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Willem]

CTips wrote:
) Like I said, if one knows what one is doing (which he does) then one can 
) disregard the rules. If one does not know what one is doing (which you 
) don't) then one should follow the rules.

Shortened to the classic:

If you understand the rules, you can disregard them.
If you do not understand them, you have to follow them.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[REH]

"CTips" <ctips@bestweb.net> wrote in message
news:1133rhdt7dan4fa@corp.supernews.com...
> Based on this thread, I think most of the Ada advocates here (and maybe
> most Ada programmers)
> - don't know how a processor works
> - don't know how to measure performance
> - don't know how to program for performance
> - don't know where Ada will hurt performance
> - don't really care about performance
>
> This is pretty much in line with my experience. The Ada advocates (I've
> known several) don't really know how to program for performance. All the
> people I know who program for performance pick C (if they have the
choice).

Then you don't know much.  Ada programmers, and programmers in general care
about a lot more than performance.  Performance is not the end-all-be-all of
building software.  You can write crap that takes 1us to execute, and I'll
wite good, fault-tolerance code that runs in 1ms, but still meets all its
requirements and real-time deal-lines.  I'll take the later.  This faster is
better crap is utter non-sense, and it usually exhibited in inexperienced
engineers (and the immature ones).  I write Ada, C, and C++ professionally,
so I guess I no "advocate."  I also would not make snide, inappropriate,
unnecessary, childish, and down right wrong statement about anyone who is
one.  Ada programmers usually work in the world of real-time software where
there are many kinds of "performance."  When you can do monotonic-rate
analysis, et. al., like some Ada Engineers I know, then come talk to me
about knowing how to measure performance.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

REH wrote:

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


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


*Today* one may use a std::pair or a combination of std::pairs for 
return values.

E.g.

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


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

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


Also this gets more syntactic sugar with the upcoming TR1 standard 
library extension and more particularly with "Tuple types".


Here are the proposals that have been accepted for the upcoming TR1:

http://www.open-std.org/jtc1/sc22/wg21/docs/library_technical_report.html


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

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


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1110569032.207770@athnrd02...
> Dr. Adrian Wrigley wrote:
>
> >>Ada features I would love to have in C++:
> >>* "new types" and sub-ranges
>
>
> I do not know what you mean exactly by that, however one can define his
> own types rather than having everything as built-in.

Ada allows you to define a primative type (int, etc.) that is "distinct"
from others.  This is nice for overload resolution, etc.

>
>
> C++ provides general purpose facilities with which one can build his own
> special purpose libraries, rather than providing special purpose
> facilities as built in.
I know, but being about to write "is new integer" is a lot simplier than
creating a class just to create a "unique" integer type.  Plus. since it is
a unique type I can define its exact size in bits which make portabililty
easier:

type Byte is new integer range 0 .. 16#ff#;
for Byte'size use 8;

> > Vital!  C++ and C suffer a lot from not enforcing encapsulation,
> > allowing headers to break stuff etc.  Better control of scope
> > and visibility.  Better separation of interface and implementation
>
>
> May I assume that packages are a form of precompiled dynamic-link
> libraries, like dlls in Windows?
No, they are compilation construct (and can be define in a hierarchy).  The
are kind of like namespaces.  If you ever used Borland's Turbo Pascal, they
are like units.  They make it easy to separate interface and implementation.
Even inlines and generic bodys go in the body package, and not the
specification package, and can be used in a library without needing the
source present to be used.  They also allow for the creation of an
elaboration (static construction) order between packages to be defined.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Ioannis Vranos wrote:

> Personally although more sugar-rich (and still built with the current 
> C++ facilities, which demonstrates the power and expressiveness of the 
> language), I am not sure we needed Tuple types, since std::pair does the 
> job. :-)
> 
> I suppose tuple types continue to be convenient for something like 10 
> return values, since it is just a returned object with the contained 
> values, but I think returning (or passing) so many values means 
> something is wrong. :-)


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




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

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

> 
> "Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> skrev i en 
> meddelelse 
> news:pan.2005.03.11.18.01.45.684764@linuxchip.demon.co.uk.uk.uk...
>> On Thu, 10 Mar 2005 17:39:13 -0500, REH wrote:
>>> Ada features I would love to have in C++:
>>> * "new types" and sub-ranges
>>
>> Agree strongly. (with compiler-generated checking!)
> 
> This can be implemented mostly with templates.

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

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

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

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

   type CrossSpectrumIntensity_T is array (EMSpectrum_T, EMSpectrum_T) of Intensity_T;

   package MyCrossBright is new CrossBright_P (EMSpectrum_T, Intensity_T);

   CrossIntensity : MyCrossBright.CrossIntensity_T := (others => (others => Intensity_T'First));
--------------------------------------------------------------

>>> * runtime template instantiation (I think being able to instantiate
>>> generics dynamically is the coolest thing!)
>>
>> This would be nice!
> 
> How would you do that without "compiling on the fly"?

same way as in Ada!

>>> * subprograms inside subprograms.  I think it would be great for use
>>> with the STL (i.e., using a local function with std::foreach)
>>
>> Agree strongly.
> 
> This will be part of the next standard, I hope. Still i do not believe it to 
> be esential for use.

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

>>>* packages.  namespaces are nice, but packages make modularity of very
>>> large system a lot easier.  Especially now with "use type"
>>
>> Vital!  C++ and C suffer a lot from not enforcing encapsulation,
>> allowing headers to break stuff etc.  Better control of scope
>> and visibility.  Better separation of interface and implementation
>>
>>>* representation specifications!!!!
>>
>> Agree.
> 
> Why? What is the purpose - if not to restrict portability?

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

...
>> -------------------------------------------------------------
>> My list of Ada features I would love to have in C++ adds:
>>
>> Concurrency.  Tasks. Protected objects.
>> Distributed programs. Persistent variables.
> 
> I doubt that this should be part of the standard. What is needed is 
> specification of low-level features in e.g. multiprocessor environments.

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

>> Eliminate large swathes of the C++ standard which leaves
>> the semantics up to the compiler!
> 
> Most of these "implementation defined" parts are there for portability. To 
> many definitions will make it more difficult to port C++ to other platforms.

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

>> Named parameter association. Proper parameter modes
>> "out" and "in out" modes
> 
> I do not see the purpose of the out-parameter. Why not simply return the 
> value(s)?

How do you return multiple values?

> As for named parameter associations, these can again be implemented in a 
> library.

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

>> clarity over arrays.  C++ gives you choice of pointers
>> C arrays, vectors.  This is one example of where the
>> 'C' facilities were too limited, and C++ added
>> alternatives, rather fhan fixing what existed in C.
>> (and char *, char arrays, string etc)
> 
> For C++ portability from C was (and is) an important issue. Thus there is no 
> question about remocing e.g. pointer-arithmetic and decaying of arrays to 
> pointers. This simply can not happen. Also some of these features are needed 
> for an efficient implementation of low-level classes (e.g. std::vector). 
> What you can do is not use these features. And it is just a matter of 
> education to routinely use e.g. std::vector< t > and std::string instead of 
> arrays and char pointers.

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

>> Strong(er) typing, better enumerations, fixed point types,
>> modular types *and* non-modular types. Basic type attributes.
> 
> There are some bad decisions in the type system - specifically i hate the 
> automatic conversions from double to integral value. But again - this is 
> something you have to live with.

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

>> More robust, more readable, less terse syntax, particularly
>> for complex templates (really!)
> 
> Right. The template stuff could possibly have been more elegant.
>>
>> Portability without resorting to preprocessor directives
>> and conditional compilation
> 
> I am not sure i follow you here. In what way do you want portability? Are 
> you thinking of e.g. portability between an X-windows system and Windows? Or 
> portability of lower-level constructs such as multithreading or networking? 
> I wonder how Ada does this stuff.

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

>> associative arrays (from Perl)
> 
> I thought Ada supported generic programming. Isn't it then just a question 
> of creating a library?

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1110570242.82910@athnrd02...
> REH wrote:
>
> >>Named parameter association. Proper parameter modes
> >>"out" and "in out" modes
> >
> > I would love have named parameters too.  That way I would not have to
> > "agonize" over the "priority" of my default parameters (i.e., if there
are
> > 10 and I have to change the 10th from its default, I have to define the
> > first 9).
>
>
> The many parameters passed by reference to be modified is an outdated C
> style.
>
>
That's not what I mean.  I mean I have a function foo that takes many
parameters.  I can think of nothing beyond a contrived example:

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

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

foo(c => 5);

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Marius Amado Alves]

On 11 Mar 2005, at 19:43, Ioannis Vranos wrote:
> ... I think returning (or passing) so many values means something is 
> wrong. :-)

Returning maybe, but passing no. In some domains e.g. GUI it is normal 
to have operations requiring a lot of parameters e.g.

OSErr MakeTrackTimeTable (
      Track        trackH,
      long         **offsets,
      TimeValue    startTime,
      TimeValue    endTime,
      TimeValue    timeIncrement,
      short        firstDataRefIndex,
      short        lastDataRefIndex,
      long         *retdataRefSkew );

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> wrote in message
news:pan.2005.03.11.20.06.33.572481@linuxchip.demon.co.uk.uk.uk...
> >>> * subprograms inside subprograms.  I think it would be great for use
> >>> with the STL (i.e., using a local function with std::foreach)
> >>
> >> Agree strongly.
> >
> > This will be part of the next standard, I hope. Still i do not believe
it to
> > be esential for use.
>
> It is sometimes handy to use the C preprocessor for local functions
>
That would not work in the example above, i.e., for use as the operation
given to STL algorithms.  Besides, inline is better for "quick" functions
than the preprocessor.

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

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

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

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

REH wrote:

> "CTips" <ctips@bestweb.net> wrote in message
> news:1133rhdt7dan4fa@corp.supernews.com...
> 
>>Based on this thread, I think most of the Ada advocates here (and maybe
>>most Ada programmers)
>>- don't know how a processor works
>>- don't know how to measure performance
>>- don't know how to program for performance
>>- don't know where Ada will hurt performance
>>- don't really care about performance
>>
>>This is pretty much in line with my experience. The Ada advocates (I've
>>known several) don't really know how to program for performance. All the
>>people I know who program for performance pick C (if they have the
> 
> choice).
> 
> Then you don't know much.  Ada programmers, and programmers in general care
> about a lot more than performance.  Performance is not the end-all-be-all of
> building software.  You can write crap that takes 1us to execute, and I'll
> wite good, fault-tolerance code that runs in 1ms, but still meets all its
> requirements and real-time deal-lines.  I'll take the later.  This faster is
> better crap is utter non-sense, and it usually exhibited in inexperienced
> engineers (and the immature ones).  I write Ada, C, and C++ professionally,
> so I guess I no "advocate."  I also would not make snide, inappropriate,
> unnecessary, childish, and down right wrong statement about anyone who is
> one.  Ada programmers usually work in the world of real-time software where
> there are many kinds of "performance."  When you can do monotonic-rate
> analysis, et. al., like some Ada Engineers I know, then come talk to me
> about knowing how to measure performance.
> 

Ummm...you're talking to the wrong guy here. I have written significant 
chunks of:
- optimizing compilers (including things like software pipelining, 
register allocation, various whole program analyses etc.)
- OSes & RTOSes (including schedulers, device drivers, filesystems, 
interrupt handler subsystems, synchronization mechanisms etc.)
- JITs (Java and ISA simulators)
- cycle accurate microprocessor simulators (for one of the high-end 
microprocessors shipping now)
- event-driven hard-real-time programs
- synthesis tools
- profiling tools that use performance counters.
- real time DSP programming
Probably over a million loc of shippable code at this point...

Apart from that I've done some full-custom and synthesis hardware design.

Rate-monotonic analysis is pretty basic stuff compared to some of the 
other stuff I've done.

Based on what I've seen, I still maintain that most Ada programmer don't 
know how to get decent performance.

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

[Robert A Duff]

"Jerry Coffin" <jcoffin@taeus.com> writes:

> Robert A Duff wrote:
> 
> [ ... ]
> 
> > If you really want to know about these languages that are being
> > discussed (Ada and C++) nothing beats reading a textbook or two.
> 
> Much as I hate to further my (undoubtedy bad) reputation for being
> disagreeable, I still have to disagree.
> 
> If you follow-up the reading with some real use, it beats reading alone
> by a wide margin, at least IME.

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

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

- Bob

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[REH]

"CTips" <ctips@bestweb.net> wrote in message
news:11340afoijql22e@corp.supernews.com...
> Ummm...you're talking to the wrong guy here. I have written significant
> chunks of:
> - optimizing compilers (including things like software pipelining,
> register allocation, various whole program analyses etc.)
> - OSes & RTOSes (including schedulers, device drivers, filesystems,
> interrupt handler subsystems, synchronization mechanisms etc.)
> - JITs (Java and ISA simulators)
> - cycle accurate microprocessor simulators (for one of the high-end
> microprocessors shipping now)
> - event-driven hard-real-time programs
> - synthesis tools
> - profiling tools that use performance counters.
> - real time DSP programming
> Probably over a million loc of shippable code at this point...
>
> Apart from that I've done some full-custom and synthesis hardware design.
>
Do you think that impressive? I work with about 100 Ada engineers who do
exactly the same types of things, sucessfully,  everyday...

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Willem]

REH wrote:
) Do you think that impressive? I work with about 100 Ada engineers who do
) exactly the same types of things, sucessfully,  everyday...

You 'work with'...  Does that mean that you're the one with pointy hair ?


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[REH]

"Willem" <willem@stack.nl> wrote in message
news:slrnd341tl.2eq4.willem@toad.stack.nl...
> You 'work with'...  Does that mean that you're the one with pointy hair ?
>
>
> SaSW, Willem
No, I'm a software engineer.  I write real-time embedded systems in the
avionics world (Ada '83 and '95, C, and C++).  I said "work with" because 1)
I DO work with some very good people, and 2) I don't like to--nor even seem
to--brag or pat myself on the back.  I find such behavior borish in the
least.

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

[Robert A Duff]

CTips <ctips@bestweb.net> writes:

> Dmitry A. Kazakov wrote:
> 
> > On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote:
> >
> >>How easy is it to build an arena allocator in Ada?
> > It is trivial:
> > type Object is ...;
> > type Object_Ptr is access Object;
> > for Object_Ptr'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?

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

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

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

> > Note that Object can still be allocated on the stack or in any other
> > pool:
> > type Object_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.

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

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

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

- Bob

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

[Robert A Duff]

Wes Groleau <groleau+news@freeshell.org> writes:

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

Actually, I doubt that.  I'm a compiler writer.  In my opinion,
the issue is how much information is available to the compiler.
The explicitness vs. implicitness of the checks is usually
irrelevant to whether they can be optimized away.

To optimize-away a check, whether explicit or implicit,
requires the compiler to prove the check can't fail.
Compilers tend to be stupider, but more meticulous, in
doing so, than human programmers.

> Also, the compiler is less likely to make typos on the checks
> it does not optimize away!

Yes, I agree with that.

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

Heh.  I'm not calling you a fool.  Can I instead merely disagree about
what compilers are typically capable of?

- Bob

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

[Wes Groleau]

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

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


-- 
Wes Groleau

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

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

[Wes Groleau]

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

A misunderstanding shared by the inventors of Java?

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

-- 
Wes Groleau

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

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

[Wes Groleau]

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

Although in at least one point they removed something that
Ada had already proved is not necessarily unsafe: operator
overloading.  As a result, Java programmers either have to
give up both object-orienting and abstraction or use crap like

A.Multiply(2).Divide(B.negative().add(sqrt(B.squared().add(A.mult(2).mult(C)))

for things that are conceptually numeric.

-- 
Wes Groleau

    If you put garbage in a computer nothing comes out but garbage.
    But this garbage, having passed through a very expensive machine,
    is somehow ennobled and none dare criticize it.

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

[Wes Groleau]

Jerry Coffin wrote:
> First of all, work on ARPAnet started out around the mid-1960's, but it
> only became available to most of the public around the early 1990's or
> so. Had development been delayed for 20 years or so until Ada compilers
> were available, we'd be waiting another five years or so before it
> became available to most of its current users.

And if development been delayed until C compilers were available?


-- 
Wes Groleau
   "Grant me the serenity to accept those I cannot change;
    the courage to change the one I can;
    and the wisdom to know it's me."
                                -- unknown

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

[Wes Groleau]

Robert A Duff wrote:
>>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.
> 
> Actually, I doubt that.  I'm a compiler writer.  In my opinion,
> the issue is how much information is available to the compiler.

Well, you may be right.  What I was thinking was that
a compiler(writer) can more easily analyze an RM-required
implicit check (the implementation of which was designed
by the same compiler writer) than a check designed and
written by the compiler user.

-- 
Wes Groleau

Always listen to experts.  They'll tell you
what can't be done and why.  Then do it.
                     -- Robert A. Heinlein

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

Larry Kilgallen wrote:
> If I understand where the various posters are coming from, there have not
> been any Ada users saying "if it compiles it is right", but rather "if it
> fails to compile, it is wrong" and "Ada will fail to compile on a larger
> number of errors than many other languages".

I prefer to say,

"Ada will refuse to compile a larger number of errors...."


-- 
Wes Groleau

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

Alberto wrote:
> As many people on this thread noticed, it was only a (bad?) joke. I
> simply wanted to remark that I was somewhat tired of reading the same
> story of Ada L. when some innocent soul dared to write "ADA" :)

 From another newsgroup: "How can you expect to program in perl
if you can't even spell it?"

(not the exact words)


-- 
Wes Groleau
   "Two things are infinite, the universe and human stupidity.
    But I'm not so sure about the universe."
                                -- Albert Einstein

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

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

Actually, the compiler will not allow any casting into
loop control variables.  And if they were not loop control
variables, the compiler will add checks anywhere that can
be reached from code that has done such a conversion.

-- 
Wes Groleau

    After the christening of his baby brother in church, Jason sobbed
    all the way home in the back seat of the car.  His father asked him
    three times what was wrong.  Finally, the boy replied, "That preacher
    said he wanted us brought up in a Christian home, and I wanted to
    stay with you guys."

Re: 10 rules for benchmarking (was Re: Teaching new tricks to anold dog (C++ -->Ada))

[infobahn]

Jean-Pierre Rosen wrote:
> 
> Blindly claiming that C is faster than Ada is not supported by hard figures.

Indeed. It's like claiming that English is faster than Spanish.

Languages are not implementations.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

REH wrote:
> "CTips" <ctips@bestweb.net> wrote in message
> news:11340afoijql22e@corp.supernews.com...
> 
>>Ummm...you're talking to the wrong guy here. I have written significant
>>chunks of:
>>- optimizing compilers (including things like software pipelining,
>>register allocation, various whole program analyses etc.)
>>- OSes & RTOSes (including schedulers, device drivesrs, filesystems,
>>interrupt handler subsystems, synchronization mechanisms etc.)
>>- JITs (Java and ISA simulators)
>>- cycle accurate microprocessor simulators (for one of the high-end
>>microprocessors shipping now)
>>- event-driven hard-real-time programs
>>- synthesis tools
>>- profiling tools that use performance counters.
>>- real time DSP programming
>>Probably over a million loc of shippable code at this point...
>>
>>Apart from that I've done some full-custom and synthesis hardware design.
>>
> 
> Do you think that impressive? I work with about 100 Ada engineers who do
> exactly the same types of things, sucessfully,  everyday...

Impressive? Up to you. All I was pointing out is that I am qualified to 
make judgements about performance, and the quite visible lack of any 
evidence that any of the Ada-vocates on this thread know about how to 
get good performance.

But since you raised the issue: you mentioned that you work with 100s of 
engineers who do same kind of stuff: lets go down the list and see how 
plausible your claims are:
Write an optimizing compiler? [Remotely possible - some optimizing 
compilers in Ada exist]
Write an RTOS (posix-real-time spec compliant)? [I don't know - I don't 
claim to know all the posix/elcps compliant RTOSes out there, so maybe]
Write a high-end microprocessor simulator? [not a chance in hell. I know 
pretty much everything/everyone in that field, and they use C/C++.]
Synthesis tools? [Huh? You know of commercial EDA tools written in Ada? 
Thats news to me.]
Real-time DSP programming [in C OR Ada - fat chance. At least 20-30% 
assembly; maybe on the TI C67x series its lower; after all they bought 
tartan]
JITs in Ada? [Care to name any?]
Profiling tools baesd on performance monitoring registers? [The ones I 
know of are in C or C++; perhaps you could tell us where Ada is used]

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

[Ludovic Brenta]

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

Aliasing?

-- 
Ludovic Brenta.

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

[Ludovic Brenta]

"Jerry Coffin" writes:
> Martin Dowie wrote:
>> Jerry Coffin wrote:
>> > The subject at hand was the use of C++ in the air traffic control
>> > system.
>> >
>> > As such, X running on top of Windows and/or UNIX becomes relevant
>> > ONLY when tied to the development of air traffic control
>> > software.  This page shows exactly that. A page only about X on
>> > Windows or UNIX would not.
>>
>> Well, I don't think this is *big* news to anyone!
>
> Perhaps not -- but the strong implication that C++ was NOT used in
> such systems, seems to leave only two possible conclusions: the
> person who made the implication was either ignorant or lying.
>
> I prefer to think this WAS big news, meaning the implication was
> simply an honest mistake rather than an outright lie, or the result
> of such a shallow view as to ignore the majority of the system.

Many ATC systems have a GUI which runs on top of X and Motif.
Toolkits such as the one you referred to are designed to avoid C or
C++ programming when creating the GUI.  Instead, the GUI is generated
from point-and-click interfaces.  That's fine by me.

Any tool that helps avoid mistakes or catch mistakes early is IMHO
good.  Eventually, all tools end up generating machine code anyway.
It's just that Ada is better than C++ for safety-critical software.
Code generators can also help, even if they generate unreadable C or
C++ or machine code.

Even in Barco's avionics displays, part of the software is in C, but
generated from a GUI code generator.  Our customers are usually
responsible for this (since they define the graphical appearance of
the display), so we don't worry too much about that.  But buffer
overflows have been known to happen in the generated code during
testing :)

I maintain that most of Eurocontrol's software is written in Ada.  I
think there was an old issue of the Ada User Journal detailing this.
I'm not sure about the GUI however; how much of it is generated I
don't know.

-- 
Ludovic Brenta.

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

[Martin Dowie]

Jerry Coffin wrote:
> Pascal Obry wrote:
> 
>>"Jerry Coffin" <jcoffin@taeus.com> writes:
>>
>>
>>>Your claim of fewer bugs is just the sort of unsupported anti-C
>>>comment we see all the time.
>>
>>Just plain wrong, there is data (a PHD) see
>>http://www.adaic.com/whyada/ada-vs-c/cada_art.html

Ok, what about this paper:
http://www.praxis-his.com/pdfs/c_by_c_better_cheaper.pdf

In particular the company audited by the UK MoD on the 3rd page showed 
interesting results. I work for the company audited and I'm sure the 
audit is post-1995 by some margin (when I was no longer working there), 
and by your own argument, by 1990 the compilers were pretty close to 
standard C, yet this study still found a 10*defect rate in C than in 
Ada... and a 100* defect rate compared to SPARK...

Yet, this sort of report seems all to common to me. Every language since 
'C' has had at least 1 report that shows how brilliant it is at compared 
to 'C', yet 'C' is still the most widely spread language. Why?

I think we perhaps need a psychologists view rather than looking at 
language differences. Are humans 'hooked' on tracking down /really/ 
tricky null pointer dereference problems? Is it really just a fight for 
'silver back status' coz 'my programs compile to 1 long word less than 
yours'?...

Cheers

-- Martin

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

[Martin Dowie]

Martin Dowie wrote:
> interesting results. I work for the company audited and I'm sure the 

That should have read "I worked for the...".

Cheers

-- Martin

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Jim Rogers]

CTips <ctips@bestweb.net> wrote in
news:11329cb96h2p19f@corp.supernews.com: 

> 
> Since it appears that several people out here are making some very
> basic mistakes when they report benchmark numbers, I thought I'd write
> a small note on how to do benchmarking.
> 
[snip advice]
> 10. Make sure that your numbers are reproducible: report
>    - your times
>    - your hardware
>    - your system
>      * OS (with version)
>      * compiler (with version)
>     - the compiler flags used
> 
> 

Let's see if this helps.
I have adjusted my program to meet some of your advice.
The I/O at the end is not included in the reported timing.
The program now runs for > 1 second.


Time run: 1.94 seconds
Hardware: 2.0GHz AMD 64 processor with 512 Mb memory
System :
         OS : WIN XP Service Pack 1
         compiler: GNAT v3.15p
Compiler flags: none (-O2 was tried but appeared to remove too much)

Program: Performs bit search 10,000,000 times

-- 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;
   Bit_Num : Index_Type := 0;
begin
   Start := Clock;
   Num := 1;
   for X in 1..10_000_000 loop
      for I in reverse Overlay'range loop
         if Overlay(I) then
            Bit_Num := I;
            exit;
         end if;
      end loop;
   end loop;
   Stop := Clock;
   Ada.Text_IO.Put_Line("High bit :" & Index_Type'Image(Bit_Num));
   Ada.Text_IO.Put_Line("Execution time: " & 
                         Duration'Image(Stop - Start));
end Highest_Bit_Set;

Program output:
High bit : 0
Execution time:  1.950221327

Jim Rogers

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Jim Rogers wrote:
> CTips <ctips@bestweb.net> wrote in
> news:11329cb96h2p19f@corp.supernews.com: 
> 
> 
>>Since it appears that several people out here are making some very
>>basic mistakes when they report benchmark numbers, I thought I'd write
>>a small note on how to do benchmarking.
>>
> 
> [snip advice]
> 
>>10. Make sure that your numbers are reproducible: report
>>   - your times
>>   - your hardware
>>   - your system
>>     * OS (with version)
>>     * compiler (with version)
>>    - the compiler flags used
>>
>>
> 
> 
> Let's see if this helps.
> I have adjusted my program to meet some of your advice.
> The I/O at the end is not included in the reported timing.
> The program now runs for > 1 second.

Close, but still has one problem. You're using Ada.Calendar.Clock, 
which, IIRC, returns the actual wall-clock time. So, if you were swapped 
out in the middle, you would be over-reporting the time. Isn't there 
some Ada call that is the equivalent of POSIX clock() [or, better, 
times()]?

If I look at your numbers, it seems that you using 2e-7 seconds per 
call. On a 2GHz AMD, that translates to 388 cycles per call.

IIRC, the C codes that were posted to find the highest bit set thread 
were about 1/10th of that number. Just to double check, I wrote and 
measured some C code. On my 3GHz Xeon running with cygwin on WinXP, when 
compiled with gcc3.3.3 using -mpcu=i686 -O0, I got a total run-time of 
2.3s, for about 69 cycles/iteration, and with -O2 I get 0.94s for about 
28 cycles/iteration.

We're comparing a Xeon with a AMD so its not apples to apples, but 
still, it suggests that either your timing methodology could use some 
work, or that the code generated is quite bad.


unsigned
FindHighestBit(unsigned n)
{
   unsigned d = 0;
   if( n > 0xffff ) {
     d += 16;
     n >>= 16;
   }
   if( n > 0xff ) {
     d += 8;
     n >>= 8;
   }
   if( n > 0xf ) {
     d += 4;
     n >>= 4;
   }
   if( n > 0x3 ) {
     d += 2;
     n >>= 2;
   }
   if( n > 0x1 ) {
     d += 1;
     n >>= 1;
   }
   if( n > 0x0 ) {
     d += 1;
   }
   return d;
}
  main(void)
{
   unsigned i;
   unsigned j;
   unsigned s= 0;
   unsigned val[32];

   for( i = 0; i < 32; i+= 2 ) {
     val[i] = (1U<<i)-1;
     val[i+1] = 1U<<(31-i);
   }

   for( i = 0; i < 3125000; i++ ) {
     for( j = 0; j < 32; j++ ) {
       s += FindHighestBit(val[j]);
     }
   }
   return s;
}
> 
> Time run: 1.94 seconds
> Hardware: 2.0GHz AMD 64 processor with 512 Mb memory
> System :
>          OS : WIN XP Service Pack 1
>          compiler: GNAT v3.15p
> Compiler flags: none (-O2 was tried but appeared to remove too much)
> 
> Program: Performs bit search 10,000,000 times
> 
> -- 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;
>    Bit_Num : Index_Type := 0;
> begin
>    Start := Clock;
>    Num := 1;
>    for X in 1..10_000_000 loop
>       for I in reverse Overlay'range loop
>          if Overlay(I) then
>             Bit_Num := I;
>             exit;
>          end if;
>       end loop;
>    end loop;
>    Stop := Clock;
>    Ada.Text_IO.Put_Line("High bit :" & Index_Type'Image(Bit_Num));
>    Ada.Text_IO.Put_Line("Execution time: " & 
>                          Duration'Image(Stop - Start));
> end Highest_Bit_Set;
> 
> Program output:
> High bit : 0
> Execution time:  1.950221327
> 
> Jim Rogers
> 
> 
> 

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Jim Rogers wrote:
> CTips <ctips@bestweb.net> wrote in
> news:11329cb96h2p19f@corp.supernews.com: 
> 
> 
>>Since it appears that several people out here are making some very
>>basic mistakes when they report benchmark numbers, I thought I'd write
>>a small note on how to do benchmarking.
>>
> 
> [snip advice]
> 
>>10. Make sure that your numbers are reproducible: report
>>   - your times
>>   - your hardware
>>   - your system
>>     * OS (with version)
>>     * compiler (with version)
>>    - the compiler flags used
>>
>>
> 
> 
> Let's see if this helps.
> I have adjusted my program to meet some of your advice.
> The I/O at the end is not included in the reported timing.
> The program now runs for > 1 second.

Close, but still has one problem. You're using Ada.Calendar.Clock, 
which, IIRC, returns the actual wall-clock time. So, if you were swapped 
out in the middle, you would be over-reporting the time. Isn't there 
some Ada call that is the equivalent of POSIX clock() [or, better, 
times()]?

If I look at your numbers, it seems that you using 2e-7 seconds per 
call. On a 2GHz AMD, that translates to 388 cycles per call.

IIRC, the C codes that were posted to find the highest bit set thread 
were about 1/10th of that number. Just to double check, I wrote and 
measured some C code. On my 3GHz Xeon running with cygwin on WinXP, when 
compiled with gcc3.3.3 using -mpcu=i686 -O0, I got a total run-time of 
2.3s, for about 69 cycles/iteration, and with -O2 I get 0.94s for about 
28 cycles/iteration.

We're comparing a Xeon with a AMD so its not apples to apples, but 
still, it suggests that either your timing methodology could use some 
work, or that the code generated is quite bad.


unsigned
FindHighestBit(unsigned n)
{
   unsigned d = 0;
   if( n > 0xffff ) {
     d += 16;
     n >>= 16;
   }
   if( n > 0xff ) {
     d += 8;
     n >>= 8;
   }
   if( n > 0xf ) {
     d += 4;
     n >>= 4;
   }
   if( n > 0x3 ) {
     d += 2;
     n >>= 2;
   }
   if( n > 0x1 ) {
     d += 1;
     n >>= 1;
   }
   if( n > 0x0 ) {
     d += 1;
   }
   return d;
}
  main(void)
{
   unsigned i;
   unsigned j;
   unsigned s= 0;
   unsigned val[32];

   for( i = 0; i < 32; i+= 2 ) {
     val[i] = (1U<<i)-1;
     val[i+1] = 1U<<(31-i);
   }

   for( i = 0; i < 3125000; i++ ) {
     for( j = 0; j < 32; j++ ) {
       s += FindHighestBit(val[j]);
     }
   }
   return s;
}
> 
> Time run: 1.94 seconds
> Hardware: 2.0GHz AMD 64 processor with 512 Mb memory
> System :
>          OS : WIN XP Service Pack 1
>          compiler: GNAT v3.15p
> Compiler flags: none (-O2 was tried but appeared to remove too much)
> 
> Program: Performs bit search 10,000,000 times
> 
> -- 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;
>    Bit_Num : Index_Type := 0;
> begin
>    Start := Clock;
>    Num := 1;
>    for X in 1..10_000_000 loop
>       for I in reverse Overlay'range loop
>          if Overlay(I) then
>             Bit_Num := I;
>             exit;
>          end if;
>       end loop;
>    end loop;
>    Stop := Clock;
>    Ada.Text_IO.Put_Line("High bit :" & Index_Type'Image(Bit_Num));
>    Ada.Text_IO.Put_Line("Execution time: " & 
>                          Duration'Image(Stop - Start));
> end Highest_Bit_Set;
> 
> Program output:
> High bit : 0
> Execution time:  1.950221327
> 
> Jim Rogers
> 
> 
> 

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Jim Rogers]

CTips <ctips@bestweb.net> wrote in news:1134l8n86c5f163@corp.supernews.com:

> Jim Rogers wrote:
>> CTips <ctips@bestweb.net> wrote in
>> news:11329cb96h2p19f@corp.supernews.com: 
>> 
>> 
>>>Since it appears that several people out here are making some very
>>>basic mistakes when they report benchmark numbers, I thought I'd write
>>>a small note on how to do benchmarking.
>>>
>> 
>> [snip advice]
>> 
>>>10. Make sure that your numbers are reproducible: report
>>>   - your times
>>>   - your hardware
>>>   - your system
>>>     * OS (with version)
>>>     * compiler (with version)
>>>    - the compiler flags used
>>>
>>>
>> 
>> 
>> Let's see if this helps.
>> I have adjusted my program to meet some of your advice.
>> The I/O at the end is not included in the reported timing.
>> The program now runs for > 1 second.
> 
> Close, but still has one problem. You're using Ada.Calendar.Clock, 
> which, IIRC, returns the actual wall-clock time. So, if you were swapped 
> out in the middle, you would be over-reporting the time. Isn't there 
> some Ada call that is the equivalent of POSIX clock() [or, better, 
> times()]?
> 
> If I look at your numbers, it seems that you using 2e-7 seconds per 
> call. On a 2GHz AMD, that translates to 388 cycles per call.
> 
> IIRC, the C codes that were posted to find the highest bit set thread 
> were about 1/10th of that number. Just to double check, I wrote and 
> measured some C code. On my 3GHz Xeon running with cygwin on WinXP, when 
> compiled with gcc3.3.3 using -mpcu=i686 -O0, I got a total run-time of 
> 2.3s, for about 69 cycles/iteration, and with -O2 I get 0.94s for about 
> 28 cycles/iteration.
> 
> We're comparing a Xeon with a AMD so its not apples to apples, but 
> still, it suggests that either your timing methodology could use some 
> work, or that the code generated is quite bad.

I have created another version and downloaded the latest cygwin to
try to make the system as similar as possible. I have translated your
example into Ada for another increase in similarity.

compiled with -gnatwu -gnato -I 

Using the cygwin time command I got  a total run-time of 2.1s.
With -O2 I get 1.1s 

My speed appears to be very similar to yours.

-- Highest_Bit2
-- More efficient algoritm than Highest_Bit

with Interfaces; 
use Interfaces;
with Ada.Command_Line;
use Ada.Command_Line;

procedure Highest_Bit2 is
   function Find_Highest_Bit(N : Unsigned_32) return Unsigned_32 is
      D : Unsigned_32 := 0;
      V : Unsigned_32 := N;
   begin
      if V > 16#FFFF# then
         D := D + 16;
         V := Shift_Right(Value => V, Amount =>16);
      end if;
      if V > 16#FF# then
         D := D + 8;
         V := Shift_Right(Value => V, Amount => 8);
      end if;
      if V > 16#F# then
         D := D + 4;
         V := Shift_Right(Value => V, Amount => 4);
      end if;
      if V > 3 then
         D := D + 2;
         V := Shift_Right(Value => V, Amount => 2);
      end if;
      if V > 1 then
         D := D + 1;
         V := Shift_Right(Value => V, Amount => 1);
      end if;
      if V > 0 then
         D := D + 1;
      end if;
      return D; 
   end Find_Highest_Bit;
   
   type Index is mod 32;
   type Val_Array is array(Index) of Unsigned_32;
   Val : Val_Array;
   S : Unsigned_32 := 0;
   I : Index := 0;  
   U : Unsigned_32 := 1;    
begin
   loop
      Val(I) := Shift_Left(Value => U, Amount => Natural(I)) - 1;
      if I < Index'Last - 2 then
         Val(I + 1) := Shift_Left(U, 32 - Natural(I));
         I := I + 2;
      else
         exit;
      end if;
   end loop;
   for N in 0..3124999 loop
      for J in Index'range loop
         S := S + Find_Highest_Bit(Val(J));
      end loop;
   end loop;
   Set_Exit_Status(Exit_Status(S));
end Highest_Bit2;


Jim Rogers

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

REH wrote:

> Ada allows you to define a primative type (int, etc.) that is "distinct"
> from others.  This is nice for overload resolution, etc.
> 
> I know, but being about to write "is new integer" is a lot simplier than
> creating a class just to create a "unique" integer type.  Plus. since it is
> a unique type I can define its exact size in bits which make portabililty
> easier:
> 
> type Byte is new integer range 0 .. 16#ff#;
> for Byte'size use 8;


I am pretty sure one can write a library that can enable just that.


Now that I am thinking of it, there are some, and let's begin from Boost:


http://www.boost.org/libs/integer/integer.htm


#include <boost/integer.hpp>


int main()
{
     using namespace boost;

     int_t<24>::least my_var;
}



with "least" being the smallest built-in type that supports the given 
bit count.



You see, that's easy. :-) Just "plug in" Boost.


I am sure there are other libraries too.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Jerry Coffin]

Robert A Duff wrote:

[ ... ]

> > If you follow-up the reading with some real use, it beats reading
> > alone by a wide margin, at least IME.
>
> But I agree with that!  Your reputation as disagreeable is ruined.
> ;-)

Pardon my being blunt, but Damn! The one thing I was good at is ruined!

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

This, unfortunately, is all too true.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Ioannis Vranos wrote:

> I am pretty sure one can write a library that can enable just that.
> 
> 
> Now that I am thinking of it, there are some, and let's begin from Boost:
> 
> 
> http://www.boost.org/libs/integer/integer.htm
> 
> 
> #include <boost/integer.hpp>
> 
> 
> int main()
> {
>     using namespace boost;
> 
>     int_t<24>::least my_var;
> }
> 
> 
> 
> with "least" being the smallest built-in type that supports the given 
> bit count.
> 
> 
> 
> You see, that's easy. :-) Just "plug in" Boost.
> 
> 
> I am sure there are other libraries too.



Actually the Boost type that you are probably looking for is:


"uint_value_t: The smallest built-in unsigned integral type that 
supports the given value as a maximum. The parameter should be a 
positive number."


This is the equivalent of 0..whatever.


Myself thinks though that this whole range specialisation thing is 
non-sense for regular application programming at least.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Ioannis Vranos wrote:

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



So the example becomes:

#include <boost/integer.hpp>


int main()
{
     using namespace boost;

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

     my_var= 9;
}



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


Indeed. :-)



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Georg Bauhaus]

CTips wrote:
> Jean-Pierre Rosen wrote:
> 
>> CTips a �crit :
>>
>>>
>>> Since it appears that several people out here are making some very 
>>> basic mistakes when they report benchmark numbers, I thought I'd 
>>> write a small note on how to do benchmarking.
>>>
>> [lots of good stuff deleted]
>>
>> You are absolutely right, but there is one thing that this benchmark 
>> *proves*:
>>
>> Blindly claiming that C is faster than Ada is not supported by hard 
>> figures.
>>
> 
> Actually, it is.

Seems not so easy as you claim it to be.
I have done some more tests following your advice.
Though, I find my computer far too complicated for me to understand
or predict, even speculating about caches and TLB. Can a
PC be described in sufficient detail to say anything precise
or to write predictable assembly language programs for all kinds
of situations with PC OSs?

Anyway, here goes.
The starred columns show seconds with checks turned off
(in both languages).

Your program has, at C module level,
int perm[N];
so I did the same in Ada, results are in the T and TC columns.
The TU and TUC columns show seconds when dynamically allocated
array are used, from an unconstrained array type.

                      C             |             Ada
N        R       *T*         TC      *T*      TC      TU      TUC
4000     50000   1.01        2.46    1.01     1.67    1.65    2.0
8000     25000   1.01 (2.31) 2.45    1.01     1.67    1.65    2.0
10000    20000   1.01        2.46    1.01     1.65    1.65    2.0
20000    10000   1.02 (2.32) 2.48    1.02+    1.7++   2.5-    2.0
25000    8000    1.7++       2.46++  1.78++   2.6+--  2.6+-   2.3++-
40000    5000    4.6+        5.48+   4.6++    5.0+-   5.5+-   5.1+-
50000    4000    6.1  (6.4+) 6.7     6.1      6.4+-   5.9+-   7.1-
100000   2000    7.4         7.25    7.2      7.0     7.0     7.2
200000   1000    7.38        7.26    7.22     6.9     6.8     7.1

N: number of integers in the arrays

R: number of runs (calls of do_perm)

T: time without checks

TC: time with checks
   C = checking handcoded conditionals. In () short circuit checks
   Ada = compiler switches turning all checks on

TU: time, unconstrained Ada arrays (dynamically allocated)
TUC: again, with all checks on

+ and - indicate strong deviations in running time in:
$ while true ; do time ./perm ; done
(I guess the fluctuations might indicate where the something becomes
full or loaded.)
The numbers given are the shortest times except when the results
were jumpy and showed a faster result just once in a long series.

There is 1G of memory in the machine, and two PIII at 800 MHz.
The OS (GNU/Linux 2.6.8) has been operating in single user mode,
unloaded, compiler is GCC 4.0.0 20050215 in all cases.

gcc -O2 -ansi -pedantic
gnatmake -O2 -gnatwa -gnatp
gnatmake -O2 -gnatwa -gnatVa -gnato

I have used your C code for the C-no-checks test. For the checks
test I modified the commented conditional (see below).
The reason is that it should match the array range checking in Ada
and other languages, where semantically each array has two bounds,
for a total of four for perm[] and val[].  In (some) theory.
So I wrote a dumb test, and a slightly less dumb test.

The parenthesised times in the table have been measured after short
circuit operators had replaced the bit operators.
Obviously, when I want to compare checking of unknown bounds, I
have to pass bounds to do_perms(). Just comparing the loop counter to
N isn't the same thing. The parameters are named perm_n and val_n.

     /**/
     if ( i < 0 | i >= perm_n ) {
       abort();
     }
     if( perm[i] < 0 | perm[i] >= val_n) {
       abort();
     }
     /**/

For sure this is not the optimal or necessary check in this
loop, but for the test case it provides for comparing _unconstrained_
array types.
Otherwise 0 as the first index in C had been used a built-in
constraint.

(With this particular loop the checking can be made faster by
reversing the order of comparisons, as for example i < 0 will
invariably be false.)

Ada text, the dynamically allocated arrays:

    type Perm_Array is array(Natural range <>)  of Integer;
...
    setup_perm(perm.all);
    for rep in 1 .. R  loop
       do_perm(val.all, perm.all);
    end loop;

My conclusion is that for some data the C version is faster,
and that for some data the Ada version is faster, on this
machine. It takes a lot of time to really find out what
and why. Still, you get fast code from either language front
end, so if an Ada compiler will check more things at
compile time, support more programming language, and you want
your compiler to do this, it can be a plus.

Adding a complete set of runtime checks can be quite expensive,
some lines in the table show this. (GNAT doesn't add all
checks by default.)
Paradoxically, for both C and Ada, checks seem to speed up
processing (see the last line) when the amount of data
is growing.

The unconstrained array version has been faster with some data
than the constrained array type version...

Both versions can run more quickly on this machine when
the arrays can live on the stack. :-)

Georg


> In most cases, it is possible to get close to assembly performance out 
> of C [one major case where it isn't is when you want to use 
> labels-as-addresses].

I take it you mean the one best performing assembly language
program found by a very clever programmer beating all optimizers.
Possible, but how do you get there systematically?
Given that you can insert assembly instructions in a number of PLs,
this alone is not a competitive argument.

> In fact, it is _NOT_ possible to beat that number 
> using any language.

For this to be true, someone would have to actually prove
that a given assembly language program cannot be beaten by
any other assembly language program taking the same set
of inputs to outputs, and react in the same ways that the
given assembly language program does. Possible, o.K., but
feasably for any reasonably sized program?

> If there are any run-time checks added by the Ada 
> compiler, then the performance will not be the assembly level 
> performance.

How do you explain, in terms of assembly language instructions,
the speedup in the last line of the table above (T -> TC)?
(I have double-checked them for both languages.)

> Consequently, either one must program so that no checks 
> need to be added OR one must disable all run-time checking.


> BTW - all the psuedo-benchmarking people have done on this thread so far 
> has provided meaningless numbers - too small run-times, performance 
> dominated by cache misses etc.

And VERY_LARGE_NUMBER meaning not too large for ... :-)

Georg

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

[Georg Bauhaus]

CTips wrote:
> Georg Bauhaus wrote:
> 
> 
>> Done. You might be disappointed by the results. In short:
>> < 1%, < 3%; and < 8% for a different program, really.
> 
> 
> I'm not disappointed at all, in fact the numbers are way worse than I 
> expected, [...]

> You have to be *very* careful that what you're measuring isn't hidden 
> behind some other effect.

I admit that I was measuring relative performance of a program
written in two programming languages. And I didn't want to write
a benchmark program; how useful, well-defined, etc. are they.

Out of curiosity, if a 1.03x slowdown is far worse than expected,
than what is a not-so-bad slowdown that would make you say o.K.
to checks?

> ----------------------------------------------------------
> 
> #define N 50000

... (more and hopefully better results in another post)

Georg

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Georg Bauhaus]

CTips wrote:

> Like I said, if one knows what one is doing (which he does) then one can 
> disregard the rules. If one does not know what one is doing (which you 
> don't) then one should follow the rules.

If one defines what is the right thing to do and does it
then there is nothing to argue about. OTOH, who says
who is doing right because they are referring to some machine
that allows them to explain that they know what they are
doing? This may sound like far fetched, but there are other
references, e.g. (semi-)formal economic, or organisational.
If
  "To produce a fast program, and a fast enough one,
   but not the fastest will be easier, and sooner,"
is true, then,
  "so do that"
is an argument outperforming every benchmark argument out
there (yes, the arguement is not always true).

If someone is utterly ignorant of anything inside the
computer on the desktop and they ask, "can this VB
program format 30 documents per hour?" then they know
very well what they are asking, and they are right when
they are suspicious of someone explaining to them that
this program is wasting a dose of valuable instruction
cycles and that with proper knowledge, language, and effort,
the same box could format 110 documents per hour.
   In the commercial frame of reference, _this_ is
ignorant in their view, because in this case the benchmarkers
don't follow the rules by wasting brain cycles on
silly speed things ;-).

Some people do know (very well) how to write a benchmark,
I'm not one of them. This does not however imply that
a benchmark incorporates all the references to the important
things to measure or to discuss. E.g. a compiler has a
"human user interface", and its output is not just
performance. A compiler's  input is, de facto, not just
instructions to a specific computing machine.
So combining "human user interface" and "not just
instructions" yields guidance as to what should be
measured when comparing relative merits of a programming
language in a given situation.


Georg

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Georg Bauhaus]

Falk Tannh�user wrote:
> Dr. Adrian Wrigley wrote:
> 
>> But what of features not present in either?
> 
> [...]
> 
>> associative arrays (from Perl)
> 
> 
> Wouldn't that be std::map in C++?

and in Ada 2005,

Ada.Containers.Hashed_Maps  and  Ada.Containers.Hashed_Maps


Georg

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Aslan Kral]

"CTips" <ctips@bestweb.net>, haber iletisinde sunlari
yazdi:1134l90ja5sqm73@corp.supernews.com...
> Jim Rogers wrote:
> > CTips <ctips@bestweb.net> wrote in
> > news:11329cb96h2p19f@corp.supernews.com:
> >
> >
> >>Since it appears that several people out here are making some very
> >>basic mistakes when they report benchmark numbers, I thought I'd write
> >>a small note on how to do benchmarking.
> >>
> >
> > [snip advice]
> >
> >>10. Make sure that your numbers are reproducible: report
> >>   - your times
> >>   - your hardware
> >>   - your system
> >>     * OS (with version)
> >>     * compiler (with version)
> >>    - the compiler flags used
> >>
> >>
> >
> >
> > Let's see if this helps.
> > I have adjusted my program to meet some of your advice.
> > The I/O at the end is not included in the reported timing.
> > The program now runs for > 1 second.
>
> Close, but still has one problem. You're using Ada.Calendar.Clock,
> which, IIRC, returns the actual wall-clock time. So, if you were swapped
> out in the middle, you would be over-reporting the time. Isn't there
> some Ada call that is the equivalent of POSIX clock() [or, better,
> times()]?
>
> If I look at your numbers, it seems that you using 2e-7 seconds per
> call. On a 2GHz AMD, that translates to 388 cycles per call.
>
> IIRC, the C codes that were posted to find the highest bit set thread
> were about 1/10th of that number. Just to double check, I wrote and
> measured some C code. On my 3GHz Xeon running with cygwin on WinXP, when
> compiled with gcc3.3.3 using -mpcu=i686 -O0, I got a total run-time of
> 2.3s, for about 69 cycles/iteration, and with -O2 I get 0.94s for about
> 28 cycles/iteration.
>

OK. I adjusted the code to run in your loop.

Your score is a bit strange to me?! It may be the compiler that makes the
difference.
I timed your code in my P4 1.4GHz NT4.0 SP6 (MSVC6) and my result is ~2100
ms for your code while the best version suggested by Williem finishes in
~650 ms (which is slightly better than 1-opcode "bsr" inline assembly
version). I guess it is because you use a 5-bit lookup table. Unfortunately
I couldn't test the Ada version.

And I tried to run the loops twice in a row and they seem linear except for
the assembly version which seems to get slightly better.
Yours: 4200 ms
Williem's: 1300 ms
"bsr": 1280 ms




> We're comparing a Xeon with a AMD so its not apples to apples, but
> still, it suggests that either your timing methodology could use some
> work, or that the code generated is quite bad.
>
>
> unsigned
> FindHighestBit(unsigned n)
> {
>    unsigned d = 0;
>    if( n > 0xffff ) {
>      d += 16;
>      n >>= 16;
>    }
>    if( n > 0xff ) {
>      d += 8;
>      n >>= 8;
>    }
>    if( n > 0xf ) {
>      d += 4;
>      n >>= 4;
>    }
>    if( n > 0x3 ) {
>      d += 2;
>      n >>= 2;
>    }
>    if( n > 0x1 ) {
>      d += 1;
>      n >>= 1;
>    }
>    if( n > 0x0 ) {
>      d += 1;
>    }
>    return d;
> }
>   main(void)
> {
>    unsigned i;
>    unsigned j;
>    unsigned s= 0;
>    unsigned val[32];
>
>    for( i = 0; i < 32; i+= 2 ) {
>      val[i] = (1U<<i)-1;
>      val[i+1] = 1U<<(31-i);
>    }
>
>    for( i = 0; i < 3125000; i++ ) {
>      for( j = 0; j < 32; j++ ) {
>        s += FindHighestBit(val[j]);
>      }
>    }
>    return s;
> }
> >
> > Time run: 1.94 seconds
> > Hardware: 2.0GHz AMD 64 processor with 512 Mb memory
> > System :
> >          OS : WIN XP Service Pack 1
> >          compiler: GNAT v3.15p
> > Compiler flags: none (-O2 was tried but appeared to remove too much)
> >
> > Program: Performs bit search 10,000,000 times
> >
> > -- 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;
> >    Bit_Num : Index_Type := 0;
> > begin
> >    Start := Clock;
> >    Num := 1;
> >    for X in 1..10_000_000 loop
> >       for I in reverse Overlay'range loop
> >          if Overlay(I) then
> >             Bit_Num := I;
> >             exit;
> >          end if;
> >       end loop;
> >    end loop;
> >    Stop := Clock;
> >    Ada.Text_IO.Put_Line("High bit :" & Index_Type'Image(Bit_Num));
> >    Ada.Text_IO.Put_Line("Execution time: " &
> >                          Duration'Image(Stop - Start));
> > end Highest_Bit_Set;
> >
> > Program output:
> > High bit : 0
> > Execution time:  1.950221327
> >
> > Jim Rogers
> >
> >
> >

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

[Simon Wright]

Pascal Obry <pascal@obry.org> writes:

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

Google shows me lwlock as a C function in the PostGres support groups;
I don't know what machine architecture has these instructions? PowerPC?

It could be used by any compiler as part of a low-level
implementation, of course, but it's hardly likely that a C compiler
could use it off its own bat. Why whould it want to unless you the
programmer tells it to?

If you're talking about assembler inserts in C -- for Pete's sake, we
can insert assembler in Ada as a last resort if it's needed.

What happens with lwlock about priority inversion?

> 
> No protected type implementations will be so light. This is impossible as it
> brings far more than atomic integer. For an atomic integer it is possible to
> declare :
> 
>    Value : Integer;
>    pragma Atomic (Value);

I don't think this will make

  Value := Value + 1;

atomic, though!

-- 
Simon Wright                               100% Ada, no bugs.

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

[Martin Krischik]

Jerry Coffin wrote:

> Pascal Obry wrote:
>> "Jerry Coffin" <jcoffin@taeus.com> writes:
>>
>> > Your claim of fewer bugs is just the sort of unsupported anti-C
>> > comment we see all the time.
>>
>> Just plain wrong, there is data (a PHD) see
>> http://www.adaic.com/whyada/ada-vs-c/cada_art.html
> 
> Perhaps you should reread this, paying paritcular attention to the
> dates involved. According to the paper, they started switching from C
> to Ada around 1986. C wasn't standardized until 1989, and (as you'd
> expect) it was some time after that before most compilers implemented
> the standard language.

Did they? Or did they just implemented some 80% of the new features? My
experience with C/C++ (and I have 10 years + of that) is that at no time
there was a fully compiant C compiler available. There where allways a lot
of compiler avaliable who claimed to be <small>almost</small> complinant -
but never one which realy was.

Partily because - unlike Ada (http://en.wikipedia.org/wiki/ISO_18009) -
there is not official testsuite to test a C/C++ compiler and runtime
library. Such an official testsuite would do C/C++ all sorts of good.

> By 1990 or so when compilers conforming reasonably closely with the C
> standard became available, it appears likely that essentially all new
> development was being done in Ada. Under the circumstances, it would be
> rather surprising if the C code was ever rewritten into standard C.

On the last project I was working with a 3rd party library which had not a
single "const" in its header files - probably to be compatible with old
compilers. So a major "savety" feature of C89 was still missing in current
code - and affected our current development - since I has to use that
library.

> In short, this is not a comparison to the C language as it exists
> today, or has existed in well over a decade.

What do you mean by "exists today"? C99 is 5 years old and still no compiler
is available which support all C99 features. "restrict" - missing in MS-C
(even thrue restrict can be implemented as "no operation") - VA - arrays
(savety critical feature) - missing in MS-C, buggy in GCC. 

The most compatible C/C++ compiler AFAIK is digital mars
(http://www.digitalmars.com) with "only" 4 C99 features missing: 
(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#c_unimplemented).

But even digital mars aims only at the C++98 and not the current C++ 2003.
And there are still 4 features missing: 
(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#cpp_unimplemented).

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

Maybe just maybe - if there realy was any standart compiler available - but
there isn't - the C/C++ compiler vendors are allways one release behind the
actual ISO standart.

> By contrast, comparing modern C++ to the pre-standard C shows _large_
> improvements in nearly all areas. This is due in part to the changes in
> the language itself, but perhaps even more so to improved understanding
> of how to use the language.

True - the former slim languages designed by individuals have become fad
languages desined by the ISO commitie ;-).

It is true that a programming language need some minimum features set to be
usefull. And that feature set is a lot larger then most belive. If a
successfull language does not provide that set it will be bolted on later.
If anything the current C/C++ ISO standards clearly show that the advocates
for slim languages hat been wrong all along.

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

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Jim Rogers wrote:
>
> 
> I have created another version and downloaded the latest cygwin to
> try to make the system as similar as possible. I have translated your
> example into Ada for another increase in similarity.
> 
> compiled with -gnatwu -gnato -I 
> 
> Using the cygwin time command I got  a total run-time of 2.1s.
> With -O2 I get 1.1s 
> 
> My speed appears to be very similar to yours.

Good!

Did you run the C code as well by any chance?

BTW: the numbers *should* be the pretty close to identical. The 
algorithms are the same, Ada does not need to kick in any of its 
run-time checks, and the two backends are the same.

About the only room for difference is if the two flags (-O2) kick off 
different sets of optimizations for Ada and C.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

"REH" <bogus@nowhere.net> skrev i en meddelelse 
news:d0strm$ep73@cui1.lmms.lmco.com...
>
> "Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
> news:1110570242.82910@athnrd02...
>> REH wrote:
>>
>> >>Named parameter association. Proper parameter modes
>> >>"out" and "in out" modes
>> >
>> > I would love have named parameters too.  That way I would not have to
>> > "agonize" over the "priority" of my default parameters (i.e., if there
> are
>> > 10 and I have to change the 10th from its default, I have to define the
>> > first 9).
>>
>>
>> The many parameters passed by reference to be modified is an outdated C
>> style.
>>
>>
> That's not what I mean.  I mean I have a function foo that takes many
> parameters.  I can think of nothing beyond a contrived example:
>
> void foo(int a= 1, int b = 2, int c = 3);
>
> I usually try and determine which will change most often, and make that 
> the
> first one, and on down the line.  The is because if I need to define
> parameter c in a call to foo, I need to define a and b also.  In Ada I can
> just say:
>
> foo(c => 5);
>
> I had one instance where I had many complex objects that took a lot of
> constructor parameters.  I ended up putting the parameters in related
> groups, and making each group a struct, each with its own set of defaults 
> so
> I would only have to define them if I cared about a particular group.  I'm
> sure there is probably a better design.  I hope that was clear.
>
>
First off, I do not believe in procedures with many parameters. But if you 
do want to use such a feature, look at boost, which lets you say e.g. foo(c 
= 5) or foo(c = 4,a = 2). This is all outside the core language, relying on 
some (vlever) template programming. 

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

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Google shows me lwlock as a C function in the PostGres support groups;
> I don't know what machine architecture has these instructions? PowerPC?

Someone else gave me the key: the first result returned by a Google
Groups query for 'store word conditional' says (a) the instructions
are present on (newer?) PowerPCs, (b)

   You can't use load word and reserve and store word conditional to
   protect more than one word in common between interrupt and
   non-interrupt code, because doing so requires implementing a
   semaphore/mutex.  I don't see how you can do this against interrupt
   code, which has no way of yielding to the non-interrupt code if it
   finds that the non-interrupt code is in the critical section.

   Load word and reserve and store word conditional work fine between
   interrupt and non-interrupt code, but only protect a single word.

   Dealing with critical-section changes to more than one word
   appears, to me, to require either locking out interrupts while in
   the critical section or else having the interrupt code do something
   requiring critical section modification of only one word
   (e.g. putting some data on a singly linked list), and deferring the
   rest of the work to non-interrupt code that *can* yield (or, ick,
   busy wait for a preemption) on a semaphore.

and I suspect there's similar reservation when you have preemptive
priorities.

I am _really_ not interested in being able to increment integers
atomically!

-- 
Simon Wright                               100% Ada, no bugs.

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

[Martin Krischik]

Ludovic Brenta wrote:

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

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

Martin

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

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

[Peter Koch Larsen]

"Martin Krischik" <martin@krischik.com> skrev i en meddelelse 
news:4952804.Myubg7stsI@linux1.krischik.com...
> Jerry Coffin wrote:
>
>> Pascal Obry wrote:
>>> "Jerry Coffin" <jcoffin@taeus.com> writes:
>>>
>>> > Your claim of fewer bugs is just the sort of unsupported anti-C
>>> > comment we see all the time.
>>>
>>> Just plain wrong, there is data (a PHD) see
>>> http://www.adaic.com/whyada/ada-vs-c/cada_art.html
>>
>> Perhaps you should reread this, paying paritcular attention to the
>> dates involved. According to the paper, they started switching from C
>> to Ada around 1986. C wasn't standardized until 1989, and (as you'd
>> expect) it was some time after that before most compilers implemented
>> the standard language.
>
> Did they? Or did they just implemented some 80% of the new features? My
> experience with C/C++ (and I have 10 years + of that) is that at no time
> there was a fully compiant C compiler available. There where allways a lot
> of compiler avaliable who claimed to be <small>almost</small> complinant -
> but never one which realy was.
>
> Partily because - unlike Ada (http://en.wikipedia.org/wiki/ISO_18009) -
> there is not official testsuite to test a C/C++ compiler and runtime
> library. Such an official testsuite would do C/C++ all sorts of good.

I do not believe that to be the problem. There is a standard and there are 
commercial libraries out there to test conformance. The problem rather lies 
in other areas such as:

- compiler vendors wanting to be backwards compatible.
- compiler vendors wanting to get a grip on their customers by ofering 
"extensions" to the language.
- compiler vendors who don't care if their product is standards-compliant.
>
>> By 1990 or so when compilers conforming reasonably closely with the C
>> standard became available, it appears likely that essentially all new
>> development was being done in Ada. Under the circumstances, it would be
>> rather surprising if the C code was ever rewritten into standard C.
>
> On the last project I was working with a 3rd party library which had not a
> single "const" in its header files - probably to be compatible with old
> compilers. So a major "savety" feature of C89 was still missing in current
> code - and affected our current development - since I has to use that
> library.

You could use another library out there. Cars are not bad just because one 
manufacturer ships buggy cars out.
>
>> In short, this is not a comparison to the C language as it exists
>> today, or has existed in well over a decade.
>
> What do you mean by "exists today"? C99 is 5 years old and still no 
> compiler
> is available which support all C99 features. "restrict" - missing in MS-C
> (even thrue restrict can be implemented as "no operation") - VA - arrays
> (savety critical feature) - missing in MS-C, buggy in GCC.
>
> The most compatible C/C++ compiler AFAIK is digital mars
> (http://www.digitalmars.com) with "only" 4 C99 features missing:
> (http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#c_unimplemented).
>
> But even digital mars aims only at the C++98 and not the current C++ 2003.
> And there are still 4 features missing:
> (http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#cpp_unimplemented).
>
Did you have a look at Comeau C++?

>> If anything, based on my own experience with standard C vs.
>> pre-standard C, I'd say his study shows rather the opposite of what you
>> think it does. Standard C was enough of an improvement over
>> pre-standard C that it would be rather surprising if standard C didn't
>> beat Ada in most areas studied (the primary exception being code
>> reuse).
>
> Maybe just maybe - if there realy was any standart compiler available - 
> but
> there isn't - the C/C++ compiler vendors are allways one release behind 
> the
> actual ISO standart.

If you look at C++ (i can't comment on C), all major vendors i know of have 
a high level of compliance.

>
>> By contrast, comparing modern C++ to the pre-standard C shows _large_
>> improvements in nearly all areas. This is due in part to the changes in
>> the language itself, but perhaps even more so to improved understanding
>> of how to use the language.
>
> True - the former slim languages designed by individuals have become fad
> languages desined by the ISO commitie ;-).

This is simply not true. The "ISO commitie" you refer to consists of people 
using C++ in daily life.

>
> It is true that a programming language need some minimum features set to 
> be
> usefull. And that feature set is a lot larger then most belive. If a
> successfull language does not provide that set it will be bolted on later.
> If anything the current C/C++ ISO standards clearly show that the 
> advocates
> for slim languages hat been wrong all along.

I have to disagree again. C/C++ has been most succesfull as a language if 
you measure that by the number of applications written in that language.

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

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Willem]

Georg wrote:
) Anyway, here goes.
) The starred columns show seconds with checks turned off
) (in both languages).
)
) Your program has, at C module level,

Would you mind quoting exactly which C program you ran the tests with ?
And maybe also which Ada program ?


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Ioannis Vranos wrote:

> Dr. Adrian Wrigley wrote:
> 
>>>Ada features I would love to have in C++:
>>>* "new types" and sub-ranges

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

explicit typedef int My_Integer;

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

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

The other would be

explicit typdef int <1, 31> Day_Of_Month;

See: http://en.wikibooks.org/wiki/Programming:Ada:Types:range

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

Shure you can create a template for the problem above - but without the
"explicit typdef" you always have the problem of

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

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

I have 10+ years experience of C/C++ - I already know the little tricks you
could do to circumvent the problem above. It would be nicer without tricks.

>  From my (perhaps limited) experience of .NET where run-time generics
> are also available to C++ (with the upcoming C++/CLI, .NET 2 and VC++
> 2005 - currently Beta), run-time generics are more limited than
> compile-time templates. Also since they are run-time they are less
> efficient.

I think they are more free:

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

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

And yes: that works in Ada.

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

No - usualy they result in .obj files. Ada packages consist of a
specification file and a body file which result into object file and some
form of precompiled header file. The Ada language more or less demands some
form of precompiled header files (very simply speaking).

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

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

>> Portability without resorting to preprocessor directives
>> and conditional compilation

> These are used essentially for system-oriented code.

No, almost all header files need:

#if defined (X_INCLUDED)
#define X_INCLUDED)

#endif

Which brings us back to the packages ;-) . 

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message 
news:1110609321.686344@athnrd02...

>> Myself thinks though that this whole range specialisation thing is 
>> non-sense for regular application programming at least.
>
>
> Indeed. :-)
>
>
Not all of us do "regular application programming."  I write 
mission-critical systems.  In such an environment, it is non-sense NOT to 
define ranges for data types that have them.  I would rather it "failed 
loudly" when a variable strayed out of range and raised an exception I can 
recover from, then continuing to run, causing unknown or undefined behavior.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message 
news:1110607809.837000@athnrd02...
> I am pretty sure one can write a library that can enable just that.
>
>
> Now that I am thinking of it, there are some, and let's begin from Boost:
>
>
> http://www.boost.org/libs/integer/integer.htm
>
>
> #include <boost/integer.hpp>
>
>
> int main()
> {
>     using namespace boost;
>
>     int_t<24>::least my_var;
> }
>
>
>
> with "least" being the smallest built-in type that supports the given bit 
> count.
>
>
>
> You see, that's easy. :-) Just "plug in" Boost.
>
Yes, I'd used Boost.  It's an amazing library, but the above is not 
equivalent to what I wrote.  The major different, and the feature I'd mainly 
like to see in C++ in that the definition of Byte above is a unique type. 
It can participate in overload resolution.  Different typedefs using 
int_t<24> are not distinct.  I know this can be achieved with an extra 
template parameter, enums, or classes, but I don't want to go to that kind 
of effort just to tell the compiler to treat it as a unique type.  Another 
difference,  in C++ you cannot create an array of int_t<3> and have all the 
element be exactly 3 bits.  Using 'size and 'component_size (or even pragma 
pack), in Ada you can.  I can also specify a range other than zero to max. 
You may not care (as your other post suggests), but for fault tolerance, I 
do.

Don't get me wrong.  I'm not one of the C++ bashers (I think 
language-bashing is nonsense).  C++ is my favorite language.  But Ada has 
some really nice features I'd like to see in it.  I don't care about the 
forced range checking.  I don't think that "fits" C++.  I would however, 
like to be able to easily define unique types of primatives.  Being able to 
portable and explicitly define its size in bits (so that arrays and structs 
obey) would be nice, too.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Aslan Kral]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4163 bytes --]


"Aslan Kral" <aslanski2002@yahoo.com>, haber iletisinde �unlar�
yazd�:39fr2iF5uq3mvU1@individual.net...
> > IIRC, the C codes that were posted to find the highest bit set thread
> > were about 1/10th of that number. Just to double check, I wrote and
> > measured some C code. On my 3GHz Xeon running with cygwin on WinXP, when
> > compiled with gcc3.3.3 using -mpcu=i686 -O0, I got a total run-time of
> > 2.3s, for about 69 cycles/iteration, and with -O2 I get 0.94s for about
> > 28 cycles/iteration.
> >
>

Oops! I failed to read the -O2 part. It makes sense now. And your code
doesn't use any lookup table that is why it is slower than Willem's. Anyway
the version with lookup table is quite close to "bsr" version. So yours also
can get faster with the addition of lookup table. It would be interesting to
see how much Ada can get close to "bsr" version below! (By adding a lookup
table, I mean.)

__inline unsigned FindHighestBit(unsigned n)
{
   __asm
   {
      bsr eax, n
   }
}
.

> OK. I adjusted the code to run in your loop.
>
> Your score is a bit strange to me?! It may be the compiler that makes the
> difference.
> I timed your code in my P4 1.4GHz NT4.0 SP6 (MSVC6) and my result is ~2100
> ms for your code while the best version suggested by Williem finishes in
> ~650 ms (which is slightly better than 1-opcode "bsr" inline assembly
> version). I guess it is because you use a 5-bit lookup table.
Unfortunately
> I couldn't test the Ada version.
>
> And I tried to run the loops twice in a row and they seem linear except
for
> the assembly version which seems to get slightly better.
> Yours: 4200 ms
> Williem's: 1300 ms
> "bsr": 1280 ms
>
>
>
>
> > We're comparing a Xeon with a AMD so its not apples to apples, but
> > still, it suggests that either your timing methodology could use some
> > work, or that the code generated is quite bad.
> >
> >
> > unsigned
> > FindHighestBit(unsigned n)
> > {
> >    unsigned d = 0;
> >    if( n > 0xffff ) {
> >      d += 16;
> >      n >>= 16;
> >    }
> >    if( n > 0xff ) {
> >      d += 8;
> >      n >>= 8;
> >    }
> >    if( n > 0xf ) {
> >      d += 4;
> >      n >>= 4;
> >    }
> >    if( n > 0x3 ) {
> >      d += 2;
> >      n >>= 2;
> >    }
> >    if( n > 0x1 ) {
> >      d += 1;
> >      n >>= 1;
> >    }
> >    if( n > 0x0 ) {
> >      d += 1;
> >    }
> >    return d;
> > }
> >   main(void)
> > {
> >    unsigned i;
> >    unsigned j;
> >    unsigned s= 0;
> >    unsigned val[32];
> >
> >    for( i = 0; i < 32; i+= 2 ) {
> >      val[i] = (1U<<i)-1;
> >      val[i+1] = 1U<<(31-i);
> >    }
> >
> >    for( i = 0; i < 3125000; i++ ) {
> >      for( j = 0; j < 32; j++ ) {
> >        s += FindHighestBit(val[j]);
> >      }
> >    }
> >    return s;
> > }
> > >
> > > Time run: 1.94 seconds
> > > Hardware: 2.0GHz AMD 64 processor with 512 Mb memory
> > > System :
> > >          OS : WIN XP Service Pack 1
> > >          compiler: GNAT v3.15p
> > > Compiler flags: none (-O2 was tried but appeared to remove too much)
> > >
> > > Program: Performs bit search 10,000,000 times
> > >
> > > -- 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;
> > >    Bit_Num : Index_Type := 0;
> > > begin
> > >    Start := Clock;
> > >    Num := 1;
> > >    for X in 1..10_000_000 loop
> > >       for I in reverse Overlay'range loop
> > >          if Overlay(I) then
> > >             Bit_Num := I;
> > >             exit;
> > >          end if;
> > >       end loop;
> > >    end loop;
> > >    Stop := Clock;
> > >    Ada.Text_IO.Put_Line("High bit :" & Index_Type'Image(Bit_Num));
> > >    Ada.Text_IO.Put_Line("Execution time: " &
> > >                          Duration'Image(Stop - Start));
> > > end Highest_Bit_Set;
> > >
> > > Program output:
> > > High bit : 0
> > > Execution time:  1.950221327
> > >
> > > Jim Rogers
> > >
> > >
> > >
>
>

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

[Willem]

jimmaureenrogers@worldnet.att.net wrote:
) -- 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;

Are you sure the compiler doesn't recognise that 'Num' is constant
and precalculate the endresult, by the way ?
I think a test that loops over different values of 'Num' would be better.

Maybe a print of the assembly that the compiler spits out from this
code would be nice to have a look at as well.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[jimmaureenrogers]

CTips wrote:
> Jim Rogers wrote:
> >
> >
> > I have created another version and downloaded the latest cygwin to
> > try to make the system as similar as possible. I have translated
your
> > example into Ada for another increase in similarity.
> >
> > compiled with -gnatwu -gnato -I
> >
> > Using the cygwin time command I got  a total run-time of 2.1s.
> > With -O2 I get 1.1s
> >
> > My speed appears to be very similar to yours.
>
> Good!
>
> Did you run the C code as well by any chance?
>
> BTW: the numbers *should* be the pretty close to identical. The
> algorithms are the same, Ada does not need to kick in any of its
> run-time checks, and the two backends are the same.
>
> About the only room for difference is if the two flags (-O2) kick off

> different sets of optimizations for Ada and C.

One other small difference is that GNAT 3.15p uses a much older
version of the gcc backend. That, along with the differences in
cpus, may easily account for differences.

Jim Rogers

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

REH wrote:

> Not all of us do "regular application programming."  I write 
> mission-critical systems.  In such an environment, it is non-sense NOT to 
> define ranges for data types that have them.  I would rather it "failed 
> loudly" when a variable strayed out of range and raised an exception I can 
> recover from, then continuing to run, causing unknown or undefined behavior.


If you are having for loops with arrays in mind, a simple high level 
safe C++ solution exists. Consider:


#include <algorithm>
#include <vector>

inline int doubleF(const int &arg) { return 2*arg; }

// ...

vector<int>someArray(10, 1);

// ...

transform( someArray.begin(), someArray.end(),
            someArray.begin(), doubleF );


This can't ever be out of bounds.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Jim Rogers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

"Aslan Kral" <aslanski2002@yahoo.com> wrote in
news:39g6jbF62g4qjU1@individual.net: 

> 
> "Aslan Kral" <aslanski2002@yahoo.com>, haber iletisinde �unlar�
> yazd�:39fr2iF5uq3mvU1@individual.net...
>> > IIRC, the C codes that were posted to find the highest bit set
>> > thread were about 1/10th of that number. Just to double check, I
>> > wrote and measured some C code. On my 3GHz Xeon running with cygwin
>> > on WinXP, when compiled with gcc3.3.3 using -mpcu=i686 -O0, I got a
>> > total run-time of 2.3s, for about 69 cycles/iteration, and with -O2
>> > I get 0.94s for about 28 cycles/iteration.
>> >
>>
> 
> Oops! I failed to read the -O2 part. It makes sense now. And your code
> doesn't use any lookup table that is why it is slower than Willem's.
> Anyway the version with lookup table is quite close to "bsr" version.
> So yours also can get faster with the addition of lookup table. It
> would be interesting to see how much Ada can get close to "bsr"
> version below! (By adding a lookup table, I mean.)
> 
> __inline unsigned FindHighestBit(unsigned n)
> {
>    __asm
>    {
>       bsr eax, n
>    }
> }
> .
> 

I sems to have lost the C version of the lookup table.
Could you please repost that or send me the version.

Thanks.

Jim Rogers

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message 
news:1110632256.180589@athnrd02...
> If you are having for loops with arrays in mind, a simple high level safe 
> C++ solution exists. Consider:
>
>
> #include <algorithm>
> #include <vector>
>
> inline int doubleF(const int &arg) { return 2*arg; }
>
> // ...
>
> vector<int>someArray(10, 1);
>
> // ...
>
> transform( someArray.begin(), someArray.end(),
>            someArray.begin(), doubleF );
>
>
> This can't ever be out of bounds.
>
Much more just array accesses.  Variables of particular units that must stay 
within range (i.e., lat/long, BAMS, radians, velocities, altitudes, depths, 
etc.).  I'm not saying this can't be done in C++, because I've done it. 
It's just easier in Ada.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Aslan Kral]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]


"Jim Rogers" <jimmaureenrogers@att.net>, haber iletisinde �unlar�
yazd�:DYBYd.373707$w62.141894@bgtnsc05-news.ops.worldnet.att.net...
> "Aslan Kral" <aslanski2002@yahoo.com> wrote in
> news:39g6jbF62g4qjU1@individual.net:
>
> >
> > "Aslan Kral" <aslanski2002@yahoo.com>, haber iletisinde �unlar�
> > yazd�:39fr2iF5uq3mvU1@individual.net...
> >> > IIRC, the C codes that were posted to find the highest bit set
> >> > thread were about 1/10th of that number. Just to double check, I
> >> > wrote and measured some C code. On my 3GHz Xeon running with cygwin
> >> > on WinXP, when compiled with gcc3.3.3 using -mpcu=i686 -O0, I got a
> >> > total run-time of 2.3s, for about 69 cycles/iteration, and with -O2
> >> > I get 0.94s for about 28 cycles/iteration.
> >> >
> >>
> >
> > Oops! I failed to read the -O2 part. It makes sense now. And your code
> > doesn't use any lookup table that is why it is slower than Willem's.
> > Anyway the version with lookup table is quite close to "bsr" version.
> > So yours also can get faster with the addition of lookup table. It
> > would be interesting to see how much Ada can get close to "bsr"
> > version below! (By adding a lookup table, I mean.)
> >
> > __inline unsigned FindHighestBit(unsigned n)
> > {
> >    __asm
> >    {
> >       bsr eax, n
> >    }
> > }
> > .
> >
>
> I sems to have lost the C version of the lookup table.
> Could you please repost that or send me the version.
>
> Thanks.
>
> Jim Rogers
>
OK.

static unsigned highBitSmall[256] =
{
  0,0,1,1,2,2,2,2,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
  5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,
  6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,
  6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,
  7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
  7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
  7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
  7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7
};

__inline unsigned FindHighestBit( unsigned n )
{
    unsigned bits = 0;
    if (n >> 16) {
    n = n >> 16;
    bits = 16;
    }
    if (n >> 8) {
    n = n >> 8;
    bits += 8;
    }
    return bits + highBitSmall[n];
}

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Georg Bauhaus wrote:

> CTips wrote:
> 
>> Jean-Pierre Rosen wrote:
>>
>>> CTips a �crit :
>>>
>>>>
>>>> Since it appears that several people out here are making some very 
>>>> basic mistakes when they report benchmark numbers, I thought I'd 
>>>> write a small note on how to do benchmarking.
>>>>
>>> [lots of good stuff deleted]
>>>
>>> You are absolutely right, but there is one thing that this benchmark 
>>> *proves*:
>>>
>>> Blindly claiming that C is faster than Ada is not supported by hard 
>>> figures.
>>>
>>
>> Actually, it is.
> 
> 
> Seems not so easy as you claim it to be.

<grin> It seemed easy for me.

> I have done some more tests following your advice.
> Though, I find my computer far too complicated for me to understand
> or predict, even speculating about caches and TLB. Can a
> PC be described in sufficient detail to say anything precise
> or to write predictable assembly language programs for all kinds
> of situations with PC OSs?

Umm good question. I know very little about the specifics about the x86 
architecture implementations, but I do know about how uPs in general are 
designed. I'll try and answer this question in a separate note. I think 
the answer is, yes, it can be described adequately.


> Anyway, here goes.

This is pretty good work.

> The starred columns show seconds with checks turned off
> (in both languages).

> Your program has, at C module level,
> int perm[N];
> so I did the same in Ada, results are in the T and TC columns.
> The TU and TUC columns show seconds when dynamically allocated
> array are used, from an unconstrained array type.
> 
>                      C             |             Ada
> N        R       *T*         TC      *T*      TC      TU      TUC
> 4000     50000   1.01        2.46    1.01     1.67    1.65    2.0
> 8000     25000   1.01 (2.31) 2.45    1.01     1.67    1.65    2.0
> 10000    20000   1.01        2.46    1.01     1.65    1.65    2.0
> 20000    10000   1.02 (2.32) 2.48    1.02+    1.7++   2.5-    2.0
> 25000    8000    1.7++       2.46++  1.78++   2.6+--  2.6+-   2.3++-
> 40000    5000    4.6+        5.48+   4.6++    5.0+-   5.5+-   5.1+-
> 50000    4000    6.1  (6.4+) 6.7     6.1      6.4+-   5.9+-   7.1-
> 100000   2000    7.4         7.25    7.2      7.0     7.0     7.2
> 200000   1000    7.38        7.26    7.22     6.9     6.8     7.1

For some reason your numbers at the higher end are anamolous. The 
checked code should not take less time than the unchecked code. There is 
something else going on.

You're running on a 2-processor system, so you could be ping-ponging 
between processors. Does the version of linux you are running have 
processor affinity? Also, if you're running on an loaded system, this 
would explain things.

I would rerun the numbers on a machine with less load before I concluded 
anything.

> N: number of integers in the arrays
> 
> R: number of runs (calls of do_perm)
> 
> T: time without checks
> 
> TC: time with checks
>   C = checking handcoded conditionals. In () short circuit checks
>   Ada = compiler switches turning all checks on
> 
> TU: time, unconstrained Ada arrays (dynamically allocated)
> TUC: again, with all checks on
> 
> + and - indicate strong deviations in running time in:
> $ while true ; do time ./perm ; done
> (I guess the fluctuations might indicate where the something becomes
> full or loaded.)
> The numbers given are the shortest times except when the results
> were jumpy and showed a faster result just once in a long series.
> 
> There is 1G of memory in the machine, and two PIII at 800 MHz.
> The OS (GNU/Linux 2.6.8) has been operating in single user mode,
> unloaded, compiler is GCC 4.0.0 20050215 in all cases.
> 
> gcc -O2 -ansi -pedantic
> gnatmake -O2 -gnatwa -gnatp
> gnatmake -O2 -gnatwa -gnatVa -gnato
> 
> I have used your C code for the C-no-checks test. For the checks
> test I modified the commented conditional (see below).

Your check could be better, see why below.

> The reason is that it should match the array range checking in Ada
> and other languages, where semantically each array has two bounds,
> for a total of four for perm[] and val[].  In (some) theory.
> So I wrote a dumb test, and a slightly less dumb test.
> 
> The parenthesised times in the table have been measured after short
> circuit operators had replaced the bit operators.
> Obviously, when I want to compare checking of unknown bounds, I
> have to pass bounds to do_perms(). Just comparing the loop counter to
> N isn't the same thing. The parameters are named perm_n and val_n.
> 
>     /**/
>     if ( i < 0 | i >= perm_n ) {
>       abort();
>     }
>     if( perm[i] < 0 | perm[i] >= val_n) {
>       abort();
>     }
>     /**/
> 

> For sure this is not the optimal or necessary check in this
> loop, but for the test case it provides for comparing _unconstrained_
> array types.
> Otherwise 0 as the first index in C had been used a built-in
> constraint.

Instead of using
   if( i < 0 && i > N ) { abort(); }
Try using
   if( (unsigned) i > N ) {abort(); }
Its the same check, only a lot faster. This probably explains any 
difference between checked and unchecked C. [It might be interesting to 
look at the assembler output for Ada and see if thats what they are using].


> (With this particular loop the checking can be made faster by
> reversing the order of comparisons, as for example i < 0 will
> invariably be false.)
> 
> Ada text, the dynamically allocated arrays:
> 
>    type Perm_Array is array(Natural range <>)  of Integer;
> ...
>    setup_perm(perm.all);
>    for rep in 1 .. R  loop
>       do_perm(val.all, perm.all);
>    end loop;
> 
> My conclusion is that for some data the C version is faster,
> and that for some data the Ada version is faster, on this
> machine.

Ada is not faster- the results where Ada is faster are not trustworthy. 
Replace the C checks with the alternate form, and run on an *unloaded* 
machine.

> It takes a lot of time to really find out what
> and why. Still, you get fast code from either language front
> end, so if an Ada compiler will check more things at
> compile time, support more programming language, and you want
> your compiler to do this, it can be a plus.

And if you want performance, use C instead.

> Adding a complete set of runtime checks can be quite expensive,
> some lines in the table show this. (GNAT doesn't add all
> checks by default.)
> Paradoxically, for both C and Ada, checks seem to speed up
> processing (see the last line) when the amount of data
> is growing.

I think that is unlikely. Its much more likely that you're seeing 
effects from something else that is happenning at the same time.

> The unconstrained array version has been faster with some data
> than the constrained array type version...
> 
> Both versions can run more quickly on this machine when
> the arrays can live on the stack. :-)
> 
> Georg
> 
> 
>> In most cases, it is possible to get close to assembly performance out 
>> of C [one major case where it isn't is when you want to use 
>> labels-as-addresses].
> 
> 
> I take it you mean the one best performing assembly language
> program found by a very clever programmer beating all optimizers.
> Possible, but how do you get there systematically?
> Given that you can insert assembly instructions in a number of PLs,
> this alone is not a competitive argument.
> 
>> In fact, it is _NOT_ possible to beat that number using any language.
> 
> 
> For this to be true, someone would have to actually prove
> that a given assembly language program cannot be beaten by
> any other assembly language program taking the same set
> of inputs to outputs, and react in the same ways that the
> given assembly language program does. Possible, o.K., but
> feasably for any reasonably sized program?
> 
>> If there are any run-time checks added by the Ada compiler, then the 
>> performance will not be the assembly level performance.
> 
> 
> How do you explain, in terms of assembly language instructions,
> the speedup in the last line of the table above (T -> TC)?
> (I have double-checked them for both languages.)
> 
>> Consequently, either one must program so that no checks need to be 
>> added OR one must disable all run-time checking.
> 
> 
> 
>> BTW - all the psuedo-benchmarking people have done on this thread so 
>> far has provided meaningless numbers - too small run-times, 
>> performance dominated by cache misses etc.
> 
> 
> And VERY_LARGE_NUMBER meaning not too large for ... :-)
> 
> Georg
> 

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

[CTips]

Georg Bauhaus wrote:

> CTips wrote:
> 
>> Georg Bauhaus wrote:
>>
>>
>>> Done. You might be disappointed by the results. In short:
>>> < 1%, < 3%; and < 8% for a different program, really.
>>
>>
>>
>> I'm not disappointed at all, in fact the numbers are way worse than I 
>> expected, [...]
> 
> 
>> You have to be *very* careful that what you're measuring isn't hidden 
>> behind some other effect.
> 
> 
> I admit that I was measuring relative performance of a program
> written in two programming languages. And I didn't want to write
> a benchmark program; how useful, well-defined, etc. are they.
> 
> Out of curiosity, if a 1.03x slowdown is far worse than expected,
> than what is a not-so-bad slowdown that would make you say o.K.
> to checks?


I'm not certain about the question. What I had expected when I specified 
the problem was about 20-30% slowdown. When I saw your array sizes, I 
expected a 0% slowdown - all the extra checking should have been hidden 
in the shadow of the L2 load miss.

If you're asking how much slowdown is acceptable (i.e. how much would I 
be willing to pay for extra checking), it will vary from application to 
application. On some of the stuff I do, no overhead at all is 
acceptable. On others, well, things need to run fast, but its acceptable 
to trade-off performance for ease-of-modification.

As for automatically or manual checking - I add a lot of checking code 
to my programs [see http://users.bestweb.net/~ctips ].  However, I do 
try to follow a few rules:
- The checking code can be disabled via a compile-time flag
- Enabling/disabling checking code does not change the memory layout of 
objects.
Ada, I believe, violates the second rule. If you disable bounds 
checking, it will replace handles with straight pointers, which can 
result in considerably different memory images.

Another problem with automatic checking is that it can only check for a 
few things. For instance, consider a list ADT:
    struct list {
      struct list * next;
      T value;
    };
    struct list * merge_list(struct list *, struct list *);
    ...
In this case, one of the checks I add is "this list is non-circular". 
This has to be added manually.

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

[Robert A Duff]

Pascal Obry <pascal@obry.org> writes:

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

However, it will be legal to pass a nested procedure in Ada 2005,
and GNAT already supports that.  The rules still prevent dangling
pointers:

   procedure P (Proc : access procedure(...)) is
   begin
      Proc;
   end P;

   procedure P2 is
      P2_Local: Integer := 0;
      procedure P3 is
      begin
         P2_Local := P2_Local + 1;
      end P3;
   begin
      P (P3'Access);
   end P2;

In Pascal's example, P can assign Proc into a global variable, and it
can be called after P2 returns, which is why it is forbidden to pass
P3.  In my example, on the other hand, you can pass P3, but P cannot
assign Proc into a global variable.  Either way, no dangling pointers,
unless you play some low-level tricks.

> > Can templates recurse?
> 
> Yes.

I think he meant "can generic instantiation be recursive", and the
answer is "no, it cannot".  A generic procedure can call itself,
but that's not the same thing.

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

... and 'in' mode parameters can't be modified, and you can't modify
what an access-to-constant points at.

I think it's a bit more difficult to "cast away const" in Ada,
and the results can be bad news.

- Bob

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Jim Rogers]

Here is my Ada version using a lookup table.
My system is an AMD 64 cpu at 2.0 Ghz with 512Mb memory.
I ran the program using the cygwin time function.
The compiler is GNAT 3.15p.

All times are with range-checking suppressed.

when compiled without optimization the time is
1.8 seconds

when compiled with -O2 the time is
1.4 seconds

The Ada code is:

with Interfaces;
use type Interfaces.Unsigned_32;

package Bits_Utils is
   type Array_Index is mod 2**8;
   subtype Bits_Adjust is Integer range 0..7;
   type Adjust_Array is array(Array_Index) of Bits_Adjust;
   High_Bit_Small : constant Adjust_Array := 
      (0,0,1,1,2,2,2,2,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
      5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,
      6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,
      6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,
      7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
      7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
      7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
      7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7);
      
   function Find_Highest_Bits(N : Interfaces.Unsigned_32) return 
Bits_Adjust;
end Bits_Utils;

package body Bits_Utils is
   pragma Suppress(Range_Check);
   function Find_Highest_Bits(N : Interfaces.Unsigned_32) 
                                      return Bits_Adjust is
      Bits : Natural := 0;
      V : Interfaces.Unsigned_32 := N;
   begin
      if Interfaces.Shift_Right(Value => V, Amount => 16) > 0 then
         V := Interfaces.Shift_Right(Value => V, Amount => 16);
         Bits := 16;
      end if;
      if Interfaces.Shift_Right(Value => V, Amount => 8) > 0 then
         V := Interfaces.Shift_Right(Value => V, Amount => 8);
         Bits := Bits + 8;
      end if;
      return Bits + High_Bit_Small(Array_Index(V));
   end Find_Highest_Bits;
   pragma Inline (Find_Highest_Bits);
end Bits_Utils;

with Bits_Utils;
with Interfaces; use Interfaces;
with Ada.Command_Line; 
use Ada.Command_Line;

procedure Highest_Bits3 is
   type Index is mod 32;
   type Val_Array is array(Index) of Unsigned_32;
   Val : Val_Array;
   S : Natural := 0;
   I : Index := 0;  
   U : Unsigned_32 := 1;    
begin
   loop
      Val(I) := Shift_Left(Value => U, Amount => Natural(I)) - 1;
      if I < Index'Last - 2 then
         Val(I + 1) := Shift_Left(U, 32 - Natural(I));
         I := I + 2;
      else
         exit;
      end if;
   end loop;
   for N in 0..3124999 loop
      for J in Index'range loop
         S := S + Bits_Utils.Find_Highest_Bits(Val(J));
      end loop;
   end loop;
   Set_Exit_Status(Exit_Status(S));
end Highest_Bits3;

Jim Rogers

Re: 10 rules for benchmarking

[Martin Eisenberg]

CTips wrote:

> 2. When running the benchmark program,
>    * use an unloaded machine (i.e. as little else as possible
>    running), * do multiple (3-5) runs
>    * report the minimum time

That is great stuff! Most of it is perfectly intuitive to me, but why 
do you advise to report the best run? I would have thought that the 
median timing, maybe without the first run, made sense to use.

-- 
Quidquid latine dictum sit, altum viditur.

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

[Robert A Duff]

Falk Tannh�user <falk.tannhauser@crf.canon.fr> writes:

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

Yes.  I believe that the C++ exception design was based on Ada
exceptions, and the Ada finalization stuff was based on the C++
features.  The differences in these areas are fairly minor.
I guess the biggest one is that a C++ exception is a first-class
object, so you can pass extra information along with a thrown exception
in a straightforward way, whereas in Ada, the mechanism for passing
extra information is an ugly kludge.

Another difference is that Ada doesn't rely so heavily on constructors
-- there is something like a constructor in Ada, but the *usual* way to
create objects is simply to call a function that returns one, as in:

    X: Int_Set := Empty_Set;
    Y: constant Int_Set := Singleton_Set(17);

- Bob

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

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

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

Heh?  Pascal has that.  In fact, practically every programming language
outside the C family has this feature.  It's quite useful -- almost
essential in multi-threaded programs.

- Bob

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

[Martin Krischik]

Peter Koch Larsen wrote:

> I do not believe that to be the problem. There is a standard and there are
> commercial libraries out there to test conformance. The problem rather
> lies in other areas such as:
> 
> - compiler vendors wanting to be backwards compatible.
> - compiler vendors wanting to get a grip on their customers by ofering
> "extensions" to the language.
> - compiler vendors who don't care if their product is standards-compliant.

How very true.

>>> By 1990 or so when compilers conforming reasonably closely with the C
>>> standard became available, it appears likely that essentially all new
>>> development was being done in Ada. Under the circumstances, it would be
>>> rather surprising if the C code was ever rewritten into standard C.
>>
>> On the last project I was working with a 3rd party library which had not
>> a single "const" in its header files - probably to be compatible with old
>> compilers. So a major "savety" feature of C89 was still missing in
>> current code - and affected our current development - since I has to use
>> that library.
> 
> You could use another library out there. Cars are not bad just because one
> manufacturer ships buggy cars out.

It was a very special lib with only a very few alternatives out there.

>> The most compatible C/C++ compiler AFAIK is digital mars
>> (http://www.digitalmars.com) with "only" 4 C99 features missing:
>>
(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#c_unimplemented).
>>
>> But even digital mars aims only at the C++98 and not the current C++
>> 2003. And there are still 4 features missing:
>>
(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#cpp_unimplemented).

> Did you have a look at Comeau C++?

No. Got a link to have a look?

>> Maybe just maybe - if there realy was any standart compiler available -
>> but
>> there isn't - the C/C++ compiler vendors are allways one release behind
>> the
>> actual ISO standart.
> 
> If you look at C++ (i can't comment on C), all major vendors i know of
> have a high level of compliance.

For the '98 standart yes - but how about the '03 standard. As I said - one
release behind.

And they havn't got 100% compliance - as the Ada compiler vendors have. And
they can indedd claim that - Ada has the ACATS test - pass the test you are
100% compliant - fail the thest and (almost) no customer will consider your
offer.

>>> By contrast, comparing modern C++ to the pre-standard C shows _large_
>>> improvements in nearly all areas. This is due in part to the changes in
>>> the language itself, but perhaps even more so to improved understanding
>>> of how to use the language.
>>
>> True - the former slim languages designed by individuals have become fad
>> languages desined by the ISO commitie ;-).

> This is simply not true.

Shure it is true: The C++ ISO standard has ruffly 200 pages more then the
Ada ISO standard. The C standard is a few pages shorter - but C hasn't got
object orientation, concurency, real time and distributed system included. 

> The "ISO commitie" you refer to consists of 
> people using C++ in daily life.

So are the Ada commitie memebers. Still Ada was/is bashed for beeing a
commitie language and C++ isn't.

>> It is true that a programming language need some minimum features set to
>> be
>> usefull. And that feature set is a lot larger then most belive. If a
>> successfull language does not provide that set it will be bolted on
>> later. If anything the current C/C++ ISO standards clearly show that the
>> advocates
>> for slim languages hat been wrong all along.
> 
> I have to disagree again. C/C++ has been most succesfull as a language if
> you measure that by the number of applications written in that language.

Shure C/C++ are successfull I never said any different - I just pointed out
that C/C++ are not slim and lightweight languages any more. They have
become fat over time. Only the fat does not show - because theree so many
implit features which only show when you read the ISO standart itself. 

And since the very successfull C/C++ have become as big as they are I
rightfully claim the the advocates for slim languages hat been wrong all
along.

But prove me wrong and show me any successful slim language - which has not
become fat (either by language or by build in library) withing 10 years of
becomming successfull.

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

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

[Ioannis Vranos]

Martin Krischik wrote:

> For the '98 standart yes - but how about the '03 standard. As I said - one
> release behind.


C++03 is C++98 bug fixed. You can have a look at the list of fixes:

http://www.acceleratedcpp.com/authors/koenig/c++std/revisions.pdf



> And they havn't got 100% compliance - as the Ada compiler vendors have.


Today in the latest compiler releases of the major vendors, compliance 
is at least >98% (*there are* 100% compliant implementations).



> And
> they can indedd claim that - Ada has the ACATS test - pass the test you are
> 100% compliant - fail the thest and (almost) no customer will consider your
> offer.


There are compliance tests for C++ too.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Georg Bauhaus wrote:

> CTips wrote:
> 
>> Like I said, if one knows what one is doing (which he does) then one 
>> can disregard the rules. If one does not know what one is doing (which 
>> you don't) then one should follow the rules.
> 
<snip: summary: performance isn't everything, nor is it required>

I agree.

I was trying to point out that Ada's extra checking can come with 
performance costs. It may not be important in many applications, but 
when performance is at all a requirement, then Ada may be an 
inapprorpiate choice of languages.

BTW: I was looking around - I couldn't find an Ada equivalent to the ISO 
C clock() routine. What is it? I can't believe that the Ada standard 
community would have been *that* oblivious to performance that they 
wouldn't put a performance measuring routine in the core specification.

Oh, and just to illustrate another point about Ada, try running the Ada 
program equivalent to the following program:

#define N 30000
#define N2 60000

void
setup_array(
	int *	x[N2],
	int	p[N+1],
	int	q[N+1]
	)
{
   int i;
   for( i = 0; i < N; i++ ) {
     x[i] = &p[i];
     x[i+N] = &q[i];

   }
}

void
do_array(
  	int * x[N2]
	)
{
   int i;
   int *p;
   for( i = 0; i < N2; i++ ) {
     p = x[i];
     p[1] = i;
    }
}

int
main(void)
{
   int p[N+1];
   int q[N+1];
   int * x[N2];
   int i;

   setup_array(x, p, q);
   for( i = 0; i < 10000; i++ ) {
     do_array(x);
   }
   return 0;
}

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

[CTips]

Simon Wright wrote:

> Pascal Obry <pascal@obry.org> writes:
> 
> 
>>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.
> 
> 
> Google shows me lwlock as a C function in the PostGres support groups;
> I don't know what machine architecture has these instructions? PowerPC?

Yes, and alpha.

> 
> It could be used by any compiler as part of a low-level
> implementation, of course, but it's hardly likely that a C compiler
> could use it off its own bat. Why whould it want to unless you the
> programmer tells it to?
> 
> If you're talking about assembler inserts in C -- for Pete's sake, we
> can insert assembler in Ada as a last resort if it's needed.

Can you do the following in Ada: use an assembler inset for just stwcond 
and lwlock, and use C for everything else, and then get the expected 
assembly code.

> What happens with lwlock about priority inversion?

You don't need it. Thats one of the big advantages about lock free schemes.

> 
>>No protected type implementations will be so light.

Umm ... look at the set of lock-free data-structures out there. Quite 
heavy-weight structures can be implemented, including a queue where a 
thread can be adding elements while other threads are removing elements.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[CTips]

REH wrote:

> "Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message 
> news:1110609321.686344@athnrd02...
> 
> 
>>>Myself thinks though that this whole range specialisation thing is 
>>>non-sense for regular application programming at least.
>>
>>
>>Indeed. :-)
>>
>>
> 
> Not all of us do "regular application programming."  I write 
> mission-critical systems.  In such an environment, it is non-sense NOT to 
> define ranges for data types that have them.  I would rather it "failed 
> loudly" when a variable strayed out of range and raised an exception I can 
> recover from, then continuing to run, causing unknown or undefined behavior.
> 

Thats another problem with Ada's run-time checking. If you're using it 
in an environment where the hardware may "fail" [e.g. alpha particles 
randomizing memory], the checks are quite often in the wrong place.

For example, look at the Ada equivalent of the following code.
    typedef enum {0, 1, 2, 3} four_val;
    four_val x;

    x = (four_val) some_int;
    ....
    assert( x < 4);

The compiler will drop in a check at the cast to ensure that the wrong 
value is not getting stored into x. Then, it will proceed to eliminate 
the check that x < 4, because it knows that 0..3 are the only legal 
values of x. However, if there is a hardware bug, the value of x will 
get changed between the definition point and the use point.

When bringing up hardware, I like to have a little more control over 
where the run-time checks are going to be placed. This is another niche 
situtation in which the compiler's "automatic" checking does the wrong 
thing.

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

[CTips]

Robert A Duff wrote:

> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
> 
>>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.
> 
> 
> Heh?  Pascal has that.  In fact, practically every programming language
> outside the C family has this feature.  It's quite useful -- almost
> essential in multi-threaded programs.
> 
> - Bob

Yeah, and don't ask what it costs you. I'd carefully forgotten about all 
the grungy details about displays and static/dynamic chaining, and you 
had to remind me. I particularily like solutions that reserves a 
register for the top-of-display/top-of-static-chain. Thats right - blow 
away a register for that. And then of course the cost of 
maintaining/walking those structures.

If you need thread-private storage, there are *much* cheaper solutions.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Martin Dowie]

CTips wrote:
> BTW: I was looking around - I couldn't find an Ada equivalent to the ISO 
> C clock() routine. What is it? I can't believe that the Ada standard 
> community would have been *that* oblivious to performance that they 
> wouldn't put a performance measuring routine in the core specification.

See http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00307.TXT?rev=1.13 
for the Ada2005 standard package which also detects execution time overruns.

Cheers

-- Martin

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

CTips wrote:

> REH wrote:
> 
>> "Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
>> news:1110609321.686344@athnrd02...
>> 
>> 
>>>>Myself thinks though that this whole range specialisation thing is
>>>>non-sense for regular application programming at least.
>>>
>>>
>>>Indeed. :-)
>>>
>>>
>> 
>> Not all of us do "regular application programming."  I write
>> mission-critical systems.  In such an environment, it is non-sense NOT to
>> define ranges for data types that have them.  I would rather it "failed
>> loudly" when a variable strayed out of range and raised an exception I
>> can recover from, then continuing to run, causing unknown or undefined
>> behavior.
>> 
> 
> Thats another problem with Ada's run-time checking. If you're using it
> in an environment where the hardware may "fail" [e.g. alpha particles
> randomizing memory], the checks are quite often in the wrong place.
> 
> For example, look at the Ada equivalent of the following code.
>     typedef enum {0, 1, 2, 3} four_val
>     four_val x;
> 
>     x = (four_val) some_int;
>     ....
>     assert( x < 4);
> 
> The compiler will drop in a check at the cast to ensure that the wrong
> value is not getting stored into x. Then, it will proceed to eliminate
> the check that x < 4, because it knows that 0..3 are the only legal
> values of x. However, if there is a hardware bug, the value of x will
> get changed between the definition point and the use point.

Well actualy: since 4 is not a valid value for the enum four_val the Ada
compiler won't compile the code - Ada does not automaticy convert enums
into integer.

The way you would do it in Ada is

pragma Assert (x'Valid);

The 'Valid attribute checks if a variable contains a valid value.

>When bringing up hardware, I like to have a little more control over 
>where the run-time checks are going to be placed. This is another niche 
>situtation in which the compiler's "automatic" checking does the wrong 
>thing.

'Valid is used when a variable may contain an invalid value because of
calling a non Ada function or maybe a hardware problem :-) .

You may also use "pragma Volatile" if you fear that a variable chances its
value. Which is the very same in C89: without "volatile" the optimizer may
remove a access to a variable. No difference between C and Ada once
optimizer kicks in.

But then: most C programmers fear the optimizer while most Ada programmers
welcome the optimizer.

With Regards

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jeff C]

CTips wrote:
> REH wrote:
> 
>> "Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message 
>> news:1110609321.686344@athnrd02...
>>
>>
>>>> Myself thinks though that this whole range specialisation thing is 
>>>> non-sense for regular application programming at least.
>>>
>>>
>>>
>>> Indeed. :-)
>>>
>>>
>>
>> Not all of us do "regular application programming."  I write 
>> mission-critical systems.  In such an environment, it is non-sense NOT 
>> to define ranges for data types that have them.  I would rather it 
>> "failed loudly" when a variable strayed out of range and raised an 
>> exception I can recover from, then continuing to run, causing unknown 
>> or undefined behavior.
>>
> 
> Thats another problem with Ada's run-time checking. If you're using it 
> in an environment where the hardware may "fail" [e.g. alpha particles 
> randomizing memory], the checks are quite often in the wrong place.
> 
> For example, look at the Ada equivalent of the following code.
>    typedef enum {0, 1, 2, 3} four_val;
>    four_val x;
> 
>    x = (four_val) some_int;
>    ....
>    assert( x < 4);
> 
> The compiler will drop in a check at the cast to ensure that the wrong 
> value is not getting stored into x. Then, it will proceed to eliminate 
> the check that x < 4, because it knows that 0..3 are the only legal 
> values of x. However, if there is a hardware bug, the value of x will 
> get changed between the definition point and the use point.
> 
> When bringing up hardware, I like to have a little more control over 
> where the run-time checks are going to be placed. This is another niche 
> situtation in which the compiler's "automatic" checking does the wrong 
> thing.

Of course one could insert manual checks for those cases as well and it 
is certainly possible to disable the automatic checks (in fact, I'd 
argue a bit with some others about the "cheapness" of these checks. It 
certainly varies from compiler to compiler and program to program but in 
a moderate sized set of applications (~150K SLOC) I have measured the 
penalty as high as 10-15%.).  The automatic checks are available. You 
can use them just during development and disable for production or if 
you can live with them, then you can leave them on during 
production..But, arguing that it is bad for the language to provide for 
them because it might not be what you want is like arguing that the C++ 
standard should not include any references to floating point since 
sometimes you have a processor that does not have an FPU and then you'd 
feel more comfortable  rolling your own floating point.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ed Falis]

On Sat, 12 Mar 2005 12:46:11 -0500, CTips <ctips@bestweb.net> wrote:

> For example, look at the Ada equivalent of the following code.
>    typedef enum {0, 1, 2, 3} four_val;
>    four_val x;
>     x = (four_val) some_int;
>    ....
>    assert( x < 4);


    type Four_Val is range 0 .. 3;
    X : Four_Val;
begin
    X := Four_Val (Some_Int);
    ...
    pragma Assert (X < 4, "Something is seriously honked here");
    --  Currently supported by GNAT; part of Ada 2005
    --  Or write your own subprogram in Ada 95 as I did for AUnit
    Do_Something_With (X);

Sounds to me as though you just like to argue, because this one was pretty  
silly.

- Ed

C/C++ ISO releases and compliance

[Martin Krischik]

Ioannis Vranos wrote:

> Martin Krischik wrote:
> 
>> For the '98 standart yes - but how about the '03 standard. As I said -
>> one release behind.

> C++03 is C++98 bug fixed. You can have a look at the list of fixes:
> 
> http://www.acceleratedcpp.com/authors/koenig/c++std/revisions.pdf

Ups, right C++ 2003 is only the 5 year bug fix. But then: that isn't good
news. The C++ 98 is out for 7 years and you still have to look hard to find
a fully compliant compiler. 

>> And they havn't got 100% compliance - as the Ada compiler vendors have.

> Today in the latest compiler releases of the major vendors, compliance
> is at least >98% (*there are* 100% compliant implementations).

I still look for one. Not trolling here - I would realy love to see at least
one fully compiant compiler.

As for major vendors: MS-C++ 7.1 and digital mars do not know about
"export". In my book 98% does not apply when a hole keyword is missing.

Side note: All Ada templates are "export" - so it is possible implement
export.

>> And
>> they can indedd claim that - Ada has the ACATS test - pass the test you
>> are 100% compliant - fail the thest and (almost) no customer will
>> consider your offer.

> There are compliance tests for C++ too.

With ISO number? If so tell me - I love to know. Without ISO: better then
nothing but not as helpfull to get companies like M$ to comply.

With reagards

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Robert A Duff]

CTips <ctips@bestweb.net> writes:

> Thats another problem with Ada's run-time checking. If you're using it
> in an environment where the hardware may "fail" [e.g. alpha particles
> randomizing memory], the checks are quite often in the wrong place.

That's like saying "another problem with my refrigerator is that it
doesn't cook food".  Ada's run-time checking is not intended to deal
with hardware failures of this nature.  Neither are if statements in Ada
or C++.

> For example, look at the Ada equivalent of the following code.
>     typedef enum {0, 1, 2, 3} four_val;
>     four_val x;
> 
>     x = (four_val) some_int;
>     ....
>     assert( x < 4);
> 
> The compiler will drop in a check at the cast to ensure that the wrong
> value is not getting stored into x. Then, it will proceed to eliminate
> the check that x < 4, because it knows that 0..3 are the only legal
> values of x. However, if there is a hardware bug, the value of x will
> get changed between the definition point and the use point.

That could happen whether or not you have automatic run-time checks.
And in the above, there is no guarantee that x<4 in the code following
the assert -- the alpha particle could hit just after the assertion.

Just as in "if (X < 4) { ... X ... }", the second reference to X might
produce 17, if hardware can fail.

> When bringing up hardware, I like to have a little more control over
> where the run-time checks are going to be placed. This is another niche
> situtation in which the compiler's "automatic" checking does the wrong
> thing.

You have no such control in either language under discussion.  Compilers
can and do optimize code based on the assumption that the hardware is
perfect.  If you don't like that, you have to write in assembly
language, or dump out the assembly language and make sure it does what
you want.  Or use redundant hardware, or wrap the thing in lead, or any
number of other techniques that have nothing whatsoever to do with Ada
or C++ or run-time checking!

- Bob

Re: C/C++ ISO releases and compliance

[Ioannis Vranos]

Martin Krischik wrote:

>>Today in the latest compiler releases of the major vendors, compliance
>>is at least >98% (*there are* 100% compliant implementations).
> 
> 
> I still look for one. Not trolling here - I would realy love to see at least
> one fully compiant compiler.


http://www.comeaucomputing.com


> As for major vendors: MS-C++ 7.1 and digital mars do not know about
> "export". In my book 98% does not apply when a hole keyword is missing.
> 
> Side note: All Ada templates are "export" - so it is possible implement
> export.


Comeau supports export.

Regarding MS, upcoming VC++ 2005 (8) is even more compliant (>~99%) than 
7.1.

They say that they do not support export though, because there is no 
user demand (use) of it and it takes much work to implement it.


>>There are compliance tests for C++ too.
> 
> 
> With ISO number? If so tell me - I love to know. Without ISO: better then
> nothing but not as helpfull to get companies like M$ to comply.


Third party test suites as far as I know. MS strives for complete ISO 
C++ conformance (except export).



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Martin Krischik wrote:

> Well actualy: since 4 is not a valid value for the enum four_val the Ada
> compiler won't compile the code - Ada does not automaticy convert enums
> into integer.
> 
> The way you would do it in Ada is
> 
> pragma Assert (x'Valid);
> 
> The 'Valid attribute checks if a variable contains a valid value.


Now that I am thinking of it, isn't it a value range?


int main()
{
     enum four_val {a,b,c,d};

     four_val x;

     x = 4;
}


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

C:\c>


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Martin Dowie wrote:

> CTips wrote:
> 
>> BTW: I was looking around - I couldn't find an Ada equivalent to the 
>> ISO C clock() routine. What is it? I can't believe that the Ada 
>> standard community would have been *that* oblivious to performance 
>> that they wouldn't put a performance measuring routine in the core 
>> specification.
> 
> 
> See http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00307.TXT?rev=1.13 
> for the Ada2005 standard package which also detects execution time 
> overruns.
> 
> Cheers
> 
> -- Martin

So it still isn't in the standard...

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[CTips]

Ed Falis wrote:

> On Sat, 12 Mar 2005 12:46:11 -0500, CTips <ctips@bestweb.net> wrote:
> 
>> For example, look at the Ada equivalent of the following code.
>>    typedef enum {0, 1, 2, 3} four_val;
>>    four_val x;
>>     x = (four_val) some_int;
>>    ....
>>    assert( x < 4);
> 
> 
> 
>    type Four_Val is range 0 .. 3;
>    X : Four_Val;
> begin
>    X := Four_Val (Some_Int);
>    ...
>    pragma Assert (X < 4, "Something is seriously honked here");
>    --  Currently supported by GNAT; part of Ada 2005
>    --  Or write your own subprogram in Ada 95 as I did for AUnit
>    Do_Something_With (X);
> 
> Sounds to me as though you just like to argue, because this one was 
> pretty  silly.
> 
> - Ed
Did you compile it and see if the check was still in the generated code? 
If it is, I'd start wondering about the quality of the compiler... 
(unless there was something which disabled range propagation [or its 
equivalent] for asserts...)

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

[Robert A Duff]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

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

Career reasons?  I believe Stepanov is on record as stating that at
least part of the reason for using C++ is that the STL can be programmed
more efficiently in that language than in Ada.  I *think* he was talking
about Ada 83.  And I think he was mainly referring to the ability to
make pointers into the middle of an array, and to do address arithmetic
on them.  The former is easy in Ada 95, and the latter is possible,
although it requires jumping through some hoops.

- Bob

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

[Ed Falis]

On 12 Mar 2005 15:30:29 -0500, Robert A Duff  
<bobduff@shell01.TheWorld.com> wrote:

> Career reasons?  I believe Stepanov is on record as stating that at
> least part of the reason for using C++ is that the STL can be programmed
> more efficiently in that language than in Ada.  I *think* he was talking
> about Ada 83.  And I think he was mainly referring to the ability to
> make pointers into the middle of an array, and to do address arithmetic
> on them.  The former is easy in Ada 95, and the latter is possible,
> although it requires jumping through some hoops.


That matches my recollection as well.

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

[Robert A Duff]

Martin Krischik <martin@krischik.com> writes:

> And they havn't got 100% compliance - as the Ada compiler vendors have. And
> they can indedd claim that - Ada has the ACATS test - pass the test you are
> 100% compliant - fail the thest and (almost) no customer will consider your
> offer.

Now wait.  Let's be fair.  Sure, the ACATS test suite is a good thing.
But no test suite can ensure 100% compliance with the language
standard.  Ada compilers do have bugs that are not caught by the ACATS!

Having a standard compliance test suite is an advantage of ADa,
but it's not a 100% guarantee of anything.  (In fact, all Ada compiler
vendors I know of have huge regression test suites that go way beyond
ACATS.)

- Bob

P.S. Oops, I typed "ADa" above, instead of "Ada".  I think I'll leave
that typo in, just to taunt the zealots who think spelling the name of
the language correctly is important.  ;-)  Come on folks, do you think
being pedantic about ADA vs. Ada will win converts?  I think it adds to
the (mostly wrong) impression that Ada is all about rules and
regulations for no good reason.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Dowie]

CTips wrote:
> Thats another problem with Ada's run-time checking. If you're using it 
> in an environment where the hardware may "fail" [e.g. alpha particles 
> randomizing memory], the checks are quite often in the wrong place.

That's what CBIT is for.

Cheers

-- Martin

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

[Robert A Duff]

"Jerry Coffin" <jcoffin@taeus.com> writes:

> Adrien Plisson wrote:
> > Jerry Coffin wrote:
> > > Second, if the work had been done exclusively or primarily in
> > > a language the DoD considered its own, I suspect opening it up
> > > to the public would have taken even longer, if it was ever
> > > allowed to happen at all.
> >
> > but still ARPA-net was created by the United States Defense Advanced
> > Research Project Agency, part of... the DoD !
> 
> That was exactly my point: it started out as a DoD-funded project. The
> question is about what happened then -- how willing the DoD was to open
> the project to the public at large. As it was, the project was done
> with DoD funding, but was really done at and by universities. While it
> is openly acknowledged to have fulfilled its original intent extremely
> well, nearly every choice in its design and implementation was about as
> UN-military as possible. Despite this, it took 20+ years before it was
> really open to the general public.
> 
> Had even ONE element in the design or implementation fit even slightly
> more closely with the military mind-set, I doubt it would have been
> opened up to the public yet, or possibly ever.

Sorry, I don't know how to say it politely, but this argument (on both
sides) is patently ridiculous.  For one thing, neither C++ nor Ada 95
existed at the time the Arpanet was created.  For another thing, Ada has
never been "a language the DoD considered its own" -- the design has
always been entirely open.  For goodness sakes, they even chose a
foreigner (Jean Ichbiah, who is French) to do the original 1983 language
design!

- Bob

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

[Larry Kilgallen]

In article <wccu0ng6hie.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
>> 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.
> 
> Heh?  Pascal has that.

Yes, I just said Pascal had that.

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

[Robert A Duff]

"fabio de francesco" <fmdf@tiscali.it> writes:

> B.Stroustrup wrote in his "C++ Programming Language" that He was partly
> inspired by Ada (and by a misterious to me "Clu") in creating C++
> templates and exceptions. Does it mean these languages are closer than
> everyone would expect?

Yes, these languages (C++ and Ada) are quite similar in many ways, and
both borrowed something from each other.  To a programmer familiar with
Common Lisp or ML or many others, the arguments in this endless thread
must seem pretty silly.  Kind of like arguing whether McDonald's or
Burger King is the better restaurant, not knowing about any others.  On
the other hand, *those* languages also have serious flaws, too.

Clu is definitely worth learning.

- Bob

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

[dave]

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.

Turamnvia, use what you like. A good compiler, good library set is only 
as good as the programmer that uses it.

C is fast, small very flexible and somewhat dangerous. The MISRA subset 
of C produce better mission critical code, because the richness of the 
language is restricted/disallowed.

C++ is an object oriented extension to C. It is an improvement on C, but 
IMHO not well suited to small embedded systems. However it depends on 
your tools and your writing skills. (Java would be better than C++ for 
embedded design, but try finding native compilers!)

ADA provides for concise system description right there within the 
language. It works everytime, all the time. It is not prone to code 
ambiguity like C and therefore C++, even though all code ambiguity is 
the programmers fault.

Every mission critical system I developed or assisted on pre 2001 was 
ADA and Occam based. After 2001 some of my employers have switched to 
the use of C (adhering to the MISRA subset/controls.) Conversely, pre 
and post 2001 every GUI, test tool, front-end, test engine and 
instrumentation interface was written in C, C++, Java, Delphi and more 
recently C# (quick and dirty).

> I've many years of experience in C/C++ (and 
> Delphi) but no Ada knowledge.
> 
Delphi grew from Turbo Pascal at Borland. ADA is Pascal with necessary 
enhancements for mission critical (military) applications. btw VHDL grew 
out of ADA.

> May I ask if it is too difficult to move from C/C++ to Ada?
You may ask. Answer: it depends on you. IMHO no, but I learned Pascal 
before C, OOA/OOD before C++ and ADA after 'Z'. Simply put, the 
languages are different, the concepts and methods are different. The 
applications are not.

> What is the best way of learning Ada for a C/C++ programmer?
> 
Get some books you like. You want a hacker's guides to start with, free 
stuff, online manuals, tutorials etc. Make notes and lots of code 
snippets; lots and lots of code snippets.

This will get you up and running. Then the heavy stuff later on: set 
yourself tasks, projects etc. Discover what tools and methods are 
available to perform ADA design on your target system(s).

----------------
Lastly, avoid comparing the languages. Avoid conversations especially 
with lecturers and users of more modern languages (c/c++, c# even 
Delphi). It will just start arguments.

All programming languages have their niches and some are more suited to 
a task than others. Most Aircraft use ADA; Banks use C++; Most 
Instrumentation and embedded engineers use C/Assembler (ASM); Most Game 
developers use ASM and more recently C; Communication systems requiring 
formal definition use CSP & Occam. Schools teach Basic; Colleges teach 
C, C#, vb.net or vb; Universities teach Pascal, C, C++, Occam, ADA and 
more......

An introduction to cat skinning. (The Abridged War and Peace version)

Good luck and God Bless.

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

[Ioannis Vranos]

dave wrote:

> C++ is an object oriented extension to C. It is an improvement on C, but 
> IMHO not well suited to small embedded systems. However it depends on 
> your tools and your writing skills. (Java would be better than C++ for 
> embedded design, but try finding native compilers!)


I can't understand why native Java would be better.


> Lastly, avoid comparing the languages. Avoid conversations especially 
> with lecturers and users of more modern languages (c/c++, c# even 
> Delphi). It will just start arguments.


I agree completely with this.



> Most Game developers use ASM and more recently C;

And more recently (years) C++. :-)


> Communication systems requiring 
> formal definition use CSP & Occam. Schools teach Basic;


Actually I think they teach Pascal and perhaps some C. But it depends on 
  the countries I guess.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Robert A Duff]

CTips <ctips@bestweb.net> writes:

> Umm ... look at the set of lock-free data-structures out there. Quite
> heavy-weight structures can be implemented, including a queue where a
> thread can be adding elements while other threads are removing elements.

Umm ... what does this have to do with the discussion, which was about
C++ vs. Ada, or perhaps C vs. Ada?

Of course you can write lock-free algorithms equally well in all the
languages in question.  Of course all these languages allow machine-code
inserts, and of course you can't know from the language standard what
the compiler does with them.  If you have evidence to the contrary,
let's hear it.

- Bob

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"CTips" <ctips@bestweb.net> wrote in message 
news:1136ao15lb0go9c@corp.supernews.com...
> REH wrote:
> Thats another problem with Ada's run-time checking. If you're using it in 
> an environment where the hardware may "fail" [e.g. alpha particles 
> randomizing memory], the checks are quite often in the wrong place.
>
> For example, look at the Ada equivalent of the following code.
>    typedef enum {0, 1, 2, 3} four_val;
>    four_val x;
>
>    x = (four_val) some_int;
>    ....
>    assert( x < 4);
>
> The compiler will drop in a check at the cast to ensure that the wrong 
> value is not getting stored into x. Then, it will proceed to eliminate the 
> check that x < 4, because it knows that 0..3 are the only legal values of 
> x. However, if there is a hardware bug, the value of x will get changed 
> between the definition point and the use point.
>
> When bringing up hardware, I like to have a little more control over where 
> the run-time checks are going to be placed. This is another niche 
> situtation in which the compiler's "automatic" checking does the wrong 
> thing.

You continue to make illogical arguments in some misguide attempt to prove 
you are somehow better than those who program in Ada.  Next you are going to 
complain because Ada can recover from your hardware catching fire.  You are 
just being ridiculous.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Georg Bauhaus]

Willem wrote:
> Georg wrote:
> ) Anyway, here goes.
> ) The starred columns show seconds with checks turned off
> ) (in both languages).
> )
> ) Your program has, at C module level,
> 
> Would you mind quoting exactly which C program you ran the tests with ?
> And maybe also which Ada program ?

The C program is that of CTips in <1132e5g2cor3oe2@corp.supernews.com>
A constant R is #defined for each row in the table, replacing the
10000 in the for loop. The checks are as described in my post.

The Ada programs for setup_perm and do_perm are the same as in
the package body Perms in
<42307820$0$26539$9b4e6d93@newsread4.arcor-online.net>.

(Actually there are two Ada programs driving the procedures,
one is using constrained arrays allocated at library level,
like he C program.
The other is using dynamically allocated arrays using an
unconstrained array type. So the compiler will add bounds
checking code.)

Georg

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

[Greg Comeau]

In article <4952804.Myubg7stsI@linux1.krischik.com>,
Martin Krischik  <martin@krischik.com> wrote:
>Jerry Coffin wrote:
>> Pascal Obry wrote:
>>> "Jerry Coffin" <jcoffin@taeus.com> writes:
>>> > Your claim of fewer bugs is just the sort of unsupported anti-C
>>> > comment we see all the time.
>>>
>>> Just plain wrong, there is data (a PHD) see
>>> http://www.adaic.com/whyada/ada-vs-c/cada_art.html
>> 
>> Perhaps you should reread this, paying paritcular attention to the
>> dates involved. According to the paper, they started switching from C
>> to Ada around 1986. C wasn't standardized until 1989, and (as you'd
>> expect) it was some time after that before most compilers implemented
>> the standard language.
>
>Did they? Or did they just implemented some 80% of the new features? My
>experience with C/C++ (and I have 10 years + of that) is that at no time
>there was a fully compiant C compiler available. There where allways a lot
>of compiler avaliable who claimed to be <small>almost</small> complinant -
>but never one which realy was.

Many vendors have misspoken their situation.  That aside,
I'm confused about the above.   Are you saying that
from 10 years from 1989 you only came across 80% complaincy
of C compilers?

>Partily because - unlike Ada (http://en.wikipedia.org/wiki/ISO_18009) -
>there is not official testsuite to test a C/C++ compiler and runtime
>library. Such an official testsuite would do C/C++ all sorts of good.

Partly, but on partly :)
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

[Greg Comeau]

In article <4952804.Myubg7stsI@linux1.krischik.com>,
Martin Krischik  <martin@krischik.com> wrote:
>Jerry Coffin wrote:
>> In short, this is not a comparison to the C language as it exists
>> today, or has existed in well over a decade.
>
>What do you mean by "exists today"? C99 is 5 years old and still no compiler
>is available which support all C99 features. "restrict" - missing in MS-C
>(even thrue restrict can be implemented as "no operation") - VA - arrays
>(savety critical feature) - missing in MS-C, buggy in GCC. 

Comeau C (based on EDG) + Dinkumware has provided said for a
few years now.  See http://www.peren.com/pages/cvsa_isocvpl.htm

>The most compatible C/C++ compiler AFAIK is digital mars
>(http://www.digitalmars.com) with "only" 4 C99 features missing: 
>(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#c_unimplemented).
>
>But even digital mars aims only at the C++98 and not the current C++ 2003.
>And there are still 4 features missing: 
>(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#cpp_unimplemented).

I think you've misread that URL.  It does not say that.
It's a reasonable compiler, and has many pros, but it is
not to my knowledge the most compatible(?) C/C++ compiler.

>> If anything, based on my own experience with standard C vs.
>> pre-standard C, I'd say his study shows rather the opposite of what you
>> think it does. Standard C was enough of an improvement over
>> pre-standard C that it would be rather surprising if standard C didn't
>> beat Ada in most areas studied (the primary exception being code
>> reuse).
>
>Maybe just maybe - if there realy was any standart compiler available - but
>there isn't - the C/C++ compiler vendors are allways one release behind the
>actual ISO standart.

Comeau C (to C90 and C99) and Comeau C++ (to C++98 and C++03)
along with Dinkumware gives you it all, tons of additional modes,
multiplatform, etc.   For many years for each language.

>> By contrast, comparing modern C++ to the pre-standard C shows _large_
>> improvements in nearly all areas. This is due in part to the changes in
>> the language itself, but perhaps even more so to improved understanding
>> of how to use the language.
>
>True - the former slim languages designed by individuals have become fad
>languages desined by the ISO commitie ;-).
>
>It is true that a programming language need some minimum features set to be
>usefull. And that feature set is a lot larger then most belive. If a
>successfull language does not provide that set it will be bolted on later.
>If anything the current C/C++ ISO standards clearly show that the advocates
>for slim languages hat been wrong all along.

There's room for each.
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

[dave]

Ioannis Vranos wrote:

> I can't understand why native Java would be better.
A mute point since the source has now been released, but Java 
compilation into native CPU machine code, presents the most efficient 
expression of the OO concept in the embedded area. Bytecode, JIT and JVM 
have their place, but not in space & speed limited chips.

>> Most Game developers use ASM and more recently C;
> 
> And more recently (years) C++. :-)
Can't argue with your correction here, however I find it is the tool, 
graphic and IDE engine vendors that are driving this. The original 
engine sources tended to be C with assembler booster code (Quake, 
HalfLife and derivatives). Microsoft, Nvidia, SGI (where are they now!) 
and GL developer packages are offered as C++ libraries. So you are still 
correct.

>> Schools teach Basic;
> 
> Actually I think they teach Pascal and perhaps some C. But it depends on 
>  the countries I guess.

I can only speak to the UK and USA; and just parts therein also. 
Education is in the hands of the educator. Some of my colleges are 
teaching Java to 11-16 year olds, thus it would not surprise me to learn 
Pascal or even C is being taught to the same age group.

Note however: there are implementations of Basic that surpass both 
Pascal and C. VAX Basic, for instance, was taught in an area of Florida 
I lived in. Students studied it from 11yrs through to University.

Different horses, different courses. Different countries, different 
methods. Different goals....

Nme. God Bless.

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

[Georg Bauhaus]

CTips wrote:

> - Enabling/disabling checking code does not change the memory layout of 
> objects.
> Ada, I believe, violates the second rule. If you disable bounds 
> checking, it will replace handles with straight pointers, which can 
> result in considerably different memory images.
> 

Hmm. Insofar as Ada object properties such as bounds are still available
to a subprogram irrespective of bounds checking ('first, 'length etc.),
this sounds too general but IANALL/compiler writer.
(I've looked at a sample case, and find the same fragments for
updating an array cell, for example.)
Data objects with representation clauses have their memory layout
specified (record layout, 'component_size etc.) so layout shouldn't
be touched by checks on/off in this case. (This is certainly true
when an object has an 'Address attribute which wouldn't make sense 
otherwise.)

If representations of access to data items at object code level
must not be changed, won't this preclude working with different
levels of optimization? Or with alternative compiler (versions)
for that matter?
I'm sure that freezing compiler flexibility is necessary when
detailed knowledge of architecture has sufficiently valuable
implications for the translated program. Still as a general rule
this sounds rather limiting, IIUC.

Georg

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

[Greg Comeau]

In article <1462853.JgxLXPrZ7W@linux1.krischik.com>,
Martin Krischik  <martin@krischik.com> wrote:
>...
>And they havn't got 100% compliance - as the Ada compiler vendors have. And
>they can indedd claim that - Ada has the ACATS test - pass the test you are
>100% compliant - fail the thest and (almost) no customer will consider your
>offer.

Out of curiosity how old is the ACATS test, and how many
compilers currently pass it?
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Jim Rogers]

CTips <ctips@bestweb.net> wrote in news:11369p5jrcc6835@corp.supernews.com:

> 
> Oh, and just to illustrate another point about Ada, try running the Ada 
> program equivalent to the following program:
> 
> #define N 30000
> #define N2 60000
> 
> void
> setup_array(
>      int *     x[N2],
>      int     p[N+1],
>      int     q[N+1]
>      )
> {
>    int i;
>    for( i = 0; i < N; i++ ) {
>      x[i] = &p[i];
>      x[i+N] = &q[i];
> 
>    }
> }

The function setup_array sets up the x array
so that the first N elements each individually
point to the elements of the p array, except for
the last element in the p array. The second N
elements of X point to the elements of the q
array, except for the last element of the q
array.

> 
> void
> do_array(
>        int * x[N2]
>      )
> {
>    int i;
>    int *p;
>    for( i = 0; i < N2; i++ ) {
>      p = x[i];
>      p[1] = i;
>     }
> }

do_array has p point to the ith element in x,
then treats p as an array and assigns its second
element the value i. 

This sort of programming is generally foolishness.
x[i] points to an int. Ints are not the same as
arrays of ints. Treating the address of any int
as the beginning of an array is a formula for buffer
overflow, as is demonstrated in this example.

This kind of programming may be useful to virus
developers, but I cannot see its usefulness to any
other developers.


> 
> int
> main(void)
> {
>    int p[N+1];
>    int q[N+1];
>    int * x[N2];
>    int i;
> 
>    setup_array(x, p, q);
>    for( i = 0; i < 10000; i++ ) {
>      do_array(x);
>    }
>    return 0;
> }
> 

I suspect you want a solution written as you would write
it in C. That is not quite reasonable. Each language has
its own best approach to a given problem. I chose to write
the Ada solution as a solution to what I understand is the
problem you are trying to solve.

procedure Array_Pointers is
   N : constant Positive := 30000;

   type Int_Array is array(Positive range <>) of aliased Integer;
   type Int_Ptr is access all Integer;
   type Element_Ptr is array(Positive range 1..N) of Int_Ptr;
   type Combiner is record
      P : Element_Ptr;
      Q : Element_Ptr;
   end record;
      
   procedure Do_Array(X : Combiner) is
      PA : Element_Ptr;
   begin
      Pa := X.P; -- assign all elements of X.P to Pa
      Pa(2).all := 1; -- Assign 1 to the second value in the array
      Pa := X.Q; -- assign all elements of X.Q to Pa
      Pa(2).all := 1; -- Assign 1 to the second value in the array
   end Do_Array;
   
   P : Int_Array(1..N + 1);
   Q : Int_Array(1..N + 1);
   X : Combiner;
   
begin
   -- set up the combiner to point to the elements
   -- in P and Q
   for I in 1..N loop
      X.P(I) := P(I)'access;
      X.Q(I) := Q(I)'access;
   end loop;
   for I in 1..10_000 loop
      Do_Array(X);
   end loop;
end Array_Pointers;

This program compiles and runs without errors.

Jim Rogers

Re: C/C++ ISO releases and compliance

[Greg Comeau]

In article <4587297.MlX1AOUbAb@linux1.krischik.com>,
Martin Krischik  <martin@krischik.com> wrote:
>Ioannis Vranos wrote:
>> Martin Krischik wrote:
>> 
>>> For the '98 standart yes - but how about the '03 standard. As I said -
>>> one release behind.
>
>> C++03 is C++98 bug fixed. You can have a look at the list of fixes:
>> 
>> http://www.acceleratedcpp.com/authors/koenig/c++std/revisions.pdf
>
>Ups, right C++ 2003 is only the 5 year bug fix. But then: that isn't good
>news. The C++ 98 is out for 7 years and you still have to look hard to find
>a fully compliant compiler. 
>
>>> And they havn't got 100% compliance - as the Ada compiler vendors have.
>
>> Today in the latest compiler releases of the major vendors, compliance
>> is at least >98% (*there are* 100% compliant implementations).
>
>I still look for one. Not trolling here - I would realy love to see at least
>one fully compiant compiler.
>
>As for major vendors: MS-C++ 7.1 and digital mars do not know about
>"export". In my book 98% does not apply when a hole keyword is missing.
>
>Side note: All Ada templates are "export" - so it is possible implement
>export.

export was implemented in C++, a few years ago now, so it's
agree it is possible to implement export.  At least Comeau C++
provides export and is "100%" compliant, whatever it is that
that means.

>>> And
>>> they can indedd claim that - Ada has the ACATS test - pass the test you
>>> are 100% compliant - fail the thest and (almost) no customer will
>>> consider your offer.
>
>> There are compliance tests for C++ too.
>
>With ISO number? If so tell me - I love to know.

Through 3rd party commercial products.

> Without ISO: better then
>nothing but not as helpfull to get companies like M$ to comply.

MS has disclosed the major features that they don't support.
How would it change things?
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

[Larry Elmore]

Robert A Duff wrote:
> Marius Amado Alves <amado.alves@netcabo.pt> writes:
> 
> 
>>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!
> 
> 
> Career reasons?  I believe Stepanov is on record as stating that at
> least part of the reason for using C++ is that the STL can be programmed
> more efficiently in that language than in Ada.  I *think* he was talking
> about Ada 83.  And I think he was mainly referring to the ability to
> make pointers into the middle of an array, and to do address arithmetic
> on them.  The former is easy in Ada 95, and the latter is possible,
> although it requires jumping through some hoops.

Stepanov was definitely talking about Ada 83.

--Larry

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Greg Comeau]

In article <1110655701.196383@athnrd02>,
Ioannis Vranos  <ivr@remove.this.grad.com> wrote:
>Martin Krischik wrote:
>
>> Well actualy: since 4 is not a valid value for the enum four_val the Ada
>> compiler won't compile the code - Ada does not automaticy convert enums
>> into integer.
>> 
>> The way you would do it in Ada is
>> 
>> pragma Assert (x'Valid);
>> 
>> The 'Valid attribute checks if a variable contains a valid value.
>
>
>Now that I am thinking of it, isn't it a value range?
>
>
>int main()
>{
>     enum four_val {a,b,c,d};
>
>     four_val x;
>
>     x = 4;
>}
>
>
>C:\c>g++ temp.cpp -o temp.exe
>temp.cpp: In function `int main()':
>temp.cpp:7: error: invalid conversion from `int' to `main()::four_val'

In C++ but not in C it's an error, but it can also be "invalidly"
cast to the enum.
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Arthur J. O'Dwyer]

On Sun, 13 Mar 2005, Jim Rogers wrote:
>
> CTips <ctips@bestweb.net> wrote in news:11369p5jrcc6835@corp.supernews.com:
>> Oh, and just to illustrate another point about Ada, try running the Ada
>> program equivalent to the following program:

Source code below has been reformatted to save space and look prettier.
I think regardless of CTips' and Jim's points in this thread, the original
code serves as an excellent argument against using [] in function headers;
the extra "documentation" is more than offset by the decline in 
readability, as far as I'm concerned.

>> #define N 30000
>> #define N2 60000
>>
>> void setup_array(int **x, int *p, int *q)
>> {
>>    int i;
>>    for( i = 0; i < N; i++ ) {
>>      x[i] = &p[i];
>>      x[i+N] = &q[i];
>>    }
>> }
>
> The function setup_array sets up the x array
> so that the first N elements each individually
> point to the elements of the p array, except for
> the last element in the p array. The second N
> elements of X point to the elements of the q
> array, except for the last element of the q
> array.

Or: The first N elements of the x array refer to the N two-element slices
of the p array, and the second N elements of the x array refer to the N
two-element slices of the q array.

>> void
>> do_array(
>>        int * x[N2]
>>      )
>> {
>>    int i;
>>    int *p;
>>    for( i = 0; i < N2; i++ ) {
>>      p = x[i];
>>      p[1] = i;
>>     }
>> }
>
> do_array has p point to the ith element in x,
> then treats p as an array and assigns its second
> element the value i.

   "Treats p as an array" is a bit of meaningless C-bashing, in this 
context.  What Jim means is "treats p as a pointer" (since the
[] operator applies only to pointer values in C) --- and p /is/ a
pointer!  There's nothing suspect going on with the types here.

> This sort of programming is generally foolishness.
> x[i] points to an int. Ints are not the same as
> arrays of ints.

   Not in Ada, no.  I believe that was the point CTips was demonstrating
with this code snippet: The same code, written in Ada, would be much
longer, slower, and immensely more cumbersome for the reader.  I don't
know to what purpose one might put the demonstrated code, so I think it's
kind of a silly example.  The proper retort is, "Ah, but Ada wasn't
designed for such nonsensical tasks!  Show me a /useful/ algorithm
where C is more expressive!"

> Treating the address of any int
> as the beginning of an array is a formula for buffer
> overflow, as is demonstrated in this example.

   This example does not appear to contain any buffer oveflow.
If you think it does, please point it out to me.  I may have
missed something.


> I suspect you want a solution written as you would write
> it in C. That is not quite reasonable. Each language has
> its own best approach to a given problem. I chose to write
> the Ada solution as a solution to what I understand is the
> problem you are trying to solve.
>
> procedure Array_Pointers is
>   N : constant Positive := 30000;
>
>   type Int_Array is array(Positive range <>) of aliased Integer;
>   type Int_Ptr is access all Integer;
>   type Element_Ptr is array(Positive range 1..N) of Int_Ptr;
>   type Combiner is record
>      P : Element_Ptr;
>      Q : Element_Ptr;
>   end record;
>
>   procedure Do_Array(X : Combiner) is
>      PA : Element_Ptr;
>   begin
>      Pa := X.P; -- assign all elements of X.P to Pa

   Um... surely there's a better way to do this!  Are you really
copying N references here, or is something going on more subtle
than the comment indicates?

>      Pa(2).all := 1; -- Assign 1 to the second value in the array

   For my own edification: Am I correct in thinking that the ".all"
is superfluous in this expression?

>      Pa := X.Q; -- assign all elements of X.Q to Pa
>      Pa(2).all := 1; -- Assign 1 to the second value in the array
>   end Do_Array;
>
>   P : Int_Array(1..N + 1);
>   Q : Int_Array(1..N + 1);
>   X : Combiner;
>
> begin
>   -- set up the combiner to point to the elements
>   -- in P and Q
>   for I in 1..N loop
>      X.P(I) := P(I)'access;
>      X.Q(I) := Q(I)'access;
>   end loop;
>   for I in 1..10_000 loop
>      Do_Array(X);
>   end loop;
> end Array_Pointers;


-Arthur

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Jim Rogers wrote:

> CTips <ctips@bestweb.net> wrote in news:11369p5jrcc6835@corp.supernews.com:
> 
> 
>>Oh, and just to illustrate another point about Ada, try running the Ada 
>>program equivalent to the following program:
>>
>>#define N 30000
>>#define N2 60000
>>
>>void
>>setup_array(
>>     int *     x[N2],
>>     int     p[N+1],
>>     int     q[N+1]
>>     )
>>{
>>   int i;
>>   for( i = 0; i < N; i++ ) {
>>     x[i] = &p[i];
>>     x[i+N] = &q[i];
>>
>>   }
>>}
> 
> 
> The function setup_array sets up the x array
> so that the first N elements each individually
> point to the elements of the p array, except for
> the last element in the p array. The second N
> elements of X point to the elements of the q
> array, except for the last element of the q
> array.
> 
> 
>>void
>>do_array(
>>       int * x[N2]
>>     )
>>{
>>   int i;
>>   int *p;
>>   for( i = 0; i < N2; i++ ) {
>>     p = x[i];
>>     p[1] = i;
>>    }
>>}
> 
> 
> do_array has p point to the ith element in x,
> then treats p as an array and assigns its second
> element the value i. 
> 
> This sort of programming is generally foolishness.

This is meant to bring a performance issue into sharp focus. Each 
element of this program was picked specifically for that reason. Try 
writing the *equivalent* Ada program and *benchmark* it. See what the 
performance will be.

The following elements are involved:
- I want an array of "handles"; that's why I picked a set of pointers.
- I want an array bounds check. Thats why the pointers are pointers to 
unbounded arrays, and why there is a p[1].
- I want the arrays to have a particular size; that is why I picked N as 
30000.
- I used two arrays p & q to inhibit a possible compiler optimization 
(which is not very likely, but its nice to cover all the bases)

The rest of setup_array and main are really there to make sure that the 
right things happens, and that the function gets called the right number 
of times.

This is not intended to be a real program; it is meant to illustrate how 
much slower Ada can get than C. Try and write it as specified and 
measure the resulting performance.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Georg Bauhaus]

CTips wrote:
> Georg Bauhaus wrote:

> 
>> Anyway, here goes.
> 
> 
> This is pretty good work.

Thank you!


>>                      C             |             Ada
>> N        R       *T*         TC      *T*      TC      TU      TUC
 >> ...
 >> ...
>> 100000   2000    7.4         7.25    7.2      7.0     7.0     7.2
>> 200000   1000    7.38        7.26    7.22     6.9     6.8     7.1
> 
> 
> For some reason your numbers at the higher end are anamolous. The 
> checked code should not take less time than the unchecked code. There is 
> something else going on.

I found this puzzling, too. I'll try some more combinations next week.


> You're running on a 2-processor system, so you could be ping-ponging 
> between processors. Does the version of linux you are running have 
> processor affinity? Also, if you're running on an loaded system, this 
> would explain things.

The system showed a load of 0.0 between tests, runlevel == 1, no jobs.
I'll try again setting the affinity.


> Ada is not faster- the results where Ada is faster are not trustworthy. 
> Replace the C checks with the alternate form, and run on an *unloaded* 
> machine.

Well... To me,
                     T           TC      T        TC      TU      TUC
 >> 50000    4000    6.1  (6.4+) 6.7     6.1      6.4+-   5.9+-   7.1-
 >> 100000   2000    7.4         7.25    7.2      7.0     7.0     7.2
shows that apart from the 7.4/7.25 (C) and 7.2/7.0 (Ada) surprises
in the TC columns (where both programs run faster with checks _on_)
the unconstrained array version (Ada) appears indeed faster
than anything else in this row, interpreting the stable
7.0 (TU) as less than all other stable timings in the 100000/2000
row.

I agree that every number marked +- appears less trustworthy than
the others, even though the reason is not clear. The two 200k
arrays both almost fill the cache (256k PIII Coppermine), so maybe
there is some "fuzzy" loading going on ... Perhaps between the
procesors? I'll see next week.


>> It takes a lot of time to really find out what
>> and why. Still, you get fast code from either language front
>> end, so if an Ada compiler will check more things at
>> compile time, support more programming language, and you want
>> your compiler to do this, it can be a plus.
> 
> 
> And if you want performance, use C instead.

In the current context I prefer to let the timings in both T
columns favour neither language based on performance.
Neither is really performing better than the other when no
runtime checks have been added.
So I get the same performance out of C or Ada, with an additional
yield of either fewer or more compile time checks, respectively.


Georg

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

[Marius Amado Alves]

>> Stepanov moved to C/C++ for career reasons and basically he 
>> (consulting with Stroustrup) created C++ templates because he needed 
>> generics in C++ to do there what he had done in Ada! (myself)
>
> Career reasons?  I believe Stepanov is on record as stating that at
> least part of the reason for using C++ is that the STL can be 
> programmed more efficiently in that language than in Ada. (R. Duff)

I'd like to see that record.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[jimmaureenrogers]

Arthur J. O'Dwyer wrote:
> On Sun, 13 Mar 2005, Jim Rogers wrote:
> > This sort of programming is generally foolishness.
> > x[i] points to an int. Ints are not the same as
> > arrays of ints.
>
>    Not in Ada, no.  I believe that was the point CTips was
demonstrating
> with this code snippet: The same code, written in Ada, would be much
> longer, slower, and immensely more cumbersome for the reader.  I
don't
> know to what purpose one might put the demonstrated code, so I think
it's
> kind of a silly example.  The proper retort is, "Ah, but Ada wasn't
> designed for such nonsensical tasks!  Show me a /useful/ algorithm
> where C is more expressive!"

 On the other hand I have read arguments in comp.lang.c where some
C-bashing person tries to claim that pointers and arrays in C
are indistinguishable. The C faithful clearly stated that there is
a difference. I was trying (however poorly) to restate that position.
A pointer to an int is used to pass either an int by reference,
or the pointer to an array of int. The parameter passed is not
an array, but the address of the start of the array. Unfortunately,
the way many people write C it is not possible from inside a called
function to determine whether the address passed was really to an
array of int, or to a single int. The function is left to make
assumptions about this issue.

>
> > Treating the address of any int
> > as the beginning of an array is a formula for buffer
> > overflow, as is demonstrated in this example.
>
>    This example does not appear to contain any buffer oveflow.
> If you think it does, please point it out to me.  I may have
> missed something.
>

Ok, I understand why he made p and q with N+1 elements.
This allows him to point past the Nth element without
leaving either p or q's allocated space. Nonetheless,
the data element in the highest position of those arrays
has not been initialized. This is not the best practice.

>
> > I suspect you want a solution written as you would write
> > it in C. That is not quite reasonable. Each language has
> > its own best approach to a given problem. I chose to write
> > the Ada solution as a solution to what I understand is the
> > problem you are trying to solve.
> >
> > procedure Array_Pointers is
> >   N : constant Positive := 30000;
> >
> >   type Int_Array is array(Positive range <>) of aliased Integer;
> >   type Int_Ptr is access all Integer;
> >   type Element_Ptr is array(Positive range 1..N) of Int_Ptr;
> >   type Combiner is record
> >      P : Element_Ptr;
> >      Q : Element_Ptr;
> >   end record;
> >
> >   procedure Do_Array(X : Combiner) is
> >      PA : Element_Ptr;
> >   begin
> >      Pa := X.P; -- assign all elements of X.P to Pa
>
>    Um... surely there's a better way to do this!  Are you really
> copying N references here, or is something going on more subtle
> than the comment indicates?

That is exactly what I am doing, which matches nicely with the
actions taken in the C code for the function setup_array:

void
setup_array(
     int * x[N2],
     int   p[N+1],
     int   q[N+1]
     )
{
  int i;
  for(i=0; i< N;i++){
   x[i]-&p[i];
   x[i_N]=&q[i];
  }
}

This appears to also be copying two sets of N pointers.

>
> >      Pa(2).all := 1; -- Assign 1 to the second value in the array
>
>    For my own edification: Am I correct in thinking that the ".all"
> is superfluous in this expression?
>

Not at all. This is equivalent to the C syntax
   *(p[1]) = 1;


Jim Rogers

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[jimmaureenrogers]

CTips wrote:
> Jim Rogers wrote:
>
> > CTips <ctips@bestweb.net> wrote in
news:11369p5jrcc6835@corp.supernews.com:
> >
> >
> >>Oh, and just to illustrate another point about Ada, try running the
Ada
> >>program equivalent to the following program:
> >>
> >>#define N 30000
> >>#define N2 60000
> >>
> >>void
> >>setup_array(
> >>     int *     x[N2],
> >>     int     p[N+1],
> >>     int     q[N+1]
> >>     )
> >>{
> >>   int i;
> >>   for( i = 0; i < N; i++ ) {
> >>     x[i] = &p[i];
> >>     x[i+N] = &q[i];
> >>
> >>   }
> >>}
> >
> >
> > The function setup_array sets up the x array
> > so that the first N elements each individually
> > point to the elements of the p array, except for
> > the last element in the p array. The second N
> > elements of X point to the elements of the q
> > array, except for the last element of the q
> > array.
> >
> >
> >>void
> >>do_array(
> >>       int * x[N2]
> >>     )
> >>{
> >>   int i;
> >>   int *p;
> >>   for( i = 0; i < N2; i++ ) {
> >>     p = x[i];
> >>     p[1] = i;
> >>    }
> >>}
> >
> >
> > do_array has p point to the ith element in x,
> > then treats p as an array and assigns its second
> > element the value i.
> >
> > This sort of programming is generally foolishness.
>
> This is meant to bring a performance issue into sharp focus. Each
> element of this program was picked specifically for that reason. Try
> writing the *equivalent* Ada program and *benchmark* it. See what the

> performance will be.
>
> The following elements are involved:
> - I want an array of "handles"; that's why I picked a set of
pointers.
> - I want an array bounds check. Thats why the pointers are pointers
to
> unbounded arrays, and why there is a p[1].

I do not see any pointers to unbounded arrays.
This is not using C99 dynamic arrays. It simply treats a pointer
to int as a pointer to an unspecified sized array of int. This is
done even though there is no such beast being pointed to at the
time.

Ada would not handle this with bounds checking at run time.
The compiler would not allow this kind of activity.
You will not demonstrate the speed of C over Ada. You have
demonstrated the ability to misuse C constructs and complain
when Ada does not allow the same kinds of misuse.

> - I want the arrays to have a particular size; that is why I picked N
as
> 30000.
> - I used two arrays p & q to inhibit a possible compiler optimization

> (which is not very likely, but its nice to cover all the bases)
>
> The rest of setup_array and main are really there to make sure that
the
> right things happens, and that the function gets called the right
number
> of times.
>
> This is not intended to be a real program; it is meant to illustrate
how
> much slower Ada can get than C. Try and write it as specified and
> measure the resulting performance.


The program will not compile if I write it as specified. It is
an erroneous program.

Jim Rogers

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Greg Comeau wrote:

>>Now that I am thinking of it, isn't it a value range?
>>
>>
>>int main()
>>{
>>    enum four_val {a,b,c,d};
>>
>>    four_val x;
>>
>>    x = 4;
>>}
>>
>>
>>C:\c>g++ temp.cpp -o temp.exe
>>temp.cpp: In function `int main()':
>>temp.cpp:7: error: invalid conversion from `int' to `main()::four_val'
> 
> 
> In C++ but not in C it's an error, but it can also be "invalidly"
> cast to the enum.


Yes, the subject in this thread is C++ and Ada. :-)

Also casting this means that you know what you are doing, and thus not 
excused for mistakes. :-)

Thus you can't do that by accident.




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Ed Falis wrote:

> On Sat, 12 Mar 2005 12:46:11 -0500, CTips <ctips@bestweb.net> wrote:
> 
>> For example, look at the Ada equivalent of the following code.
>>    typedef enum {0, 1, 2, 3} four_val;
>>    four_val x;
>>     x = (four_val) some_int;
>>    ....
>>    assert( x < 4);
> 
> 
>     type Four_Val is range 0 .. 3;
>     X : Four_Val;

pragma Volatile (X); -- ;-)

> begin
>     X := Four_Val (Some_Int);
>     ...
>     pragma Assert (X < 4, "Something is seriously honked here");
>     --  Currently supported by GNAT; part of Ada 2005
>     --  Or write your own subprogram in Ada 95 as I did for AUnit
>     Do_Something_With (X);

Are you sure? After all 4 is not a valid value for Four_Val. I would rather
go for either:

pragma Assert (X <= Four_Val'Last, "Something is seriously honked here");

or:

pragma Assert (X'Valid, "Something is seriously honked here");
 
> Sounds to me as though you just like to argue, because this one was pretty
> silly.

Of course it is silly - mostly because the C example isn't using volatile
which you should if you fear hardware intervention - otherwise X might be
cached inside a register and you never notice the problem anyway.

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

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[fabio de francesco]

CTips wrote:

> Jim Rogers wrote:

> > CTips <ctips@bestweb.net> wrote in
news:11369p5jrcc6835@corp.supernews.com:

> >> [skip]


> >>Oh, and just to illustrate another point about Ada, try running the
Ada
> >>program equivalent to the following program:

> > This sort of programming is generally foolishness.

> [skip]

> This is meant to bring a performance issue into sharp focus. Each
> element of this program was picked specifically for that reason. Try
> writing the *equivalent* Ada program and *benchmark* it. See what the

> performance will be.

> [skip]

> This is not intended to be a real program; it is meant to illustrate
how
> much slower Ada can get than C. Try and write it as specified and
> measure the resulting performance.

Ok, I have compiled and run them both.

I think results will interest you, since you are the one who proposed
such a comparison.

I used GCC-3.4.1 either for compiling your C program and Jim's one. My
computer is a single Xeon 450 Mh,1GB RAM Linux-2.6.10.

gcc array_c.c -o array_c -O2 -march=pentium2
gnatmake array_ada.adb -O2 -march=pentium2 -gnatp

The gcc/gnat "-gnatp" option is just to suppress all checks, that is C
default behaviour (seen it doesn't manage run-time exceptions).

The following are best times that were computed over 6+6 executions of
these two programs.

Ada: user 0m11.052s, sys 0m0.005s.
C:   user 0m13.185s, sys 0m0.008s

So, what does it make you think C program is faster than Ada one?
Please, compile and run both them by yourself in order to see this
evidence.

Furthermore I have to say that, with no optimisations, Ada program was
a lot faster than C one. Figures are so much ridicoulos that I don't
want to show them. I thought that GCC had some kind of problem in
compiling that C program, so I wanted to re-compile it. Results didn't
change and GCC wasn't somehow able to link the program and it showed
the following error every 1 over 6 compilations:

array_c: file not recognized: File truncated
collect2: ld returned 1 exit status

I may expect you don't trust me, so please try yourself.

Ciao,

fabio de francesco

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

[Martin Dowie]

Greg Comeau wrote:
> In article <1462853.JgxLXPrZ7W@linux1.krischik.com>,
> Martin Krischik  <martin@krischik.com> wrote:
> 
>>...
>>And they havn't got 100% compliance - as the Ada compiler vendors have. And
>>they can indedd claim that - Ada has the ACATS test - pass the test you are
>>100% compliant - fail the thest and (almost) no customer will consider your
>>offer.
> 
> 
> Out of curiosity how old is the ACATS test, and how many
> compilers currently pass it?

The latest (I believe) is dated 2002 but will certainly be getting 
updated to test Ada2005. See http://www.ada-auth.org/acats.html

All compiler vendors claim some level of conformance and some publish 
their results. Also, all compiler vendors will have a large number of 
suplimentary tests of there own. These tend to include propriatory code 
from customers, so usually aren't published.

Cheers

-- Martin

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Ioannis Vranos wrote:

> Martin Krischik wrote:
> 
>> Well actualy: since 4 is not a valid value for the enum four_val the Ada
>> compiler won't compile the code - Ada does not automaticy convert enums
>> into integer.
>> 
>> The way you would do it in Ada is
>> 
>> pragma Assert (x'Valid);
>> 
>> The 'Valid attribute checks if a variable contains a valid value.
> 
> 
> Now that I am thinking of it, isn't it a value range?
> 
> 
> int main()
> {
>      enum four_val {a,b,c,d};
> 
>      four_val x;
> 
>      x = 4;
> }
> 
> 
> C:\c>g++ temp.cpp -o temp.exe
> temp.cpp: In function `int main()':
> temp.cpp:7: error: invalid conversion from `int' to `main()::four_val'

True - C++ won't convert int to enum either without a static_cast. You know
what I realy miss in C++: dynamic_cast for discreed number:

long X = f();
short Y = dynamic_cast <short> (X);

with a throw range_error when X is to large for Y.

Yes - I have a template for that. But a template need two parameters
<from_type, to_type>  and won't optimize as well as a build in function.
And with -W3 you need a lot of specialized versions to avoid all sorts of
"conditional ist constant" warnings.

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

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

[Martin Krischik]

Robert A Duff wrote:

> Martin Krischik <martin@krischik.com> writes:
> 
>> And they havn't got 100% compliance - as the Ada compiler vendors have.
>> And they can indedd claim that - Ada has the ACATS test - pass the test
>> you are 100% compliant - fail the thest and (almost) no customer will
>> consider your offer.
> 
> Now wait.  Let's be fair.  Sure, the ACATS test suite is a good thing.
> But no test suite can ensure 100% compliance with the language
> standard.  Ada compilers do have bugs that are not caught by the ACATS!

Shure, you are right. However in the end the 100% stuff is all about
marketing - as you said - no compiler is bug free. And in fact nowadays
most of the "chosing a compiler" stuff is about marketing. Not the best
wins but the one average one with the best marketing does.

And here a CCATS and C++CATS would help a lot. Or could you imagine any Ada
vendor not submitting to running the ACATS?

Note to the C/C++ community: when we speak of ACATS we also speak of the Ada
Conformity Assessment Authority (http://www.ada-auth.org/) which actualy
runs the test. Shure anybody can run the test (i.E. with gcc you use "make
-C gcc check-ada" - you need configured gcc sources and a gcc with Ada
enabled) but that is of no marketing value.

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

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Georg Bauhaus]

CTips wrote:

  [a C program for measureing p[i] in Ada]

Ada program below. It isn't really much longer than the C program
as some seem to have expected.

> This is not intended to be a real program; it is meant to illustrate how 
> much slower Ada can get than C. Try and write it as specified and 
> measure the resulting performance.

Done. Performance: either a 10%--50% slowdown, or exactly the
same speed.

The  "Ada" program below has values for N and N2 so that I am at least
seing some repeatable figures, but I have tried other values as well.
(The L2 processor cache is 256k bytes in size). The C program used
for comparison has the exact same values.

As you suggested, I have not tried to write an Ada program really,
but instead to write the same program using Ada for writing C.
The result is twofold:

1) The execution speed of Ada is either much less, 0.92 vs 1.36, or
2) The execution speed is the same, 0.92 vs 0.92.

For reasons of explanation, (2) is achieved when you remove a
null pointer check that Ada requires for pointer p when doing
pointer arithmentic, that is when computing p[1]. The pointer
arithmetic function "+" from  Interfaces.C.Pointers has been
modified so that it omits the null test. But
DON'T DO THIS when writing Ada programs, you are messing
with Ada's meaning! Ada programs don't do arithmetic on null
pointers!)

    function "+" (Left : Pointer; Right : ptrdiff_t) return Pointer is
    begin
--C     if Left = null then
--C         raise Pointer_Error;
--C      end if;

       return To_Pointer (To_Addr (Left) + To_Addr (Elmt_Size * Right));
    end "+";

With this change the "Ada" program is exactly as fast as the C
program. I hear the opportunist say that you have to modify the
Ada library in order to get fast programs... Oh well, so much
for rationality in language comparisons ...


gcc -O2 -ansi -pedantic (C)
gnatmake -O2 -gnatp -gnatN (Ada)

GCC 4.0.0 20050215, 2xPIII 800MHz 256k, 1G, load low, no jobs.
$ while true ; do ./a.out ; done     # done many times


with Perm_Arrays;

procedure c is
    use Perm_Arrays;

    p, q: Int_Array(0 .. N);
    x: Ptr_Array(0 .. N2);

begin
    setup_array(x, p, q);
    for i in 1 .. 30_000 loop
       do_array(x);
    end loop;
end c;

with Interfaces.C.Pointers;

package Perm_Arrays is
    use Interfaces;

    N: constant := 3000;
    N2: constant := 6000;

    type Int_Array is array (Natural range <>) of aliased Integer;
    type Int_Ptr is access all Integer;

    package Int_Arrays is
      new C.Pointers(Natural, Integer, Int_Array, -1);

    type Ptr_Array is array (Natural range <>) of Int_Arrays.Pointer;

    procedure do_array(x: in Ptr_Array);
    procedure setup_array(x: out Ptr_Array; p, q: in out Int_Array);

end Perm_Arrays;


package body Perm_Arrays is

    use Int_Arrays;

    procedure do_array(x: in Ptr_Array) is
       p: Pointer;
    begin
       for i in x'range loop
          p := x(i);
          increment(p);
          p.all := i;
       end loop;
    end do_array;

    procedure setup_array(x: out Ptr_Array; p, q: in out Int_Array) is
    begin
       for i in p'range loop
          x(i) := p(i)'unchecked_access;
          x(i + N) := q(i)'unchecked_access;
       end loop;
    end setup_array;

end Perm_Arrays;


--  Georg

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Georg Bauhaus]

CTips wrote:

>>> void
>>> do_array(
>>>       int * x[N2]
>>>     )
>>> {

> - I want an array bounds check. Thats why the pointers are pointers to 
> unbounded arrays, and why there is a p[1].

Do you really get bounds checks for an array that
has an integer constant in its declarator?

$ como -A --c99 --optimize

doesn't show any speed difference when I play with the x
parameter in do_array().

Georg

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Georg Bauhaus]

Georg Bauhaus wrote:

> 1) The execution speed of Ada is either much less, 0.92 vs 1.36, or
1a) The execution speed of Ada is either somewhat less, 0.92 vs 1.12
                                                                 ^^^^
Reason: use constrained arrays as well, like in the C program.

diff:
    type Integer_Array is array (Natural range <>) of aliased Integer;
    type Int_Ptr is access constant Integer;

    subtype Int_Array is Integer_Array(0 .. N2);  -- used
etc.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Marin David Condic]

Here is an amazing thing to me: We keep getting sucked up into the "C is 
faster than Ada" troll. We all know Ada is capable of being just as fast 
as C (and occasionally faster, because the additional semantic content 
allows for more optimizations), so we get offended by the claim.

I think it is important to note that in an incredibly large percentage 
of the apps that ever get written, whatever differences might exist 
(hypothetically, Ada being 2x slower than C - or vice versa) it will 
NEVER make any difference. In the incredibly small percentage of apps 
where it actually matters, everybody tends to use highly optimizing 
compilers custom targeted to the machines of interest and the comparison 
is really more on the quality of the compiler back ends and not so much 
on the syntax/semantics of the source langauge. (Many realtime, embedded 
compilers process multiple source languages and get similar runtime 
performance - as one might expect.)

Could we PLEASE put this one to rest? Ada can be just as fast - if not 
occasionally faster - than C or any other language used where speed is 
an issue. It has been demonstrated numerous times. Period. Full stop. 
Let's NOT bring it up again PLEASE. And perhaps before we get another C 
programmer with a bad case of techno-lust for high speed computing 
raising the issue again, we ought to insist they define the application 
domain of interest FIRST before they state "I can't use Ada because its 
slower than C..." If its a workstation/GUI kind of app, it probably 
doesn't matter. If it has a duty cycle in the 1 millisecond range - come 
talk to me. (I regularly use Ada in such apps and y'all probably have 
flown around safely in the sky trusting that Ada is fast enough to meet 
that demand.)

MDC


Georg Bauhaus wrote:
> 
> 
> Done. Performance: either a 10%--50% slowdown, or exactly the
> same speed.
> 

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Greg Comeau]

In article <1110700112.230910@athnrd02>,
Ioannis Vranos  <ivr@remove.this.grad.com> wrote:
>Greg Comeau wrote:
>>>Now that I am thinking of it, isn't it a value range?
>>>int main()
>>>{
>>>    enum four_val {a,b,c,d};
>>>
>>>    four_val x;
>>>
>>>    x = 4;
>>>}
>>>
>>>C:\c>g++ temp.cpp -o temp.exe
>>>temp.cpp: In function `int main()':
>>>temp.cpp:7: error: invalid conversion from `int' to `main()::four_val'
>> 
>> In C++ but not in C it's an error, but it can also be "invalidly"
>> cast to the enum.
>
>Yes, the subject in this thread is C++ and Ada. :-)
>
>Also casting this means that you know what you are doing, and thus not 
>excused for mistakes. :-)
>
>Thus you can't do that by accident.

*You* can not, but somebody else can :) :)
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

[Greg Comeau]

In article <d110iv$kqb$1@sparta.btinternet.com>,
Martin Dowie  <martin.dowie@btopenworld.com> wrote:
>Greg Comeau wrote:
>> In article <1462853.JgxLXPrZ7W@linux1.krischik.com>,
>> Martin Krischik  <martin@krischik.com> wrote:
>>>And they havn't got 100% compliance - as the Ada compiler vendors
>>>have. And they can indedd claim that - Ada has the ACATS test -
>>>pass the test you are 100% compliant - fail the thest and (almost)
>>>no customer will consider your offer.
>> 
>> Out of curiosity how old is the ACATS test, and how many
>> compilers currently pass it?
>
>The latest (I believe) is dated 2002 but will certainly be getting 
>updated to test Ada2005. See http://www.ada-auth.org/acats.html

Ok.

>All compiler vendors claim some level of conformance

In what ways?   This sounds like a different statement
than I thought others were saying/implying.

> and some publish their results.

Again, seems a different statement.

>Also, all compiler vendors will have a large number of 
>suplimentary tests of there own. These tend to include
>propriatory code from customers, so usually aren't published.

I'm sure.

I'm also sure this is all workable, and to work well.
As I'm sure it's not the only way to do it (not saying
you said it was, just adding to the table).
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

[Greg Comeau]

In article <3254889.VeKxRnD1pd@linux1.krischik.com>,
Martin Krischik  <martin@krischik.com> wrote:
>Robert A Duff wrote:
>> Martin Krischik <martin@krischik.com> writes:
>>> And they havn't got 100% compliance - as the Ada compiler vendors have.
>>> And they can indedd claim that - Ada has the ACATS test - pass the test
>>> you are 100% compliant - fail the thest and (almost) no customer will
>>> consider your offer.
>> 
>> Now wait.  Let's be fair.  Sure, the ACATS test suite is a good thing.
>> But no test suite can ensure 100% compliance with the language
>> standard.  Ada compilers do have bugs that are not caught by the ACATS!
>
>Shure, you are right. However in the end the 100% stuff is all about
>marketing - as you said - no compiler is bug free. And in fact nowadays
>most of the "chosing a compiler" stuff is about marketing. Not the best
>wins but the one average one with the best marketing does.

And don't forget comments such as that found in
http://www.ada-auth.org/acats.html: "Formal test disputes should
submitted to the agent ..." meaning bugs and other things can
pop up in other areas too.

>And here a CCATS and C++CATS would help a lot. Or could you imagine
>any Ada vendor not submitting to running the ACATS?

Probably can't imagine it, but in the end, the playing field
seem level.

>Note to the C/C++ community: when we speak of ACATS we also speak of the Ada
>Conformity Assessment Authority (http://www.ada-auth.org/) which actualy
>runs the test. Shure anybody can run the test (i.E. with gcc you use "make
>-C gcc check-ada" - you need configured gcc sources and a gcc with Ada
>enabled) but that is of no marketing value.

Probably.  FWIW, C++ has always succeeded against horrible
marketing.  It's unclear whether that is a plus or not,
or whether some other way is.
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Jim Rogers]

CTips <ctips@bestweb.net> wrote in
news:1137falp86qhk89@corp.supernews.com: 

> This is meant to bring a performance issue into sharp focus. Each 
> element of this program was picked specifically for that reason. Try 
> writing the *equivalent* Ada program and *benchmark* it. See what the 
> performance will be.
[snip]
> This is not intended to be a real program; it is meant to illustrate
> how much slower Ada can get than C. Try and write it as specified and 
> measure the resulting performance.
>

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Martin Krischik wrote:

>>C:\c>g++ temp.cpp -o temp.exe
>>temp.cpp: In function `int main()':
>>temp.cpp:7: error: invalid conversion from `int' to `main()::four_val'
> 
> 
> True - C++ won't convert int to enum either without a static_cast. You know
> what I realy miss in C++: dynamic_cast for discreed number:
> 
> long X = f();
> short Y = dynamic_cast <short> (X);
> 
> with a throw range_error when X is to large for Y.
> 
> Yes - I have a template for that. But a template need two parameters
> <from_type, to_type>  and won't optimize as well as a build in function.
> And with -W3 you need a lot of specialized versions to avoid all sorts of
> "conditional ist constant" warnings.


I am not convinced yet this integer range topic is that a big issue. One 
can easily write his own test routine (function, template), if the 
default provided assert() doesn't do the job.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

In article <1110728735.107616@athnrd02>, Ioannis Vranos <ivr@remove.this.grad.com> writes:

> I am not convinced yet this integer range topic is that a big issue. One 
> can easily write his own test routine (function, template), if the 
> default provided assert() doesn't do the job.

Whether someone can is not at issue.

What matters is whether they _will_.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an

[Larry Kilgallen]

In article <1137falp86qhk89@corp.supernews.com>, CTips <ctips@bestweb.net> writes:

> - I want an array of "handles"; that's why I picked a set of pointers.

> This is not intended to be a real program; it is meant to illustrate how 
> much slower Ada can get than C. Try and write it as specified and 
> measure the resulting performance.

Will you then commit to write a program in C whose specifications
are tilted toward Ada ?

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Ioannis Vranos wrote:

> Martin Krischik wrote:
> 
>>>C:\c>g++ temp.cpp -o temp.exe
>>>temp.cpp: In function `int main()':
>>>temp.cpp:7: error: invalid conversion from `int' to `main()::four_val'
>> 
>> 
>> True - C++ won't convert int to enum either without a static_cast. You
>> know what I realy miss in C++: dynamic_cast for discreed number:
>> 
>> long X = f();
>> short Y = dynamic_cast <short> (X);
>> 
>> with a throw range_error when X is to large for Y.
>> 
>> Yes - I have a template for that. But a template need two parameters
>> <from_type, to_type>  and won't optimize as well as a build in function.
>> And with -W3 you need a lot of specialized versions to avoid all sorts of
>> "conditional ist constant" warnings.

> I am not convinced yet this integer range topic is that a big issue. 

The JPEC viruses work in integer range overruns - and that is an issue since
a virus inside an JPEC picture is nasty. Every Web-Page has dozends of
JPEC's - no web browser would consider a JPEC a security risc.

> One 
> can easily write his own test routine (function, template), if the
> default provided assert() doesn't do the job.

But assert() only work if the programmer won't forget to insert one. And the
programmers for libjpec for Linux as well as the Microsoft employees which
did a similar lib for Windows forgot.

Not one pogrammer forgot: both *teams* forgot. Not matter if OpenSource team
or comertial team - both forgot to check the integer range inside a JPEC
picture.

For this I go for the template version - and I do indeed have a template
called Ada::Range for C++. And this template can check any range (i.E.
typedef Ada::Range <short, 1, 31> Day_Of_Month;) and not only short, long
overruns. Very helpfull indeed.

And yes, I have a template called numeric_cast <class From, class To> as
well - just build in would be better.

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

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

[Martin Krischik]

Greg Comeau wrote:

> In article <d110iv$kqb$1@sparta.btinternet.com>,
> Martin Dowie  <martin.dowie@btopenworld.com> wrote:
>>Greg Comeau wrote:
>>> In article <1462853.JgxLXPrZ7W@linux1.krischik.com>,
>>> Martin Krischik  <martin@krischik.com> wrote:

>>>>And they havn't got 100% compliance - as the Ada compiler vendors
>>>>have. And they can indedd claim that - Ada has the ACATS test -
>>>>pass the test you are 100% compliant - fail the thest and (almost)
>>>>no customer will consider your offer.
>>> 
>>> Out of curiosity how old is the ACATS test, and how many
>>> compilers currently pass it?
>>
>>The latest (I believe) is dated 2002 but will certainly be getting
>>updated to test Ada2005. See http://www.ada-auth.org/acats.html
> 
> Ok.
> 
>>All compiler vendors claim some level of conformance
> 
> In what ways?   This sounds like a different statement
> than I thought others were saying/implying.

The Ada standart consists of the core language and optional features like
real-time system and distributed systems.

>> and some publish their results.
 
> Again, seems a different statement.

You might want to read the first chapter of http://www.ada-auth.org. Usualy
the test is done by third part laboratories and then the vendor publish
"pass" for there major releases - but they might not publish for
intermediate releases :-( .

BTW: In the past it was Ada(tm) and only compilers with pass the test where
allowed to use the trademark Ada. For better or worse that is gone now -
and with it the need for a vendor to publish the result.

Also: The test is OpenSource and it is even part the gcc source tree - so if
you have the gcc sources handy you can just run the test yourself.

>>Also, all compiler vendors will have a large number of
>>suplimentary tests of there own. These tend to include
>>propriatory code from customers, so usually aren't published.
> 
> I'm sure.
> 
> I'm also sure this is all workable, and to work well.
> As I'm sure it's not the only way to do it (not saying
> you said it was, just adding to the table).

The important point that it puts more pressure on the vendors as most
customers won't consider a compiler which won't pass the test.

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

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

[Martin Dowie]

>>>All compiler vendors claim some level of conformance
>>
>>In what ways?   This sounds like a different statement
>>than I thought others were saying/implying.
> 
> 
> The Ada standart consists of the core language and optional features like
> real-time system and distributed systems.
> 
> 
>>>and some publish their results.
> 
>  
> 
>>Again, seems a different statement.

I only meant "publish" as in 'here's our results on our website'. I'm 
sure all vendors would make their results available if you asked their 
sales/marketing/support.

Cheers

-- Martin

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

[Jerry Coffin]

Martin Krischik wrote:

[ ... ]

> Did they? Or did they just implemented some 80% of the new features?
> My experience with C/C++ (and I have 10 years + of that) is that at
> no time there was a fully compiant C compiler available. There where
> allways a lot of compiler avaliable who claimed to be
> <small>almost</small> complinant - but never one which realy was.
>
> Partily because - unlike Ada (http://en.wikipedia.org/wiki/ISO_18009)
> - there is not official testsuite to test a C/C++ compiler and
> runtime library. Such an official testsuite would do C/C++ all sorts
> of good.

I'm quite impressed with the statements above -- lots of Usenet posts
contain errors, but most of them are pretty obvious. You've managed to
fit more plausibile-sounding errors into fewer sentences than nearly
any other post I've ever seen.

Let's address the Ada side first. Official Ada validation was done
under the auspices of NIST, who delegated this task to the Ada Joint
Program Office. The AJPO ceased to exist years ago, and the job was
never turned over to anybody else when that happened. Meanwhile, NIST
has discontinued _all_ of its compiler validation programs, not just
the Ada program. Currently, both the ISO standard at a number of FIPS
pubs _require_ Ada compilers to be officially validated, but at least
in the US, there is absolutely NO agency to do that.

The situation on the C side isn't nearly as different as you seem to
think. After the C standard was published, NIST and BSI (to name only
two that I know of with certainty) started doing validation of C
compilers. BSI certified at least one C implementation in 1990, the
same year the ISO C standard was approved. While that first one was for
code-checking, not production of executables, other implementations
(e.g. at least one version from Borland) were certified as well.

As mentioned above, NIST no longer validates/certifies compilers, so at
least in the US, there is no such thing as an officially validated
compiler for C, Ada, or any other language.

> What do you mean by "exists today"? C99 is 5 years old and still no\
> compiler is available which support all C99 features. "restrict" -
> missing in MS-C (even thrue restrict can be implemented as "no
> operation") - VA - arrays (savety critical feature) - missing in
> MS-C, buggy in GCC.

I take it you've never used or even tested the Comeau compiler?

> Maybe just maybe - if there realy was any standart compiler available
> - but there isn't - the C/C++ compiler vendors are allways one
> release behind the actual ISO standart.

I see Greg has entered the thread, so he can speak for himself, but
unless memory serves me particularly poorly today, he had C++ 2003
implemented _before_ it was officially approved.

In fairness, I should add that I found a _few_ defects in the Borland
compiler that was certified -- but back when I worked in Ada, I found
defects in every certified Ada compiler I used as well. In both cases
the defects were small and easily avoided, but the defects in the C
compilers were smaller and more easily avoided.

[ ... ]

> It is true that a programming language need some minimum features set
> to be usefull. And that feature set is a lot larger then most belive.
> If a successfull language does not provide that set it will be bolted
> on later. If anything the current C/C++ ISO standards clearly show'
> that the advocates for slim languages hat been wrong all along.

More nonsense, I'm afraid. First of all, the argument is defective from
the beginning: changes in C and/or C++ absolutely cannot prove anything
about languages in general. Second, some extremely slim languages have
clearly been useful at times, easily disproving your conclusion on
minimum feature sets as well.

None of this proves, or even provides evidence, directly related to
what is claimed by most advocates of smaller languages. Most have said,
for example, that all else being equal, a smaller feature set is easier
to understand completely. Now you may be convinced that a larger
feature set outweighs this fact, and you might even be right -- but
that doesn't make them wrong.

IMO, arguments of the benefits of "small" ("slim", etc.) vs. larger
languages mostly miss the point though.  IMO, there's a much more
fundamental and useful distinction to be considered. That is the
distinction between those where the language itself is the major
player, and those were the language is mostly a way of producing and/or
using libraries.

Ada certainly provides facilities useful for writing libraries, but at
least to me seems to fall into the former group -- it works well for
writing code directly, but attempting to write good libraries in it
tends to be frustrating.

C++, while certainly providing some features useful for direct coding,
is strongly oriented toward the language providing facilities for
building libraries, and much (in many cases, MOST) of what the end-user
does is uses the libraries.

Looking at things from this perspective, Ada may be the last of its
line. 30 years ago, Lisp was nearly the only library-oriented language,
with a miniscule market share.

Now, the library oriented languages dominate. Fortran and Cobol may
never die, but they're certainly not the market leaders they once were.
PL/I is dead, and Ada is hardly dominant. C++ has already been
mentioned. Java is a fairly small language with a huge library. The
next obvious step is .NET, which de-emphasizes languages to the point
that .NET itself IS simply a huge library, with facilities to make it
easy to use that library from any (or all) of a large and growing
collection of languages.

Of course, if you want to discuss slim languages, there's always
Smalltalk -- the language itself is absolutely puny, providing little
more than the ability to send messsages to objects, and receive back
results. Everything else is in the standard library, even such basics
as creating an object. This means the language needs a fairly large,
pre-existing standard library to be able to do anything at all.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Ioannis Vranos]

Jerry Coffin wrote:

>  The next obvious step is .NET, which de-emphasizes languages to the point
> that .NET itself IS simply a huge library, with facilities to make it
> easy to use that library from any (or all) of a large and growing
> collection of languages.



More precisely, it is a CLI compliant VM environment which provides a 
fairly large, high-level, Windows-oriented API which is common for all 
languages.


However C++/CLI design ideals, are not only C++ to be used for 
application programming as a first class citizen CLI (.NET) citizen, but 
*also* for .NET library writing (managed dlls).


With C++/CLI and VC++ 2005, C++ becomes the systems programming language 
of CLI (and .NET).


You may take a look at these:

http://msdn.microsoft.com/msdnmag/issues/05/01/COptimizations/default.aspx

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

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

http://www.accu.org/conference/presentations/Sutter_-_Is_C++_Relevant_on_Modern_Environments_%28keynote%29.pdf


And a page of mine:

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



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

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



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Georg Bauhaus]

Marin David Condic wrote:
> Here is an amazing thing to me: We keep getting sucked up into the "C is 
> faster than Ada" troll. We all know Ada is capable of being just as fast 
> as C (and occasionally faster, because the additional semantic content 
> allows for more optimizations), so we get offended by the claim.

We might know that Ada is capable of being just as fast as C,
but others might never know this, unless Ada is given the rank it
deserves now for technical reasons based on evaluation. And evaluation
invariably includes speed, like it or not. The reputation of a
programming language has an influence on its use. The reputation
of a programming language is a social, human fact, not a technical
fact. (A big part of marketing is about establishing a reputation
for a product, and little else. The trick is to make this work.)
So it is important to see how speed comparisions add to the
reputation of languages.

Another social, human fact is that 20 years old arguments are still
influential when it comes to comparing current languages.
Ignoring technical progress helps arguing a lot. One of the
old "arguments" is that Ada compilers are big, expensive, slow,
complicated, and buggy.

So a social, human fact is that many people care for
speed ranking. Rankings are popular. This is important because
it makes the winners popular. It adds to the winners' reputation.
It also adds to the reputation of the loosers.

As long as test results show Ada in an inadequate position,
in particular wrt execution speed, the ranking will add to the
reputation of Ada, properties that have once again been stated in
this and related threads (about C++ as well).
The mentioned matrix test has a scientific appearance. Whether the
results are real or bogus, intentionally or not, doesn't matter much.
But visibility of a high rank does matter. Just submit yourself to
the fantasy that some reputable list of test results shows an Ada
program at number one. _This_ will be a killer application.

You might frown upon this kind of evaluation, but consider:

Situation 1: An Apple employee (program development) at a developer
conference tells his audience, in the style of an serious hint,
"You can always sell speed, so try some fpt optimizations, and be
careful".

Situation 2: Remember the card games where each card is essentially
a small technical data sheet of a car, with a small image?
Player A beats player B if A's maximum rounds per minute
exceeds B's.

 From a normal (formal) life-course point of view,
many of us are speed fans, and stay speed fans. So speed is one
obvious criterion when comparing things, and for sure it is
considered important. In computing, there is no "too fast",
in general...


> I think it is important to note that in an incredibly large percentage 
> of the apps that ever get written, whatever differences might exist 
> (hypothetically, Ada being 2x slower than C - or vice versa) it will 
> NEVER make any difference.

Speed will make a difference in the perception of a quite numerous
population buying CPUs, DVD recorders, high speed graphics cards,
and of course, programs. Games, fast and slow, digitally animated
movies, wave file manipulation programs, search engines. Also, number
plate recognition programs ...


Georg

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

[Ed Falis]

On 13 Mar 2005 10:41:16 -0800, Jerry Coffin <jcoffin@taeus.com> wrote:

> Ada certainly provides facilities useful for writing libraries, but at
> least to me seems to fall into the former group -- it works well for
> writing code directly, but attempting to write good libraries in it
> tends to be frustrating.


Interesting way of thinking about things.  But for writing libraries, I  
tend to prefer Ada and Eiffel (in that order).  I don't really see what  
leads to the frustration you talk about above - wouldn't mind hearing your  
opinions about that.
Admittedly, creating a library written in either of these two languages  
for use by other languages requires some special steps in packaging, but  
they can be easily automated.  Java, of course, requires anything written  
in other languages to be specially packaged for it to be a client (perhaps  
excepting components accessible via RMI or another component model).  And  
most component models require special packaging anyway.

- Ed

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

[Greg Comeau]

In article <19167262.fkuVsrGd7i@linux1.krischik.com>,
Martin Krischik  <martin@krischik.com> wrote:
>Greg Comeau wrote:
>> In article <d110iv$kqb$1@sparta.btinternet.com>,
>> Martin Dowie  <martin.dowie@btopenworld.com> wrote:
>>>Greg Comeau wrote:
>>>> In article <1462853.JgxLXPrZ7W@linux1.krischik.com>,
>>>> Martin Krischik  <martin@krischik.com> wrote:
>
>>>>>And they havn't got 100% compliance - as the Ada compiler vendors
>>>>>have. And they can indedd claim that - Ada has the ACATS test -
>>>>>pass the test you are 100% compliant - fail the thest and (almost)
>>>>>no customer will consider your offer.
>>>> 
>>>> Out of curiosity how old is the ACATS test, and how many
>>>> compilers currently pass it?

Still looking for this number if anybody has it handy.


>>>The latest (I believe) is dated 2002 but will certainly be getting
>>>updated to test Ada2005. See http://www.ada-auth.org/acats.html
>> 
>> Ok.
>> 
>>>All compiler vendors claim some level of conformance
>> 
>> In what ways?   This sounds like a different statement
>> than I thought others were saying/implying.
>
>The Ada standart consists of the core language and optional features like
>real-time system and distributed systems.
>
>>> and some publish their results.
> 
>> Again, seems a different statement.
>
>You might want to read the first chapter of http://www.ada-auth.org. Usualy
>the test is done by third part laboratories and then the vendor publish
>"pass" for there major releases - but they might not publish for
>intermediate releases :-( .
>
>BTW: In the past it was Ada(tm) and only compilers with pass the test where
>allowed to use the trademark Ada. For better or worse that is gone now -
>and with it the need for a vendor to publish the result.

These points certainly "lessen the gap" then (if there was one)
and make it much closer to the C++ situation then.

>Also: The test is OpenSource and it is even part the gcc source tree - so if
>you have the gcc sources handy you can just run the test yourself.
>
>>>Also, all compiler vendors will have a large number of
>>>suplimentary tests of there own. These tend to include
>>>propriatory code from customers, so usually aren't published.
>> 
>> I'm sure.
>> 
>> I'm also sure this is all workable, and to work well.
>> As I'm sure it's not the only way to do it (not saying
>> you said it was, just adding to the table).
>
>The important point that it puts more pressure on the vendors as most
>customers won't consider a compiler which won't pass the test.

I not convinced it puts "more pressure."  I'm sure it puts some
pressure but "different pressure".

In the C++ world, customers do consider compilers which won't pass.
And it's no secret that this is the case, even w/o all the specifics.
(And I don't think this disses standardization efforts.)

As just one counter-example, and I've leaving out many many details,
but MS was not keeping up, and customer pressure came even w/o
"official tests", and they reacted, to their credit.  So the
official tests need not be a requirement and one can get similar
end results through alternative means.  No one way is perfect.
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <wccu0ng6hie.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> > 
> >> 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.
> > 
> > Heh?  Pascal has that.
> 
> Yes, I just said Pascal had that.

Oh, sorry, I must have thought you said "...in addition to what Pascal
has..." or something.  My bad.

Anyway, nested functions are really nested in any useful sense if you
can't do uplevel addressing, right?

- Bob

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

[Robert A Duff]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> >> Stepanov moved to C/C++ for career reasons and basically he
> >> (consulting with Stroustrup) created C++ templates because he needed
> >> generics in C++ to do there what he had done in Ada! (myself)
> >
> > Career reasons?  I believe Stepanov is on record as stating that at
> > least part of the reason for using C++ is that the STL can be
> > programmed more efficiently in that language than in Ada. (R. Duff)
> 
> I'd like to see that record.

Well, I have a book called "STL Tutorial and Reference Guide",
by David R. Musser and Atul Saini, which says on page xviii,
after mentioning Stepanov's work in Ada, "Another reason for turning to
C++, which Alex recognized early on, was that the C/C++ model of
computation, which allows very flexible access to storage (via pointers)
is crucial to achieving generality without losing efficiency."

It's not a direct quote from Stepanov, but I have some vague
recollection of Stepanov saying the same thing.  Sorry, I have
no cite.

As I said, such "flexible access" is also possible in Ada,
although it's somewhat more painful than in C++.

- Bob

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

[dave]

Ioannis Vranos wrote:
> Jerry Coffin wrote:
> 
>>  The next obvious step is .NET, which de-emphasizes languages to the 
>> point
>> that .NET itself IS simply a huge library, with facilities to make it
>> easy to use that library from any (or all) of a large and growing
>> collection of languages.
> 
> 
> 
> 
> More precisely, it is a CLI compliant VM environment which provides a 
> fairly large, high-level, Windows-oriented API which is common for all 
> languages.
> 
> 
> However C++/CLI design ideals, are not only C++ to be used for 
> application programming as a first class citizen CLI (.NET) citizen, but 
> *also* for .NET library writing (managed dlls).
> 
> 
> With C++/CLI and VC++ 2005, C++ becomes the systems programming language 
> of CLI (and .NET).
> 
> 
> You may take a look at these:
> 
> http://msdn.microsoft.com/msdnmag/issues/05/01/COptimizations/default.aspx
> 
> http://pluralsight.com/blogs/hsutter/archive/2004/10/05/2672.aspx
> 
> http://blogs.msdn.com/branbray/archive/2003/11/07/51007.aspx
> 
> http://www.accu.org/conference/presentations/Sutter_-_Is_C++_Relevant_on_Modern_Environments_%28keynote%29.pdf 
> 
> 
> 
> And a page of mine:
> 
> http://www23.brinkster.com/noicys/cppcli.htm
> 
> 
> 
> With C++/CLI, C++ has two worlds: The unmanaged world and the managed 
> world.
> 
> In the managed world every CLI (.NET) feature is provided separately 
> from the unmanaged world features.
> 
> 
> 

ADA.net? Surely not!!

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

[Robert A Duff]

comeau@panix.com (Greg Comeau) writes:

> >>>> Out of curiosity how old is the ACATS test, and how many
> >>>> compilers currently pass it?
> 
> Still looking for this number if anybody has it handy.

Not sure which number you're looking for...

The ACATS has been around since the 1980's (although in those days it
was called ACVC; it got renamed ACATS around the time Ada 95 became an
ISO standard).  It gets updated from time to time, as new language
revisions come out, and as the language committee issues rulings about
some fine points of the language.

As far as I know, all Ada compiler vendors take it seriously, and ensure
that their compilers pass 100% of the test suite.  My company (Sofcheck,
Inc.) runs the ACATS every night, so we notice any regressions quickly.
We don't normally release a compiler that doesn't pass.  I believe
AdaCore (the folks who produce the gcc version of Ada (GNAT)) do the
same.

As I said elsewhere, passing 100% of the ACATS, or 100% of any other
test suite, does not guarantee the absense of bugs (obviously).

> >BTW: In the past it was Ada(tm) and only compilers with pass the test where
> >allowed to use the trademark Ada. For better or worse that is gone now -
> >and with it the need for a vendor to publish the result.
> 
> These points certainly "lessen the gap" then (if there was one)
> and make it much closer to the C++ situation then.

What is the C++ situation?  Is there a conformance test suite available?
Is it free?  What about C (same questions)?  (Sorry, if you already
answered that.)

By the way, the idea that Ada(tm) compilers had to pass some tests is
long, long gone.  It was a fairly silly idea, anyway, and totally
unenforceable.  Nobody's stopping anybody from producing a compiler for
Ada-except-some-diffs, or C++-except-some-diffs, for that matter.

- Bob

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Arthur J. O'Dwyer]

On Sun, 12 Mar 2005, jimmaureenrogers@worldnet.att.net wrote:
> Arthur J. O'Dwyer wrote:
>>    This example does not appear to contain any buffer oveflow.
>> If you think it does, please point it out to me.  I may have
>> missed something.
>>
>
> Ok, I understand why he made p and q with N+1 elements.
> This allows him to point past the Nth element without
> leaving either p or q's allocated space.

   Right.  (That's still a weird way of putting it... /obviously/
you need more than N elements in an array if you're going to be
accessing the N+1th element! :)

> Nonetheless,
> the data element in the highest position of those arrays
> has not been initialized. This is not the best practice.

   /None/ of the data elements of 'p' or 'q' has been initialized.
The array elements all have indeterminate (undefined) value until
they have been assigned-to in the 'do_array' routine.  (And then,
IIRC, it's the /first/ elements of 'p' and 'q' that still don't
receive values.  But I'm not looking at the code right now.)

>> On Sun, 13 Mar 2005, Jim Rogers wrote:
>>>
>>>   procedure Do_Array(X : Combiner) is
>>>      PA : Element_Ptr;
>>>   begin
>>>      Pa := X.P; -- assign all elements of X.P to Pa
>>
>>    Um... surely there's a better way to do this!  Are you really
>> copying N references here, or is something going on more subtle
>> than the comment indicates?
>
> That is exactly what I am doing, which matches nicely with the
> actions taken in the C code for the function setup_array:
>
> void
> setup_array(
>     int * x[N2],
>     int   p[N+1],
>     int   q[N+1]
>     )
> {
>  int i;
>  for(i=0; i< N;i++){
>   x[i]-&p[i];
>   x[i_N]=&q[i];
>  }
> }
>
> This appears to also be copying two sets of N pointers.

   Yes, but only once.  You put the same code inside 'Do_Array',
which IIRC gets called 10_000 times inside the main loop.  As I
read the C code, the point of 'setup_array' (assuming the whole
program made sense, which it doesn't) is to avoid having to do
tedious calculations inside 'do_array'.  But your code is doing
an O(N) copy operation inside 'do_array'!


>>>      Pa(2).all := 1; -- Assign 1 to the second value in the array
>>
>>    For my own edification: Am I correct in thinking that the ".all"
>> is superfluous in this expression?
>
> Not at all. This is equivalent to the C syntax
>   *(p[1]) = 1;

   Where '.all' corresponds to C's '*' operator, right.  I thought
I recalled reading that Ada would infer the '.all' to make the types
work out in some cases (similarly to Algol?); either I read wrong,
or this just isn't one of those cases.

-Arthur

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

[Ed Falis]

On 13 Mar 2005 19:31:47 -0500, Robert A Duff  
<bobduff@shell01.TheWorld.com> wrote:

> As far as I know, all Ada compiler vendors take it seriously, and ensure
> that their compilers pass 100% of the test suite.  My company (Sofcheck,
> Inc.) runs the ACATS every night, so we notice any regressions quickly.
> We don't normally release a compiler that doesn't pass.  I believe
> AdaCore (the folks who produce the gcc version of Ada (GNAT)) do the
> same.

Yes, we do.

> As I said elsewhere, passing 100% of the ACATS, or 100% of any other
> test suite, does not guarantee the absense of bugs (obviously).

Agree wholeheartedly.

- Ed

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

[Jeff C]

dave wrote:

> 
> ADA.net? Surely not!!

Umm...Yes
http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html

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

[Jean-Pierre Rosen]

Jerry Coffin a �crit :
> Let's address the Ada side first. Official Ada validation was done
> under the auspices of NIST, who delegated this task to the Ada Joint
> Program Office. The AJPO ceased to exist years ago, and the job was
> never turned over to anybody else when that happened. Meanwhile, NIST
> has discontinued _all_ of its compiler validation programs, not just
> the Ada program. Currently, both the ISO standard at a number of FIPS
> pubs _require_ Ada compilers to be officially validated, but at least
> in the US, there is absolutely NO agency to do that.
> 
I can assure you that there is still one official ACAL (laboratory for 
performing validation): Adalog, that's my company!

OK, it's not in the US. So what? Ada is an international standard.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

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

[Ioannis Vranos]

Robert A Duff wrote:

> What is the C++ situation?  Is there a conformance test suite available?
> Is it free?  What about C (same questions)?  (Sorry, if you already
> answered that.)


Here is one that major vendors use:

http://www.plumhall.com/ste.html


They are also preparing one for C++/CLI if I recall correctly.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Ioannis Vranos wrote:

> Here is one that major vendors use:
> 
> http://www.plumhall.com/ste.html


and

http://www.plumhall.com/libste.html


> They are also preparing one for C++/CLI if I recall correctly.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[dave]

Jeff C wrote:
> dave wrote:
> 
>>
>> ADA.net? Surely not!!
> 
> 
> Umm...Yes
> http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html

Well I never! Gore blimi! You what! and, well... er... yes.

If I had not seen it with my own eyes...

Nme. God Bless.

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

[dave]

dave wrote:
> Jeff C wrote:
> 
>> dave wrote:
>>
>>>
>>> ADA.net? Surely not!!
>>
>>
>>
>> Umm...Yes
>> http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html
> 
> 
> Well I never! Gore blimi! You what! and, well... er... yes.
> 
> If I had not seen it with my own eyes...
> 
> Nme. God Bless.
> 

After thought:

Microsoft + CLI == Not Mission Safe

Microsoft + CLI + ADA == Bad for ADA

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

[Ioannis Vranos]

Jeff C wrote:

> Umm...Yes
> http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html


Unfortunately this does not load in here, so I viewed it through 
google's cache. Also the ftp site does not work.


Perhaps they do not allow connections from outside the US so as to 
protect the precious .NET-enabled Ada. :-)


In any case, I suspect this will be fine to create .NET applications, 
however I suspect that it cannot produce 100% verifiable .NET code (the 
equivalent of VC++ 2005 /clr:safe), that is 100% managed code.


That is, it must be something like VC++ 2003 for C++.


In addition, I suspect it does not provide any designer support (RAD)...



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Martin Dowie]

CTips wrote:
> So it still isn't in the standard...

Not yet but there are plenty of reference implementations for all the other
new
library packages being added to Ada2005. Ask your compiler vendor load
enough and I'm sure they would supply it before the standard goes formal.

Or 'roll your own'.

Cheers

-- Martin

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Sat, 12 Mar 2005 09:42:26 +0100, Georg Bauhaus wrote:

> Falk Tannh�user wrote:
>> Dr. Adrian Wrigley wrote:
>> 
>>> But what of features not present in either?
>> 
>> [...]
>> 
>>> associative arrays (from Perl)
>> 
>> Wouldn't that be std::map in C++?
> 
> and in Ada 2005,
> 
> Ada.Containers.Hashed_Maps  and  Ada.Containers.Hashed_Maps

I have probably missed a trick in the C++, but I couldn't get
std::map code to compile (except in the trivial cases):

#include <map>

struct compoundindex {
  int a, b, c;
};

int main()
{
    std::map<compoundindex, float> hash;
    compoundindex fred = { 1, 2, 4 };

    hash[fred] = 0.123;
}

cpptest.cpp: In function `int main()':
cpptest.cpp:14: error: `main()::compoundindex' uses local type
`main()::compoundindex'
(8 more lines of errors here!)

(what is the simplest C++ code to get this intent?) 
--
The Ada associative arrays from the new draft standard
are specified as something like:

generic
   type Key_Type is private;
   type Element_Type is private;
   with function Hash (Key : Key_Type)
      return Hash_Type is <>;
   with function Is_Equal_Key (Left, Right : Key_Type)
      return Boolean is "=";
   with function "=" (Left, Right : Element_Type)
      return Boolean is <>;
package Ada.Containers.Hashed_Maps is...


Which clearly won't work unless you can find the three
function generic parameters.  I don't see how this can be
used easily in a generic context.

I don't think I am being *that* unreasonable in asking for arrays
indexed by arbitrary types, without jumping through hoops :)
-- 
Adrian

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

[Dr. Adrian Wrigley]

On Sat, 12 Mar 2005 12:59:31 -0500, CTips wrote:

> Robert A Duff wrote:
> 
>> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>> 
>> 
>>>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.
>> 
>> 
>> Heh?  Pascal has that.  In fact, practically every programming language
>> outside the C family has this feature.  It's quite useful -- almost
>> essential in multi-threaded programs.
>> 
>> - Bob
> 
> Yeah, and don't ask what it costs you. I'd carefully forgotten about all 
> the grungy details about displays and static/dynamic chaining, and you 
> had to remind me. I particularily like solutions that reserves a 
> register for the top-of-display/top-of-static-chain. Thats right - blow 
> away a register for that. And then of course the cost of 
> maintaining/walking those structures.
> 
> If you need thread-private storage, there are *much* cheaper solutions.

isn't uplevel addressing usually zero cost?  Are you saying it is
expensive whenever you use it?  Or expensive on all programs, whether
or not it is used?  Is it absent from C++ because of cost?
(I'm sure Robert understands this far better than I!)
-- 
Adrian

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

> #include <map>
> 
> struct compoundindex {
>   int a, b, c;
> };


inline bool operator <(const compoundindex &a, const compoundindex &b)
{
     return (a.a<b.a && a.b<b.b && a.c<b.c)? true: false;
}


> int main()
> {
>     std::map<compoundindex, float> hash;
>     compoundindex fred = { 1, 2, 4 };
> 
>     hash[fred] = 0.123;
> }



As a rule of thumb remember that most standard containers and algorithms 
require the presence of operator <.


 From a design perspective, in the example above, it is better to make 
operator< a member of the struct. I made it a global function, in case 
you want a POD struct.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Gautier]

CTips:

> He's done it right:
>   - he's running them on a Linux machine, which is more accurate than 
> cygwin for measuring performance (and where sys/user really mean something).
>    - he's using the improved times() which gives better resolution
>    - he's controlling for the startup overhead.
>    - he's using best of 4 runs.
>    - he's picked data sizes that will not blow the cache
>    - he's picked data sizes that will give decent run-times.
> 
> Like I said, if one knows what one is doing (which he does) then one can 
> disregard the rules. If one does not know what one is doing (which you 
> don't) then one should follow the rules.

He just forgot (and you forgot he forgot!) the main thing: to set the
right (indeed: any) compilation options for the Ada code...
______________________________________________________________
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!

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

[Dr. Adrian Wrigley]

On Sat, 12 Mar 2005 08:56:37 -0500, CTips wrote:

> As for automatically or manual checking - I add a lot of checking code 
> to my programs [see http://users.bestweb.net/~ctips ].  However, I do 
> try to follow a few rules:
> - The checking code can be disabled via a compile-time flag
> - Enabling/disabling checking code does not change the memory layout of 
> objects.
> Ada, I believe, violates the second rule. If you disable bounds 
> checking, it will replace handles with straight pointers, which can 
> result in considerably different memory images.

I've never heard of an Ada compiler changing memory layout under
such circumstances!  Even if it did, we're discussing languages,
not implementations - if the semantics are met, why would it matter?

I didn't think GNAT uses handles for arrays in the first place!
Whenever I have checked the code, data have always been accessed directly,
with a simple pointer.  If the bounds are relevant, a second pointer
is used.  Usually either the bounds pointer is important (and would be
needed in normal as an extra parameter or two in C code), or it
disappears. Fat pointers are not handles(?)

The use of handles seems to be a big concern for you.  When you
used (or evaluated) Ada for real applications, have you:

1) found that the code is handle based?
2) this caused a performance or other problem? (which compiler?)
-- 
Adrian

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Peter Koch Larsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]


"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> skrev i en 
meddelelse 
news:pan.2005.03.14.14.41.47.813082@linuxchip.demon.co.uk.uk.uk...
> On Sat, 12 Mar 2005 09:42:26 +0100, Georg Bauhaus wrote:
>
>> Falk Tannh�user wrote:
>>> Dr. Adrian Wrigley wrote:
>>>
>>>> But what of features not present in either?
>>>
>>> [...]
>>>
>>>> associative arrays (from Perl)
>>>
>>> Wouldn't that be std::map in C++?
>>
>> and in Ada 2005,
>>
>> Ada.Containers.Hashed_Maps  and  Ada.Containers.Hashed_Maps
>
> I have probably missed a trick in the C++, but I couldn't get
> std::map code to compile (except in the trivial cases):
>
> #include <map>
>
> struct compoundindex {
>  int a, b, c;
> };
>
> int main()
> {
>    std::map<compoundindex, float> hash;
>    compoundindex fred = { 1, 2, 4 };
>
>    hash[fred] = 0.123;

First off, std::map is not hash-based. It is a sorted container. Now in 
order to use this, you need a comparing function. It can be the "standard" 
ordering function for your key or it can be a user specified function.

> }
>
> cpptest.cpp: In function `int main()':
> cpptest.cpp:14: error: `main()::compoundindex' uses local type
> `main()::compoundindex'
> (8 more lines of errors here!)

You must have snipped the most interesting errormessage.
>
> (what is the simplest C++ code to get this intent?)

What you need here is a comparator:

bool operator<(compoundindex const& lhs,compoundindex const& rhs)
{
....
}

And the map should work.
> --
> The Ada associative arrays from the new draft standard
> are specified as something like:
>
> generic
>   type Key_Type is private;
>   type Element_Type is private;
>   with function Hash (Key : Key_Type)
>      return Hash_Type is <>;
>   with function Is_Equal_Key (Left, Right : Key_Type)
>      return Boolean is "=";
>   with function "=" (Left, Right : Element_Type)
>      return Boolean is <>;
> package Ada.Containers.Hashed_Maps is...
>
>
> Which clearly won't work unless you can find the three
> function generic parameters.  I don't see how this can be
> used easily in a generic context.
>
> I don't think I am being *that* unreasonable in asking for arrays
> indexed by arbitrary types, without jumping through hoops :)

But I do! How can you index without at least knowing if two values are 
different or the same?
The C++ standard will have a hash-based container later. Those interested in 
having one can download one from e.g. boost (I believe this container also 
to be implemented by boost and prbably several others).

> -- 
> Adrian
>
/Peter 

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Falk Tannhäuser]

Dr. Adrian Wrigley wrote:
> I have probably missed a trick in the C++, but I couldn't get
> std::map code to compile (except in the trivial cases):
> 
> #include <map>
> 
> struct compoundindex {
>   int a, b, c;
> };
> 
> int main()
> {
>     std::map<compoundindex, float> hash;
>     compoundindex fred = { 1, 2, 4 };
> 
>     hash[fred] = 0.123;
> }

C++ associative containers (map, set, multimap, multiset) require
a "strict weak ordering" for their key types. In the present case,
it is enough to define the following 'operator<' to induce a total
ordering:

   bool operator<(compoundindex const& x, compoundindex const& y)
   {
     if(x.a < y.a) return true;
     if(x.a == y.a)
     {
       if(x.b < y.b) return true;
       if(x.b == y.b)
         return x.c < y.c;
     }
     return false;
   }

Alternatively, if there is no natural definition for a general-purpose
operator< for the key type in question, it is possible to create a
comparison functor and to instantiate the container with it as
supplementary template parameter.
In either case, the container implementation uses the order to store its
elements in a balanced tree, so that element access becomes possible
with logarithmic complexity regarding to the number of elements currently
in the container.

Hash-based associative containers (guaranteing constant-time access as
long as there are no key collisions) are not (yet) provided by the
standard library but are widely available through third party / extension
libraries.

Falk

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Gautier wrote:
> CTips:
> 
> 
>>He's done it right:
>>  - he's running them on a Linux machine, which is more accurate than 
>>cygwin for measuring performance (and where sys/user really mean something).
>>   - he's using the improved times() which gives better resolution
>>   - he's controlling for the startup overhead.
>>   - he's using best of 4 runs.
>>   - he's picked data sizes that will not blow the cache
>>   - he's picked data sizes that will give decent run-times.
>>
>>Like I said, if one knows what one is doing (which he does) then one can 
>>disregard the rules. If one does not know what one is doing (which you 
>>don't) then one should follow the rules.
> 
> 
> He just forgot (and you forgot he forgot!) the main thing: to set the
> right (indeed: any) compilation options for the Ada code...

The site maintainer doesn't set the compile flags... the person who 
submits the code fragment gives him the compile & run script. I'm not 
surprised that the submitter neglected to set up any flags for performance.

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

[Larry Kilgallen]

In article <wcczmx7azgt.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
>> In article <wccu0ng6hie.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>> > 
>> >> 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.
>> > 
>> > Heh?  Pascal has that.
>> 
>> Yes, I just said Pascal had that.
> 
> Oh, sorry, I must have thought you said "...in addition to what Pascal
> has..." or something.  My bad.
> 
> Anyway, nested functions are really nested in any useful sense if you
> can't do uplevel addressing, right?

I much prefer that capability, but in Bliss (which lacks uplevel addressing)
there is some benefit provided by just the reduced visibility of the
nested function.  I know for sure that I can call my nested function
RETRIEVE_STATUS without worrying about a conflict with something else
of the first name.

This is _certainly_ not a Bliss vs. Ada argument, but for me it is
a Bliss vs. C argument.

Please remember, however, that I only mentioned it because you asked :-)

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

[Larry Kilgallen]

In article <opsnlu5k0q5afhvo@localhost>, "Ed Falis" <falis@verizon.net> writes:
> On 13 Mar 2005 19:31:47 -0500, Robert A Duff  
> <bobduff@shell01.TheWorld.com> wrote:
> 
>> As far as I know, all Ada compiler vendors take it seriously, and ensure
>> that their compilers pass 100% of the test suite.  My company (Sofcheck,
>> Inc.) runs the ACATS every night, so we notice any regressions quickly.
>> We don't normally release a compiler that doesn't pass.  I believe
>> AdaCore (the folks who produce the gcc version of Ada (GNAT)) do the
>> same.
> 
> Yes, we do.
> 
>> As I said elsewhere, passing 100% of the ACATS, or 100% of any other
>> test suite, does not guarantee the absense of bugs (obviously).
> 
> Agree wholeheartedly.

But it is reassuring to know that a particular compiler does at least
some things correctly.

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

[Larry Kilgallen]

In article <pan.2005.03.14.14.49.18.718254@linuxchip.demon.co.uk.uk.uk>, "Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:
> On Sat, 12 Mar 2005 12:59:31 -0500, CTips wrote:
> 
>> Robert A Duff wrote:
>> 
>>> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>>> 
>>> 
>>>>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.
>>> 
>>> 
>>> Heh?  Pascal has that.  In fact, practically every programming language
>>> outside the C family has this feature.  It's quite useful -- almost
>>> essential in multi-threaded programs.
>>> 
>>> - Bob
>> 
>> Yeah, and don't ask what it costs you. I'd carefully forgotten about all 
>> the grungy details about displays and static/dynamic chaining, and you 
>> had to remind me. I particularily like solutions that reserves a 
>> register for the top-of-display/top-of-static-chain. Thats right - blow 
>> away a register for that. And then of course the cost of 
>> maintaining/walking those structures.
>> 
>> If you need thread-private storage, there are *much* cheaper solutions.

But what if you actually need uplevel addressing ?

Why would one presume that users of uplevel addressing actually need
thread-private storage ?  Thread-private storage would give just
a single instance per thread, not multiple nested instances per
thread.

> isn't uplevel addressing usually zero cost?  Are you saying it is
> expensive whenever you use it?  Or expensive on all programs, whether
> or not it is used?  Is it absent from C++ because of cost?

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 17:06:10 +0100, Falk Tannh�user wrote:

> Alternatively, if there is no natural definition for a general-purpose
> operator< for the key type in question, it is possible to create a
> comparison functor and to instantiate the container with it as
> supplementary template parameter.

the problem as I suggested in my previous post is that you have to
pass in the comparison operator or hash function down the tree
of template/generic instantiation, (composing them along the way)
if you want to use maps/hashes. If the necessary functions are
not passed in and built up, you can't instantiate the map/hash.
This means that you can't write an implementation of a template/generic
function using a map/hash without changing some/all the implementations
and interfaces up the instantiation tree (am I right?). Obviously this
may not be possible, for example in large a multi-team or multi
language project. If you changed from a map to a hash, you'd have
to change all the interfaces to pass the hashing function instead
or as well as the comparison operator.

In Ada, a private (nonlimited) generic formal type guarantees
an equality operation and assignment is defined for the type.
These are the only logical requirements for an associative array.
I guess an efficient hash/map library could be written for
private nonlimited generic formals, but neither std::map nor
hashed maps meet this less restrictive requirement.

Put another way, neither language has minimally restrictive
associative arrays in their (or their standard library) specification.
-- 
Adrian

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

[jtg]

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

I had the same problem several years ago.
I was learning Ada from tutorials (www.adahome.com) and online
articles. They were nice and I could get the ideas quickly, but
they were rather shallow and I just could not find answers to
many questions.

After buying one poor book (just the only I could find in local
bookstores) I decided to search for a good book in online bookstores.
I chose "Ada as a second language" by Norman Cohen and I am very glad
with it. All the questions that bothered me (some for months) were
answered in no time. AFAIR always when I needed to know something
about Ada I could find it in this book (well, one exception:
I could not find any information about preprocessor, but some
Ada programmers claim you don't need preprocessor in Ada).

As the title suggests, the book assumes that the reader is already
a skilled programmer :-)
In the book there are many comparisons to C, C++ and some other
languages. If an Ada feature is similar to something in C or C++,
the book mentions it to help pick the idea. If there are differences,
the book mentions them too, to help avoid potential pitfalls
or correct "bad habits", i.e. ways which are natural in one
language but are not the right way to do sth in Ada. So I think
the book would be as useful for you as it was for me.

Is it difficult to move from C/C++ to Ada? Maybe I can tell
you what you may expect (from my own experience only).
When you write in Ada, it is much, much easier to get bugless
program once you manage to compile it (of course if you make
use of Ada features). However, trying to compile an Ada code may be
sometimes very, very frustrating, when the compiler complains
about sth, you look into the code and cannot find out what a strange
rule you are breaking this time in this particular place.

And in Ada you must write a lot more.
You must declare everything, you must be explicit, you must obey
the rules which sometimes seem stupid.
And you must forget about these handy i++, --j, i+=a etc.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[jtg]

Paul E. Bennett wrote:

> 
> 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.
> 
So, why people don't mount these spikes, and instead they mount
seatbelts and airbags? Strange, isn't it?
I use Ada because I can crate programs much faster, while retaining
safety level.
If I had to write the same programs in C, I could retain the safety
with "more cautious approach", but I would need more time to finish
them.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Pascal Obry]

CTips <ctips@bestweb.net> writes:

> The site maintainer doesn't set the compile flags... the person who submits
> the code fragment gives him the compile & run script. I'm not surprised that
> the submitter neglected to set up any flags for performance.

How do you know that ? I did not found this from there web site !

I just contributed the new Matrix Ada version. I also talked to the
maintainer and my understanding is that the scripts are done by him.

Pascal.

PS : I'm still asking myself why I continue to argue with you! It seems that
     you just fill this space with mis-information.

-- 

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

> the problem as I suggested in my previous post is that you have to
> pass in the comparison operator or hash function down the tree
> of template/generic instantiation, (composing them along the way)
> if you want to use maps/hashes.


In the standard library containers and algorithms case you do not pass 
any function to the container. operator< is implicitly used.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote:

> Dr. Adrian Wrigley wrote:
> 
>> the problem as I suggested in my previous post is that you have to
>> pass in the comparison operator or hash function down the tree
>> of template/generic instantiation, (composing them along the way)
>> if you want to use maps/hashes.
> 
> In the standard library containers and algorithms case you do not pass
> any function to the container. operator< is implicitly used.

The comparison operator here seems to be a generic formal function
parameter with a default value.  This must be available at instantiation.
The operator becomes part of the interface (implicitly or explicitly) for
any code instantiating the std::map.  Where does the code for the
comparison operator go?  It *has* to go at the point the class
is defined.  This could be at the other end of a hierarchy of
generic instantiations.  The result is that the implementation
requirement (needs a comparison operator) has propagated up the
generic hierarchy to some otherwise completely independent code as an
interface requirement.  I'm sorry I can't explain this any better!
(should I give a code example?)
-- 
Adrian

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

[kevin cline]

adaworks@sbcglobal.net wrote:

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

But not all lines of source code are created equally.  Written in a
more expressive language the application might be only half that size,
or most likely even less.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Mon, 14 Mar 2005 19:29:25 GMT, Dr. Adrian Wrigley wrote:

> On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote:
> 
>> Dr. Adrian Wrigley wrote:
>> 
>>> the problem as I suggested in my previous post is that you have to
>>> pass in the comparison operator or hash function down the tree
>>> of template/generic instantiation, (composing them along the way)
>>> if you want to use maps/hashes.
>> 
>> In the standard library containers and algorithms case you do not pass
>> any function to the container. operator< is implicitly used.
> 
> The comparison operator here seems to be a generic formal function
> parameter with a default value.  This must be available at instantiation.
> The operator becomes part of the interface (implicitly or explicitly) for
> any code instantiating the std::map.  Where does the code for the
> comparison operator go?  It *has* to go at the point the class
> is defined.  This could be at the other end of a hierarchy of
> generic instantiations.  The result is that the implementation
> requirement (needs a comparison operator) has propagated up the
> generic hierarchy to some otherwise completely independent code as an
> interface requirement.  I'm sorry I can't explain this any better!

It can be formulated in two words: "contract model" is what C++ templates
lack.

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

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

[kevin cline]

Martin Krischik wrote:

> Shure it is true: The C++ ISO standard has ruffly 200 pages more then
the
> Ada ISO standard. The C standard is a few pages shorter - but C
hasn't got
> object orientation, concurency, real time and distributed system
included.

No surprise there.  The C++ standard covers the C++ standard library.

> But prove me wrong and show me any successful slim language - which
has not
> become fat (either by language or by build in library) withing 10
years of
> becomming successfull.

Personally I prefer slimmer languages and fatter libraries whenever
possible.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

> The comparison operator here seems to be a generic formal function
> parameter with a default value.  This must be available at instantiation.
> The operator becomes part of the interface (implicitly or explicitly) for
> any code instantiating the std::map.  Where does the code for the
> comparison operator go?  It *has* to go at the point the class
> is defined.


Yes. However if you later convert to a hash container, it can remain 
around unused in the particular container.




>  This could be at the other end of a hierarchy of
> generic instantiations.  The result is that the implementation
> requirement (needs a comparison operator) has propagated up the
> generic hierarchy to some otherwise completely independent code as an
> interface requirement.  I'm sorry I can't explain this any better!
> (should I give a code example?)


Yes, also operator< is used to all containers and algorithms where a 
comparison takes place, like sorting algorithms (std::sort, 
std::stable_sort, etc).


I can not understand how this could be avoided for such operations and 
containers, since a comparison is required.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Georg Bauhaus]

Dr. Adrian Wrigley wrote:
> On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote:
> 
> 
>>Dr. Adrian Wrigley wrote:
>>
>>
>>>the problem as I suggested in my previous post is that you have to
>>>pass in the comparison operator or hash function down the tree
>>>of template/generic instantiation, (composing them along the way)
>>>if you want to use maps/hashes.
>>
>>In the standard library containers and algorithms case you do not pass
>>any function to the container. operator< is implicitly used.
> 
> 
> The comparison operator here seems to be a generic formal function
> parameter with a default value. 

I think this description is o.K. for Ada, but perhaps not
for C++. E.g. you can place the following in three different
files (modules), somewhat like in Ada, and you don't have
to write the < into the module containing the compared type.

// 1

#include "comp.h"
#include <map>

bool operator< (V a, V b) { return a.val() < b.val(); }
  
int main()
{
  std::map<V, float> m;
  V key1, key2 = V(3);

  m[key1] = 1.0;
  m[key2] = 1.0;
 
  return 0;
}

// 2

class V {
  int v;
public:
  V() : v(0) {}
  V(int val) : v(val) {}
  int val() const;
};

// 3

#include "comp.h"

int V::val() const {
  return v;
}

Georg 

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

[Ioannis Vranos]

kevin cline wrote:

> Personally I prefer slimmer languages and fatter libraries whenever
> possible.


However C++ has also the ideal to be able to write these libraries with 
the language itself.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Robert A Duff]

CTips <ctips@bestweb.net> writes:

> Robert A Duff wrote:
> 
> > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> >
> >>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.
> > Heh?  Pascal has that.  In fact, practically every programming language
> > outside the C family has this feature.  It's quite useful -- almost
> > essential in multi-threaded programs.
> > - Bob
> 
> Yeah, and don't ask what it costs you. I'd carefully forgotten about all
> the grungy details about displays and static/dynamic chaining, and you
> had to remind me. I particularily like solutions that reserves a
> register for the top-of-display/top-of-static-chain. Thats right - blow
> away a register for that. And then of course the cost of
> maintaining/walking those structures.

I beg to differ.  Uplevel references can be implemented as efficiently
as parameter passing (which is what you normally do in C-family
languages as a substitute).  And it can cost nothing when not used.
It can also cost nothing when the procedures involved can be inlined
(which is a very common case -- the reason I'm writing a nested procedure
is usually so I can pass it to an iterator, and both the iterator and
the nested procedure are usually small enough to deserve inlining).

(I'm not a big fan of displays, by the way.)

> If you need thread-private storage, there are *much* cheaper solutions.

This seems like a nonsequitor -- thread-private storage and uplevel
references are different things, with different (though somewhat
related) purposes.  C and C++ have neither, which can make using thread
packages painful, though gcc supports uplevel references (for both C and
Ada, and I think C++ also).

And having implemented both, I'd say thread-private storage is
generally more expensive than uplevel references.  What's your
much cheaper solution?

- Bob

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

[Greg Comeau]

In article <wccpsy3awzw.fsf@shell01.TheWorld.com>,
Robert A Duff  <bobduff@shell01.TheWorld.com> wrote:
>comeau@panix.com (Greg Comeau) writes:
>
>> >>>> Out of curiosity how old is the ACATS test, and how many
>> >>>> compilers currently pass it?
>> 
>> Still looking for this number if anybody has it handy.
>
>Not sure which number you're looking for...

How many current compiler pass current ACATS test,
at least those that are required.

>...
>As I said elsewhere, passing 100% of the ACATS, or 100% of any other
>test suite, does not guarantee the absense of bugs (obviously).

Obviously, indeed

>> >BTW: In the past it was Ada(tm) and only compilers with pass the test where
>> >allowed to use the trademark Ada. For better or worse that is gone now -
>> >and with it the need for a vendor to publish the result.
>> 
>> These points certainly "lessen the gap" then (if there was one)
>> and make it much closer to the C++ situation then.
>
>What is the C++ situation?  Is there a conformance test suite available?
>Is it free?  What about C (same questions)?  (Sorry, if you already
>answered that.)

One's leaping right to mind are Perennial, PlumHall and Dinkumware's,
as commercial products.  There's other too, and other open source
regressions, etc too.

>By the way, the idea that Ada(tm) compilers had to pass some tests is
>long, long gone.  It was a fairly silly idea, anyway, and totally
>unenforceable.  Nobody's stopping anybody from producing a compiler for
>Ada-except-some-diffs, or C++-except-some-diffs, for that matter.

Yes, I'm hearing that loud and clear.
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> It can be formulated in two words: "contract model" is what C++ templates
> lack.

I think "explicit contract model" is slightly better, and perhaps
you can say something about the closure that the compiler needs
to find out whether a contract is fulfilled (Can_Copy etc.)?
 

Georg 

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

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> > Anyway, nested functions are really nested in any useful sense if you
                                ^not
Of course I meant "not" above.  Sorry again.

> > can't do uplevel addressing, right?
> 
> I much prefer that capability, but in Bliss (which lacks uplevel addressing)

Hmm.  I had forgotten that about Bliss.  I did a fair amount of Bliss
programming a long time ago...

So it's sort of like a "static" variable declared inside a C function --
it's nested with respect to visibility, but its lifetime is not,
so its run-time semantics are just as if declared at top level.

> there is some benefit provided by just the reduced visibility of the
> nested function.  I know for sure that I can call my nested function
> RETRIEVE_STATUS without worrying about a conflict with something else
> of the first name.
> 
> This is _certainly_ not a Bliss vs. Ada argument, but for me it is
> a Bliss vs. C argument.
> 
> Please remember, however, that I only mentioned it because you asked :-)

Well thanks for answering.  ;-)

- Bob

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 19:29:25 +0000, Dr. Adrian Wrigley wrote:

>  I'm sorry I can't explain this any better!
> (should I give a code example?)

OK.  How about a trivial but reasonable example:

#include <time.h>
#include <map>

struct interval {
  tm start, finish;
};

int main()
{
    std::map<interval, float> hash;
    interval fred;

    //   set fred here!    

    hash[fred] = 0.123;
}

No suitable place to put the compare operator!
-- 
Adrian

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

[kevin cline]

Martin Dowie wrote:
> Jerry Coffin wrote:
> > Pascal Obry wrote:
> >
> >>"Jerry Coffin" <jcoffin@taeus.com> writes:
> >>
> >>
> >>>Your claim of fewer bugs is just the sort of unsupported anti-C
> >>>comment we see all the time.
> >>
> >>Just plain wrong, there is data (a PHD) see
> >>http://www.adaic.com/whyada/ada-vs-c/cada_art.html
>
> Ok, what about this paper:
> http://www.praxis-his.com/pdfs/c_by_c_better_cheaper.pdf
>
> In particular the company audited by the UK MoD on the 3rd page
showed
> interesting results. I work for the company audited and I'm sure the
> audit is post-1995 by some margin (when I was no longer working
there),
> and by your own argument, by 1990 the compilers were pretty close to
> standard C, yet this study still found a 10*defect rate in C than in
> Ada... and a 100* defect rate compared to SPARK...
>
> Yet, this sort of report seems all to common to me. Every language
since
> 'C' has had at least 1 report that shows how brilliant it is at
compared
> to 'C', yet 'C' is still the most widely spread language. Why?
>
> I think we perhaps need a psychologists view rather than looking at
> language differences. Are humans 'hooked' on tracking down /really/
> tricky null pointer dereference problems? Is it really just a fight
for
> 'silver back status' coz 'my programs compile to 1 long word less
than
> yours'?...

No, people are hooked on getting work done with what they perceive to
be the least possible effort and minimal risk.  So they pick what they
know, what their colleagues know, what has been known to work in the
past in their application domain.  Ada rarely enters the picture.  They
don't know Ada, no one they know uses Ada, no one they read advocates
Ada.

For a lot of commerical applications Perl or Python or Ruby or another
higher level language would be considerably better than Java, or C++,
or C#, but mostly they aren't used either.  Even though they are
considerably more popular than Ada, they still aren't popular enough
for risk-averse project managers.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Robert A Duff]

CTips <ctips@bestweb.net> writes:

> Gautier wrote:
> > CTips:
> >
> >>He's done it right:
> >>  - he's running them on a Linux machine, which is more accurate than
> >> cygwin for measuring performance (and where sys/user really mean
> >> something).

Why is that?  When I use cygwin, the sys/user times indeed seem
completely bogus.  Are these impossible to measure on windows?  If that
were true, why wouldn't it always print 0 or something?  The cygwin
'time' command is obviously trying to measure *something* with these
numbers.

- Bob

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

[Greg Comeau]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

In article <ath31d.1vm.ln@hunter.axlog.fr>,
Jean-Pierre Rosen  <rosen@adalog.fr> wrote:
>Jerry Coffin a �crit :
>> Let's address the Ada side first. Official Ada validation was done
>> under the auspices of NIST, who delegated this task to the Ada Joint
>> Program Office. The AJPO ceased to exist years ago, and the job was
>> never turned over to anybody else when that happened. Meanwhile, NIST
>> has discontinued _all_ of its compiler validation programs, not just
>> the Ada program. Currently, both the ISO standard at a number of FIPS
>> pubs _require_ Ada compilers to be officially validated, but at least
>> in the US, there is absolutely NO agency to do that.
>> 
>I can assure you that there is still one official ACAL (laboratory for 
>performing validation): Adalog, that's my company!
>
>OK, it's not in the US. So what? Ada is an international standard.

Other posts seems to disagree.  Please clarify for us.
Also include how and why your company is the _official_ lab.
(I'm not challenging you, but seems to me a mixed message
is coming through this thread.)
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

[kevin cline]

Dr. Adrian Wrigley wrote:
> On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote:
>
> > Dr. Adrian Wrigley wrote:
> >
> >> the problem as I suggested in my previous post is that you have to
> >> pass in the comparison operator or hash function down the tree
> >> of template/generic instantiation, (composing them along the way)
> >> if you want to use maps/hashes.
> >
> > In the standard library containers and algorithms case you do not
pass
> > any function to the container. operator< is implicitly used.
>
> The comparison operator here seems to be a generic formal function
> parameter with a default value.  This must be available at
instantiation.
> The operator becomes part of the interface (implicitly or explicitly)
for
> any code instantiating the std::map.  Where does the code for the
> comparison operator go?  It *has* to go at the point the class
> is defined.

Actually, it doesn't.  If not defined as a member function in the
class, it can be defined as a free function wherever convenient.  Or a
custom comparison function can be defined and specified in the
instantiation.

Either this:

   class Stuff {
   public:
      bool operator<(const Stuff& rhs);
   };

or this:

   bool operator<(const Stuff& lhs, const Stuff& rhs);

will work with this:

   std::set<Stuff> allStuff;

Or you can define a special comparator to be used for a particular
instantiation, like this:

   struct compareStuff()
   {
       bool operator()(const Stuff& lhs, const Stuff& rhs) { ... }
   }

   std::set<Stuff, compareStuff> zeds;

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 14 Mar 2005 19:29:25 GMT, Dr. Adrian Wrigley wrote:
> 
> > On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote:
> > 
> >> Dr. Adrian Wrigley wrote:
> >> 
> >>> the problem as I suggested in my previous post is that you have to
> >>> pass in the comparison operator or hash function down the tree
> >>> of template/generic instantiation, (composing them along the way)
> >>> if you want to use maps/hashes.
> >> 
> >> In the standard library containers and algorithms case you do not pass
> >> any function to the container. operator< is implicitly used.

The fact that "<" can be implicitly passed to the template/generic (in
C++/Ada) is not relevant; Dr. Wrigley's point is that it has to be
there.

> > The comparison operator here seems to be a generic formal function
> > parameter with a default value.  This must be available at instantiation.
> > The operator becomes part of the interface (implicitly or explicitly) for
> > any code instantiating the std::map.  Where does the code for the
> > comparison operator go?  It *has* to go at the point the class
> > is defined.

Because the "<" (or Hash) needs to know the internals of the thing.

In other words, at the point where you declare a type, you have to think
ahead: this type might want to live inside one of those containers, so
I'd better define the necessary operations.

I agree -- that's a pain.

The only way around it, it seems to me, is to have the compiler
automatically create a hash function (or something) for every type --
after all, you can't expect to create these kinds of containers without
a hash function (or something, like "<"), whether the user is required
to write it or not.  Lots of languages do something like that, but I
don't know of any such that emphasize efficiency like C++ and Ada.
Also, in the "<" case, the "<" might mean something important
(so you can iterate through the container in a sensible order),
and I don't see how the compiler can be expected to guess what order
that is.

> > ...This could be at the other end of a hierarchy of
> > generic instantiations.  The result is that the implementation
> > requirement (needs a comparison operator) has propagated up the
> > generic hierarchy to some otherwise completely independent code as an
> > interface requirement.  I'm sorry I can't explain this any better!

I think I understand what you mean.

> It can be formulated in two words: "contract model" is what C++ templates
> lack.

Which is both a benefit and a drawback.  C++ templates are somewhat more
powerful that Ada generics, because of the lack of contract model, and
implicit instantiation.

But I don't think that addresses Dr. Wrigley's complaint (which applies
to both Ada and C++).

- Bob

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

[CTips]

Dr. Adrian Wrigley wrote:
> On Sat, 12 Mar 2005 12:59:31 -0500, CTips wrote:
> 
> 
>>Robert A Duff wrote:
>>
>>
>>>Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>>>
>>>
>>>
>>>>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.
>>>
>>>
>>>Heh?  Pascal has that.  In fact, practically every programming language
>>>outside the C family has this feature.  It's quite useful -- almost
>>>essential in multi-threaded programs.
>>>
>>>- Bob
>>
>>Yeah, and don't ask what it costs you. I'd carefully forgotten about all 
>>the grungy details about displays and static/dynamic chaining, and you 
>>had to remind me. I particularily like solutions that reserves a 
>>register for the top-of-display/top-of-static-chain. Thats right - blow 
>>away a register for that. And then of course the cost of 
>>maintaining/walking those structures.
>>
>>If you need thread-private storage, there are *much* cheaper solutions.
> 
> 
> isn't uplevel addressing usually zero cost?  Are you saying it is
> expensive whenever you use it?  Or expensive on all programs, whether
> or not it is used?  Is it absent from C++ because of cost?
> (I'm sure Robert understands this far better than I!)

My knowledge of this is a little dated and hazy, so I could be wrong.

If we're doing something like:
   foo()
   {
     int x, y;
     bar()
     {
       int y;
       gah()
       {
         use(x), use(y);
        }
      }
    }

then, at run-time, in use(x), x comes from the stack-frame of the 
nearest invocation of foo() on the stack, and in use(y), y comes from 
the stack-frame of the nearest invocation of bar().

There has to be a mechanism to identify the nearest invocation of 
foo()/bar(). There are, if I remember correctly, 4 mechanisms to find 
the invocation:
- dynamic chaining: you just follow the back-chain pointers, stepping 
through all stack frames, till you come to the right stack frame.
- static chianing: you maintain a separate chain (the static chain) that 
directly link to the stack frame of the enclosing functions. Thus the 
static chain for gah() would have the last invocation of bar() followed 
by the last invocation of foo().
- display: somewhat like the static chain, except its an array instead 
of a list
- currying (?): this one I'm really hazy about, but, roughly, you passed 
pointers to the correct uplevel variables as extra arguments to the 
functions. Thus bar would be passed the pointer to x and gah would be 
passed pointers to x and y, as well as their other arguments, or 
something like that.

There were some additional nastinesses dealing with what happens when a 
nested function is passed as an argument

Depending on the techinques, you either pay whenever you access 
variables of enclosing functions, or you pay to maintain the 
data-structures [static-chain,display] which make this access cheaper, 
or both.

On some implementations (on RISC architectures) a register is reserved 
for the static-chain. This means one less register for *every* function 
(or maybe only for enclosed functions?) when used with a language that 
support this kind of nested functions.

C++ probably left it out because of its C heritage, while Ada probably 
dropped it in because of its Pascal heritage. IMHO, its probably not 
worth the cost.

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

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 13:02:10 -0800, kevin  cline wrote:

> Dr. Adrian Wrigley wrote:
>> any code instantiating the std::map.  Where does the code for the
>> comparison operator go?  It *has* to go at the point the class
>> is defined.
> 
> Actually, it doesn't.  If not defined as a member function in the
> class, it can be defined as a free function wherever convenient.  Or a
> custom comparison function can be defined and specified in the
> instantiation.

OK.  Maybe there are circumstances where it could, in practice, go
somewhere else.  If some of the sorted values are in the private
part, I guess you could use a friend class(?).  But in the particular
case of generic hierarchies, there is probably nowhere convenient :(
Even in simple cases, the encapsulation has to be broken (see the
time interval example).
-- 
Adrian

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

[Robert A Duff]

comeau@panix.com (Greg Comeau) writes:

> In article <wccpsy3awzw.fsf@shell01.TheWorld.com>,
> Robert A Duff  <bobduff@shell01.TheWorld.com> wrote:
> >comeau@panix.com (Greg Comeau) writes:
> >
> >> >>>> Out of curiosity how old is the ACATS test, and how many
> >> >>>> compilers currently pass it?
> >> 
> >> Still looking for this number if anybody has it handy.
> >
> >Not sure which number you're looking for...
> 
> How many current compiler pass current ACATS test,
> at least those that are required.

Well, let's see.  Off the top of my head, Ada compilers are available
from Sofcheck (that's my company), AdaCore (that's the free software
version; they make their money by providing support), Greenhills
(which uses the SofCheck Ada front end, and supports many embedded
targets), Aonix (also uses the SofCheck front end), RR Software,
DDC-I, ICSC (sp?), IBM...  (Did I forget some?)

I don't know which ones pass (the required portion of) the ACATS.
My guess is: all of them.

(The reason there are ACATS tests that are not required is that some
portions of the language standard are optional.  The standard has
optional annexes for various specialized purposes: real-time,
information systems, safety critical, etc.)

By the way, SofCheck's current focus is not Ada compilers: we're
concentrating on static analysis tools for Java and Ada and eventually
other languages such as C++.  But we still make most of our revenue
from the compiler side of the business.

> >By the way, the idea that Ada(tm) compilers had to pass some tests is
> >long, long gone.  It was a fairly silly idea, anyway, and totally
> >unenforceable.  Nobody's stopping anybody from producing a compiler for
> >Ada-except-some-diffs, or C++-except-some-diffs, for that matter.

...but of course there's a lot of market pressure to produce
standard-conforming compilers, for those languages that have official
standards (Ada, C, C++, Fortran, Cobol, etc).

> Yes, I'm hearing that loud and clear.

- Bob

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

[Robert A Duff]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> kevin cline wrote:
> 
> > Personally I prefer slimmer languages and fatter libraries whenever
> > possible.

I agree.

> However C++ has also the ideal to be able to write these libraries with
> the language itself.

As opposed to... ?

- Bob

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 16:02:43 -0500, Robert A Duff wrote:


<lots of sensible clarification of the issue removed>


> I agree -- that's a pain.
> 
> The only way around it, it seems to me, is to have the compiler
> automatically create a hash function (or something) for every type --
> after all, you can't expect to create these kinds of containers without
> a hash function (or something, like "<"), whether the user is required
> to write it or not.  Lots of languages do something like that...

precisely.  That was my point (Friday) about needing proper
language support for associative arrays in both C++ and Ada, or
(as you suggest) lower-level prerequisites.  In Ada, maybe it could
be a 'Hash attribute.

I think we can also see clearly how generics/templates are only
superficially equivalent in what programmers demand of them.
The contract model being a big part of the encapsulation process
considered essential by Ada users, but *worse than useless* from
the C++ view.

Thnaks Rob for putting the points more eloquently!
-- 
Adrian

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

[Greg Comeau]

In article <wcc4qfdoqzd.fsf@shell01.TheWorld.com>,
Robert A Duff  <bobduff@shell01.TheWorld.com> wrote:
>comeau@panix.com (Greg Comeau) writes:
>
>> In article <wccpsy3awzw.fsf@shell01.TheWorld.com>,
>> Robert A Duff  <bobduff@shell01.TheWorld.com> wrote:
>> >comeau@panix.com (Greg Comeau) writes:
>> >
>> >> >>>> Out of curiosity how old is the ACATS test, and how many
>> >> >>>> compilers currently pass it?
>> >> 
>> >> Still looking for this number if anybody has it handy.
>> >
>> >Not sure which number you're looking for...
>> 
>> How many current compiler pass current ACATS test,
>> at least those that are required.
>
>Well, let's see.  Off the top of my head, Ada compilers are available
>from Sofcheck (that's my company), AdaCore (that's the free software
>version; they make their money by providing support), Greenhills
>(which uses the SofCheck Ada front end, and supports many embedded
>targets), Aonix (also uses the SofCheck front end), RR Software,
>DDC-I, ICSC (sp?), IBM...  (Did I forget some?)
>
>I don't know which ones pass (the required portion of) the ACATS.
>My guess is: all of them.
>
>(The reason there are ACATS tests that are not required is that some
>portions of the language standard are optional.  The standard has
>optional annexes for various specialized purposes: real-time,
>information systems, safety critical, etc.)
>
>By the way, SofCheck's current focus is not Ada compilers: we're
>concentrating on static analysis tools for Java and Ada and eventually
>other languages such as C++.  But we still make most of our revenue
>from the compiler side of the business.
>
>> >By the way, the idea that Ada(tm) compilers had to pass some tests is
>> >long, long gone.  It was a fairly silly idea, anyway, and totally
>> >unenforceable.  Nobody's stopping anybody from producing a compiler for
>> >Ada-except-some-diffs, or C++-except-some-diffs, for that matter.
>
>...but of course there's a lot of market pressure to produce
>standard-conforming compilers, for those languages that have official
>standards (Ada, C, C++, Fortran, Cobol, etc).

And hence why I'm curious exactly which ones are fully standard
conforming, optional parts aside (or at least clearly labelled).
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Randy Brukardt]

CTips wrote:

> BTW: I was looking around - I couldn't find an Ada equivalent to the
> ISO C clock() routine. What is it? I can't believe that the Ada
> standard community would have been *that* oblivious to performance
> that they wouldn't put a performance measuring routine in the core
> specification.

As previously mentioned, it will be added to Ada 2005 (expected approval
this summer).

I believe that the reason that it didn't exist in previous versions of Ada
was that directly targeting bare machines was an intended implementation of
Ada. That is, the Ada RTS would provide the entire RTOS for the target,
including tasking, exceptions, and so on. In that case, providing a CPU time
function would have added overhead that may not have had any value to the
user (you would have to keep track of it on every task switch whether it was
used or not).

Similarly, a lot of systems didn't provide anything like that. For instance,
there wouldn't have been any portable way to do it on our MS-DOS compilers,
and we had a policy of not depending on the hardware configuration (because
that changed too frequently for us to keep up - we didn't want to be selling
products that only worked on real IBM PCs and a few clones).

Now, most Ada compilers target RTOSes rather than bare hardware boards, and
most OSes of any sort include performance info, so it makes more sense to
include it in the Standard.

                         Randy Brukardt

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

[Robert A Duff]

Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng
Subject: Re: Teaching new tricks to an old dog (C++ -->Ada)
References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110377260.350158.58730@z14g2000cwz.googlegroups.com> <hOJ6B0Xgm3Th@eisner.encompasserve.org> <wccu0ng6hie.fsf@shell01.TheWorld.com> <1136bh3li136dac@corp.supernews.com> <pan.2005.03.14.14.49.18.718254@linuxchip.demon.co.uk.uk.uk> <113bvkqbb8q0038@corp.supernews.com>
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Organization: The World Public Access UNIX, Brookline, MA
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Date: 14 Mar 2005 17:35:28 -0500
Message-ID: <wccsm2xn9e7.fsf@shell01.TheWorld.com>
Lines: 139
--text follows this line--
CTips <ctips@bestweb.net> writes:

> My knowledge of this is a little dated and hazy, so I could be wrong.
> 
> If we're doing something like:
>    foo()
>    {
>      int x, y;
>      bar()
>      {
>        int y;
>        gah()
>        {
>          use(x), use(y);
>         }
>       }
>     }
> 
> then, at run-time, in use(x), x comes from the stack-frame of the
> nearest invocation of foo() on the stack, and in use(y), y comes from
> the stack-frame of the nearest invocation of bar().

Right.  Note that multi-level nesting as in this example is rare in
languages that allow nesting.  (And of course nonexistent in languages
that don't!)  The vast majority of procedures are not nested (level 0),
some are nested (level 1), and extremely few are more nested (level 2 or
more).  So to implement this stuff efficiently, the compiler writer
should keep this in mind.

> There has to be a mechanism to identify the nearest invocation of
> foo()/bar(). There are, if I remember correctly, 4 mechanisms to find
> the invocation:
> - dynamic chaining: you just follow the back-chain pointers, stepping
> through all stack frames, till you come to the right stack frame.

I don't know of any compilers that do that.  To make that work, you'd
have to have some way to identify the "right" stack frame, and I can't
think of any way to do that efficiently.

> - static chianing: you maintain a separate chain (the static chain) that
> directly link to the stack frame of the enclosing functions. Thus the
> static chain for gah() would have the last invocation of bar() followed
> by the last invocation of foo().

That's the method I prefer.  The best way to think about it is: the
static link is an extra parameter passed to the called function.
Each nested function needs a parameter that somehow represents its
context.

Given that multi-level nesting is rare, the chain is usually length 1
(or we don't need to do anything at all, for the nonnested ones).

> - display: somewhat like the static chain, except its an array instead
> of a list

To me, that seems like an attempt to optimize multi-level nesting, which
is why I don't prefer it.

> - currying (?): this one I'm really hazy about, but, roughly, you passed
> pointers to the correct uplevel variables as extra arguments to the
> functions. Thus bar would be passed the pointer to x and gah would be
> passed pointers to x and y, as well as their other arguments, or
> something like that.

Yes, something like that makes sense; I view it as an optimization of
static chains.  It's not what I know as "currying", though, which is
something completely different.  In the example you gave, you can pass x
and y, not pointers to them.

> There were some additional nastinesses dealing with what happens when a
> nested function is passed as an argument

It's really no big deal.  When passing a nested procedure to an outer
one, you need to pass an extra parameter indicating the enclosing
context.  When using static chains, this is just the static link.
Or, in some cases, optimize by doing what you called "currying" above.
(Which is just like optimizing by passing the components of a struct
instead of passing a pointer to it.)

Note that Ada distinguishes (syntactically) the case where the passed
procedure can be nested, and the case where it cannot.  The case where
it cannot is handled exactly as in C -- pass just the address of the
procedure's code.

(Actually, that's an oversimplification -- the nonnested case is really
the same-nested case, which includes the C case of nonnested.)

Or, in many cases, inline the whole mess, and there's no call overhead
at all.

Yes, there is some cost -- it complexifies the compiler, for one thing.
But the run-time cost is really near zero.

By the way, there's another method you didn't mention.  The gcc dialect
of C supports nested functions (and passing those as parameters), and
they're implemented using trampolines.

> Depending on the techinques, you either pay whenever you access
> variables of enclosing functions, or you pay to maintain the
> data-structures [static-chain,display] which make this access cheaper,
> or both.

Right.  But in most cases, you pay nothing, and in the cases where you
pay, you're getting something for it (like, not having to pass extra
parameters, which you would have to pay for instead).

> On some implementations (on RISC architectures) a register is reserved
> for the static-chain. This means one less register for *every* function
> (or maybe only for enclosed functions?) when used with a language that
> support this kind of nested functions.

Only for nested functions.  And when passing functions as parameters, if
the function *might* be nested (which, in Ada, the compiler knows).

> C++ probably left it out because of its C heritage,

Yes.

>... while Ada probably
> dropped it in because of its Pascal heritage.

Perhaps, but it's not just Pascal.  It's pretty much every language from
Algol and Lisp onward.  This feature is really extremely useful!

>... IMHO, its probably not
> worth the cost.

Well, my philosophy is: the (run-time) cost is irrelevant.  If you need
some feature, you need it, and if it's not in the language, you have to
implement it yourself, and that will cost at least as much.  What's
relevant is distributed overhead: if you pay the cost for a feature when
you *don't* use a feature, then that's a good reason to leave it out of
the language.  IMHO, to argue against nested procedures, you have to
either argue that they're not very useful, or you have to argue that
they cause distributed overhead (cost when you don't need them).  You
can't just argue that they're slow, because the alternatives
(implemented by hand) are just as slow.

- Bob

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

> OK.  How about a trivial but reasonable example:
> 
> #include <time.h>
> #include <map>
> 
> struct interval {
>   tm start, finish;
> };
> 
> int main()
> {
>     std::map<interval, float> hash;
>     interval fred;
> 
>     //   set fred here!    
> 
>     hash[fred] = 0.123;
> }
> 
> No suitable place to put the compare operator!


I am not sure I understood what you are saying. First, map is not using 
hash, so the identifier hash may be misleading.

Secondly you can either specify an operator<, or a predicate like this:


#include <ctime>
#include <map>

struct interval
{
     std::tm start, finish;
};

struct IntervalLessCompare
{
     inline bool operator() (interval a, interval b) const
     {
         using namespace std;

         return difftime( mktime(&a.finish), mktime(&a.start) ) <
                       difftime( mktime(&b.finish), mktime(&b.start) );
     }
};

int main()
{
     using namespace std;

     map<interval, float, IntervalLessCompare> somemap;

     interval fred;

     //   set fred here!

     somemap[fred] = 0.123f;
}








-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Robert A Duff wrote:

>>However C++ has also the ideal to be able to write these libraries with
>>the language itself.
> 
> 
> As opposed to... ?


... other slimmer languages using "exotic" libraries.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Martin Dowie]

Greg Comeau wrote:
> In article <ath31d.1vm.ln@hunter.axlog.fr>,
> Jean-Pierre Rosen  <rosen@adalog.fr> wrote:
> 
>>Jerry Coffin a �crit :
>>
>>>Let's address the Ada side first. Official Ada validation was done
>>>under the auspices of NIST, who delegated this task to the Ada Joint
>>>Program Office. The AJPO ceased to exist years ago, and the job was
>>>never turned over to anybody else when that happened. Meanwhile, NIST
>>>has discontinued _all_ of its compiler validation programs, not just
>>>the Ada program. Currently, both the ISO standard at a number of FIPS
>>>pubs _require_ Ada compilers to be officially validated, but at least
>>>in the US, there is absolutely NO agency to do that.
>>>
>>
>>I can assure you that there is still one official ACAL (laboratory for 
>>performing validation): Adalog, that's my company!
>>
>>OK, it's not in the US. So what? Ada is an international standard.
> 
> 
> Other posts seems to disagree.  Please clarify for us.
> Also include how and why your company is the _official_ lab.
> (I'm not challenging you, but seems to me a mixed message
> is coming through this thread.)

Because the "Ada Compiler Assesment Authority" authorised it.

Some usefull links:
http://www.ada-auth.org/info.html
http://www.adaic.com/compilers/testing.html
http://www.adalog.fr/acal2.htm

Cheers

-- Martin

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

[Randy Brukardt]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:1110739276.774946.103020@z14g2000cwz.googlegroups.com...
...
> Let's address the Ada side first. Official Ada validation was done
> under the auspices of NIST, who delegated this task to the Ada Joint
> Program Office. The AJPO ceased to exist years ago, and the job was
> never turned over to anybody else when that happened.

This statement is false. I was going to try to explain precisely what
happened, but it probably is better to just point to the articles on that
topic that were published at the time. See:
    http://www.adaic.com/compilers/index.html
and in particular:
   http://www.adaic.com/compilers/acaa.html

The ARA funding of the ACAA continues today; the process is alive and well.
There has been a significant drop off in formal testing, supposedly because
customers aren't demanding it as much as they did in the past. (Personally,
I think that is a good thing, because it lets implementers concentrate on
what's important to their customers rather than formal testing -- even
though it means I make less money. It's also less necessary because all Ada
vendors run the test suite regularly as part of their in-house regression
tests -- there isn't anyone trying to get by without conforming.)

                       Randy Brukardt
                       ACAA Technical Agent

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

[Randy Brukardt]

"Greg Comeau" <comeau@panix.com> wrote in message
news:d14t70$ilm$1@panix1.panix.com...
> In article <ath31d.1vm.ln@hunter.axlog.fr>,
...> >
I can assure you that there is still one official ACAL (laboratory for
> >performing validation): Adalog, that's my company!
> >
> >OK, it's not in the US. So what? Ada is an international standard.
>
> Other posts seems to disagree.  Please clarify for us.
> Also include how and why your company is the _official_ lab.
> (I'm not challenging you, but seems to me a mixed message
> is coming through this thread.)

See the links I posted earlier. The ACAA is an instantiation of ISO 18009
funded by the Ada Resource Association. AdaLog is an accredited ACAL under
ISO 18009.

Note that AJPO transferred pretty much all of its programs and materials to
the ARA, including its website (www.adaic.org), validation testing,
marketing programs, and so on. Anyway, it seemed better to put "conformity
assessment" under an International Standard rather than a program managed by
a specific country.

                          Randy Brukardt

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

[Robert A Duff]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Robert A Duff wrote:
> 
> >>However C++ has also the ideal to be able to write these libraries with
> >>the language itself.
> > As opposed to... ?
> 
> 
> ... other slimmer languages using "exotic" libraries.

Such as... ?

I'm still not understanding your point.  Are you referring to the fact
that the Java garbage collector cannot reasonably be implemented in
Java, and things like that?

- Bob

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

[Hyman Rosen]

Dr. Adrian Wrigley wrote:
> Even in simple cases, the encapsulation has to be broken

Free functions that help implement an abstraction don't break
encapsulation, they are part of it.

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

[Ioannis Vranos]

Robert A Duff wrote:

> Such as... ?
> 
> I'm still not understanding your point.  Are you referring to the fact
> that the Java garbage collector cannot reasonably be implemented in
> Java, and things like that?


Apart from these, let's talk about Pascal for example. I do not think 
everything in its library can be written with the language itself.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Hyman Rosen]

Robert A Duff wrote:
> Because the "<" (or Hash) needs to know the internals of the thing.

It may be possible to order the objects through information
available from public accessors, so this is false.

> In other words, at the point where you declare a type, you have to think
> ahead: this type might want to live inside one of those containers, so
> I'd better define the necessary operations.

False, as per above. In fact, the ordered containers can be instantiated
with order functions, so there need not be a single unique ordering for
a given type.

For example, any string type has a public way of delivering up the
characters it contains. That lets you define string containers which
hold their strings in alphabetical order, in case-insensitive order,
or even in pig-latin order if you want. None of this requires the
string implementor to anticipate such ordering requirements.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Hyman Rosen]

Dr. Adrian Wrigley wrote:
> This means that you can't write an implementation of a template/generic
> function using a map/hash without changing some/all the implementations
> and interfaces up the instantiation tree (am I right?).

No, you are wrong. Simply write your comparison or hash function at the
point where you need it. Use the public accessors to get the data you
need to perform the operations.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
> > Because the "<" (or Hash) needs to know the internals of the thing.
> 
> It may be possible to order the objects through information
> available from public accessors, so this is false.

OK, please let me amend my statement to "...*usually* needs to know...".

So "this is false" should be "this is sometimes false".

> > In other words, at the point where you declare a type, you have to think
> > ahead: this type might want to live inside one of those containers, so
> > I'd better define the necessary operations.
> 
> False, as per above. In fact, the ordered containers can be instantiated
> with order functions, so there need not be a single unique ordering for
> a given type.
> 
> For example, any string type has a public way of delivering up the
> characters it contains. That lets you define string containers which
> hold their strings in alphabetical order, in case-insensitive order,
> or even in pig-latin order if you want. None of this requires the
> string implementor to anticipate such ordering requirements.

Yes, if the thing has a natural "<" function, or some public information
from which that can be garnered, then "<" is not a problem.  That's true
of character strings.  And of course I understand that you can sort
backwards by using a different function (as in "<" => ">" in Ada
terms). 

But if you want to hide most of the data of some abstraction, and
there's no "natural" meaning of "<", then you have to think ahead, and
define some "<" operation just in case somebody wants to put the thing
into a container.  (Or, of course, go back and add that in to an
existing data type when you find it's needed.)

The same is true with Hash.  For a character string type, you can
declare it on the fly, because such a type exposes all the data.  But
for a type that's "private" in Ada, or has protected/private members in
C++, the Hash function, like the "<" function, often needs access to the
private data.  In Ada, you can use a child (which does not require
modifying the original thing).  In C++, you can use a friend.  Or, in
either language, you can just put Hash or "<" in the original thing.

One possibility is to have a coding convention: always declare "<" and
Hash for every data type, just in case it might be needed for one of
these containers.

- Bob

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Tue, 15 Mar 2005 00:47:37 +0200, Ioannis Vranos wrote:

> struct IntervalLessCompare
> {
>      inline bool operator() (interval a, interval b) const
>      {
>          using namespace std;
> 
>          return difftime( mktime(&a.finish), mktime(&a.start) ) <
>                        difftime( mktime(&b.finish), mktime(&b.start) );
>      }
> };

Doesn't this break down for times beyond the end of the epoch,
which are valid tm values, but invalid time_t values?
You've ended up mapping all post-epoch times to the same entry!

Doesn't it also break down when someone adds a microsecond
value in the tm struct for some platforms?  Seems like
a reasonable thing for someone to try to do, but breaks this
code.  You have to then introduce a platform specific fix.
Maybe unlikely for ctime, but there are plenty of less stable
interfaces.  What if it was mm.h's mem_core struct (Linux)?
What about things with floating point components, where
different values compare as equal (+0 and -0) and
identical values (NaN) give inconsistent comparison?

In general, you may need to use "private" implementation details
of the class when defining the operator, ending up with
broken code, broken "contracts" and broken encapsulation.

This is sounding too much like a troll, and I think the points
have been fully made by Robert and others.  I have learnt that
there is a major gulf between users' expectations of C++ templates
and of Ada generics. "contract model" is the difference.
-- 
Adrian

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 23:46:33 +0000, Hyman Rosen wrote:

> Dr. Adrian Wrigley wrote:
>> This means that you can't write an implementation of a template/generic
>> function using a map/hash without changing some/all the implementations
>> and interfaces up the instantiation tree (am I right?).
> 
> No, you are wrong. Simply write your comparison or hash function at the
> point where you need it. Use the public accessors to get the data you
> need to perform the operations.

That's the point... there aren't any public accessor functions
for opaque data types such as non-limited generic formal parameters.
-- 
Adrian

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

[Robert A Duff]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Robert A Duff wrote:
> 
> > Such as... ?
> > I'm still not understanding your point.  Are you referring to the fact
> > that the Java garbage collector cannot reasonably be implemented in
> > Java, and things like that?
> 
> Apart from these, let's talk about Pascal for example. I do not think
> everything in its library can be written with the language itself.

Pascal (as defined by Wirth) doesn't even support separate compilation,
so there is no concept of libraries in Pascal, so nothing in its
"libraries" can be written in Pascal.

- Bob

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

[Ioannis Vranos]

Robert A Duff wrote:

> Pascal (as defined by Wirth) doesn't even support separate compilation,
> so there is no concept of libraries in Pascal, so nothing in its
> "libraries" can be written in Pascal.


Actually I had turbo pascal 6.x-7.x in mind.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Larry Kilgallen]

In article <113bvkqbb8q0038@corp.supernews.com>, CTips <ctips@bestweb.net> writes:

> On some implementations (on RISC architectures) a register is reserved 
> for the static-chain. This means one less register for *every* function 
> (or maybe only for enclosed functions?) when used with a language that 
> support this kind of nested functions.

It does not have much to do with whether one language supports it,
so long as _some_ language supports it.

If I have a call chain:

	Ada => C => Ada

that second Ada subprogram might want to access a variable in the first
Ada subprogram.  So the C implementation must pass the context along.
As I understand it, that is the job of the "Bound Procedure Value"
construct in the VMS Calling Standard.  Such relationships between
languages must be defined by the calling standard for the platform,
meaning that the C compiler should honor it as well.  I imagine that
HP Ada and HP Pascal interact properly in this regard -- I have no idea
about HP C.

> C++ probably left it out because of its C heritage, while Ada probably 
> dropped it in because of its Pascal heritage. IMHO, its probably not 
> worth the cost.

If that is your opinion, I would say you have not done enough programing
in a language where it is provided.

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

[Larry Kilgallen]

In article <1110843401.905302@athnrd02>, Ioannis Vranos <ivr@remove.this.grad.com> writes:
> Robert A Duff wrote:
> 
>> Such as... ?
>> 
>> I'm still not understanding your point.  Are you referring to the fact
>> that the Java garbage collector cannot reasonably be implemented in
>> Java, and things like that?
> 
> 
> Apart from these, let's talk about Pascal for example. I do not think 
> everything in its library can be written with the language itself.

Presuming that by "Pascal" you mean something meeting the "Extended Pascal"
standard rather than the Wirth original,

not a library, but...

When DEC implemented their A1 security kernel they did so in VAX Pascal
(to support provability) and required that the whole thing be written
in Pascal rather than using a runtime library written in some other
language.

==========

They cancelled the project during Field Test when they figured out that
those in the US government who wanted to see A1 systems were entirely
different from those in the US government who actually purchase systems.

I believe, in fact, those rooting most strongly for Multilevel Security
actually run "system high" in their own shops.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Robert A Duff wrote:
> CTips <ctips@bestweb.net> writes:
> 
> 
>>Gautier wrote:
>>
>>>CTips:
>>>
>>>
>>>>He's done it right:
>>>> - he's running them on a Linux machine, which is more accurate than
>>>>cygwin for measuring performance (and where sys/user really mean
>>>>something).
> 
> 
> Why is that?  When I use cygwin, the sys/user times indeed seem
> completely bogus.  Are these impossible to measure on windows?  If that
> were true, why wouldn't it always print 0 or something?  The cygwin
> 'time' command is obviously trying to measure *something* with these
> numbers.
> 
> - Bob
Probably eventually calls GetProcesTimes from the Windows kernel.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[CTips]

Randy Brukardt wrote:

> CTips wrote:
> 
> 
>>BTW: I was looking around - I couldn't find an Ada equivalent to the
>>ISO C clock() routine. What is it? I can't believe that the Ada
>>standard community would have been *that* oblivious to performance
>>that they wouldn't put a performance measuring routine in the core
>>specification.
> 
> 
> As previously mentioned, it will be added to Ada 2005 (expected approval
> this summer).
> 
> I believe that the reason that it didn't exist in previous versions of Ada
> was that directly targeting bare machines was an intended implementation of
> Ada. That is, the Ada RTS would provide the entire RTOS for the target,
> including tasking, exceptions, and so on. In that case, providing a CPU time
> function would have added overhead that may not have had any value to the
> user (you would have to keep track of it on every task switch whether it was
> used or not).

How about the ANSI C solution: clock() must be defined, but can always 
return -1 if the service is not available. Isn't that a better way?

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ed Falis]

On 14 Mar 2005 19:00:00 -0500, Robert A Duff  
<bobduff@shell01.TheWorld.com> wrote:

> But if you want to hide most of the data of some abstraction, and
> there's no "natural" meaning of "<", then you have to think ahead, and
> define some "<" operation just in case somebody wants to put the thing
> into a container.  (Or, of course, go back and add that in to an
> existing data type when you find it's needed.)

Bertrand Meyer went pretty heavily into this situation with his  
"open-closed" principle in Eiffel - largely why he's a big fan of multiple  
inheritance.  This in a sense follows your paranthetical remark.

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

[Jerry Coffin]

Randy Brukardt wrote:

[ ... ]

> This statement is false. I was going to try to explain precisely what
> happened, but it probably is better to just point to the articles on
that
> topic that were published at the time. See:
>     http://www.adaic.com/compilers/index.html
> and in particular:
>    http://www.adaic.com/compilers/acaa.html

I see it, but I also see things like this:

----- quote -----
Q. What about NIST? Isn't Ada still a FIPS standard, with requirements
for NIST validation?

A. FIPS 119-1 is still valid, and section 11.4 states that
"Implementations of FIPS Ada shall be validated in accordance with the
NIST Computer Systems Laboratory (CSL) validation procedures for FIPS
Ada". However, such validation procedures no longer exist, since NIST
had delegated Ada validation authority to AJPO, and AJPO did not
re-delegate this authority.
--- end quote ---

(from: http://sw-eng.falls-church.va.us/ajpofaq.html) which seems to
agree reasonably closely with what I said. Some of it appears to be
obsolete -- FIPS pub 119-1 is NOT valid anymore; it has been withdrawn.
That has little to do with events that happened years ago though.

I'd also note that the relationship between the ACAA and the ISO seems
to be rather one-sided -- while you emphasize your relationship with
the ISO rather heavily on your web site, the ISO seems to mention you
rather a bit less -- a search for "ACAA" on the ISO web site more or
less implies that they've never even heard of you.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Randy Brukardt]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:1110858931.523773.124170@z14g2000cwz.googlegroups.com...
> Randy Brukardt wrote:
...
> I see it, but I also see things like this:
<Misleading junk snipped>
...
> (from: http://sw-eng.falls-church.va.us/ajpofaq.html) which seems to
> agree reasonably closely with what I said.

Ah, yes, the imfamous "Ada is dead site". (It doesn't say that anymore, but
it once did.) That site was created by someone how posted all kinds of
misinformation; people seem to believe it because they registered the old
AJPO domain name. Of course, anyone can post anything on the net, and it can
be hard to tell what's accurate and what isn't.

> I'd also note that the relationship between the ACAA and the ISO seems
> to be rather one-sided -- while you emphasize your relationship with
> the ISO rather heavily on your web site, the ISO seems to mention you
> rather a bit less -- a search for "ACAA" on the ISO web site more or
> less implies that they've never even heard of you.

Since the ACAA is defined in an ISO standard (specifically ISO/IEC 18009),
and ISO makes money by *selling* their standards, you're hardly going to
find anything there. I don't think you can find much about Ada there,
either. The ACAA I run is an instantiation of that described by that
standard.

You might be able to find out more on the WG9 web site (WG9 is the Ada
Working Group within ISO/IEC JTC1 SC22), but it is pretty sparse:
    http://www.open-std.org/JTC1/SC22/WG9/

                         Randy.

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Randy Brukardt]

"CTips" <ctips@bestweb.net> wrote in message
news:113cfqv380t2dc7@corp.supernews.com...
> Randy Brukardt wrote:
...
> > As previously mentioned, it will be added to Ada 2005 (expected approval
> > this summer).
> >
> > I believe that the reason that it didn't exist in previous versions of
Ada
> > was that directly targeting bare machines was an intended implementation
of
> > Ada. That is, the Ada RTS would provide the entire RTOS for the target,
> > including tasking, exceptions, and so on. In that case, providing a CPU
time
> > function would have added overhead that may not have had any value to
the
> > user (you would have to keep track of it on every task switch whether it
was
> > used or not).
>
> How about the ANSI C solution: clock() must be defined, but can always
> return -1 if the service is not available. Isn't that a better way?

Well, in Ada it would raise an exception, not return some answer that could
be mistaken for an actual result. And indeed there are plenty of things that
work that way, like I/O and the command line. But time functions are not
that way; every Ada implementation is expected to have them. I presume that
they were considered fundamental.

That seems to be the case for the new execution-time functions as well.
Since they're in the real-time annex, they only have to be provided for
implementations that implement that annex. So implementations running in
non-real-time environments (like Windows) don't necessarily have to provide
these functions.

Anyway, I don't know as a fact why there wasn't any such functions in the
past; I don't recall them having been suggested during the Ada 9X project
(which eventually lead to Ada 95), and I wasn't involved in the definition
of Ada 83. So it's possible that they simply never were in the requirements.
Perhaps no one ever thought to individually time parts of tasks. (I've
generally benchmarked complete systems, so the wall time from start to
finish is the most interesting, as all of the components of the program,
including the OS calls and tasking overhead, contribute.) I've given my best
guess, but it's just a guess.

                       Randy.

Re: 10 rules for benchmarking

[Vinzent 'Gadget' Hoefler]

CTips wrote:

> BTW: I was looking around - I couldn't find an Ada equivalent to the
> ISO C clock() routine.

That's because Ada programs usually need real time, not fake time
clocks.


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Tue, 15 Mar 2005 00:10:27 GMT, Dr. Adrian Wrigley wrote:

> On Mon, 14 Mar 2005 23:46:33 +0000, Hyman Rosen wrote:
> 
>> Dr. Adrian Wrigley wrote:
>>> This means that you can't write an implementation of a template/generic
>>> function using a map/hash without changing some/all the implementations
>>> and interfaces up the instantiation tree (am I right?).
>> 
>> No, you are wrong. Simply write your comparison or hash function at the
>> point where you need it. Use the public accessors to get the data you
>> need to perform the operations.
> 
> That's the point... there aren't any public accessor functions
> for opaque data types such as non-limited generic formal parameters.

Then the data are inherently non-sortable. That was designer's decision,
and that is *the* contract. To define "<" would mean to break that
contract.

There are lot of situations where some ad-hoc generated comparison will not
work. Especially if objects are in fact handles to something that may
change asynchronously to the container.

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On 14 Mar 2005 16:02:43 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> It can be formulated in two words: "contract model" is what C++ templates
>> lack.
> 
> Which is both a benefit and a drawback.  C++ templates are somewhat more
> powerful that Ada generics, because of the lack of contract model, and
> implicit instantiation.

I think that the reason is not contracts but inflexible contracts. Ada
formal generic parameters are not ADTs. So there is no way to define a
formal generic type Ordered. Instead of that ADTs are defined ad-hoc:

generic
   type Foo is private;
   function "<" (Left, Right : Foo) return Boolean is <>;
package ...

What is worse is that these ad-hoc ADTs are not named, so in fact it is a
kind of that flawed structural type equivalence reborn.

> But I don't think that addresses Dr. Wrigley's complaint (which applies
> to both Ada and C++).

Indirectly it does, because what he wants is to get more that is in the
contract ... (:-))

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

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

[Jean-Pierre Rosen]

Greg Comeau a �crit :
> Other posts seems to disagree.  
I don't see how they could disagree with the mere fact that Adalog is a 
registered ACAL, but anyway...

> Please clarify for us.
> Also include how and why your company is the _official_ lab.
> (I'm not challenging you, but seems to me a mixed message
> is coming through this thread.)
The ACAA (see Randy's posts) is the official office for issuing 
conformance certificates. These certificates are issued after 
conformance testing has been performed by an ACAA approved laboratory, 
called and ACAL. Adalog has been approved by ACAA, and this is easily 
checked by going to the ACAA site!

People arguing that there is no more validation office are simply wrong, 
and I hope it is misinformation and not malice.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
 
> I think that the reason is not contracts but inflexible contracts. Ada
> formal generic parameters are not ADTs. So there is no way to define a
> formal generic type Ordered.

Hm. Do you mean, a contract type cannot be _defined_ in the
generic formal part of a unit?
Otherwise, why not just write

generic
   type Ordered is new Has_Less_Than with private;
package ...

where Has_Less_Than is an abstract type with a "<" operation.

(Or use multiple interfaces and Ada 2005.)

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

[Hans Malherbe]

Dr. Adrian Wrigley wrote:
>That's the point... there aren't any public accessor
>functions

It's a good point. If you design a library you not only have to decide
up front whether you want to let users put your class in ordered
containers but whether you want to allow containers at all (Generic
algorithms freely make copies of elements and assume value semantics).

I have to ask myself though: If I am denied access to information that
lets me  implement a < operator, am I supposed to be able to sort it?

Groete
Hans

Magic ordering

[Marius Amado Alves]

(Sorry I changed the subject. I'm just that kind of guy :-)

On 15 Mar 2005, at 12:01, Hans Malherbe wrote:

> I have to ask myself though: If I am denied access to information that
> lets me  implement a < operator, am I supposed to be able to sort it?

This is one of my favourites. There's always a way. Bit by bit 
comparison, an arbitrary index, 'Address comparison...

I'm the guilty part for Ada.Containers supplying a default hash 
function for some types (Strings I think). I also fought for a magic 
ordering function, and to extend both to all types, or at least to a 
vaster class, but I lost.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Tue, 15 Mar 2005 11:51:33 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>  
>> I think that the reason is not contracts but inflexible contracts. Ada
>> formal generic parameters are not ADTs. So there is no way to define a
>> formal generic type Ordered.
> 
> Hm. Do you mean, a contract type cannot be _defined_ in the
> generic formal part of a unit?
> Otherwise, why not just write
> 
> generic
>    type Ordered is new Has_Less_Than with private;
> package ...
> 
> where Has_Less_Than is an abstract type with a "<" operation.

In which case it simple does not need to be generic! Ordered here is a
normal ADT, which class is Has_Less_Than'Class. So the package should work
directly with the class and be non-generic. End of story.

What I meant was:

generic
   type Ordered is Has_Less_Than; -- This is not Ada!
package ...

Here Has_Less_Than is not a type but a [generic] class of types, like
"private", "limited private", "range <>", etc. It is almost same but not
the same. This is actually why I strongly believe that generics are
superfluous and should be replaced by better ADTs (now normal ones, one
storey below). In other words there is no need to make a fuss with types
ADT (=classes of formal generic types) when we are far from being ready
with the normal ones!

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Tue, 15 Mar 2005 11:51:33 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>  
>> I think that the reason is not contracts but inflexible contracts. Ada
>> formal generic parameters are not ADTs. So there is no way to define a
>> formal generic type Ordered.
> 
> Hm. Do you mean, a contract type cannot be _defined_ in the
> generic formal part of a unit?
> Otherwise, why not just write
> 
> generic
>    type Ordered is new Has_Less_Than with private;
> package ...
> 
> where Has_Less_Than is an abstract type with a "<" operation.
> 
> (Or use multiple interfaces and Ada 2005.)

isn't this where (in Ada 95) you would use a package formal
generic parameter?

   generic
      type Ordered is private;
      with function Hash (X : Ordered) return Hash_T;
      with function "<" (X, Y : Ordered) return Boolean;
      with function "=" (X, Y : Ordered) return Boolean;
-- other things go here
   package OrderedHashable is
   end OrderedHashable;

   generic
      with package Useful is new OrderedHashable (<>);
   package Blob is
-- ...
   end;

Does this not meet the contract flexibility needed, and is basically
a format generic ADT parameter?

I haven't looked at Ada 2005 interfaces yet, but I assume they
give more power and/or convenience than this.

When I come to "translate" this into C++, I am completely stumped!
The best I have come up with is adding lines like:

    __glibcpp_class_requires(_Tp, _SGIAssignableConcept)
    __glibcpp_class_requires4(_Compare, bool, _Key, _Key, _BinaryFunctionConcept)

to the template class!

Of course I am not trying to write Ada in C++(!), but it does mean
that skills developed in generics don't directly apply to template classes
and vice-versa.
-- 
Adrian

Re: Magic ordering

[Dmitry A. Kazakov]

On Tue, 15 Mar 2005 12:54:30 +0000, Marius Amado Alves wrote:

> (Sorry I changed the subject. I'm just that kind of guy :-)
> 
> On 15 Mar 2005, at 12:01, Hans Malherbe wrote:
> 
>> I have to ask myself though: If I am denied access to information that
>> lets me  implement a < operator, am I supposed to be able to sort it?
> 
> This is one of my favourites. There's always a way. Bit by bit 
> comparison, an arbitrary index, 'Address comparison...

All of which might appear wrong. The objects might be non-contiguous, have
replicas etc.

Comparison should reflect the semantics of compared things. There is no
universal way to do it.

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

Re: Magic ordering

[Marius Amado Alves]

On 15 Mar 2005, at 13:16, Dmitry A. Kazakov wrote:
>>> ... If I am denied access to information that
>>> lets me  implement a < operator, am I supposed to be able to sort it?
>>
>> This is one of my favourites. There's always a way. Bit by bit
>> comparison, an arbitrary index, 'Address comparison...
>
> All of which might appear wrong. The objects might be non-contiguous, 
> have
> replicas etc.

Note that you *know* they are non-contiguous, have replicas, etc. then 
you *have* the required information.

> Comparison should reflect the semantics of compared things.

If you mean *deep* semantics, then not necessarily. I've come across 
many situations where the order does not (need to) reflect it. A 
strictly algebraic order is enough. For example ordering a set of 
integers for search (e.g. in an Ada.Containers.Ordered_Set). The deep 
meaning of the integers does not matter. They can be SS numbers, or IP 
addresses, or the height of people. However you can still get something 
useful from the container, e.g. "is it there?"

> There is no universal way to do it.

I don't claim there is an "universal" way, but that there is always one.

Ok, maybe theoretically any usable information may be missing. But in 
practice this is an anomalous situation. If you need an order for some 
type, then certainly you have same usable information. Either the 
(deep) meaning of the type, or some structural property, or some 
reliable representation. If all these are missing, and you still need 
an order, the design must be at fault.

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

[Jerry Coffin]

Randy Brukardt wrote:

[ ... ]

> Ah, yes, the imfamous "Ada is dead site". (It doesn't say that
> anymore, but it once did.) That site was created by someone
> how posted all kinds of misinformation; people seem to believe
> it because they registered the old AJPO domain name. Of course,
> anyone can post anything on the net, and it can be hard to tell
> what's accurate and what isn't.

I agree that there's a lot of misinformation around, and sometimes it's
difficult to sort out what's real and what isn't. Fortunately, the US
Gov't makes this one easy to sort out.

Since NIST is and the AJPO was run by the US gov't, an official action
such as turning the testing responsibilities over to somebody else
would have to be recorded in the US federal register. Since you're
claiming it happened, please be so kind as to tell us the volume and
page number in the federal register where it's recorded -- I did a
search at:

http://www.gpoaccess.gov/fr/index.html

and couldn't turn anything up recording the action you allege to have
taken place.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Magic ordering

[Dmitry A. Kazakov]

On Tue, 15 Mar 2005 13:53:50 +0000, Marius Amado Alves wrote:

> On 15 Mar 2005, at 13:16, Dmitry A. Kazakov wrote:
>>>> ... If I am denied access to information that
>>>> lets me  implement a < operator, am I supposed to be able to sort it?
>>>
>>> This is one of my favourites. There's always a way. Bit by bit
>>> comparison, an arbitrary index, 'Address comparison...
>>
>> All of which might appear wrong. The objects might be non-contiguous, 
>> have replicas etc.
> 
> Note that you *know* they are non-contiguous, have replicas, etc. then 
> you *have* the required information.

1. to know "<" is much cheaper than the above

2. with the above it is still a halting problem

The idea of contracts is exactly to avoid such semantic pitfalls. My part
of the contract is to tell you that the thing is ordered, yours is to
implement sorting.

>> Comparison should reflect the semantics of compared things.
> 
> If you mean *deep* semantics, then not necessarily. I've come across 
> many situations where the order does not (need to) reflect it.
> A strictly algebraic order is enough. For example ordering a set of 
> integers for search (e.g. in an Ada.Containers.Ordered_Set). The deep 
> meaning of the integers does not matter. They can be SS numbers, or IP 
> addresses, or the height of people. However you can still get something 
> useful from the container, e.g. "is it there?"

There could be many orders defined on the same objects, as Hyman rightfully
pointed out. But any of them have to be published in the contract. There is
nothing outside the contract.

>> There is no universal way to do it.
> 
> I don't claim there is an "universal" way, but that there is always one.
> 
> Ok, maybe theoretically any usable information may be missing. But in 
> practice this is an anomalous situation. If you need an order for some 
> type, then certainly you have same usable information. Either the 
> (deep) meaning of the type, or some structural property, or some 
> reliable representation. If all these are missing, and you still need 
> an order, the design must be at fault.

Yes it is a design fault not to provide "<" where it exists. When you
define one at the place of instantiation, you in fact create a subtype of
the type with an extended contract containing "<". 

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

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

[Martin Krischik]

kevin  cline wrote:

> 
> Martin Krischik wrote:
> 
>> Shure it is true: The C++ ISO standard has ruffly 200 pages more then
> the
>> Ada ISO standard. The C standard is a few pages shorter - but C
> hasn't got
>> object orientation, concurency, real time and distributed system
> included.
> 
> No surprise there.  The C++ standard covers the C++ standard library.

As Ada has an Ada standart library and indeed C has an C standard library
which are all part of the ISO standarts in question.

>> But prove me wrong and show me any successful slim language - which
> has not
>> become fat (either by language or by build in library) withing 10
> years of
>> becomming successfull.

> Personally I prefer slimmer languages and fatter libraries whenever
> possible.

As lot of people do. I rather prefer explicid feature - not matter if
language or library. What *I* don't like are implicid features. Example:
Most C/C++ compiler I know of have a compiler option for "ANSI aliasing
only" - I usualy activate is since I avoid aliasing anyway but do I realy
know what it means. *NO* - about 2 meters away is it C ISO standart - I
could read it up - but I don't because all I would get is a headache if I
tried too.

With Regards

Martin

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

Re: Magic ordering

[Marius Amado Alves]

On 15 Mar 2005, at 15:08, Dmitry A. Kazakov wrote:
> There could be many orders defined on the same objects, as Hyman 
> rightfully
> pointed out. But any of them have to be published in the contract. 
> There is
> nothing outside the contract.

There may be multiple contracts overlapping, or even disjoint, 
associated with the same type. That's how most systems are constructed. 
For example a part of the program gives you a contract for the deep 
meaning e.g. retrieve the person's name given the SS number. Another 
part is a contract that ascertains if the number is in a given set. 
They overlap. The latter does not need the name. The former does not 
need the set. I know this design is not an OO pearl, but it works, 
there's nothing wrong with it, and is present in most systems I've seen 
or built.

On the (non-OO) extreme of this theory, there are no objects, just 
operations, a subset of which constitute each contract (well, each 
interface). I've been using formal packages a lot lately as an 
approximation of this.

But we diverted very quickly from the mainline, creating an order for a 
type. As I said, I believe there's always a way: but it must be done 
case by case. Show me your type, and I'll show you a way. If there's no 
way I'll ask you: why do you want to order this type? If you show a 
good reason, I'll (hopefully) be able to identify the design fault.

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

[kevin cline]

Martin Krischik wrote:
> kevin  cline wrote:
>
> >
> > Martin Krischik wrote:
> >
> >> Shure it is true: The C++ ISO standard has ruffly 200 pages more
then
> > the
> >> Ada ISO standard. The C standard is a few pages shorter - but C
> > hasn't got
> >> object orientation, concurency, real time and distributed system
> > included.
> >
> > No surprise there.  The C++ standard covers the C++ standard
library.
>
> As Ada has an Ada standart library and indeed C has an C standard
library
> which are all part of the ISO standarts in question.

True, but the C++ standard library is much more extensive than the Ada
standard library.  There's nothing in the Ada standard that compares
with the C++ standard template library.

Re: Magic ordering

[Dmitry A. Kazakov]

On Tue, 15 Mar 2005 16:21:25 +0000, Marius Amado Alves wrote:

> On 15 Mar 2005, at 15:08, Dmitry A. Kazakov wrote:
>> There could be many orders defined on the same objects, as Hyman 
>> rightfully pointed out. But any of them have to be published in the contract. 
>> There is nothing outside the contract.
> 
> There may be multiple contracts overlapping, or even disjoint, 
> associated with the same type.

I would say that are subtypes of the type.

> That's how most systems are constructed. 
> For example a part of the program gives you a contract for the deep 
> meaning e.g. retrieve the person's name given the SS number. Another 
> part is a contract that ascertains if the number is in a given set. 
> They overlap. The latter does not need the name. The former does not 
> need the set. I know this design is not an OO pearl, but it works, 
> there's nothing wrong with it, and is present in most systems I've seen 
> or built.

This is how Ada generics work. When instantiated you can reroute operations
to satisfy the contract. It is also possible to do with tagged types, no
wrappers needed:

type X is tagged null record;
function "<" (Left : X; Right : X'Class) return Boolean;
function ">" (Left : X; Right : X'Class) return Boolean;

type Y is new X with null record; -- Swap "<" and ">"
function Less (Left : Y; Right : X'Class) return Boolean renames "<";
function Greater (Left : Y; Right : X'Class) return Boolean renames ">";
function "<" (Left : Y; Right : X'Class) return Boolean renames Greater;
function ">" (Left : Y; Right : X'Class) return Boolean renames Less;

> On the (non-OO) extreme of this theory, there are no objects, just 
> operations, a subset of which constitute each contract (well, each 
> interface). I've been using formal packages a lot lately as an 
> approximation of this.

But that's the same. Whether it be stated or deduced contract, there is
one. The only difference is that the latter cannot be efficiently evaluated
neither by the compiler nor by the programmer.

> But we diverted very quickly from the mainline, creating an order for a 
> type. As I said, I believe there's always a way: but it must be done 
> case by case. Show me your type, and I'll show you a way. If there's no 
> way I'll ask you: why do you want to order this type? If you show a 
> good reason, I'll (hopefully) be able to identify the design fault.

OK but it is responsibility of the type designer to provide you with a
comparison.

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

C: [] vs * (was: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada)))

[Programmer Dude]

Arthur J. O'Dwyer writes:

> I think regardless of CTips' and Jim's points in this thread, the original
> code serves as an excellent argument against using [] in function headers;
> the extra "documentation" is more than offset by the decline in 
> readability, as far as I'm concerned.

Just as another datapoint, I feel exactly the opposite.  I much prefer
the [] notation to signify that the pointer refers to more than one of
whatever it's pointing at.

Nowadays, most of my "C" code is C++, so if I pass a "pointer" to a
single object (object in the C sense (or C++ sense, FTM)) now I'd use
a reference.  But in my C days, foo(int* pi) meant a pointer to a single
int, whereas bar(int ai[]) is (a pointer to) an array of ints.


>> Treating the address of any int
>> as the beginning of an array is a formula for buffer
>> overflow, as is demonstrated in this example.
> 
>    This example does not appear to contain any buffer oveflow.
> If you think it does, please point it out to me.  I may have
> missed something.

Maybe not in this example, but let's be fair.  He said that treating
the address of *any* int is problematic.  And it is.  C cannot be
called a "safe" language.  Safety must be imposed by the programmer.

C in the hands of the less expert programmer is *dangerous* as any
number of virii, trojans and worms have clearly demonstrated.  So
is C++, albeit maybe slightly less so (OTOH, its complexity makes it
problematic for non-experts in other areas).

If anything, I think it's better to acknowledge the dangers of any
tool rather than downplay them.  One of the reasons skydiving kills
fewer participants (percentage wise) than SCUBA is that there's no
misapprehension in anyone's mind that jumping out of an airplane is
*extremely* dangerous.  SCUBA is just swimming.

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

[Martin Dowie]

kevin cline wrote:
> True, but the C++ standard library is much more extensive than the Ada
> standard library.  There's nothing in the Ada standard that compares
> with the C++ standard template library.

Perhaps not quite as extensive (esp. in the algorithm section) but there 
are, from memory, 12 new container types (inc. Vectors, Maps, Sets, 
Lists) coming in Ada2005 and there are reference implementations out for 
all of them right now.

The hope is to use the ISO "IWA" process to expand on this. It wouldn't 
make anything an official part of the standard but it could lead to a 
'de facto' supplimentary standard.

Cheers

-- Martin

Re: C: [] vs * (was: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada)))

[Arthur J. O'Dwyer]

On Tue, 15 Mar 2005, Programmer Dude wrote:
> Arthur J. O'Dwyer writes:
>
>> I think regardless of CTips' and Jim's points in this thread, the original
>> code serves as an excellent argument against using [] in function headers;
>> the extra "documentation" is more than offset by the decline in
>> readability, as far as I'm concerned.
>
> Just as another datapoint, I feel exactly the opposite.  I much prefer
> the [] notation to signify that the pointer refers to more than one of
> whatever it's pointing at.
>
> Nowadays, most of my "C" code is C++, so if I pass a "pointer" to a
> single object (object in the C sense (or C++ sense, FTM)) now I'd use
> a reference.  But in my C days, foo(int* pi) meant a pointer to a single
> int, whereas bar(int ai[]) is (a pointer to) an array of ints.

   I agree that that's the implicit "semantics" of [] versus *; I just
find bar(int ai[]), with all those vertical things clustered so close
together, to be much harder on the eyes --- and that's a bigger negative
for me than the implicit "Look, an array!" semantics is a positive.
   Maybe that was clear the first time around; I just want to make sure
we're on the same page.

>>> Treating the address of any int
>>> as the beginning of an array is a formula for buffer
>>> overflow, as is demonstrated in this example.
>>
>>    This example does not appear to contain any buffer oveflow.
>> If you think it does, please point it out to me.  I may have
>> missed something.
>
> Maybe not in this example, but let's be fair.  He said that treating
> the address of *any* int is problematic.  And it is.  C cannot be
> called a "safe" language.  Safety must be imposed by the programmer.

   Sure.  But Jim said, "as is demonstrated in this example."  That's
like saying, "Jumping a motorcycle across a canyon is dangerous 
because you could fall to your death, as demonstrated by Evel 
Knievel."[1]

-Arthur,
daredevil

[1] - (who has /not/ fallen to his death, as of this posting, which
shows why Jim's statement IMO was either misleading or indicative of
a misapprehension)

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

[Randy Brukardt]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:1110895220.422372.189820@l41g2000cwc.googlegroups.com...
> Randy Brukardt wrote:
>
> [ ... ]
>
> > Ah, yes, the imfamous "Ada is dead site". (It doesn't say that
> > anymore, but it once did.) That site was created by someone
> > how posted all kinds of misinformation; people seem to believe
> > it because they registered the old AJPO domain name. Of course,
> > anyone can post anything on the net, and it can be hard to tell
> > what's accurate and what isn't.
>
> I agree that there's a lot of misinformation around, and sometimes it's
> difficult to sort out what's real and what isn't. Fortunately, the US
> Gov't makes this one easy to sort out.
>
> Since NIST is and the AJPO was run by the US gov't, an official action
> such as turning the testing responsibilities over to somebody else
> would have to be recorded in the US federal register. Since you're
> claiming it happened, please be so kind as to tell us the volume and
> page number in the federal register where it's recorded -- I did a
> search at:
>
> http://www.gpoaccess.gov/fr/index.html
>
> and couldn't turn anything up recording the action you allege to have
> taken place.

I don't know whether it was done formally or not; I wasn't involved with
that.

In any case, it is irrelevant to the existence of the ACAA, operated under
the requirements of an ISO standard, for performing conformity assessment of
Ada compilers. Or do you want to deny that I actually exist, that the ACAA
and its websites, test suites, and authorized laboratories, exists?

You can argue about the value of such testing (an argument that I'll sit
out), but that's a different subject.

                              Randy.

Re: C: [] vs * (was: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada)))

[Programmer Dude]

Arthur J. O'Dwyer writes:

>>> I think regardless of CTips' and Jim's points in this thread, the original
>>> code serves as an excellent argument against using [] in function headers;
>>> the extra "documentation" is more than offset by the decline in
>>> readability, as far as I'm concerned.
>>
>> Just as another datapoint, I feel exactly the opposite.  I much prefer
>> the [] notation to signify that the pointer refers to more than one of
>> whatever it's pointing at.
> 
>    I agree that that's the implicit "semantics" of [] versus *; I just
> find bar(int ai[]), with all those vertical things clustered so close
> together, to be much harder on the eyes --- and that's a bigger negative
> for me than the implicit "Look, an array!" semantics is a positive.
>    Maybe that was clear the first time around; I just want to make sure
> we're on the same page.

All totally clear!  Might be font-related or screen-related or maybe just
plain taste-related.  (-:\

>>>> Treating the address of any int
>>>> as the beginning of an array is a formula for buffer
>>>> overflow, as is demonstrated in this example.
>>>
>>>    This example does not appear to contain any buffer oveflow.
>>> If you think it does, please point it out to me.  I may have
>>> missed something.
>>
>> Maybe not in this example, but let's be fair.  He said that treating
>> the address of *any* int is problematic.  And it is.  C cannot be
>> called a "safe" language.  Safety must be imposed by the programmer.
> 
>    Sure.  But Jim said, "as is demonstrated in this example."  That's
> like saying, "Jumping a motorcycle across a canyon is dangerous 
> because you could fall to your death, as demonstrated by Evel 
> Knievel."[1]
> 
> -Arthur,
> daredevil
> 
> [1] - (who has /not/ fallen to his death, as of this posting, which
> shows why Jim's statement IMO was either misleading or indicative of
> a misapprehension)

Right (although one can argue that his stunts do indeed--regardless of
their success--demonstrate the danger...evidenced by the preparations,
emergancy vehicles present (and no doubt constant "don't try this at
home" warnings :-)).

And I just choose to focus on the meat rather than the wrapping.

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

[Martin Krischik]

kevin  cline wrote:

> 
> Martin Krischik wrote:
>> kevin  cline wrote:
>>
>> >
>> > Martin Krischik wrote:
>> >
>> >> Shure it is true: The C++ ISO standard has ruffly 200 pages more
> then
>> > the
>> >> Ada ISO standard. The C standard is a few pages shorter - but C
>> > hasn't got
>> >> object orientation, concurency, real time and distributed system
>> > included.
>> >
>> > No surprise there.  The C++ standard covers the C++ standard
> library.
>>
>> As Ada has an Ada standart library and indeed C has an C standard
> library
>> which are all part of the ISO standarts in question.

> True, but the C++ standard library is much more extensive than the Ada
> standard library.  There's nothing in the Ada standard that compares
> with the C++ standard template library.

Well it's Ada 95 and C++ 98 - the Ada standart is a 3 years older - Wait for
Ada 2005 for a standart template library.

One of the problems when comparing languages is that ISO standards a issued
every 10 years - so you always compare an older standard with a newer one.

In C/C++ this gives another interesting twist: C++98 does not understand the
new C99 features - as does C++2003 as it is only the mid-term bug fix.

Besides Ada standart library has features which C++ hasn't got. i.E. 3
string libraries (2 of which won't need heap memory) and 5 I/O Libraries
(http://en.wikibooks.org/wiki/Programming:Ada:InputOutput). Ada is more
"right tool for the task" then "one tool for all tasks." - Both approches
have advantages and disadvantages and I guess we all know them.

Martin

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

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

[Georg Bauhaus]

kevin cline wrote:

> 
> True, but the C++ standard library is much more extensive than the Ada
> standard library.  There's nothing in the Ada standard that compares
> with the C++ standard template library.

The meanings of the word "standard library" are a bit different in the two
languages.

The C++ standard template library is right now much more extensive than the
Ada 2005 STL variation. But Ada.Containers etc. is only one part of the Ada
standard library. When you need to link third party libraries in C++, you
can stay within the language in Ada:

The current Ada standard library includes for example
 distributed systems,
 information systems ("money computing"),
 string processing,
 interfaces to other languages,
 real-time facilities, and
 Ada subsetting definitions.

Ada 2005 adds more features to the standard, including
 linear algebra support, and
 more file and network I/O.


Georg 

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> On Tue, 15 Mar 2005 11:51:33 +0100, Georg Bauhaus wrote:

>>generic
>>   type Ordered is new Has_Less_Than with private;
>>package ...
>>
>>where Has_Less_Than is an abstract type with a "<" operation.
> 
> 
> In which case it simple does not need to be generic! Ordered here is a
> normal ADT, which class is Has_Less_Than'Class. So the package should work
> directly with the class and be non-generic. End of story.

If you want a set of pointers to Employee'class, how can do you do
it easily without templates for sets?

Have you read Bertrand Meyer's comparison? What do you think?

Georg 

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

[Ioannis Vranos]

Martin Krischik wrote:

> Well it's Ada 95 and C++ 98 - the Ada standart is a 3 years older - Wait for
> Ada 2005 for a standart template library.


That's good for Ada. May I assume an improved generics mechanism too? 
Something else, is this .NET enabled version of Ada compiler available 
from some other site, because those mil sites do not respond at all here 
(perhaps they have blocked non-US countries - I am in Greece, EU).

With such a protectionism, it is no wonder why Ada is not so much 
mainstream.



> One of the problems when comparing languages is that ISO standards a issued
> every 10 years - so you always compare an older standard with a newer one.
> 
> In C/C++ this gives another interesting twist: C++98 does not understand the
> new C99 features - as does C++2003 as it is only the mid-term bug fix.


C and C++ are different languages now. C++ is (hopefully) going to adopt 
only the C99 features that make sense (hopefully the general purpose 
ones), and not these that do not make sense (special interest built in 
ones).


An example is std::complex vs the new built in complex type of C99. Or 
VLAs vs vector/valarray.


You may check this article about some rational on this, search for the 
word c99 in there.

http://www.itworld.com/AppDev/710/lw-02-stroustrup/page_1.html


Also this article is very interesting regarding silver bullets. I think 
it is interesting to read it all (isn't that large).



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> The meanings of the word "standard library" are a bit different in the two
> languages.
> 
> The C++ standard template library is right now much more extensive than the
> Ada 2005 STL variation.


One thing to notice here is that STL is a subset (the most part) of the 
C++ standard library. People confusingly use the term STL and standard 
library interchangeably.



> But Ada.Containers etc. is only one part of the Ada
> standard library. When you need to link third party libraries in C++, you
> can stay within the language in Ada:


I am not sure how this can not happen in C++.


> The current Ada standard library includes for example
> distributed systems,
> information systems ("money computing"),
> string processing,
> interfaces to other languages,
> real-time facilities, and
> Ada subsetting definitions.
> 
> Ada 2005 adds more features to the standard, including
> linear algebra support, and
> more file and network I/O.


One question is, can these facilities be implemented with the language 
itself, or someone has to use another language to do the real work?



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Vinzent 'Gadget' Hoefler]

Ioannis Vranos wrote:

> Georg Bauhaus wrote:
> 
>> Ada 2005 adds more features to the standard, including
>> linear algebra support, and
>> more file and network I/O.
> 
> One question is, can these facilities be implemented with the language
> itself, or someone has to use another language to do the real work?

They can. Unlike Pascal, Ada does not know "magic" subroutines.


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

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

[Pascal Obry]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Georg Bauhaus wrote:
> 
> > The current Ada standard library includes for example
> > distributed systems,
> > information systems ("money computing"),
> > string processing,
> > interfaces to other languages,
> > real-time facilities, and
> > Ada subsetting definitions.
> > Ada 2005 adds more features to the standard, including
> > linear algebra support, and
> > more file and network I/O.
> 
> 
> One question is, can these facilities be implemented with the language
> itself, or someone has to use another language to do the real work?

In some area you need to use some call to the OS (in C or C++) and you also
need some call to the OS lib to adjust the behavior across paltforms to have
the same semantics on all implementaton (read on different OS) of the
runtime. This is true for the distributed systems annex for example.

string processing, linear algebra support, information systems can be built
in plain Ada.

Interface to other languages can't, you need support in the compiler.

   pragma Import (C, My_Routine);

The semantic behind this pragma must be defined somewhere.

So as you see it really depends on the nature of the library.

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Wed, 16 Mar 2005 12:46:10 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> On Tue, 15 Mar 2005 11:51:33 +0100, Georg Bauhaus wrote:
> 
>>>generic
>>>   type Ordered is new Has_Less_Than with private;
>>>package ...
>>>
>>>where Has_Less_Than is an abstract type with a "<" operation.
>> 
>> In which case it simple does not need to be generic! Ordered here is a
>> normal ADT, which class is Has_Less_Than'Class. So the package should work
>> directly with the class and be non-generic. End of story.
> 
> If you want a set of pointers to Employee'class, how can do you do
> it easily without templates for sets?

Exactly the same way. Access type is a type as any other. If it has to be a
member of Set_Element'Class why shouldn't it be?

type Employee_Ptr is access Employee'Class, new Set_Element;

> Have you read Bertrand Meyer's comparison? What do you think?

Any link?

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

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

[Ioannis Vranos]

Pascal Obry wrote:

> In some area you need to use some call to the OS (in C or C++) and you also
> need some call to the OS lib to adjust the behavior across paltforms to have
> the same semantics on all implementaton (read on different OS) of the
> runtime. This is true for the distributed systems annex for example.
> 
> string processing, linear algebra support, information systems can be built
> in plain Ada.


That's nice.


> Interface to other languages can't, you need support in the compiler.
> 
>    pragma Import (C, My_Routine);
> 
> The semantic behind this pragma must be defined somewhere.
> 
> So as you see it really depends on the nature of the library.


I had Ada template library in mind as also as "information systems 
("money computing"), string processing, Ada subsetting definitions 
(what's this?)" from those mentioned.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> Georg Bauhaus wrote:


>> When you need to link third party libraries in C++, you
>> can stay within the language in Ada:

>> The current Ada standard library includes 
...

>> Ada 2005 adds more features to the standard, including
...

> One question is, can these facilities be implemented with the language 
> itself, or someone has to use another language to do the real work?

As I said,
>> you can stay within the language in Ada.

I don't see why we should, by default, assume that an implementation of
a programming language has to refer to other languages to implement its
own standard. There is reason to use OS services at some low level, and
these might be written in some other language.
 You'd be programming an operating system on top of an OS just to
avoid NIH...


Georg 

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> Access type is a type as any other. If it has to be a
> member of Set_Element'Class why shouldn't it be?

Wrapping occurs, for example a set of ints will become a
set of int_also_set_element. As there might have to be
some implementation for int_also_set_element,
it can be much less convenient than having a set of plain
ints.

>>Have you read Bertrand Meyer's comparison? What do you think?
> 
> Any link?

This is a chapter in OOSC2. It's good to have a copy anyway.
http://archive.eiffel.com/doc/oosc/
From this page there is a link to a sample chapter every now
and then. See the bottom of the page.

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

[Larry Kilgallen]

In article <1639952.z7hLqyLLQL@jellix.jlfencey.com>, Vinzent 'Gadget' Hoefler <nntp-2005-03@t-domaingrabbing.de> writes:
> Ioannis Vranos wrote:
> 
>> Georg Bauhaus wrote:
>> 
>>> Ada 2005 adds more features to the standard, including
>>> linear algebra support, and
>>> more file and network I/O.
>> 
>> One question is, can these facilities be implemented with the language
>> itself, or someone has to use another language to do the real work?
> 
> They can. Unlike Pascal, Ada does not know "magic" subroutines.

What are "magic" subroutines ?

I know of nothing by that name in VAX/DEC/Compaq/HP Pascal for VMS.

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

[Georg Bauhaus]

Ioannis Vranos wrote:

> Something else, is this .NET enabled version of Ada compiler available 
> from some other site, because those mil sites do not respond at all here 
> (perhaps they have blocked non-US countries - I am in Greece, EU).

Seems like some ColdFusion restructuring is happening.

ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/asharp/
ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/ftp.usafa.af.mil/pub/dfcs/carlisle/asharp/

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> Seems like some ColdFusion restructuring is happening.
> 
> ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/asharp/


The first has not been working either.


> ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/ftp.usafa.af.mil/pub/dfcs/carlisle/asharp/ 


This works. Thanks.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Vinzent 'Gadget' Hoefler]

Larry Kilgallen wrote:

> In article <1639952.z7hLqyLLQL@jellix.jlfencey.com>, Vinzent 'Gadget'
> Hoefler <nntp-2005-03@t-domaingrabbing.de> writes:
>
>> They can. Unlike Pascal, Ada does not know "magic" subroutines.
> 
> What are "magic" subroutines ?

Try to write a procedure that can take an arbitrary number of parameters
of (almost) arbitrary types (like Integer, Real, String, Char) in
arbitrary order - in Pascal.

Yet, it exists in the incarnation of Read[Ln]/Write[Ln].


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Wed, 16 Mar 2005 15:11:46 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> Access type is a type as any other. If it has to be a
>> member of Set_Element'Class why shouldn't it be?
> 
> Wrapping occurs, for example a set of ints will become a
> set of int_also_set_element.

What's wrong with that. Or, better: how ints could be in a set being not
elements of the set? (:-))

> As there might have to be
> some implementation for int_also_set_element,
> it can be much less convenient than having a set of plain
> ints.

I'm afraid I don't fully understand what you mean here. Probably, that the
implementation of the set will use class-wide objects instead of specific
ones. It is definitely an issue to be addressed. This is why I wish a
better ADT for Ada.

> This is a chapter in OOSC2. It's good to have a copy anyway.
> http://archive.eiffel.com/doc/oosc/
> From this page there is a link to a sample chapter every now
> and then. See the bottom of the page.

Presently it is: HOW TO FIND THE CLASSES

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

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

[Pascal Obry]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> I had Ada template library in mind as 

No problem, it is built in plain Ada.

> also as "information systems ("money
> computing"), string processing, Ada subsetting definitions (what's this?)"
> from those mentioned.

I think this is the way to restrict the language. In some area it is very
important to avoid memory allocation, you can add a pragma like;

   pragma Restrictions (No_Allocators);

Here are the current (read Ada95) set of restrictions:

* Safety and Security Restrictions
====================

  1. This clause defines restrictions that can be used with pragma
     Restrictions, see *Note 13.12::, these facilitate the
     demonstration of program correctness by allowing tailored versions
     of the run-time system.


                             _Static Semantics_

  2. The following restrictions, the same as in *Note D.7::, apply in
     this Annex: No_Task_Hierarchy, No_Abort_Statement,
     No_Implicit_Heap_Allocation, Max_Task_Entries is 0,
     Max_Asynchronous_Select_Nesting is 0, and Max_Tasks is 0. The last
     three restrictions are checked prior to program execution.

  3. The following additional restrictions apply in this Annex.

  4. Tasking-related restriction:

  5. No_Protected_Types

          There are no declarations of protected types or protected
          objects.

  6. Memory-management related restrictions:

  7. No_Allocators

          There are no occurrences of an allocator.

  8. No_Local_Allocators

          Allocators are prohibited in subprograms, generic sub-programs,
          tasks, and entry bodies; instantiations of generic
          packages are also prohibited in these contexts.

  9. No_Unchecked_Deallocation

          Semantic dependence on Unchecked_Deallocation is not allowed.

 10. Immediate_Reclamation

          Except for storage occupied by objects created by allocators
          and not deallocated via unchecked deallocation, any storage
          reserved at run time for an object is immediately reclaimed
          when the object no longer exists.

 11. Exception-related restriction:

 12. No_Exceptions

          Raise_statements and exception_handlers are not allowed. No
          language-defined run-time checks are generated; however, a
          run-time check performed automatically by the hardware is
          permitted.

 13. Other restrictions:

 14. No_Floating_Point

          Uses of predefined floating point types and operations, and
          declarations of new floating point types, are not allowed.

 15. No_Fixed_Point

          Uses of predefined fixed point types and operations, and
          declarations of new fixed point types, are not allowed.

 16. No_Unchecked_Conversion

          Semantic dependence on the predefined generic
          Unchecked_Conversion is not allowed.

 17. No_Access_Subprograms

          The declaration of access-to-subprogram types is not allowed.

 18. No_Unchecked_Access

          The Unchecked_Access attribute is not allowed.

 19. No_Dispatch

          Occurrences of T'Class are not allowed, for any (tagged)
          subtype T.

 20. No_IO

          Semantic dependence on any of the library units
          Sequential_IO, Direct_IO, Text_IO, Wide_Text_IO, or Stream_IO
          is not allowed.

 21. No_Delay

          Delay_Statements and semantic dependence on package Calendar
          are not allowed.

 22. No_Recursion

          As part of the execution of a subprogram, the same subprogram
          is not invoked.

 23. No_Reentrancy

          During the execution of a subprogram by a task, no other task
          invokes the same subprogram.


* The Tasking Restrictions
====================

  1. This clause defines restrictions that can be used with a pragma
     Restrictions, see *Note 13.12::, to facilitate the construction of
     highly efficient tasking run-time systems.


                             _Static Semantics_

  2. The following restriction_identifiers are language defined:

  3. No_Task_Hierarchy

          All (nonenvironment) tasks depend directly on the environment
          task of the partition.

  4. No_Nested_Finalization

          Objects with controlled parts and access types that designate
          such objects shall be declared only at library level.

  5. No_Abort_Statements

          There are no abort_statements, and there are no calls on
          Task_Identification.Abort_Task.

  6. No_Terminate_Alternatives

          There are no selective_accepts with terminate_alternatives.

  7. No_Task_Allocators

          There are no allocators for task types or types containing
          task subcomponents.

  8. No_Implicit_Heap_Allocations

          There are no operations that implicitly require heap storage
          allocation to be performed by the implementation. The
          operations that implicitly require heap storage allocation
          are implementation defined.

  9. No_Dynamic_Priorities

          There are no semantic dependences on the package
          Dynamic_Priorities.

 10. No_Asynchronous_Control

          There are no semantic dependences on the package
          Asynchronous_Task_Control.

 11. The following restriction_parameter_identifiers are language
     defined:

 12. Max_Select_Alternatives

          Specifies the maximum number of alternatives in a
          selective_accept.

 13. Max_Task_Entries

          Specifies the maximum number of entries per task. The bounds
          of every entry family of a task unit shall be static, or
          shall be defined by a discriminant of a subtype whose
          corresponding bound is static. A value of zero indicates
          that no rendezvous are possible.

 14. Max_Protected_Entries

          Specifies the maximum number of entries per protected type.
          The bounds of every entry family of a protected unit shall be
          static, or shall be defined by a discriminant of a subtype
          whose corresponding bound is static.


                            _Dynamic Semantics_

 15. If the following restrictions are violated, the behavior is
     implementation defined. If an implementation chooses to detect
     such a violation, Storage_Error should be raised.

 16. The following restriction_parameter_identifiers are language
     defined:

 17. Max_Storage_At_Blocking

          Specifies the maximum portion (in storage elements) of a
          task's Storage_Size that can be retained by a blocked task.

 18. Max_Asynchronous_Select_Nesting

          Specifies the maximum dynamic nesting level of
          asynchronous_selects. A value of zero prevents the use of any
          asynchronous_select.

 19. Max_Tasks

          Specifies the maximum number of task creations that may be
          executed over the lifetime of a partition, not counting the
          creation of the environment task.

 20. It is implementation defined whether the use of pragma Restrictions
     results in a reduction in executable program size, storage
     requirements, or execution time. If possible, the implementation
     should provide quantitative descriptions of such effects for each
     restriction.


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

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

[Georg Bauhaus]

Ioannis Vranos wrote:

>> Ada subsetting definitions 

>(what's this?)"

Use language defined pragmas to declare that your program
doesn't use some parts of Ada. These are instructions to
the compilation system.  Then, the run-time system
can be tailored to meet the restricted set of requirements.
In addition, some formal properties of the program are
easier to demonstrate.
 For example, a program might not need protected types,
a program may have no nested tasks, or it may have no
allocators (no "new"), or no unchecked_access.

Georg 

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> Seems like some ColdFusion restructuring is happening.
> 
> ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/asharp/
> ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/ftp.usafa.af.mil/pub/dfcs/carlisle/asharp/ 


Perhaps you may help. How may I setup a .NET Ada development environment?


I have downloaded from various sites so far:

7.266.221 adagide-install.exe
30.259.357 asharp-setup.exe

19.146.036 gnat-3.15p-nt.exe
5.752.374 rapid301.zip


I suppose the last two should not be needed. Are the first two the only 
needed? adagide asked for gnat, while asharp (mgnat) was installed.


In this cache: 
http://66.102.9.104/search?q=cache:30q5cvyYvAUJ:www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html+A%23&hl=el&client=firefox-a

it says that AdaGIDE integrates fully with A#.


I am providing the cache here because as I said the original site is not 
accessible.


Not to mention that I receive anonymous security error for the site 
provided here:

"If you do not have GNAT 3.11p (or later), get it from:
ftp://ftp.cs.nyu.edu/pub/gnat/winnt

AdaGIDE uses features specific to GNAT 3.11"


So much security, and my interest of Ada has already declined to almost 0.


Being amused by this "paranoia", I checked to some local sites and found 
the latest GNAT here (just to help if someone else is interested in Ada):

ftp://ftp.ntua.gr/pub/lang/gnat/3.15p/winnt/


Any guidance for setting an Ada .NET development environment?



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Martin Krischik]

Ioannis Vranos wrote:

>> The current Ada standard library includes for example
>> distributed systems,
>> information systems ("money computing"),
>> string processing,
>> interfaces to other languages,
>> real-time facilities, and
>> Ada subsetting definitions.
>> 
>> Ada 2005 adds more features to the standard, including
>> linear algebra support, and
>> more file and network I/O.

> One question is, can these facilities be implemented with the language
> itself, or someone has to use another language to do the real work?

In theory all features could be programmed in Ada itself as the Ada ISO
standart contains system programming and  "inline assembler" in one of the
optional Anex.

In Praxis it depends on the target operating system. If you have a Linux
distribution you you can check the "praxis" part yourself - just install
the GCC sources and check the "gcc/ada" directory - there are 34 C files
and 755 ada files there. That's for the library and the compiler.

Martin

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

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

[Georg Bauhaus]

Ioannis Vranos wrote:
 
> "If you do not have GNAT 3.11p (or later), get it from:
> ftp://ftp.cs.nyu.edu/pub/gnat/winnt
> 
> AdaGIDE uses features specific to GNAT 3.11"
> 
> 
> So much security, and my interest of Ada has already declined to almost 0.

Not sure it has anything to do with a programming language.
The sftp at cs.nyu.edu is new, and affects the whole site.

Try http://libre.act-europe.fr/
Also, there is a mirror at ftp.informatik.rwth-aachen.de

> Any guidance for setting an Ada .NET development environment?

Depends on what you define to be a .NET DE. You can get the GNAT
Programming System (GPS), supporting Ada (and C++) in various ways.
You have AdaGIDE, it seems. I like GLIDE which is based on Emacs
and speedbar. Use whatever else you have for WIMP.NET programming
when needed. 

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> Not sure it has anything to do with a programming language.
> The sftp at cs.nyu.edu is new, and affects the whole site.
> 
> Try http://libre.act-europe.fr/
> Also, there is a mirror at ftp.informatik.rwth-aachen.de


OK, thanks for the links.


> Depends on what you define to be a .NET DE.


An editor (with a Designer - aka RAD - preferably), that works with "A#" 
(and not only for Win32 API).


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <1639952.z7hLqyLLQL@jellix.jlfencey.com>, Vinzent 'Gadget' Hoefler <nntp-2005-03@t-domaingrabbing.de> writes:
> > Ioannis Vranos wrote:
> > 
> >> Georg Bauhaus wrote:
> >> 
> >>> Ada 2005 adds more features to the standard, including
> >>> linear algebra support, and
> >>> more file and network I/O.
> >> 
> >> One question is, can these facilities be implemented with the language
> >> itself, or someone has to use another language to do the real work?
> > 
> > They can. Unlike Pascal, Ada does not know "magic" subroutines.
> 
> What are "magic" subroutines ?
> 
> I know of nothing by that name in VAX/DEC/Compaq/HP Pascal for VMS.

It's not a Pascal term.  "Magic" just means something available to the
language designer or compiler writer, but not available to the
programmer writing in that language.  Writeln in Pascal is magic
(which is a very poor language design).  All languages have some
magic.  Ada has a bit too much, in my opinion, but it doesn't make
the Writeln mistake.

As I'm sure you're aware, Pascal is a different language than VAX
Pascal.  VAX Pascal has some extensions, some of them quite large, like
exception handling.  The VMS design does a very good job of making the
OS language-independent, and supporting interoperability between various
languages.  Unix is very annoying in that regard -- the interface to
the OS is highly biased toward the language in which the OS is
implemented.

- Bob

Re: Magic ordering

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 15 Mar 2005 12:54:30 +0000, Marius Amado Alves wrote:
> 
> > (Sorry I changed the subject. I'm just that kind of guy :-)
> > 
> > On 15 Mar 2005, at 12:01, Hans Malherbe wrote:
> > 
> >> I have to ask myself though: If I am denied access to information that
> >> lets me  implement a < operator, am I supposed to be able to sort it?
> > 
> > This is one of my favourites. There's always a way. Bit by bit 
> > comparison, an arbitrary index, 'Address comparison...
> 
> All of which might appear wrong. The objects might be non-contiguous, have
> replicas etc.
> 
> Comparison should reflect the semantics of compared things. There is no
> universal way to do it.

It seems to me that there are two sorts of "<" operator here.

For one, "<" represents some arbitrary order.  It has to have
certain properties, like always returning the same answer on 
the same args, and X=Y implies that X<Y returns False, and
X<Y and Y<Z implies X<Z, and so forth.  You can use this to
create a container, where you don't care about the order,
just that there is *some* order.

For the other, "<" represents some semantic property of the type.
Like the usual order of integers, or lexicographic order for
character strings.

It seems to me that the compiler could provide the former,
which allows creating containers, and you can ask Is_Present,
and you can iterate in an arbitrary order.

The compiler cannot provide the latter, but if the programmer provides
it, you can have containers with iterators that use a *sensible* order.

- Bob

Re: Magic ordering

[Dmitry A. Kazakov]

On 16 Mar 2005 15:03:51 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Tue, 15 Mar 2005 12:54:30 +0000, Marius Amado Alves wrote:
>> 
>>> (Sorry I changed the subject. I'm just that kind of guy :-)
>>> 
>>> On 15 Mar 2005, at 12:01, Hans Malherbe wrote:
>>> 
>>>> I have to ask myself though: If I am denied access to information that
>>>> lets me  implement a < operator, am I supposed to be able to sort it?
>>> 
>>> This is one of my favourites. There's always a way. Bit by bit 
>>> comparison, an arbitrary index, 'Address comparison...
>> 
>> All of which might appear wrong. The objects might be non-contiguous, have
>> replicas etc.
>> 
>> Comparison should reflect the semantics of compared things. There is no
>> universal way to do it.
> 
> It seems to me that there are two sorts of "<" operator here.
> 
> For one, "<" represents some arbitrary order.  It has to have
> certain properties, like always returning the same answer on 
> the same args, and X=Y implies that X<Y returns False, and
> X<Y and Y<Z implies X<Z, and so forth.  You can use this to
> create a container, where you don't care about the order,
> just that there is *some* order.
>
> For the other, "<" represents some semantic property of the type.
> Like the usual order of integers, or lexicographic order for
> character strings.

I see no difference between them. Both have *a* semantics.
 
> It seems to me that the compiler could provide the former,
> which allows creating containers, and you can ask Is_Present,
> and you can iterate in an arbitrary order.

OK. That would mean to have one more class of types. Say, "ordered
non-limited". Which differs from usual "is private" that it also has "<",
"<=", ">", ">=". And of course "<=", ">", ">=" all are derived from "<",
the same way as "!=" is derived from "=". How to ensure transitivity? I
don't know. Anyway, we go:

type X is ordered [tagged] record ...;
type X is ordered array (...) of ...;
type X is ordered access ...;
...

instead of:

type X is [tagged] record ...;
type X is array (...) of ...;
type X is access ...;

The compiler then defines relational operations if user does not do it. It
also overrides relation operations by each type extension. I don't think
that I'd like this much. I'd prefer a more open mechanism. Because some
day, somebody would ask for a group, field, etc. That should not be
engraved in the compiler. We had enough problems with limited vs. not
classes to add a third one. I believe that better ADTs could do the trick.

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

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

[Jerry Coffin]

Randy Brukardt wrote:

[ the AJPO delegating testing authority before it was shut down ... ]

> I don't know whether it was done formally or not; I wasn't involved
> with that.

Such a thing was either one formally, or not at all.

> In any case, it is irrelevant to the existence of the ACAA, operated
> under the requirements of an ISO standard, for performing conformity
> assessment of Ada compilers. Or do you want to deny that I actually
> exist, that the ACAA and its websites, test suites, and authorized
> laboratories, exists?

The question is not one of existence. The original claim, however, was
one of their being "official" authorities. The claim that this testing
is somehow "officia" seems to be based on two claims: one, that the
AJPO delegated the authority before it was shut down, and 2) that to
some extent or other, you're acting as part of, under the saction of,
or are in some other way connected with the ISO (e.g. "Although the Ada
tool vendors finance it through the ARA, the ACAA's real boss is the
ISO" (from http://www.adaic.com/compilers/acaa.html).

At this point, it seems quite doubtful to me that the AJPO did any such
thing.

The ISO has this to say:

    ISO itself does not carry out conformity assessment. However,
    in partnership with IEC (International Electrotechnical
    Commission), ISO develops ISO/IEC guides and standards to be
    used by organizations which carry out conformity assessment
    activities. The voluntary criteria contained in these guides
    and standards represent an international consensus on what
    constitutes best practice.

(taken from:
http://www.iso.org/iso/en/aboutiso/introduction/index.html).

The bottom line seems to be that the ISO will take responsibility for
the fact that they wrote the standard you claim to follow -- but that
they disavow any and all other involvement with, or any more than the
most peripheral knowledge of you.

So, 1) one of the statements on your web site is probably outright
false, and another is saved from outright falsehood primarily by being
sufficiently vague as to only qualify as "misleading" 2) your claim
about my making a false statement was _probably_ itself false, and at
best certainly devoid of support 3) your statements about the quality
of an Ada compiler are no more "official" than mine or anybody else's.

The basic idea of an "official" verification process is that the
testing be done by a disinterested party -- one who gains _only_ by the
tests being accurate, NOT by them producing any particular result. What
we have here seems to be exactly the opposite: the Ada vendors have put
together a couple of puppet groups to give an illusion of there being
some distance between themselves and the testers, but in reality the
testers realize full well exactly where all their money comes from, and
at least some of them are even still directly associated with the very
Ada vendors they claim to be policing!

That isn't intended to imply, nor do I claim, that any of the testing
involved has ever been falsified or even mildly inaccurate. OTOH, it
throws considerable doubt on the claim that these tests should be
trusted because they're conducted by an "official" authority operating
with the ISO as its boss.

So, the question is not one of whether you exist -- but of whether you
and/or your testing should be trusted. In my view, your own posts have
thrown this into considerable doubt (at best).

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Randy Brukardt]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:1111015648.669832.140620@o13g2000cwo.googlegroups.com...
...
> So, the question is not one of whether you exist -- but of whether you
> and/or your testing should be trusted. In my view, your own posts have
> thrown this into considerable doubt (at best).

The reason Jerry comes to this conclusion is based on a single summary
statement from a 5 year-old summary article; he never looks at the testing
procedures or the ISO standard that governs those procedures. Moreover, he
seems to claim reasons for this conclusion that are clearly stated in the
article (at least I hope they're clear; I'm not that great a writer...).

I'm always amazed at the lengths that some opponents of Ada will go in order
to discredit any advantage of the language. Is this because they feel
threatened by the language? (I can't imagine why.) Or they have a deep
seated hatred of things that start with 'A'? I don't know. You can't please
(or even reason with) all of the people all of the time.

Anyway, for the benefit.of anyone else still reading this thread, I'll
explain how the testing is done, and why it can be trusted. (Whether such
testing has value in any case is another issue that could be argued forever,
but that's not the question.)

The testing process is an instantiation of the ISO testing standard (ISO/IEC
18009). The detailed procedures that are followed are available on the AdaIC
website, along with the test suite itself. They were developed from the
preexisting AJPO procedures with the oversight of a panel of users,
laboratories, and vendors.

Actual testing is done by testing laboratories (ACALs). These have to be
independent of any Ada vendor. Vendors contract directly with the
laboratories for testing; this part of the process is unchanged from when
AJPO and NIST ran it.

The ACAA is the oversight agency. We provide maintenance to the test suite,
and judge disputes between the vendors and the testing labs. We also spot
check the laboratories work to insure that they have followed the
procedures. This is the role that previously was handled by AJPO (in an
office called the AVO).

The only real difference (other than the ISO standard, which codified the
rules that AJPO had followed) is that the ACAA is funded in part by the ARA.
The ACAA is primarily funded by certificate fees, but the ARA does make up
any shortfall. The ARA is an association of Ada product vendors (not just
compiler vendors).

While there is a potential conflict of interest, it is irrelevant in
practice for three reasons:
(1) The ACAA is only a judge. Moreover, technical issues are resolved by
discussion with a panel of Ada experts; if that is not satisfactory, the
ruling can be appealed to the ARG (the Ada standard maintenance group within
the Ada working group of ISO/IEC SC22 WG9). At most, the ACAA can influence
this process, not decide it.
  (2) ARA includes most of the major Ada vendors. It would be hard to have
an conformity issue that they all would agree on that would not also be in
the interest of all Ada vendors.
  (3) The testing in question is conformity assessment. It is not about
testing usability in any way, so it has little to do with the factors on
which vendors compete. The testing is designed to provide a yes/no answer
(well, it's a little more nuanced than that) as to whether a compiler is
compliant. There isn't a lot of leeway in this process for outside
influence.

While I could imagine an outcome from this process that would favor Ada
vendors over Ada users, that would seem to be counter-productive (why hurt
your customers?). Moreover, as the testing is about conformity and not
usability, most issues that matter to users don't even fall under the
testing umbrella. Of course, the main question (Does this compiler properly
implement the Ada Standard?) is of significant interest to users,
particularly those that will need to use more than one compiler over the
life of their project.

As to whether someone could cheat in the process, I would say it would not
be the least bit hard. The results of the tests are always handled by the
vendors before the testers see them, so there is always the possibility of
games. There is nothing new about this possibility (I know or suspect
several cases where results were falsied under the AJPO testing). I think it
actually would be harder now, because (1) I've been on the other side of the
fence, so I have some idea of what to look for; and (2) we require more
information in the test report than AJPO did. We also post the test reports
publically, so anyone can check on them. (The only AJPO test reports I ever
saw, before I was sent several cartons of old AVO material, were the ones we
had done.) We even have a public test results dispute procedure (which
thankfully never has been used), its unclear if AJPO even had one.

In any event, the real benefit is that there is a *single* conformity test
suite that *all* Ada vendors use for testing. That means that there can be
no confusion about what has and has not been tested. Most differences
between Ada compilers (beyond those allowed by the Standard) are those that
come from untested combinations of Ada features.

                               Randy Brukardt

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

[Jerry Coffin]

Randy Brukardt wrote:

[ ... ]

> The reason Jerry comes to this conclusion is based on a single
> summary statement from a 5 year-old summary article;

First of all, I came to no solid conclusions. Second, there was far
more reasoning behind what I said than you admit here. Fortunately,
anybody who wishes to do so can easily go back and read about the
federal register -- wihch is available for searching by essentially
anybody who wishes to do so. If your statements are really true, why
don't you quit trying to put words in my mouth and simply show the
proof?

[ ... ]

> Moreover, he
> seems to claim reasons for this conclusion that are clearly stated
> in the article (at least I hope they're clear; I'm not that great a
> writer...).

Except for the part about your (lack of) writing ability, I have no
idea what this sentence is even attempting to say. Commenting on your
own writing ability would _seem_ to imply that you're discussing the
writing on your web site, though. If that's the case, I have to wonder
about the logic involved -- it _sounds_ more or less as if you may be
attempting to offer your own statements on your own web site as
providing "proof" of the statements you've made here!

> I'm always amazed at the lengths that some opponents of Ada will go
> in order to discredit any advantage of the language. Is this because
> they feel threatened by the language? (I can't imagine why.) Or they
> have a deep seated hatred of things that start with 'A'? I don't'
> know.

This has nothing to do with discrediting the language.

Consider, for example, buying ICs. I can not only find not only who
made the ICs, but exactly which fabrication facility they were made at.
I can find ISO 900x certification(s) on that facility, and I can find
out who did that certification. I can find who they use as a failure
analysis lab, whether they're ISO 900x certified, and if so who
certified THEM. In short, I don't simply depend on their own claims --
I can find a chain of documentation that leads to people they hope I
trust.

The question is the degree to which that situation holds here. Thus
far, you've provided essentially nothing in the way of independent
corroboration of any of your statements at all. You make a statement
here, and then offer your own statement on your own web site as the
"corroborating evidence."

> You can't please
> (or even reason with) all of the people all of the time.

At least in this thread, you don't seem to have even attempted to
_reason_ with anybody at all. You've made unsupported claims, and when
perfectly legitimate concerns are raised, you've resorted to suggesting
that they result from fear and/or irrational hatred.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Chad R. Meiners]

> The question is the degree to which that situation holds here. Thus
> far, you've provided essentially nothing in the way of independent
> corroboration of any of your statements at all.

So how does one provide independent corroboration over usenet?  If such
a method exists, is the method's cost reasonable?  Is there an ISO
standardize method?

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

[Chad R. Meiners]

quote 1
> (e.g. "Although the Ada
> tool vendors finance it through the ARA, the ACAA's real boss is the
> ISO" (from http://www.adaic.com/compilers/acaa.html).

-and-

quote 2
> The ISO has this to say:

When I read your post I recognized the the phrase "the ISO" in quote
one and two have distinct meanings.   That is they don't refer to the
same thing.  However, the rest of your post seems to rely on them
meaning the same thing.  How do you account for this?

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

[Randy Brukardt]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:1111085060.475613.176310@o13g2000cwo.googlegroups.com...
...
> The question is the degree to which that situation holds here. Thus
> far, you've provided essentially nothing in the way of independent
> corroboration of any of your statements at all. You make a statement
> here, and then offer your own statement on your own web site as the
> "corroborating evidence."

I can't imagine what sort of "independent corroboration" would satisfy you
(or why it matters, for that matter). I've already pointed you at the ISO
standard and the WG9 web site. Pretty much all of the other material on
testing was written by me. There's nothing sinister about that: I'm the only
one that is paid here, and thus I end up writing it. Of course, the
volunteer review board reviewed and approved that material. But even if that
was done publically, it wouldn't satisfy you, because *I* the webmaster of
the site and therefore would have probably formatted and posted the
material. Our budget isn't large enough to have multiple people doing
overlapping jobs just to prove some sort of independence.

Our way of proving relability is to conduct the entire process in public.
Thus, the procedures, test reports, and test suite are all publically
available. And I insist that these have enough information in them so that
any member of the public can reproduce the testing. (This isn't like the
destructive testing of ICs that only a few specialists can run -- anyone who
knows how to run a compiler can run the tests on it; and they had better get
the same results.) That means that any fault in the process can be exposed,
and that should provide a strong incentive to avoid bending the rules.

If that is not good enough for you, then there is nothing else I can say.
Personally, I would trust an open process over one that is not open, not
matter how independent the latter is. After all, the supposedly independent
government run process was cheated several times; because the reports
weren't readily available to the public, there was little chance that those
would be detected.

                               Randy.

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

[Jerry Coffin]

Chad  R. Meiners wrote:

[ ... ]

> So how does one provide independent corroboration over usenet?

Usually by pointing to a reasonably recognizable reference. Given that
Usenet is carried primarily over the Internet, something like the
address of a recognizable web site is an obvious possibility.

>  If such a method exists, is the method's cost reasonable?

It's usually free.

> Is there an ISO standardize method?

I'm not sure what you're asking here -- if you're asking whether the
ISO has methods for standardizing things, of course they do.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Jerry Coffin]

Chad  R. Meiners wrote:
> quote 1
> > (e.g. "Although the Ada
> > tool vendors finance it through the ARA, the ACAA's real boss is
the
> > ISO" (from http://www.adaic.com/compilers/acaa.html).
>
> -and-
>
> quote 2
> > The ISO has this to say:
>
> When I read your post I recognized the the phrase "the ISO" in quote
> one and two have distinct meanings.   That is they don't refer to the
> same thing.  However, the rest of your post seems to rely on them
> meaning the same thing.  How do you account for this?

Is this a troll? What in the world do you think "the ISO" could refer
to other than the ISO?

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Jerry Coffin]

Robert A Duff wrote:

[ ... ]

> Sorry, I don't know how to say it politely, but this argument (on
> both sides) is patently ridiculous.  For one thing, neither C++ nor
> Ada 95 existed at the time the Arpanet was created.

Previously noted.

> For another thing, Ada has never been "a language the DoD considered
> its own" -- the design has always been entirely open.
> For goodness sakes, they even chose a
> foreigner (Jean Ichbiah, who is French) to do the original 1983
> language design!

Hmm...so your position is that the DoD _couldn't_ feel posessive about
it because at least part of that would be irrational?

Perhaps we should start over from the beginning. Hi. Welcome to our
planet. We like to call it "earth." We call ourselves "people".
Rationality in individuals is rare and in large groups, nonexistent.
Unfortunately, even though you seem to speak (or at least type) English
just like the TV shows said you would, your thinking is appearently so
different from ours that we'll probably never be able to truly
communicate. :-)

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Jerry Coffin]

Wes Groleau wrote:

[ ... ]

> Interesting.  Ada is bad because you _think_ it won't let you do what
> you want to do.

First of all, I've never said Ada was bad -- at worst, I've said that I
found some things about it frustrating. Second, my opinions are based
on use, not just what I think might be true about it. Finally, I've
openly admitted that some (pehaps all) of my opinions may be obsolete
since my experience predates Ada 95.

> But it would be better if it prevented other people
> from doing something you think they shouldn't do.

It's been close to 10 years now that Java has had its multi-level
break, and in that time I'm not at all certain I've seen even _one_
instance of its use that wouldn't have been better off without it.

In the end, designing a (good) programming language requires a lot of
judgement calls, not simply applying some simplistic rule like "allow
everything". A theoretically ideal programming language would allow
everything that was intended and desired, but stop everything that
wasn't.

Real languages deal in compromises -- one is that permitting more of
what people want to do also generally allows more things they didn't
really want to do.

I think this "feature" has an even greater cost though. While most
people recognize that the undisguised goto is something to generally
avoid, many (especially those too young to have dealt with FORTRAN II
computed gotos) rarely consciously realize that a break (of any sort)
is simply a restricted form of a goto -- and the less restricted it is,
the more it's just a goto by a different name.

The result is that when people are faced with using a goto to exit from
a deeply nested loop, they usually have second thoughts -- and with a
little more thought, realize that the code can be re-structured to
eliminate the real problem that led them to want to do that in the
first place.

OTOH, when that goto is disguised as a "multi-level break", it appears
(at least to me) that they're much more willing to just use the
goto^H^H^H^Hmulti-level break instead of fixing the code.

In fairness, the multi-level goto is marginally more justifiable in
Java than in Ada -- Java copied all of C's biggest mistakes, including
its screwed up switch/case statement. It's quite often useful to have a
switch statement in a loop, and exit the loop as one of the legs of the
switch -- but the screwed-up switch makes this a multi-level break.

Regardless of other shortcomings I might see in its design, Ada did get
its case statement right, so a single-level break suffices for this
situation.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Ioannis Vranos]

Jerry Coffin wrote:

> In fairness, the multi-level goto is marginally more justifiable in
> Java than in Ada -- Java copied all of C's biggest mistakes, including
> its screwed up switch/case statement. It's quite often useful to have a
> switch statement in a loop, and exit the loop as one of the legs of the
> switch -- but the screwed-up switch makes this a multi-level break.


I think that wanting to break a loop from inside a case block is very 
rare, after all one places (should place) minimal code in switch cases.


On the other hand, although the designers of C#/CLI claimed their switch 
implementation to be better than C++ (as with every other language 
detail, they were very excited with C#/CLI in the beginning, they viewed 
it as a cure-all kind of thing, now they have switched back to C++ as 
the systems programming language of .NET), I think it is inferior. It 
goes with something like this if you want to use more than one cases:


switch(value)
{
  case 1:
         {
           // ...

           goto case 2;
         }

case 2:
        {
         // ...
        }


case 3:
        {
          // ...
        }
}


with implicit breaks among cases. Personally I do not like this goto stuff.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Chad R. Meiners]

the ISO = the ISO standard for Ada
the ISO = the  Internatioal Standard Organization

Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

[Dave Thompson]

On Sun, 13 Mar 2005 19:48:52 -0500 (EST), "Arthur J. O'Dwyer"
<ajo@nospam.andrew.cmu.edu> wrote:

<snip>
> >> On Sun, 13 Mar 2005, Jim Rogers wrote:
> >>>
> >>>   procedure Do_Array(X : Combiner) is
> >>>      PA : Element_Ptr;
> >>>   begin
> >>>      Pa := X.P; -- assign all elements of X.P to Pa
<snip>
> >>>      Pa(2).all := 1; -- Assign 1 to the second value in the array
> >>
> >>    For my own edification: Am I correct in thinking that the ".all"
> >> is superfluous in this expression?
> >
> > Not at all. This is equivalent to the C syntax
> >   *(p[1]) = 1;
> 
>    Where '.all' corresponds to C's '*' operator, right.  I thought
> I recalled reading that Ada would infer the '.all' to make the types
> work out in some cases (similarly to Algol?); either I read wrong,
> or this just isn't one of those cases.

Ada will automatically dereference an access type (i.e. pointer) if it
is clear from 'syntax':
  access-to-array followed by parenthesized subscript
  access-to-record (struct) followed by dot member
  access-to-subprogram followed by parenthesized argument list
  access-to-anything followed by apostrophe and an attribute (name) 
that is valid for the target but not for the access 

For access-to-scalar, or where you want a whole array or record, you
need .all to get the target (value) rather than the pointer. Ada does
not search for a set of dereferences that make LHS and RHS match like
algol. Although it does do overload resolution (which algol didn't
even have) including the 'expected' type (most simply assignment LHS).

- David.Thompson1 at worldnet.att.net

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

[adaworks]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:1110522060.091940.178510@l41g2000cwc.googlegroups.com...
> The mindset that embraces Ada simply would never have designed things
> that way. Heck, I'm clearly on the C++ side of the fence, and I stil
> find many of them at least mildly distasteful. Had they been designed
> by Ada programmers, the hackish character would be gone. Instead, the
> system would be designed to operate in harmony as a coordinated system.
>
Possibly.   However, I have seen more than enough "hacked" Ada to wonder
whether, in the hands of the larger community, the unruly would still run amuck,
even with Ada as their language.   Although the default for most constructs in
Ada tends toward the notion of "safe," there are lots of ways to "relax" the
language's emphasis on safety.   I recall that when I first learned Ada, I used
to first read Appendix F of any compiler manual so I could find ways to get
down to the machine level, do workarounds, and migrate back to my original
assembler programmer roots.   It took me quite a while to finally understand
the value of limited types, the strict model that separates scope and
visibility,
and other important [engineering] ideas unique to Ada.

As to C and C++, the rules are much more relaxed at the outset than they
are in Ada.  It is difficult to take a language that is not type-safe and get
programmers to make it type-safe than it is to take a language that is
type-safe and selectively relax the rules - something we do routinely
in Ada.

Richard Riehle

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

[adaworks]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1110645475.497596@athnrd02...
>
> There are compliance tests for C++ too.
>
True.   However, I have never known a single DoD contractor
to require a validated C++ compiler.  I have never heard of
a single DoD program manager who rquired a validated C++
compiler.   If anyone did demand this level of rigor, there would
be far less C++ used by DoD contractors, but there might also
be some improvement, ultimately, in C++ compilers.

If someone chooses Ada for a military project, one of the first
questions from the program manager is, "Is the compiler validated?"
Ada is almost always held  to a higher standard that we other
languages - and this is as it should be.

Still, when we hold one development environment (an Ada compiler)
to a higher standard, we need to understand that difference when
making comparions.  It costs a great deal more money to produce
a compiler that must pass validation (now conformity) than to
create one in which the defects are intended to be discovered
by the users and fixed in some future release.

Richard Riehle

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

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc4qfdoqzd.fsf@shell01.TheWorld.com...
>
> ...but of course there's a lot of market pressure to produce
> standard-conforming compilers, for those languages that have official
> standards (Ada, C, C++, Fortran, Cobol, etc).
>
Not Eiffel?

Richard Riehle

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

[Jerry Coffin]

adaworks@sbcglobal.net wrote:
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wcc4qfdoqzd.fsf@shell01.TheWorld.com...
> >
> > ...but of course there's a lot of market pressure to produce
> > standard-conforming compilers, for those languages that have
> > official standards (Ada, C, C++, Fortran, Cobol, etc).
> >
> Not Eiffel?

TTBOMK, Eiffel doesn't have an official standard. If there was an ISO
standard, it would naturally fall under JTC1/SC22, but the ISO
JTC1/SC22 web site: http://www.open-std.org/jtc1/sc22/, doesn't mention
Eiffel anywhere.

Searching for Eiffel on the ANSI, ECMA and IEEE web sites fails to turn
up anything positive either -- ANSI and ECMA come up completely dry and
while IEEE cites a number of papers on Eiffel, none that I could find
looked like an official standard.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Yermat]

Jerry Coffin wrote:
> adaworks@sbcglobal.net wrote:
> 
>>"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
>>news:wcc4qfdoqzd.fsf@shell01.TheWorld.com...
>>
>>>...but of course there's a lot of market pressure to produce
>>>standard-conforming compilers, for those languages that have
>>>official standards (Ada, C, C++, Fortran, Cobol, etc).
>>>
>>
>>Not Eiffel?
> 
> 
> TTBOMK, Eiffel doesn't have an official standard. If there was an ISO
> standard, it would naturally fall under JTC1/SC22, but the ISO
> JTC1/SC22 web site: http://www.open-std.org/jtc1/sc22/, doesn't mention
> Eiffel anywhere.
> 
> Searching for Eiffel on the ANSI, ECMA and IEEE web sites fails to turn
> up anything positive either -- ANSI and ECMA come up completely dry and
> while IEEE cites a number of papers on Eiffel, none that I could find
> looked like an official standard.

http://www.eiffel-nice.org/standards/

Eiffel The Language 2nd Printing
Bertrand Meyer's book describes the Eiffel language, and was adopted by 
NICE as the language standard.

-- 
Yermat

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

[Robert A Duff]

"Jerry Coffin" <jcoffin@taeus.com> writes:

> adaworks@sbcglobal.net wrote:
> > "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> > news:wcc4qfdoqzd.fsf@shell01.TheWorld.com...
> > >
> > > ...but of course there's a lot of market pressure to produce
> > > standard-conforming compilers, for those languages that have
> > > official standards (Ada, C, C++, Fortran, Cobol, etc).
> > >
> > Not Eiffel?
> 
> TTBOMK, Eiffel doesn't have an official standard. If there was an ISO
> standard, it would naturally fall under JTC1/SC22, but the ISO
> JTC1/SC22 web site: http://www.open-std.org/jtc1/sc22/, doesn't mention
> Eiffel anywhere.
> 
> Searching for Eiffel on the ANSI, ECMA and IEEE web sites fails to turn
> up anything positive either -- ANSI and ECMA come up completely dry and
> while IEEE cites a number of papers on Eiffel, none that I could find
> looked like an official standard.

I think ECMA is working on an Eiffel standard.

See:

http://www.ecma-international.org/memento/TC39-TG4.htm

- Bob

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Robert A Duff]

azdo_b@yahoo.es (Alberto) writes:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<1lr611thktbau$.1dj95z21h7l5v.dlg@40tude.net>...
> > But even then bounds checking is not needed for every access. Example:
> > 
> > procedure Dynamic (A : Some_Array) is
> >    subtype Index is Array_Index range A'Range;
> >    J : Index := A'First;
> > 
> >    for I in A'Range loop
> >       A (I) := .. -- No checks
> >       ...
> >       J := I;
> >    end loop;
> >    A (J) := ... -- Still no checks
> > 
> > C++ completely lacks the notion of constrained subtypes which makes the
> > above possible.
> 
> If Some_Array is any array supplied at run-time, how can the compiler
> know what values are stored in A'Range? (I mean, what the bounds of
> the array are) It *has* to check these bounds at run-time. 

No, that's not correct.  Some compilers can and do prove that I is
within the bounds of A, and therefore avoid generating any checking
code.  Neither the array bounds, nor the value of I, need be known
at compile time.

In general, if *you* can prove something about a program, then it is
possible to teach a compiler to do so.  Not necessarily *feasible*, but
*possible*.  This is related to what Appel calls the "full employment
act for compiler writers" or some such -- no matter how smart a compiler
is, it's always possible to write a smarter one.

But in the above code, it is both possible and feasible to eliminate
*all* of the bounds checking.  Thus, there's no need to suppress checks
on the above code.

> > 2. C++ is unable to allocate objects of indefinite size on the stack.
> 
> Well, we have alloca() for this ;)

Is alloca part of the C++ standard?  I thought not, but I could be
wrong.  Anyway, alloca doesn't really do all that Ada can do in this
regard (avoiding heap usage for dynamic-sized things).  In this case,
the Ada feature is both more efficient and safer than alloca.

- Bob

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Robert A Duff]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Ioannis Vranos wrote:
> 
> > Actually the Boost type that you are probably looking for is:
> > "uint_value_t: The smallest built-in unsigned integral type that
> > supports the given value as a maximum. The parameter should be a
> > positive number."
> 
> 
> 
> So the example becomes:
> 
> #include <boost/integer.hpp>
> 
> 
> int main()
> {
>      using namespace boost;
> 
>      // Value range 0..16
>      uint_value_t<16>::least my_var;
> 
>      my_var= 9;
> }
> 
> > This is the equivalent of 0..whatever.
> > Myself thinks though that this whole range specialisation thing is
> > non-sense for regular application programming at least.
> 
> Indeed. :-)

Ah, so Ioannis Vranos agrees with Ioannis Vranos here,
so it must be true?  ;-)

Actually, integer subranges are quite useful.  For example, in some
cases they allow the compiler to ensure (without any run time checking)
that the integer index into an array matches the bounds of that array.
Including in cases where the bounds are not known at compile time.

- Bob

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

[Paul Dietz]

adaworks@sbcglobal.net wrote:

> Still, when we hold one development environment (an Ada compiler)
> to a higher standard, we need to understand that difference when
> making comparions.  It costs a great deal more money to produce
> a compiler that must pass validation (now conformity) than to
> create one in which the defects are intended to be discovered
> by the users and fixed in some future release.

If one has a copy of the validation test suite, why is it necessary
to wait for the users to find the bugs?  Is it that you have to pay
for the cost of fixing the bugs that the users would never encounter?

	Paul

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Robert A Duff wrote:

> Actually, integer subranges are quite useful.  For example, in some
> cases they allow the compiler to ensure (without any run time checking)
> that the integer index into an array matches the bounds of that array.
> Including in cases where the bounds are not known at compile time.

OK, however as I have mentioned before, one can also provide this type 
of guarantees in C++, without any run-time checks:


#include <vector>


int main()
{
     using namespace std;

     vector<int> intVector;

     for(vector<int>::size_type i=0; i<intVector.size(); ++i)
              // ...
}





#include <vector>


int main()
{
     using namespace std;

     vector<int> intVector;

     for(vector<int>::const_iterator p= intVector.begin();
                                              p!=intVector.end(); ++p)
              ;// ...
}




// Not real value, for display purposes only
#include <algorithm>
#include <vector>

inline int doubleF(const int &arg) { return 2*arg; }

// ...

vector<int>someArray(10, 1);

// ...

transform( someArray.begin(), someArray.end(),
            someArray.begin(), doubleF );



etc.




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[adaworks]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1110326720.837893@athnrd02...
>
> It began as "C with classes", but this does not mean "it was designed
> for" that only.
>
And that is the unfortunate aspect of the language:  its foundation on C.

I once heard Stroustrup confess that, if he had had his druthers, he would
not have started with C as the seed language.

Many of the original design ideas for C++ were abandoned to keep the
language more manageable.  For example, delegation was an early idea
that failed to make it into the final design.  Templates were not in the
C++ language until much later.

C++ continues to evolve, but much of that evolution seems to follow a
course of shoring up things already in the language that don't quite work
as one might prefer, or adding a truss here and a buttress there to
prevent or enable deficiencies in the language; e.g., cast-away const,
a truly silly addition to the language.

Finally, one must give credit and admiration to Dr. Stroustrup for the superb
work he did in leveraging a mediocre language such as C into a language
that has caught on with such a wide audience.   One can only wonder, given
his genius, what a great language he might have created if he had not been
an AT&T employee, forced to start with C, those many years ago.

Richard Riehle

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

[adaworks]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]


"Falk Tannh�user" <falk.tannhauser@crf.canon.fr> wrote in message
news:d0n0vg$4oa$1@s1.news.oleane.net...
>
> 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".
>
OK.  Try this in straight C++.

         type Index is range -800_000..12_000_000;
         type Decimal_Fraction is digits 12 range -473.0 .. 2_000.0;

         type Vector is array (Index range <>) of Decimal_Fraction;

         V1 : Vector ( -47..600);   -- note the negative index range
         V2 : Vector (-1.. 10);       -- also a negative index range
         V3 : Vector (42..451);     -- index starts higher than zero;
         ...............................

         function Scan (The_Vector : Vector ; Scan_Value : Decimal_Fraction )
return Natural;
               -- This function can process any of those vector instances
without modification
         .............................
        -- possible implementation of the function
         function Scan(The_Vector : Vector; Scan_Value : Decimal_Fraction )
return Natrual is
               Scan_Count : Natural := 0;  -- Natual begins at zero
         begin
             for I in The_Vector'Range     -- No way to index off the end array
parameter
                 loop
                     if The_Vector(I) = Scan_Value;       -- looking for an
exact match
                         Scan_Count := Scan_Count + 1;  -- increment the count
                     end if;
                 end loop;
                 return Scan_Count;    -- return required; never an implicit
return
        end Scan;
        .....................................................

I submit this in response to the observation someone made about the alleged
added
difficulty Ada imposes on the programmer in flexibility of expressiveness.  In
my
own experience, Ada is far more expressive of a larger range of idioms than C++.
Note my use of the word "expressive."   We can express any idea in any language,
but some languages are more expressive of some ideas than others.

This is just one example of Ada's flexibility in managing arrays.   I could fill
many pages with
more examples.    Of interest, here, is how easy it is to have an array index
that begins at
a value other than zero, and how easy it is to create a function that will
accept any array
of any range defined for that index.    Yes, I know you can do this in C++, but
from my
perspective, it is not nearly as easy, expressive, or readable.

Counter examples to expressiveness can be illustrated in C++.   For example,
many
programmers prefer the += to the x := x + 1 syntax.    This is a minor
convenience
compared to the final program in Ada.

Richard Riehle

                                   Disclaimer:   I did not compile the code
before submitting it so there
                                                      might be some minor
errors.   RR

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

[Ioannis Vranos]

adaworks@sbcglobal.net wrote:

> OK.  Try this in straight C++.
> 
>          type Index is range -800_000..12_000_000;
>          type Decimal_Fraction is digits 12 range -473.0 .. 2_000.0;
> 
>          type Vector is array (Index range <>) of Decimal_Fraction;
> 
>          V1 : Vector ( -47..600);   -- note the negative index range
>          V2 : Vector (-1.. 10);       -- also a negative index range
>          V3 : Vector (42..451);     -- index starts higher than zero;
>          ...............................
> 
>          function Scan (The_Vector : Vector ; Scan_Value : Decimal_Fraction )
> return Natural;
>                -- This function can process any of those vector instances
> without modification
>          .............................
>         -- possible implementation of the function
>          function Scan(The_Vector : Vector; Scan_Value : Decimal_Fraction )
> return Natrual is
>                Scan_Count : Natural := 0;  -- Natual begins at zero
>          begin
>              for I in The_Vector'Range     -- No way to index off the end array
> parameter
>                  loop
>                      if The_Vector(I) = Scan_Value;       -- looking for an
> exact match
>                          Scan_Count := Scan_Count + 1;  -- increment the count
>                      end if;
>                  end loop;
>                  return Scan_Count;    -- return required; never an implicit
> return
>         end Scan;
>         .....................................................
> 
> I submit this in response to the observation someone made about the alleged
> added
> difficulty Ada imposes on the programmer in flexibility of expressiveness.  In
> my
> own experience, Ada is far more expressive of a larger range of idioms than C++.
> Note my use of the word "expressive."   We can express any idea in any language,
> but some languages are more expressive of some ideas than others.


I think you mean something like:


#include <map>
#include <iostream>

int main()
{
    using namespace std;

    map<int, double> id;

    id[-400]= 7.1;

    id[-2500]= -1;

    id[10]= 9;

    id[-300]= 7.1;

    unsigned counter= 0;

    for(map<int, double>::const_iterator p= id.begin(); p!=id.end(); ++p)
    {
        if(p->second== 7.1)
        {
            cout<<"7.1 was found at index "<<p->first<<"\n";

            ++counter;
        }
    }

    cout<<"\n7.1 was found "<<counter<<" times in total.\n";
}


C:\c>temp
7.1 was found at index -400
7.1 was found at index -300

7.1 was found 2 times in total.

C:\c>


I think this is even faster than yours, which scans the entire range.


And a more elegant and with the same efficiency solution:


#include <map>
#include <iostream>
#include <algorithm>


class comp: public std::unary_function<std::pair<int, double>, bool>
{
     const double searchValue;

     public:

         comp(const double value):searchValue(value) {}

         bool operator() (const std::pair<int, double> &arg) const
         {
             if(arg.second==searchValue)
               return true;

             return false;
         }
};



int main()
{
     using namespace std;

     map<int, double> id;

     id[-400]= 7.1;

     id[-2500]= -1;

     id[10]= 9;

     id[-300]= 7.1;

     cout<<"\n7.1 was found "<<count_if(id.begin(), id.end(), comp(7.1))
         <<" times in total.\n";
}


C:\c>temp

7.1 was found 2 times in total.

C:\c>


> 
> This is just one example of Ada's flexibility in managing arrays.   I could fill
> many pages with
> more examples.    Of interest, here, is how easy it is to have an array index
> that begins at
> a value other than zero, and how easy it is to create a function that will
> accept any array
> of any range defined for that index.


In C++ you can create whatever you want. Even a container with abstract 
conceptual features (you are limited only by your imagination).


> Yes, I know you can do this in C++, but
> from my
> perspective, it is not nearly as easy, expressive, or readable.


I think even better. That said, I like enough Ada too. :-)



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Wes Groleau]

adaworks@sbcglobal.net wrote:
> Possibly.   However, I have seen more than enough "hacked" Ada to wonder
> whether, in the hands of the larger community, the unruly would still run amuck,
> even with Ada as their language.   Although the default for most constructs in

I don't know how much effort I've put into persuading colleagues
that an Ada access type and a C pointer are NOT always interchangeable.

Or how many times they turned a deaf ear to my recommendation to
think about a warning (that the source and target of an
unchecked_conversion instantiation were not the same size).

-- 
Wes Groleau

He that is good for making excuses, is seldom good for anything else.
                                     -- Benjamin Franklin

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

[Larry Kilgallen]

In article <d1ngq0$r7e$1@avnika.corp.mot.com>, Paul Dietz <paul.f.dietz@motorola.com> writes:
> adaworks@sbcglobal.net wrote:
> 
>> Still, when we hold one development environment (an Ada compiler)
>> to a higher standard, we need to understand that difference when
>> making comparions.  It costs a great deal more money to produce
>> a compiler that must pass validation (now conformity) than to
>> create one in which the defects are intended to be discovered
>> by the users and fixed in some future release.
> 
> If one has a copy of the validation test suite, why is it necessary
> to wait for the users to find the bugs?  Is it that you have to pay
> for the cost of fixing the bugs that the users would never encounter?

One of the costs of fixing defects not reported by a user is the non-zero
probability that making a change will introduce additional defects.

Clearly that is unacceptable if the chance of some user discovering
the original defect can be proven to be zero.

It is required (someday) if the chance of some user discovering
the original defect can be proven to be one.

Unfortunately, most such probabilities lie somewhere in the vast middle.

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> adaworks@sbcglobal.net wrote:
> 
>> OK.  Try this in straight C++.

>>          type Index is range -800_000..12_000_000;
>>          type Decimal_Fraction is digits 12 range -473.0 .. 2_000.0;
>>
>>          type Vector is array (Index range <>) of Decimal_Fraction;
>>
>>          V1 : Vector ( -47..600);   -- note the negative index range

>>          function Scan (The_Vector : Vector ; Scan_Value : 
>> Decimal_Fraction )
>> return Natural;

>>              for I in The_Vector'Range     -- No way to index off the 

> I think you mean something like:

  [redesigning the problem?]

>    map<int, double> id;
> 
>    id[-400]= 7.1;

>    for(map<int, double>::const_iterator p= id.begin(); p!=id.end(); ++p)

> I think this is even faster than yours, which scans the entire range.

Hm. Searching a *map* of entries at numeric keys is different
from scanning an array of values and counting occurences. What
are you trying to do here?
The std::vector is missing an instantiation argument which adds
the guarantee that no index value is outside the range
  -800_000..12_000_000;
std::map<int, double> is a different beast entirely, with
unknown size. Consider Vector ( -47..600);

(How do you make a subrange of double, which is missing from
your example.)

  Imagine an array shared between a number of threads. The program's
task is to count the number of occurences of a particular value
in the array. Examples:
1)  A shop has 10 unique doors (use an enum). For each door 4 states
     can be measured: open/closed, van/no van at the door.
2)  A 5-player team, each team is identified by number drawn from a fixed
     set of team numbers. An array (an array, not some other data
     structure) measures the number of players from each team present in
     a room. Count the number of odd-team players in a room.

I hope these example illustrate some points. They are not meant to
trigger a discussion as to whether an array is the best data
structure for everything. (Note that it might be necessary to read
values from the array/Vector using random access in O(1), and to
store and replace values in O(1), another reason to use an array.)


> And a more elegant and with the same efficiency solution:
A solution to a different problem, I think.


> In C++ you can create whatever you want. Even a container with abstract 
> conceptual features (you are limited only by your imagination).

You can do that using assembly language or SmallTalk, whatever.
I think this was not the point, but I should have Richard Riehle's
message speak for itself.
For example, look here, and reconsider the programming task as
originally stated:
>> Yes, I know you can do this in C++, but
>> from my
>> perspective, it is not nearly as easy, expressive, or readable.

Georg

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

[adaworks]

"T Beck" <Tracy.Beck@Infineon.com> wrote in message
news:1110556310.367604.271110@g14g2000cwa.googlegroups.com...
>
> Adrien Plisson wrote:
> >
> > Ada is also used in particular rockets called missiles, and its job
> > inside is just to make them fall... but fall gracefully.
>
> Would that happen to include the now-infamous Patriot Missles (the ones
> that couldn't hit a barn after they'd been on for a while due to a
> bug?)

No.  Those missiles were not programmed in Ada.

On the other hand, there have been software failures written
in Ada, just as their have been software failures written in C,
C++, Jovial, Fortran, etc.

The use of Ada does not eliminate to potential for software failure.
No language, by itself, can guarantee there will no defects.  The
best we can hope for, in the current state of software engineering,
is to minimize the risk of failure.

Ada is designed to help reduce risk. That is a primary concern when
choosing Ada.   Still, we are always dealing with tradeoffs.

A language that allows compilers to generate some kind of result for
every syntactic expression, is likely to also permit erroneous constructs.
This is OK when that language is used in the hands of a person who
never makes mistakes.    Of course, as the size of the code grows
larger, and the number of functions increases, human comprehension
begins face more challenges in the management of the complexity.

A language that provides a set of constraints at the outset, such as
Ada, can be annoying for little programming jobs carried out by
one person.   As the software product requires more and more
people, more and more code units, and more and more time to
complete, these constraints can be useful because they prohibit
certain practices that lead to unexpected errors.

Software risk management is becoming a more and more respectable
part of software engineering practice.  Language choice is only one
part of the risk management decision matrix, and we are not going to
enumerate the many other facets of risk here.   However, language
can have an impact on risk.

I have seen software developed in many different languages over a
long period of time.   In my own view, and I don't have formal
research to support this, Ada has had value in reducing risk of
failure "when used as directed."    C++, and the C family in general,
increases the risk of failure simply because one does not have the
built-in constraints that exist in Ada.   A careful programmer can
create excellent, defect-reduced, software in C++.   A sloppy
programmer can grind out horrible, unsafe code in Ada (by
relaxing the built-in constraints).    All in all, though, I see Ada as
more risk averse than most of its competitors.

What is the cost of being risk averse?   That question is open to many
different interpretations.   There certainly is a cost.   Is that cost worth
the level of risk avoidance we hope to achieve with Ada?   The answer
to this question will also vary according to the experience, biases, and
economic decisions favored by those who must make the choices.

Richard Riehle

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

[Larry Kilgallen]

In article <jRT%d.332$FN4.273@newssvr21.news.prodigy.com>, <adaworks@sbcglobal.net> writes:

> A language that provides a set of constraints at the outset, such as
> Ada, can be annoying for little programming jobs carried out by
> one person.   As the software product requires more and more
> people, more and more code units, and more and more time to
> complete, these constraints can be useful because they prohibit
> certain practices that lead to unexpected errors.

I think there is another figure of merit which should be considered
along with the number of programmers -- the proximity of users to a
single programmer.

To support a hobby of mine, I will single-handedly program in TECO
macros (a strong competitor to APL in the write-only-programming race).
I am the only one who runs the program, and there is nowhere else
to point the finger if it fails.

But for real commercial code (one now at about 200,000 sloc), I use
Ada as a single-programmer, since I want my programming failures to
be evident on my computer, not that of the customer of my customer.

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

[fabio de francesco]

Ioannis Vranos wrote:
> adaworks@sbcglobal.net wrote:
>
> > OK.  Try this in straight C++.

> > [skip Ada program]

>
> I think you mean something like:
>

> [skip C++ programs]

> >
> > This is just one example of Ada's flexibility in managing arrays.
I could fill
> > many pages with
> > more examples.    Of interest, here, is how easy it is to have an
array index
> > that begins at
> > a value other than zero, and how easy it is to create a function
that will
> > accept any array
> > of any range defined for that index.
>
>
> In C++ you can create whatever you want. Even a container with
abstract
> conceptual features (you are limited only by your imagination).
>
>
> > Yes, I know you can do this in C++, but
> > from my
> > perspective, it is not nearly as easy, expressive, or readable.
>
>
> I think even better. That said, I like enough Ada too. :-)
>
> --
> Ioannis Vranos

Ciao,

Ioannis wrote a C++ program that in his intentions would had operate
like the Ada code that was provided as an example of language
expressiveness.

Unfortunatelly that C++ code doesn't resembles the Ada one. Have a
closer look at what Richard wrote:

type Index is range -800_000..12_000_000;
type Decimal_Fraction is digits 12 range -473.0 .. 2_000.0;
type Vector is array (Index range <>) of Decimal_Fraction;

V1 : Vector ( -47..600);   -- note the negative index range
V2 : Vector (-1.. 10);       -- also a negative index range
V3 : Vector (42..451);     -- index starts higher than zero;

He instantiated three arrays that contain elements of type
Decimal_Fraction, each of them is 12 or more digits in whatever machine
the program can compile and each variable of the type is checked to be
in range -473.0 .. 2_000.0.
Each single array has a different number of elements and no array with
more than 12_800_001 elements is permitted to be created.

Furthermore you used a tree (std::map<> is often implemented as a
red-black tree) to be read sequentially in searching the second
element. I don't think this is the most efficient way to implement what
it is better thought to be an array. I mean that if I always have to
read every element from the beginning to the end I would prefer to
insert them in a vector.

Now I remember that you wrote "This is faster than yours scanning the
entire range". Now I can be wrong, since I don't know either enough C++
and Ada too,  but it seems that you scanned the entire range too. Is it
not true? Anyway I suppose that Richard attention was to array
declarations and not to function operating on them.

Regards,

fabio de francesco

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> Hm. Searching a *map* of entries at numeric keys is different
> from scanning an array of values and counting occurences. What
> are you trying to do here?


Just using the appropriate available container. :-)


> The std::vector is missing an instantiation argument which adds
> the guarantee that no index value is outside the range
>  -800_000..12_000_000;


vector provides method at() that performs range checking. Also if you 
want a vector that has signed integer subscripts or even floating point, 
you can easily write one. However this does not "feel" C++ whose built 
in arrays always store elements from index 0 and upwards.



> std::map<int, double> is a different beast entirely, with
> unknown size. Consider Vector ( -47..600);
> 
> (How do you make a subrange of double, which is missing from
> your example.)



Do you mean like this?

#include <map>
#include <iostream>

int main()
{
    using namespace std;

    map<double, double> id;

    id[-400.1]= 7.1;

    id[-2500.6]= -1;

    id[10.43]= 9;

    id[-300.65]= 7.1;

    unsigned counter= 0;

    for(map<double, double>::const_iterator p= id.begin(); p!=id.end(); ++p)
    {
        if(p->second== 7.1)
        {
            cout<<"7.1 was found at index "<<p->first<<"\n";

            ++counter;
        }
    }

    cout<<"\n7.1 was found "<<counter<<" times in total.\n";
}


C:\c>temp
7.1 was found at index -400.1
7.1 was found at index -300.65

7.1 was found 2 times in total.

C:\c>



You can also check the entire range if you want. Here the previous style 
along with your full-range (expensive) style:


#include <map>
#include <iostream>

int main()
{
    using namespace std;

    map<int, double> id;

    id[-400]= 7.1;

    id[-2500]= -1;

    id[10]= 9;

    id[-300]= 7.1;

    unsigned counter= 0;

    for(map<int, double>::const_iterator p= id.begin(); p!=id.end(); ++p)
    {
        if(p->second== 7.1)
        {
            cout<<"7.1 was found at index "<<p->first<<"\n";

            ++counter;
        }
    }

    cout<<"\n7.1 was found "<<counter<<" times in total.\n\n\n";


    // Checks *each* range from -2500 to 10
    counter=0;
    for(int i= -2500; i<10; ++i)
    {
         if(id[i]== 7.1)
         {
             cout<<"7.1 was found at index "<<i<<"\n";

             ++counter;
         }
     }

     cout<<"\n7.1 was found "<<counter<<" times in total.\n";
}


"for(int i= -2500; i<10; ++i)" can also be written as

for(int i= id.begin()->first; i<(--id.end())->first; ++i)

if you want this kind of abstraction. But better abstraction is the 
iterator approach and the *best* the count family which (iterator and 
count family) work with *all* containers.


These are bullet-proof code approaches.



>  Imagine an array shared between a number of threads. The program's
> task is to count the number of occurences of a particular value
> in the array. Examples:
> 1)  A shop has 10 unique doors (use an enum).


We can use whatever I like, perhaps strings. What is wrong with "Door 1" 
etc?  :-)


> For each door 4 states
>     can be measured: open/closed, van/no van at the door.


OK, this sounds easy. What do you think? Since you want an array:


#include <vector>
#include <algorithm>
#include <functional>
#include <iostream>

class Door
{
     bool open, van;

     public:
         Door(){ open= van= true; }

         bool IsOpen() const { return open; }
         bool IsClosed() const { return !open; }
         bool IsVan() const { return van; }
         bool IsNoVan() const { return !van; }

         Door &SetOpen() { open= true; return *this; }
         Door &SetClosed() { open= false; return *this; }
         Door &SetVan() { van= true; return *this; }
         Door &SetNoVan() { van= false; return *this; }
};

class CheckOpen
{
     bool open, van;

     public:
         CheckOpen(bool isopen, bool isvan):open(isopen), van(isvan) {}

         bool operator() (const Door &arg)
         {
             return open== arg.IsOpen() && van== arg.IsVan();
         }
};


int main()
{
     using namespace std;

     vector<Door> doors(10);

     doors[4].SetOpen().SetNoVan();

     unsigned counter= count_if(doors.begin(), doors.end(),
                                              CheckOpen(true, false));

     cout<<"Counted "<<counter<<" occurrences.\n";
}


C:\c>temp
Counted 1 occurrences.

C:\c>




> 2)  A 5-player team, each team is identified by number drawn from a fixed
>     set of team numbers. An array (an array, not some other data
>     structure) measures the number of players from each team present in
>     a room. Count the number of odd-team players in a room.


This is easy too. I do not get your point. This can be done with arrays 
as also with other containers. Why should we be restricted to one type 
of container?



> I hope these example illustrate some points. They are not meant to
> trigger a discussion as to whether an array is the best data
> structure for everything. (Note that it might be necessary to read
> values from the array/Vector using random access in O(1), and to
> store and replace values in O(1), another reason to use an array.)


OK.


>> In C++ you can create whatever you want. Even a container with 
>> abstract conceptual features (you are limited only by your imagination).
> 
> 
> You can do that using assembly language or SmallTalk, whatever.
> I think this was not the point, but I should have Richard Riehle's
> message speak for itself.



I am not talking about assembly. It is not difficult to write a 
container getting a signed integer as a subscript and have range checking.




> For example, look here, and reconsider the programming task as
> originally stated:
> 
>>> Yes, I know you can do this in C++, but
>>> from my
>>> perspective, it is not nearly as easy, expressive, or readable.


I think it is probably more and at least the same. That said, I like Ada 
somewhat. :-)



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

fabio de francesco wrote:

> Ciao,
> 
> Ioannis wrote a C++ program that in his intentions would had operate
> like the Ada code that was provided as an example of language
> expressiveness.
> 
> Unfortunatelly that C++ code doesn't resembles the Ada one. Have a
> closer look at what Richard wrote:
> 
> type Index is range -800_000..12_000_000;
> type Decimal_Fraction is digits 12 range -473.0 .. 2_000.0;
> type Vector is array (Index range <>) of Decimal_Fraction;
> 
> V1 : Vector ( -47..600);   -- note the negative index range
> V2 : Vector (-1.. 10);       -- also a negative index range
> V3 : Vector (42..451);     -- index starts higher than zero;


It isn't difficult to implement a vector that accepts signed ranges too 
*with* range-checking, the default ones begin from 0 because this is the 
C++ natural feel. vector::at() performs range checked access.


#include <vector>
#include <exception>
#include <iostream>


int main() try
{
     std::vector<int> vec(10);

     vec.at(12)=4;


}

catch(std::exception &e)
{
     std::cerr<<e.what()<<"\n";
}


C:\c>temp
invalid vector<T> subscript

C:\c>



In other words it does not make much sense to have signed indexes. 
Otherwise it is easy and possible.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Frank J. Lhota]

<adaworks@sbcglobal.net> wrote in message 
news:9lK%d.186$FN4.48@newssvr21.news.prodigy.com...
> And that is the unfortunate aspect of the language:  its foundation on C.
>
> I once heard Stroustrup confess that, if he had had his druthers, he would
> not have started with C as the seed language.

Stroustrup said in an interview that his preference would have been Algol 
with classes.

I think that I probably would have preferred that as well!

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

[Robert A Duff]

"Frank J. Lhota" <NOSPAM.Lhota.adarose@verizon.net> writes:

> <adaworks@sbcglobal.net> wrote in message 
> news:9lK%d.186$FN4.48@newssvr21.news.prodigy.com...
> > And that is the unfortunate aspect of the language:  its foundation on C.
> >
> > I once heard Stroustrup confess that, if he had had his druthers, he would
> > not have started with C as the seed language.
> 
> Stroustrup said in an interview that his preference would have been Algol 
> with classes.

Hmm...  Isn't that language called Simula 67?  ;-)

> I think that I probably would have preferred that as well!

- Bob

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> I hope these example illustrate some points. They are not meant to
> trigger a discussion as to whether an array is the best data
> structure for everything. (Note that it might be necessary to read
> values from the array/Vector using random access in O(1), and to
> store and replace values in O(1), another reason to use an array.)


I forgot to say here that the cost of map's operator[] is O(log(n)) 
which is fairly cheap for large amount of data.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[red floyd]

Robert A Duff wrote:
> "Frank J. Lhota" <NOSPAM.Lhota.adarose@verizon.net> writes:
>>Stroustrup said in an interview that his preference would have been Algol 
>>with classes.

> Hmm...  Isn't that language called Simula 67?  ;-)
Darn!  YOu beat me to it!

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> Georg Bauhaus wrote:

> I forgot to say here that the cost of map's operator[] is O(log(n)) 
> which is fairly cheap for large amount of data.

compare O(log(n)) to O(1) where n is 1, 1000, 1_000_000.
Make this access a part of an inner loop.

Georg 

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> Georg Bauhaus wrote:
> 
>> Hm. Searching a *map* of entries at numeric keys is different
>> from scanning an array of values and counting occurences. What
>> are you trying to do here?
> 
> 
> 
> Just using the appropriate available container. :-)

Nope.

>> The std::vector is missing an instantiation argument which adds
>> the guarantee that no index value is outside the range
>>  -800_000..12_000_000;
> 
> 
> 
> vector provides method at() that performs range checking.

I think we've been through this. Again, this is not the point.

> Also if you 
> want a vector that has signed integer subscripts or even floating point,

We want a vector type indexed by values between M and N only *and* we
want the compiler + tools to help us make data structures in accord
with these ranges. We want it to take advantage of what it can learn
from the type system which allows index range checking _at compile time_.

>> (How do you make a subrange of double, which is missing from
>> your example.)
> 
> 
> 
> 
> Do you mean like this?

No. I mean a double subtype whose values range from N.M to N'.M'.

I think you are missing the point here. As someone else said this is
not about functions operating on containers.


> [STL for constructs] These are bullet-proof code approaches.

Unfortunatly, this is not relevant in this discussion, which is not
just about algorithms.

>>  Imagine an array shared between a number of threads. The program's
>> task is to count the number of occurences of a particular value
>> in the array. Examples:
>> 1)  A shop has 10 unique doors (use an enum).

> We can use whatever I like, perhaps strings. What is wrong with "Door 1" 
> etc?  :-)

I see the smiley but this is what might be wrong with your
approach: a map indexed by strings is not the same as an array
indexed by ten and only ten numbers. (Actually the numbers are in a
type which includes only 10 numbers and their operations.)

Imagine a Matrix. String indexing of matrix element seems possible
but you'd rather have proper arrays. There is something
wrong with ("Row 5", "Column 1") indexing unless you have very much
time and a lot of RAM.

>> For each door 4 states
>>     can be measured: open/closed, van/no van at the door.
> 
> 
> 
> OK, this sounds easy. What do you think? Since you want an array:

>         bool operator() (const Door &arg)

Nice. However, operator() doesn't return one out of four states,
it returns a Boolean, but o.K.
(If the door is closed and there is a van, you still want some action to
take place. Likewise for the other cases. I know you can write this,
no need as this is not the point, see below)

>         {
>             return open== arg.IsOpen() && van== arg.IsVan();
>         }


>     vector<Door> doors(10);

Here you can see one point that you might want to demonstrate:
The compiler won't tell you that there is something wrong
with

   doors[10].SetOpen().SetNoVan();

Worse, the program won't tell you either. This shows the missing
link between vector indexing and the base type system in your
approach. You could use

   doors.at(10).SetOpen().SetNoVan();

and handle the exception _at run time_.
In Ada, the compiler will tell you: "index value 10 is no good!"
because the array "doors" can only be indexed by values effectively
between 0 .. 9. These and only these are the values of the type
enumerating the ten doors, and only these are allowed as index
values x in expressios doors(x).
No exception handling, no .at() needed when you listen to your
compiler and fix the indexing error before you deliver a program.
You get this for free as a result of the language's type handling
at compile time.


>> 2)  A 5-player team, each team is identified by number drawn from a fixed
>>     set of team numbers. An array (an array, not some other data
>>     structure) measures the number of players from each team present in
>>     a room. Count the number of odd-team players in a room.
> 
> 
> 
> This is easy too. I do not get your point. This can be done with arrays 
> as also with other containers. Why should we be restricted to one type 
> of container?

There is a reason that arrays still exist. One of the reasons
should be obvious when comp.realtime is on the recipient list.
Again, imagine a wave file manipulation process. 
A map indexed by strings is probably not the recommended container
when you need fast matrix computations. In fact, a map might not be
suitable at all irrespective of its key type, when r/w should be in O(1).

- Given an enum, and
- given a language that allows the enum as a basis for the construction
 of an array type in the type system (not using some run time computation
 method, like those you have shown here, IINM)
- given that the compiler can use its knowledge of the enum
 + when it sees an array type based on the enum
 + when it sees an array
 + when it sees an array indexed by a statically known enum value
 + etc.,
you have
(a) useful names for objects in your problem domain, checked at compile-time
(b) a conceptual link between the enum (naming the single items) and
   a container _type_ (containing these items); you cannot use anything
   but these named numbers for indexing
(c) the fastest possible access, for both reading and writing, possibly
   checked at compile time
(d) etc.

The STL descriptions provide further reaonsing why there can be restrictions
on the uses of specific containers in specific situations, viz. O(f(n)).


>> I hope these example illustrate some points. They are not meant to
>> trigger a discussion as to whether an array is the best data
>> structure for everything. (Note that it might be necessary to read
>> values from the array/Vector using random access in O(1), and to
>> store and replace values in O(1), another reason to use an array.)

What if a compiler or other tool can show that in the following expression
(pseudo notation)

  array_variable.at_index [n + m]  <-  f(x)

does not need an index range check on the lhs? (Again, yes, it is possible
to write correct programs. The question is, does one notation + compilation
system have advantages when compared to another? What is the price to pay?)

>  It is not difficult to write a 
> container getting a signed integer as a subscript and have range checking.

Which is not the point.

Georg 

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

[Randy Brukardt]

"Paul Dietz" <paul.f.dietz@motorola.com> wrote in message
news:d1ngq0$r7e$1@avnika.corp.mot.com...
> adaworks@sbcglobal.net wrote:
>
> > Still, when we hold one development environment (an Ada compiler)
> > to a higher standard, we need to understand that difference when
> > making comparions.  It costs a great deal more money to produce
> > a compiler that must pass validation (now conformity) than to
> > create one in which the defects are intended to be discovered
> > by the users and fixed in some future release.
>
> If one has a copy of the validation test suite, why is it necessary
> to wait for the users to find the bugs?  Is it that you have to pay
> for the cost of fixing the bugs that the users would never encounter?

I'm not quite sure what your point is. But I think Richard was comparing a
compiler that was conformity tested against one that was not. So, such a
system wouldn't have been tested against any test suite.

Of course, in actual practice, there is a continuum of testing practice,
from formal conformity assessment to completely untested. I doubt that there
are many commercial systems on either extreme of that continuum, but Ada
systems tend to be close to the formally tested end.

                           Randy.

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

[Ioannis Vranos]

Georg Bauhaus wrote:

 > We want a vector type indexed by values between M and N only *and* we
 > want the compiler + tools to help us make data structures in accord
 > with these ranges. We want it to take advantage of what it can learn
 > from the type system which allows index range checking _at compile time_.


At first, it is easy to write a container in C++ that accepts a 
specified range for indexes. The only reason that there is not one, is 
because it does not make sense in C++ (when I learned some Pascal in the 
past, I could not understand what was the use of the ability to use 
negative indexes in arrays. The [0, +] style maps closely what is 
happening in the machine.

Also it is possible to define range-checked at run-time, operations. 
vector::at() is an example.


vector is also a dynamic-type array, so placing compile-time bounds 
checking isn't possible/doesn't make sense.


For fixed size arrays and containers it is true, the compiler does not 
catch at compile time any out of boundaries access. However we can do 
this explicitly, by using compile-time checked assertions. For example:


#include <vector>
#include <boost/static_assert.hpp>

int main()
{
     using namespace std;

     const int MAX_SIZE=10;

     vector<int> vec(MAX_SIZE);


     // Many lines of code


     BOOST_STATIC_ASSERT(10<MAX_SIZE);

     vec[10]=4;
}


C:\c\temp.cpp In function `int main()':

14 C:\c\temp.cpp incomplete type `boost::STATIC_ASSERTION_FAILURE< 
false>' used in nested name specifier




 > No. I mean a double subtype whose values range from N.M to N'.M'.


May you give an example for a container along with such a subtype?



 > Here you can see one point that you might want to demonstrate:
 > The compiler won't tell you that there is something wrong
 > with
 >
 >   doors[10].SetOpen().SetNoVan();
 >
 > Worse, the program won't tell you either. This shows the missing
 > link between vector indexing and the base type system in your
 > approach. You could use
 >
 >   doors.at(10).SetOpen().SetNoVan();
 >
 > and handle the exception _at run time_.
 > In Ada, the compiler will tell you: "index value 10 is no good!"
 > because the array "doors" can only be indexed by values effectively
 > between 0 .. 9. These and only these are the values of the type
 > enumerating the ten doors, and only these are allowed as index
 > values x in expressios doors(x).
 > No exception handling, no .at() needed when you listen to your
 > compiler and fix the indexing error before you deliver a program.
 > You get this for free as a result of the language's type handling
 > at compile time.


Will the Ada compiler tell you this, for user-defined types too? Or is 
this restricted to built-in arrays? If the latest is true, then its 
value isn't that much.


 > There is a reason that arrays still exist. One of the reasons
 > should be obvious when comp.realtime is on the recipient list.
 > Again, imagine a wave file manipulation process. A map indexed by
 > strings is probably not the recommended container
 > when you need fast matrix computations. In fact, a map might not be
 > suitable at all irrespective of its key type, when r/w should be in O(1).


OK, although O(log(n)) is fairly cheap, let's stick to O(1). However 
personally I think that the value of defined subranges in the style 
-1000, -400 has not any practical use.


 > - Given an enum, and
 > - given a language that allows the enum as a basis for the construction
 > of an array type in the type system (not using some run time computation
 > method, like those you have shown here, IINM)
 > - given that the compiler can use its knowledge of the enum
 > + when it sees an array type based on the enum
 > + when it sees an array
 > + when it sees an array indexed by a statically known enum value
 > + etc.,
 > you have
 > (a) useful names for objects in your problem domain, checked at
 > compile-time


What do you mean by names?


 > (b) a conceptual link between the enum (naming the single items) and
 >   a container _type_ (containing these items); you cannot use anything
 >   but these named numbers for indexing


Which has no value in the world of C++, but I guess many things in Ada 
depend on this.


 > (c) the fastest possible access, for both reading and writing, possibly
 >   checked at compile time


Fastest possible access in C++. Checked at run-time. Explicitly checked 
at compile-time with compile-time assertions (which are restricted only 
to constants), but is the Ada compile-time boundaries checking available 
to user-defined containers? If not, can compile-time assertions be used?



 > (d) etc.
 >
 > The STL descriptions provide further reaonsing why there can be
 > restrictions
 > on the uses of specific containers in specific situations, viz. >O(f(n)).


The access of vector, deque, string, valarray and bitset (and built in 
arrays) is O(1) and of map O(log(n)) which is fairly cheap.

If you have access to TC++PL 3, you may check page 17.1.2 on page 464.



 >>> I hope these example illustrate some points. They are not meant to
 >>> trigger a discussion as to whether an array is the best data
 >>> structure for everything. (Note that it might be necessary to read
 >>> values from the array/Vector using random access in O(1), and to
 >>> store and replace values in O(1), another reason to use an array.)
 >
 >
 > What if a compiler or other tool can show that in the following 
expression
 > (pseudo notation)
 >
 >  array_variable.at_index [n + m]  <-  f(x)
 >
 > does not need an index range check on the lhs? (Again, yes, it is 
possible
 > to write correct programs. The question is, does one notation + 
compilation
 > system have advantages when compared to another? What is the price to 
pay?)


Apart from being eager to see whether this compile-time range checking 
is available to user-defined containers, :-) in C++ there is no much 
need for run-time boundary checking, if programming properly. Of course 
one can always program improperly. :-)



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Georg Bauhaus wrote:

>> I forgot to say here that the cost of map's operator[] is O(log(n)) 
>> which is fairly cheap for large amount of data.
> 
> 
> compare O(log(n)) to O(1) where n is 1, 1000, 1_000_000.
> Make this access a part of an inner loop.



If you do the maths, you will see that log(10^6) isn't that large.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Pascal Obry]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> arrays. The [0, +] style maps closely what is happening in the machine.

Certainly. But the Ada model can maps more closely to the domain problem.
And this is an important point. We are not writting software for the machine
but to solve problems. Most of the time you just don't care how such data will
be handled by the machine (i.e. how the compiler will generate the 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

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

[Ioannis Vranos]

Pascal Obry wrote:

> Ioannis Vranos <ivr@remove.this.grad.com> writes:
> 
> 
>>arrays. The [0, +] style maps closely what is happening in the machine.
> 
> 
> Certainly. But the Ada model can maps more closely to the domain problem.
> And this is an important point. We are not writting software for the machine
> but to solve problems. Most of the time you just don't care how such data will
> be handled by the machine (i.e. how the compiler will generate the code).


C++ maps on both. However I guess Ada maps on both too since it is a 
systems programming language. :-)


Now may you explain how the ability to use negative subranges for built 
in array indices makes Ada better for any domain problem?



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Pascal Obry]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Now may you explain how the ability to use negative subranges for built in
> array indices makes Ada better for any domain problem?

For a domain problem where you have to create an area centered on (0,0)
for example. What about a vector representing altitude, the sub-zero values
being under the water. Just some examples, I bet you'll be able to think about
lot more :)

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

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

[Vinzent 'Gadget' Hoefler]

Ioannis Vranos wrote:

> Georg Bauhaus wrote:
> 
>>> I forgot to say here that the cost of map's operator[] is O(log(n))
>>> which is fairly cheap for large amount of data.
>> 
>> compare O(log(n)) to O(1) where n is 1, 1000, 1_000_000.
>> Make this access a part of an inner loop.
> 
> If you do the maths, you will see that log(10^6) isn't that large.

Yeah, right. Binary searches are not much slower. Only about 10 or 20
times. Seem, you just rendered hashing algorithms obsolete. 


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

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

[Ioannis Vranos]

Pascal Obry wrote:

> For a domain problem where you have to create an area centered on (0,0)
> for example. What about a vector representing altitude, the sub-zero values
> being under the water. Just some examples, I bet you'll be able to think about
> lot more :)


I think an associative container like map fits better to this. What do 
you do in Ada if you want to associate product names with prices, in the 
style


productlist["something"]= 71.2;


or a name with a number (string with string) in an address book 
application for example?


namelist["Obry Pascal"]="321-45563";


Also may you tell me if that famous compile-time boundary checking 
applies (can be used) to user-defined containers too?



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Pascal Obry]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> I think an associative container like map fits better to this. What do you do
> in Ada if you want to associate product names with prices, in the style
> 
> 
> productlist["something"]= 71.2;
> 
> 
> or a name with a number (string with string) in an address book application
> for example?
> 
> 
> namelist["Obry Pascal"]="321-45563";

We use a map, using the Ada.Containers STL like library.

> Also may you tell me if that famous compile-time boundary checking applies
> (can be used) to user-defined containers too?

What do you mean by that ? You want to restric a map index ?

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

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

[Ioannis Vranos]

Vinzent 'Gadget' Hoefler wrote:

> Yeah, right. Binary searches are not much slower. Only about 10 or 20
> times. Seem, you just rendered hashing algorithms obsolete. 


OK, one can use a third-party hashed container then, like a hash_map:


#include <hash_map>
#include <iostream>

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

    hash_map<double, double> id;

    id[-400.1]= 7.1;

    id[-2500.6]= -1;

    id[10.43]= 9;

    id[-300.65]= 7.1;

    unsigned counter= 0;

    for(hash_map<double, double>::const_iterator p= id.begin();
                                                        p!=id.end(); ++p)
    {
        if(p->second== 7.1)
        {
            cout<<"7.1 was found at index "<<p->first<<"\n";

            ++counter;
        }
    }

    cout<<"\n7.1 was found "<<counter<<" times in total.\n";
}


and using std::count_if in a integral indices case:


#include <hash_map>
#include <iostream>
#include <algorithm>


class comp: public std::unary_function<std::pair<int, double>, bool>
{
     const double searchValue;

     public:

         comp(const double value):searchValue(value) {}

         bool operator() (const std::pair<int, double> &arg) const
         {
             if(arg.second==searchValue)
               return true;

             return false;
         }
};



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

     hash_map<int, double> id;

     id[-400]= 7.1;

     id[-2500]= -1;

     id[10]= 9;

     id[-300]= 7.1;

     cout<<"\n7.1 was found "<<count_if(id.begin(), id.end(), comp(7.1))
         <<" times in total.\n";
}



C:\c>temp

7.1 was found 2 times in total.

C:\c>



We can also check the entire range of indices, in which case the map 
(and the third party hash_map) returns 0 (of the value type) on case 
that there is no entry.

In other words only the entries occupy space while the no-entries occupy 
no space.


Thus if not the entire range is used, the iterator/count_if approach is 
faster than the entire range check.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Pascal Obry wrote:

>>Also may you tell me if that famous compile-time boundary checking applies
>>(can be used) to user-defined containers too?
> 
> 
> What do you mean by that ? You want to restric a map index ?

In the "STL like" library do you have something like valarray or vector?



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> Georg Bauhaus wrote:
> 
>>> I forgot to say here that the cost of map's operator[] is O(log(n)) 
>>> which is fairly cheap for large amount of data.
>>
>>
>>
>> compare O(log(n)) to O(1) where n is 1, 1000, 1_000_000.
>> Make this access a part of an inner loop.
> 
> If you do the maths, you will see that log(10^6) isn't that large.

Compare log(10^6) to 1.

I can't see how O(log(n)) isn't huge when compared to
O(1), in an inner loop for containers of size 10^6.


Georg

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> What do 
> you do in Ada if you want to associate product names with prices, in the 
> style

Once again you are trying to escape the problem...
We are not discussing the value of a map. We are not
debating it either.

A map *is* most valuable. A map is *not* a vector.
Sometimes you *need* a vector. A vector is *not* a convenient
replacement for a map in C++.

And of course there are maps for Ada, but this is OT.

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> Compare log(10^6) to 1.
> 
> I can't see how O(log(n)) isn't huge when compared to
> O(1), in an inner loop for containers of size 10^6.

OK, but besides the fact that only explicit entries in map occupy space, 
and the rest keys return 0, which means that the search and counting of 
a value is faster than an array in case that no the entire range is 
under use, there are also third-party hashed containers, including 
hashed maps.

Also, as I said it is not difficult to define an array that takes 
arbitrary signed ranges, but this does not make much sense in C++.


In other words, the direct equivalent of your array is probably 
valarray/vector, ignoring the signed ranges.


BTW, the compile-time boundary checks you have been mentioning, sounds 
like they are restricted to built-in arrays, which means is not of much use.


Also the lack of a "STL like" library in Ada until now probably sounds 
like that Ada lacks much of the high-level abstraction that C++ provides.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> Once again you are trying to escape the problem...
> We are not discussing the value of a map. We are not
> debating it either.
> 
> A map *is* most valuable. A map is *not* a vector.
> Sometimes you *need* a vector. A vector is *not* a convenient
> replacement for a map in C++.
> 
> And of course there are maps for Ada, but this is OT.


OK, one can use a vector then. And as I said in other messages, it is 
not difficult to define an array that takes arbitrary signed ranges, but 
this does not make much sense in C++.


In other words, the direct equivalent of your array is probably 
valarray/vector, ignoring the signed ranges.


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Ioannis Vranos wrote:

> OK, one can use a vector then. And as I said in other messages, it is 
> not difficult to define an array that takes arbitrary signed ranges, but 
> this does not make much sense in C++.
> 
> 
> In other words, the direct equivalent of your array is probably 
> valarray/vector, ignoring the signed ranges.


BTW does Ada provide dynamic arrays like vector/deque?



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Dmitry A. Kazakov]

On Wed, 23 Mar 2005 12:36:46 +0200, Ioannis Vranos wrote:

> Pascal Obry wrote:
> 
>> For a domain problem where you have to create an area centered on (0,0)
>> for example. What about a vector representing altitude, the sub-zero values
>> being under the water. Just some examples, I bet you'll be able to think about
>> lot more :)
> 
> I think an associative container like map fits better to this. What do 
> you do in Ada if you want to associate product names with prices, in the 
> style
> 
> productlist["something"]= 71.2;
> 
> or a name with a number (string with string) in an address book 
> application for example?
> 
> namelist["Obry Pascal"]="321-45563";

In general, we use ADT. It is also a recommended practice in C++, BTW. What
would you do with

namelist["Pascal Obry"]="+0 321/45563  ";

or 

namelist["321-45563"]="Pascal Obry";

Note that both Ada and C++ support ADT. Ada's arrays is just an example of
ADT. It is possible in C++ to implement an array as a set of classes though
it will be much more verbose and suffer from numerous drawbacks.

> Also may you tell me if that famous compile-time boundary checking 
> applies (can be used) to user-defined containers too?

Of course it does. It is no different. The bounds can be specified either
as discriminants or as generic parameters (the latter has C++ equivalent).
As for the types with discriminants, they can be statically/dynamically
constrained and this is propagated down to the implementation where the
constraints are used. If corresponding methods are inlined then nothing
prevents the compiler from checking statically known bounds at
compile-time. 

I seems to me that you still missing the point. Ada's ability to check
bounds is based on the idea of constrained subtypes. It is a fundamental
concept which C++ lacks. (The only weak form of constraining C++ supports
is templates specialization.)

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

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

[Pascal Obry]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> In the "STL like" library do you have something like valarray or vector?

We have vector.

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

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> Georg Bauhaus wrote:
> 
>  > We want a vector type indexed by values between M and N only *and* we
>  > want the compiler + tools to help us make data structures in accord
>  > with these ranges. We want it to take advantage of what it can learn
>  > from the type system which allows index range checking _at compile 
> time_.
> 
> 
> At first, it is easy to write

Not the point.

> a container in C++ that accepts a 
> specified range for indexes.

A vector has an index range built into the language C++.
It was stated that type based indexing together with
attributes helps both the writer and the compiler.
No programmer effort needed.

> The only reason that there is not one, is 
> because it does not make sense in C++

Interesting claim. I Don't buy it. It is just not available
in the language.

> The [0, +] style maps closely what is 
> happening in the machine.

Another Off Topic.

> Also it is possible to define range-checked at run-time, operations. 
> vector::at() is an example.

Why are you repeating this? Not the point.

> vector is also a dynamic-type array, so placing compile-time bounds 
> checking isn't possible/doesn't make sense.

Elsewhere you say that it is possible and does make sense
to work around this lack using compile time assertions,
carfully placing them close to the object to which they are somehow
related. (Effectively creating an ad-hoc meta-language written in
templates. Only shows that the thing is indeed missing in C++.)

It makes sense to know the bounds of a container,
possibly in advance. Are you declaring that std::vector and
not knowing the bounds is the only reasonable thing to do in
programming?

Type attributes are a mode of expression, available with
types in Ada. You can build algorithms around language provided
attributes, for example bounds, without having to resort to
mere conventions and the hope that the compiler will do something
useful with the conventional items.

> For fixed size arrays and containers it is true, the compiler does not 
> catch at compile time any out of boundaries access. However we can do 
> this explicitly, by using compile-time checked assertions.

In other words, C++ array like types don't have these properties.
I'm not saying this is catastrophic. It's just not available
unless you roll your own. This has consequences for how you write
your software. It has consequences for what your compiler can do.
Some of them are interesing, because of template computing.


>  > No. I mean a double subtype whose values range from N.M to N'.M'.
> 
> 
> May you give an example for a container along with such a subtype?

It was given, starting this "sub"thread.

>  > Here you can see one point that you might want to demonstrate:
>  > The compiler won't tell you that there is something wrong
>  > with
>  >
>  >   doors[10].SetOpen().SetNoVan();
>  >
>  > Worse, the program won't tell you either. This shows the missing
>  > link between vector indexing and the base type system in your
>  > approach. You could use
>  >
>  >   doors.at(10).SetOpen().SetNoVan();
>  >
>  > and handle the exception _at run time_.
>  > In Ada, the compiler will tell you: "index value 10 is no good!"
>  > because the array "doors" can only be indexed by values effectively
>  > between 0 .. 9. These and only these are the values of the type
>  > enumerating the ten doors, and only these are allowed as index
>  > values x in expressios doors(x).
>  > No exception handling, no .at() needed when you listen to your
>  > compiler and fix the indexing error before you deliver a program.
>  > You get this for free as a result of the language's type handling
>  > at compile time.
> 
> 
> Will the Ada compiler tell you this, for user-defined types too?

An enum is a user defined type.
Any unconstrained type (including more than array types)
entails constrained objects, and the compiler may have a word
in this.
Maybe, if one gets used to template programming, the basis of the
language is deliberately ignored?
Ada just doesn't need templates for many things that are tried
using templates in C++, because the things are already in the
language.


> Or is 
> this restricted to built-in arrays? If the latest is true, then its 
> value isn't that much.

Every bug that is found at compile time is worth a lot
to me.

Try telling someone that useful array attributes, and type attributes
and object attributes in general, aren't of much value.
What else are .begin() and .end() other than roll-my-own replacements
for something that C style arrays lack, *language-wise*?
   Those working for an insurance company, in a stocks related business,
in math related computing, statistics, etc. use *Array Programming
Languages*. Why would they be doing this if good array support
isn't worth something? What is the value of good array support in
all those valuable Fortran computing libraries?

Are you saying that a robust base type system isn't worth it because
of the STL?
Consider the effort is takes to get a useful STL made of
basically, at-least-so-many-bits integers, pointers, and malloc().

Please answer this question:
Why is vector not implemented using vector? (I'm serious.)

 > I think that the value of defined subranges in the style
> -1000, -400 has not any practical use.

Any evidence?

>  > - Given an enum, and
>  > - given a language that allows the enum as a basis for the construction
>  > of an array type in the type system 
  ...
>  > (a) useful names for objects in your problem domain, checked at
>  > compile-time
> 
> 
> What do you mean by names?

I mean object names (enumerated identifiers), not strings. Like in

   typedef std::map<Some_Enum, int>  Slow_Array;

This is not the same as

   typedef std::vector<int>  Faster_Array:


>  > (b) a conceptual link between the enum (naming the single items) and
>  >   a container _type_ (containing these items); you cannot use anything
>  >   but these named numbers for indexing
> 
> 
> Which has no value in the world of C++, but I guess many things in Ada 
> depend on this.

You just gave an example of an assertion working around
the indexing issue...  So apparently proper indexing has
a value in the world of C++, contradicting your claim.


>  > (c) the fastest possible access, for both reading and writing, possibly
>  >   checked at compile time
> 
> 
> Fastest possible access in C++.

The fastest possible element access in C++ is dereferencing a pointer.
The fastest possible element access in STL/C++ is varying with container
and method.

Compare

    type Floor_Number is -2 .. 52;
      --  sky scraper

    type Door_Count is array(Floor_Number) of Natural;

versus

     typedef char Floor_Number;
     typedef std::map<Floor_Number, unsigned int> Door_Count;

We are discussing fastest access, and type based indexing.

So my question again, what does it take, in C++, to replace
Floor_Number as typedefed above with something that matches
the given building's floors exactly? What is the price to pay?


> is the Ada compile-time boundaries checking available 
> to user-defined containers? 

We are discussing the value of a container that doesn't *need*
to be defined because it is built into the language's type system,
with all bells and whistles and compiler help. No user definition
is *needed*, it's already there.

If you insist on leading us astray and on constructing your own
containers: The presence of bounds checking in programmer defined
ADTs depends on how they are defined.

 > can compile-time assertions be used?

The compiler will warn you when it can evaluate the expression
in a pragma assert at compile time. More importantly, the
compiler will use the compile-time checking required by Ada
array types. No need for programmer assertions expressed
using add-on templates.

> Of course
> one can always program improperly. :-)

I did say that this is not the point, didn't I?

The point is, how does a language help you writing
correct and efficient programs. C++ the language doesn't
have fixed size built in arrays. In some problem domains,
fixed size arrays are very useful, if not essential.

This is why many programming languages have them.

Georg

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

[Vinzent 'Gadget' Hoefler]

Ioannis Vranos wrote:

> Vinzent 'Gadget' Hoefler wrote:
> 
>> Yeah, right. Binary searches are not much slower. Only about 10 or 20
>> times. Seem, you just rendered hashing algorithms obsolete.
> 
> OK, one can use a third-party hashed container then, like a hash_map:

Which usually has it's worst case behaviour when it is close to full
(unlike the array, where a time complexity of O(1) is guaranteed,
hashing algorithm define this as average case at best).

If that's ok, it is ok, sure. But sometimes it's just not what is
needed.
Sometimes hashes are appropriate, sometimes tree-like structures,
sometimes vectors (or arrays, how I'd like to call them).

They /all/ have their uses.

_But_: To defy an O(1) example with an O(log n) one and then stating,
even for big data sets, the time difference isn't that large (usually I
do call an order of magnitude a large difference) is either just plain
ignorant or plain stupid.


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> Georg Bauhaus wrote:
> 
>> Compare log(10^6) to 1.
>>
>> I can't see how O(log(n)) isn't huge when compared to
>> O(1), in an inner loop for containers of size 10^6.
> 
> 
> OK, but besides the fact that only explicit entries in map occupy space,

Yet another issue having nothing to do with how
Ada arrays compare to C++ style arrays when the problem
requires plain arrays, not sparse arrays.

> Also, as I said it is not difficult to define an array that takes 
> arbitrary signed ranges, but this does not make much sense in C++.

Any evidence?


> In other words, the direct equivalent of your array is probably 
> valarray/vector, ignoring the signed ranges.

"ignoring" seems to be an attitude in your responses. ;-)

 > built-in arrays, which means is not of much  use.

Do you know what a built in array really is, and what it does?


> Also the lack of a "STL like" library in Ada until now probably sounds 
> like that Ada lacks much of the high-level abstraction that C++ provides.

Oh, come on. You are making claims about a language and
then guess about it? For many things a library was just not
needed in Ada. The language already provided what was needed,
including the high level of abstraction.

I've tried to picture the higher level of abstraction
in the Ada base type system that is just not present in C++.
For example, there is no need for .begin() and .end() in Ada
because it has always had these as attributes. In Ada it has always
been possible to write a generic array algorithm simply by requiring
that the G in <typename G, ...> is of an array type. There was
no need to add the hot new things like Can_Copy because they
were already in the language.

There have always been well designed ADT libraries (including
graph support). One of them has actually been ported from Ada 83 to C++,
and later to Ada 95 (Booch components).

Come to think of it, I don't know of anything like task *types*
and shared variable *types* built into the language C++.
This is right under your nose as high level abstractions
in plain Ada program structuring.

�C++ adds concurrency support to the C++ type system, at a somewhat
lower level of abstraction than Ada.
Still, �C+++ reimports the weaknesses of the precursor languages.
Sad, but successful because of mass momentum.

Georg

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

[Vinzent 'Gadget' Hoefler]

Ioannis Vranos wrote:

> OK, although O(log(n)) is fairly cheap, let's stick to O(1). However
> personally I think that the value of defined subranges in the style
> -1000, -400 has not any practical use.

So? Let me take a look at some current project:

|type DAC_Range is new Interfaces.Unsigned_8;
|type Offset    is new Interfaces.Integer_8;
|
|--  lookup tables are faster
|type Offset_Skew is array(Offset) of DAC_Range;

So the array indices are - of course - from -127 to 128.

(Of course you can remap that to 0 to 255, but because I am calculating
in signed range for relatively obvious reasons, this is much more
convenient.)


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Matthew Heaney]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:

> >> Wouldn't that be std::map in C++?
> > 
> > and in Ada 2005,
> > 
> > Ada.Containers.Hashed_Maps  and  Ada.Containers.Hashed_Maps

Ada 2005 will have both ordered ("sorted") maps and hashed maps.  The
current C++ standard only has ordered maps.


> I have probably missed a trick in the C++, but I couldn't get
> std::map code to compile (except in the trivial cases):
> 
> #include <map>
> 
> struct compoundindex {
>   int a, b, c;
> };

This type doesn't have a relational operator, which you need to
instantiate the map.


> --
> The Ada associative arrays from the new draft standard
> are specified as something like:
> 
> generic
>    type Key_Type is private;
>    type Element_Type is private;
>    with function Hash (Key : Key_Type)
>       return Hash_Type is <>;
>    with function Is_Equal_Key (Left, Right : Key_Type)
>       return Boolean is "=";
>    with function "=" (Left, Right : Element_Type)
>       return Boolean is <>;
> package Ada.Containers.Hashed_Maps is...

Yes, but the analog to the C++ map is Ada.Containers.Ordered_Maps, not
the hashed map.


> Which clearly won't work unless you can find the three
> function generic parameters.  I don't see how this can be
> used easily in a generic context.

But this is true of C++ as well.  There's no magic: your key either
needs a relational operator (for the ordered map), or it needs a hash
function (for the hashed map).


> I don't think I am being *that* unreasonable in asking for arrays
> indexed by arbitrary types, without jumping through hoops :)

Requiring that the key used to instantiate a hashed map have a hash
function hardly constitutes "jumping through hoops."  In any event, you
probably want an ordered map anyway:

generic

   type Key_Type is private;

   type Element_Type is private;

   with function "<" (Left, Right : Key_Type) return Boolean is <>;

   with function "=" (Left, Right : Element_Type) return Boolean is <>;

package Ada.Containers.Ordered_Maps is


in which case all you need is a relational op:

  function "<" (L, R : Compound_Index) return Boolean is
  begin
    if L.A < R.A then
       return True;
    end if;

    if L.A > R.A then
      return False;
    end if;

    if L.B < R.B then ...
  end;

  package Compound_Index_Maps is
    new Ada.Containers.Ordered_Maps (Compound_Index, Float);

  declare
    M : Compound_Index_Maps.Map;
  begin
    M.Include (Key => (1, 2, 4), New_Item => 0.123);
  end;

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

[fabio de francesco]

Ioannis Vranos wrote:
> Ioannis Vranos wrote:
>
> > OK, one can use a vector then. And as I said in other messages, it
is
> > not difficult to define an array that takes arbitrary signed
ranges, but
> > this does not make much sense in C++.
> >
> >
> > In other words, the direct equivalent of your array is probably
> > valarray/vector, ignoring the signed ranges.
>
>
> BTW does Ada provide dynamic arrays like vector/deque?
>
> --
> Ioannis Vranos

Ciao,

I think we don't have to care about the presence of a high-level
construct like whatever container. When C++ hadn't yet standardised
containers, everyone could actually build these higher-level structures
by himself. The only problem is standardisation. If you have languages
that are sufficienly low-level like C++ and Ada you can manufacture
every type of algorithm and containers you need.

You build higher-level components by using lower-level built-in
language features. Every compile-time or run-type check that you can
have for built-in types you "inherit" for user created structures. This
is said to answer your past question about Ada having or not same
checks for built-in types and user defined types.

I suppose std::vector is a simple array which must be copied to a
larger one in order to insert a new element while it is full. You know
it can be done in Ada too.

What's more in Ada is that you can, in a standardised way, directly
create low-level representation of user defined types with a lot of
attributes that C++ doesn't provide. Ada programmers prefer to build
their own types rather than using built-in Integer, Float, Long_Float
(int, float, double) and so on in order to gain a much finer control.

In Ada you can decide representation attributes like range, digit,
delta, mod, address, alignment, size, byte-order (little or big endian)
in record component, and many other things like these. As an example
you can write:

type Counter is new Integer;
for Counter'Size use 48;
for Counter'Alignment use 16;

What's more, you get a compiler error if your machine can't use some
sort of representation you need in order to free you from knowing how
much space a type can provide.

You said that real C++ code hardly need to specify ranges, because you
should be careful not to assign a value that can't be held by a
variable of some specific type. Imagine you have know a variable is to
hold numbers not larger than 99_999 and you choose to store them in an
"int" knowing that you have enough space. When later you port your
program to a machine where "int" is 16 bits you don't have any warning
from a C++ compiler and program run for years until for some reason
that variable is assigned with say 86_000. I think you know what
happens..

If you had that type declared as "type Var_T is range 0 .. 99_999;", at
the very moment you port your program to this new machine the compiler
would choose the correct size to hold values of that type so program is
no more restricted to this 16 bits C++ "int" and consequently won't
raise this bug.

Do you still think you don't need ranges?

Regards,

fabio de francesco

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

[bjarne]

Robert A Duff wrote:
> "Frank J. Lhota" <NOSPAM.Lhota.adarose@verizon.net> writes:
>
> > <adaworks@sbcglobal.net> wrote in message
> > news:9lK%d.186$FN4.48@newssvr21.news.prodigy.com...
> > > And that is the unfortunate aspect of the language:  its
foundation on C.
> > >
> > > I once heard Stroustrup confess that, if he had had his druthers,
he would
> > > not have started with C as the seed language.
> >
> > Stroustrup said in an interview that his preference would have been
Algol
> > with classes.
>
> Hmm...  Isn't that language called Simula 67?  ;-)
>
> > I think that I probably would have preferred that as well!
>
> - Bob

The Algol I was talking about in that context was Algol68. The result
would have been a more flexible and efficient language than Simula67
and a cleaner language than C++ became. Unfortunately, there was no
chance of such a language succeeding at that time and place - the
understanding of the basic concepts among the intended users and the
infrastructure needed to get work done were missing. It would have been
yet another beautiful, but stillborn, language. C++ was designed in
response to pressing problems, not as a 10-year project aimed at
abstract beauty. I think that in the long run, it actually gained from
that.

If you want to understand how and why C++ was done, have a look at
Stroustrup: "The Design and Evolution of C++" (Addison-Wesley). If
nothing else, it might help you to avoid revisionist history and wild
conjecture. I think that documenting decisions about major tools is
important and should not be confused with "confessions".

I chose C as a base for C++ because - among the many languages I knew
of - it was the one that came closest to my needs. It wasn't perfect
and C compatibility became a bigger problem than I had bargained for,
but noone "forced me" (as is conjectured, incl. in this thread).

And no, C++ was never meant solely for object-oriented programming
(when defined as programming using class hierarchies). Support for data
abstraction and procedural programming was mentioned in my earliest
papers, and a 1981 paper grapples (rather unsuccessfully) with the
basics of generic programming.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

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

[Robert A Duff]

"bjarne" <bjarne@gmail.com> writes:

> Robert A Duff wrote:
> > "Frank J. Lhota" <NOSPAM.Lhota.adarose@verizon.net> writes:
> >
> > > <adaworks@sbcglobal.net> wrote in message
> > > news:9lK%d.186$FN4.48@newssvr21.news.prodigy.com...
> > > > And that is the unfortunate aspect of the language:  its
> foundation on C.
> > > >
> > > > I once heard Stroustrup confess that, if he had had his druthers,
> he would
> > > > not have started with C as the seed language.
> > >
> > > Stroustrup said in an interview that his preference would have been
> Algol
> > > with classes.
> >
> > Hmm...  Isn't that language called Simula 67?  ;-)
> >
> > > I think that I probably would have preferred that as well!
> >
> > - Bob
> 
> The Algol I was talking about in that context was Algol68. 

OK, fair enough.  I *did* put a smiley there!

>...The result
> would have been a more flexible and efficient language than Simula67
> and a cleaner language than C++ became.

I agree.

>... Unfortunately, there was no
> chance of such a language succeeding at that time and place - the
> understanding of the basic concepts among the intended users and the
> infrastructure needed to get work done were missing. It would have been
> yet another beautiful, but stillborn, language. C++ was designed in
> response to pressing problems, not as a 10-year project aimed at
> abstract beauty. I think that in the long run, it actually gained from
> that.
> 
> If you want to understand how and why C++ was done, have a look at
> Stroustrup: "The Design and Evolution of C++" (Addison-Wesley).

I've read it.  (And enjoyed it very much!)

>... If
> nothing else, it might help you to avoid revisionist history and wild
> conjecture. I think that documenting decisions about major tools is
> important and should not be confused with "confessions".

I apologize for what might seem like "wild conjecture".  That wasn't my
intent -- I was just making a silly joke based on the phrase "Algol with
classes".  Sorry.

> I chose C as a base for C++ because - among the many languages I knew
> of - it was the one that came closest to my needs. It wasn't perfect
> and C compatibility became a bigger problem than I had bargained for,

As one of the designers of Ada 95, I know very well what it is like to
design a language when compatibility is a constraint.

> but noone "forced me" (as is conjectured, incl. in this thread).
> 
> And no, C++ was never meant solely for object-oriented programming
> (when defined as programming using class hierarchies). Support for data
> abstraction and procedural programming was mentioned in my earliest
> papers, and a 1981 paper grapples (rather unsuccessfully) with the
> basics of generic programming.
> 
> -- Bjarne Stroustrup; http://www.research.att.com/~bs

- Bob

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Chris Jefferson]

Matthew Heaney wrote:
> "Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:
> 
> 
>>>>Wouldn't that be std::map in C++?
>>>
>>>and in Ada 2005,
>>>
>>>Ada.Containers.Hashed_Maps  and  Ada.Containers.Hashed_Maps
> 
> 
> Ada 2005 will have both ordered ("sorted") maps and hashed maps.  The
> current C++ standard only has ordered maps.
> 

Just replying to this point.. The TR1 library edition will also have 
hashed maps, although I suspect Ada 2005 might beat it out :) (Although 
G++ 4.0 will have them as contained in the (almost) final version of the 
TR1 standard).

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

[Frank J. Lhota]

"bjarne" <bjarne@gmail.com> wrote in message 
news:1111586894.547988.175600@o13g2000cwo.googlegroups.com...
> The Algol I was talking about in that context was Algol68.

Sorry for the confustion.  I had assumed that the term Algol would 
universally be interpreped as Algol68. Clearly this assumption was wrong, 
and I should have added the "68" suffix to clarify the matter.

> The result
> would have been a more flexible and efficient language than Simula67
> and a cleaner language than C++ became. Unfortunately, there was no
> chance of such a language succeeding at that time and place - the
> understanding of the basic concepts among the intended users and the
> infrastructure needed to get work done were missing. It would have been
> yet another beautiful, but stillborn, language. C++ was designed in
> response to pressing problems, not as a 10-year project aimed at
> abstract beauty. I think that in the long run, it actually gained from
> that.

Having no Simula67 experience, and no readily available way to get such 
experience, I cannot comment on the merits of that language. My exposure to 
Algol, however, leads me to believe that it would make an excellent 
foundation for a modern OO language. I understand that "Algol68 with 
classes" would have virtually no chance of succeeding, although I find the 
lack of viability of such a beautiful langage lamentable.

> If you want to understand how and why C++ was done, have a look at
> Stroustrup: "The Design and Evolution of C++" (Addison-Wesley). If
> nothing else, it might help you to avoid revisionist history and wild
> conjecture. I think that documenting decisions about major tools is
> important and should not be confused with "confessions".

I have read the book, and I can recommend it highly.

> I chose C as a base for C++ because - among the many languages I knew
> of - it was the one that came closest to my needs. It wasn't perfect
> and C compatibility became a bigger problem than I had bargained for,
> but noone "forced me" (as is conjectured, incl. in this thread).
>
> And no, C++ was never meant solely for object-oriented programming
> (when defined as programming using class hierarchies). Support for data
> abstraction and procedural programming was mentioned in my earliest
> papers, and a 1981 paper grapples (rather unsuccessfully) with the
> basics of generic programming.
>
> -- Bjarne Stroustrup; http://www.research.att.com/~bs

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[adaworks]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1110608948.651588@athnrd02...
>
> Myself thinks though that this whole range specialisation thing is
> non-sense for regular application programming at least.
>
Perhaps for your kind of programming, the Ada type model
would be unnecessary.     In fact, for many Ada programs, it
is not essential.   However, the ability to refine the meaning
of a type, in Ada, is quite useful for many reasons when writing
large-scale software where a lot of people will be involved in
the process.

      1.  It makes the program more readable because unique
           names for types can be given meaningful names.

      2.  It enforces name equivalence within the type system, rather
           than relying on structural equivalence. This deprives the
           programmer of many hours of entertaining debugging sessions.

      3. One can do simple membership tests on the specified ranges,
           thereby eliminating such annoying constructs as:
                 if X >= 20 and X <= 50 then ...
           which sometimes leads to interesting errors.

      4. The scope and visibility rules, one of the most powerful features
           of Ada for creating safe software, ensure that type names will
           not be automatically visible everywhere in the code.

These are just a few benefits.   I realize that, any one of these, taken by
itself, might not be impressive.  However,  in practice,  the combined
power of them tends to make it easier to produce fewer errors during
the development process.   You might think of this model as an assist
to the programmer in constraining the environment prior to coding in
that environment.   Such constraints have proven useful to those who
learn to use them.   For those who choose other courses of action,
no amount of argument, proof, or demonstration of benefits will suffice.

Richard Riehle

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

[adaworks]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1111464133.508323@athnrd02...

OK.  I read your C++ example with care and interest.
Then I compared it, once again, with the example I wrote.

I wonder if you truly think the two examples are equlivalent
in all respects.    I must confess that, if the C++ example
were an accurate representation of how one would solve
this problem in that language, I would abandon C++ for
all time.

A key goal of Ada is to produce readable code, not simply
writeable solutions in cryptic code.   Who, upon encountering
the C++ example in your post, would be able to quickly
apprehend the meaning, the intent, or the result of this
code?

I rest my case.

Richard Riehle

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

[adaworks]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1111572591.296439@athnrd02...
>
> C++ maps on both. However I guess Ada maps on both too since it is a
> systems programming language. :-)
>
Rene Descartes originally developed his coordinate geometry in
quadrant One.   That worked fine for a long time.   When negative
quadrants were proposed, by later mathematicians, many wondered
what they were good for.

The early Greek mathematicians found no use for a number representing
zero.   The reason:  their number system was based on geometry and
there was no need to represent a non-existent geometrical object.

Some ancient cultures started their own number systems from two
because they saw no point in counting until there was more than
one of something.

There are many cases, in programming, where one wants to map the
solution space to the problem space.   In the real world, not every
problem space originates at zero.  Quite often, it is useful to define
the solution space beginning with 1 instead of zero.  This makes
algorithms for such problems more straightforward.   Other times,
one might want to begin the indexing at a number greater than 1.

          type Channel is range 2..136;
          type Active_Channels is array(Channel) of Boolean;

In practice, particularly in real-time systems, the ability to set the
array index to a range that closely reflects the realities of the
problem space can be quite helpful.   It also acts as part of the
self-documenting aspect of the solution space.

Richard Riehle

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

[adaworks]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1111522653.164049@athnrd02...
>
> In other words it does not make much sense to have signed indexes.
> Otherwise it is easy and possible.
>
   1.  Signed indices are extremely valuable when doing certain
        kinds of mathematical modeling.

   2.  Your example did not use "straight" C++. Instead, you relied
        on the Vector template.   Doing the same thing, in Ada, we
        could have multiplied the power of this problem even more.

   3.  I have so often encountered the question, "But why would you
        want to do that? in my career, that I am still amazed when I
        hear it yet again.

Regarding number 3, I wish Ada had a good model of multiple
inheritance.   I don't mean the somewhat haphazard model of
C++, but rather something like the multiple inheritance of
Eiffel.   When someone asks me, wrt multiple inheritance, "But
why would you want to that?  it drives me a little crazy.

There are lots of good uses for multiple inheritance.  However,
there are also lots of dangers in it.  Ada correctly comes down
on the side of safety, but I do sometimes wish it were available.

Richard Riehle

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

[Martin Dowie]

adaworks@sbcglobal.net wrote:
> Regarding number 3, I wish Ada had a good model of multiple
> inheritance.   I don't mean the somewhat haphazard model of
> C++, but rather something like the multiple inheritance of
> Eiffel.   When someone asks me, wrt multiple inheritance, "But
> why would you want to that?  it drives me a little crazy.
> 
> There are lots of good uses for multiple inheritance.  However,
> there are also lots of dangers in it.  Ada correctly comes down
> on the side of safety, but I do sometimes wish it were available.

It will have multiple inheritance of interfaces (a la Java) in
Ada2005 - is that enough?

Cheers

-- Martin

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Wed, 23 Mar 2005 17:26:12 +0000, adaworks wrote:
> 
>       1.  It makes the program more readable because unique
>            names for types can be given meaningful names.
> 
>       2.  It enforces name equivalence within the type system, rather
>            than relying on structural equivalence. This deprives the
>            programmer of many hours of entertaining debugging sessions.
> 
>       3. One can do simple membership tests on the specified ranges,
>            thereby eliminating such annoying constructs as:
>                  if X >= 20 and X <= 50 then ...
>            which sometimes leads to interesting errors.
> 
>       4. The scope and visibility rules, one of the most powerful features
>            of Ada for creating safe software, ensure that type names will
>            not be automatically visible everywhere in the code.

And you can do really handy stuff passing arrays not indexed from 0,
and accessing the attributes:

-- No particular purpose but to demo 
  type MyString is array (Integer range <>) of Integer;

  procedure UpdateString (Blob : in out MyString; K : Integer) is
   begin

      if Blob'Length = 0 then
         return;
      elsif Blob'Length = 1 then
         Blob (Blob'First) := Blob (Blob'First) + K;
         return;
      else
         UpdateString (Blob (Blob'First .. Blob'First+Blob'Length/2-1), 19);
         UpdateString (Blob (Blob'First+Blob'Length/2 .. Blob'Last),    27);
         return;
      end if;

   end UpdateString;
...
   UpdateString (Fred (10 .. 19), 0);

In this case, you make the intent clear which part is being
updated in each level of recursion.  You get the bounds checking
in each level, to make sure it is not stepping outside the specific
part of the array passed.

I don't think the C++ equivalent would be so clear, since you would
have to add extra parameters saying what part of the array you are using,
and you would have to add extra bounds checking manually, even
if the container class checked against the overall bounds.

The C++ users who are so concerned about the overhead of storing
bounds in the type have to weigh the cost against storing the
bounds elsewhere and passing them as another couple of parameters.
It's rare that Ada code would have to store bounds which wouldn't
otherwise have to be stored somewhere anyway. (did we cover this already?)
-- 
Adrian

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

[Jerry Coffin]

Peter Amey wrote:

[ ... ]

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

Some of the cited cases provide checks that are free in terms of
run-time, but run-time is hardly the major cost in most software.
Though I haven't done so recently, back when I used Ada, nowhere close
to all of the checks were free even in terms of run-time either.

Furthermore, even when the run-time check itself imposes no extra code
execution, that doesn't mean it's necessarily free in terms of run-time
cost either. Simple economic reality is that writing a good compiler is
NOT a quick, cheap, or simple thing to do. Generally speaking, it's
done to a budget of some sort and time and effort that's put into
compile-time checks more or less directly translates into time and
effort that was NOT put into better code generation and optimization.
This can be ameliorated in a case like GNAT, where the Ada compiler
shares a back-end with something else, but the effect is almost never
really eliminated -- time and effort are almost always limited
resources, so expending them in one way nearly always reduces their
expenditure elsewhere.

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

Maybe...or maybe not. IME, absolute statements about generalities (e.g.
all implementations of a language) are rarely accurate. Ada compilers
vary quite widely, and I've certainly seen some emit code that included
checks that were logically unnecessary. I'd guess that the current
compilers are better, but perfection in this respect would surprise me.

In the end, my experiece has been that Ada compilers produce _slightly_
worse code in general than C and C++ compilers, but it would take
considerable work to determine how much of this is due to the source
language, and how much simply because their smaller market share
supports less time and effort in optimization. In fairness, I should
add that the differences are rarely very noteworthy. In most typical
situations, if one produces adequately fast output, so will the other.
Of course, if you're dealing with hard real-time requirements and a C++
compiler meets the requrement with only .5% to spare, there's a pretty
fair chance that Ada would fail -- but this sort of situation is
unusual (probably even rare).

[ ... ]

> It should also have been clear from the thread that Ada imposes no
> limits on expressiveness.

Nonsense -- examples of Ada expressing a few specific concepts have
been given, but this hardly proves a lack of limits. The fact is,
_every_ programming language places severe limits on expressiveness;
anybody who believes otherwise simply hasn't given the subject much
real thought. Programming languages in general express only a small
range of specific actions that are relevant to (most) computers. By
design, none of them is really expressive in areas such as human
emotions.

Even sticking to programming types of things, Ada has some limits to
its expressiveness.

Just for one obvious example, Ada doesn't provide an easy way to
express/do most of the things one can do with the C or C++
preprocessor. It provides some alternative in _some_ cases, but quite
frankly, these are really the exceptions rather than the rule.

Some areas are somewhat more questionable -- calling a class a "tagged
record" is clearly a mistake, but it's open to question whether it
should be classified under poor expression of the concept, or just
general idiocy.

The Ada folks who insist that things should be part of the base
language rather than an add-on library may have strings, but have
nothing equivalent to a dtor in C++. The possible presence of garbage
collection does little to mitigate this, as dtors are useful for _far_
more than just releasing memory when no longer in use. Ada even tacitly
admits to this shortcoming by providing Ada.Finalization in the
library. My understanding, however, is that this requires anything that
wants a destructor be derived from their base class (oops -- their base
tagged record). This may be usable, but it's hardly what I'd call a
clean expression of the concept. In fairness, I should add that I've
never used Ada.Finalization, so my understanding of it may well be
flawed, and corrections about this area would be welcome.

Speaking of strings, I'll digress for a moment: personally, I find it a
bit humorous when Ada advocates talk about things like having five
string types as an advantage. IMO, the need, or even belief, that five
string types are necessary or even useful is a _strong_ indication that
all five are wrong.

Ada's exception handling is also primitive at best (exceptionally so,
if you'll pardon a pun). In particular, in Ada what you throw is
essentially an enumaration -- a name that the compiler can match up
with the same name in a handler, but nothing more. Only exact matches
are supported and no information is included beyond the identity of the
exception.

In C++ you can throw an arbitrary type of object with an arbitrary
value. All the information relevant to the situation at hand can be
expressed cleanly and directly. The usual inheritance rules apply, so
an exception handler can handle not only one specific exception, but an
entire class of exceptions. Again, this idea can be expressed directly
rather than as the logical OR of the individual values. And, once
again, the addition of tagged records to Ada 95 testifies to the fact
that even its own designers recognized the improvement this adds in
general, but (whether due to shortsightedness, concerns for backward
compatibility or whatever) didn't allow this improvement to be applied
in this situation.

> Can you say what led you to the opposite conclusion?

Study and experience. Can you say what leads you to believe your own
claim?

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Ioannis Vranos]

Pascal Obry wrote:

> We have vector.


If it is also defined in std namespace, I am going to smile.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

fabio de francesco wrote:

> Ciao,
> 
> I think we don't have to care about the presence of a high-level
> construct like whatever container. When C++ hadn't yet standardised
> containers, everyone could actually build these higher-level structures
> by himself. The only problem is standardisation. If you have languages
> that are sufficienly low-level like C++ and Ada you can manufacture
> every type of algorithm and containers you need.
> 
> You build higher-level components by using lower-level built-in
> language features. Every compile-time or run-type check that you can
> have for built-in types you "inherit" for user created structures. This
> is said to answer your past question about Ada having or not same
> checks for built-in types and user defined types.


OK.


> I suppose std::vector is a simple array which must be copied to a
> larger one in order to insert a new element while it is full. You know
> it can be done in Ada too.


It is not that expensive. An implementer reserves some more space so as 
to avoid frequent reallocations, and vector provides reserve() method to 
allocate unitialised space for objects since the beginning by yourself, 
if you are going to insert many objects later, so as to avoid 
reallocation. For example:


// Contains 10 ints initialised to 0.
vector<int> vec(10);

// Reserves unitialised memory space for 1000 ints in total
vec.reserve(1000);



> What's more in Ada is that you can, in a standardised way, directly
> create low-level representation of user defined types with a lot of
> attributes that C++ doesn't provide. Ada programmers prefer to build
> their own types rather than using built-in Integer, Float, Long_Float
> (int, float, double) and so on in order to gain a much finer control.
> 
> In Ada you can decide representation attributes like range, digit,
> delta, mod, address, alignment, size, byte-order (little or big endian)
> in record component, and many other things like these. As an example
> you can write:
> 
> type Counter is new Integer;
> for Counter'Size use 48;
> for Counter'Alignment use 16;
> 
> What's more, you get a compiler error if your machine can't use some
> sort of representation you need in order to free you from knowing how
> much space a type can provide.
> 
> You said that real C++ code hardly need to specify ranges, because you
> should be careful not to assign a value that can't be held by a
> variable of some specific type. Imagine you have know a variable is to
> hold numbers not larger than 99_999 and you choose to store them in an
> "int" knowing that you have enough space. When later you port your
> program to a machine where "int" is 16 bits you don't have any warning
> from a C++ compiler and program run for years until for some reason
> that variable is assigned with say 86_000. I think you know what
> happens..


The standard guarantees the minimum ranges, for int can hold at least 
16-bit values and long at least 32-bit values.


> If you had that type declared as "type Var_T is range 0 .. 99_999;", at
> the very moment you port your program to this new machine the compiler
> would choose the correct size to hold values of that type so program is
> no more restricted to this 16 bits C++ "int" and consequently won't
> raise this bug.
> 
> Do you still think you don't need ranges?


Ranges are a nice thing to have, however if you are provided with 
minimum range guarantees, this also does the job.


I would prefer compiler error messages for out of range assignments 
though. And I wonder what backwards compatibility (apart from -1 
assignment to unsigned integral types) this would break.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Matthew Heaney]

Jerry Coffin wrote:
>
> Speaking of strings, I'll digress for a moment: personally, I find it
a
> bit humorous when Ada advocates talk about things like having five
> string types as an advantage. IMO, the need, or even belief, that
five
> string types are necessary or even useful is a _strong_ indication
that
> all five are wrong.

It's the same as in C++:

char[]
wchar_t[]
std::string
std::wstring

The string types in Ada95 are very similar:

String
Wide_String
Unbounded_String
Wide_Unbounded_String

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

[Ioannis Vranos]

Dmitry A. Kazakov wrote:

> In general, we use ADT. It is also a recommended practice in C++, BTW. What
> would you do with
> 
> namelist["Pascal Obry"]="+0 321/45563  ";
> 
> or 
> 
> namelist["321-45563"]="Pascal Obry";


I am not sure what you mean here, input validation should take place 
before such assignment.


> Note that both Ada and C++ support ADT. Ada's arrays is just an example of
> ADT. It is possible in C++ to implement an array as a set of classes though
> it will be much more verbose and suffer from numerous drawbacks.


I am not sure what you mean here either.


> Of course it does. It is no different. The bounds can be specified either
> as discriminants or as generic parameters (the latter has C++ equivalent).
> As for the types with discriminants, they can be statically/dynamically
> constrained and this is propagated down to the implementation where the
> constraints are used. If corresponding methods are inlined then nothing
> prevents the compiler from checking statically known bounds at
> compile-time. 
> 
> I seems to me that you still missing the point. Ada's ability to check
> bounds is based on the idea of constrained subtypes. It is a fundamental
> concept which C++ lacks. (The only weak form of constraining C++ supports
> is templates specialization.)


OK then, Ada is probably better in this area.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Matthew Heaney]

Ioannis Vranos wrote:
> Pascal Obry wrote:
> >
> > We have vector.
>
> If it is also defined in std namespace, I am going to smile.

It's declared as a child of Ada.Containers.  It's otherwise very
similar to std::vector.  (Actually, that's true of all of the
containers in the standard library, since STL was the inspiration.)

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

[Jerry Coffin]

Matthew Heaney wrote:
> Jerry Coffin wrote:
> >
> > Speaking of strings, I'll digress for a moment: personally, I find
> > it a bit humorous when Ada advocates talk about things like having
> > five string types as an advantage. IMO, the need, or even belief,
> > that five string types are necessary or even useful is a _strong_
> > indication that all five are wrong.
>
> It's the same as in C++:
>
> char[]
> wchar_t[]
> std::string
> std::wstring
>
> The string types in Ada95 are very similar:
>
> String
> Wide_String
> Unbounded_String
> Wide_Unbounded_String

char[] and wchar_t[] are arrays, not strings. C++ really only has one
string type: std::basic_string. std::string and std::wstring are not
types of their own at all, but simply typedefs as:

typedef std::basic_string<char> string;
typedef std::basic_string<wchar_t> wstring;

In addition, one of the major arguments the Ada fans have used here is
that Ada's strings are built-in, NOT added as a class like in C++. If
C++ had been designed from the beginning with a string class, the
array-based "stuff" probably wouldn't exist at all.

BTW, in case anybody really cares, yes I apply the same standard to
C++: while its string handling facilities are fewer and IMO better than
Ada's, they're still far short of perfect.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Martin Dowie]

Jerry Coffin wrote:
> Just for one obvious example, Ada doesn't provide an easy way to
> express/do most of the things one can do with the C or C++
> preprocessor. It provides some alternative in _some_ cases, but quite
> frankly, these are really the exceptions rather than the rule.

That 'problem' isn't unique to Ada - I can't think of another
language that *does* define a pre-processor.

And if you like a preprocessor - just use one! You can always write
a makefile/.bat/.com/<whatever> to invoke the preprocessor before the
compiler is called. GNAT comes with an Ada-centric preprocessor but
there is nothing to stop you using the 'C' one.


> Ada's exception handling is also primitive at best (exceptionally so,
> if you'll pardon a pun). In particular, in Ada what you throw is
> essentially an enumaration -- a name that the compiler can match up
> with the same name in a handler, but nothing more.

See Ada.Exceptions - perhaps not as elegant but it does the job and
back when the first exception mechanism for Ada was designed, I doubt
there was much call for anything other than a 'this fault has occured'
style exception. At the time, I'd guess that 90%+ of all code in
exsistance was COBOL, C or FORTRAN - none of which had any exception 
handling!


 > Only exact matches
 > are supported and no information is included beyond the identity of
 > the exception.

True for Ada83 but not so in Ada95 - again see Ada.Exceptions and
getting expanded again in Ada2005.



>  And, once
> again, the addition of tagged records to Ada 95 testifies to the fact
> that even its own designers recognized the improvement this adds in
> general, but (whether due to shortsightedness, concerns for backward
> compatibility or whatever) didn't allow this improvement to be applied
> in this situation.

Almost certainly backwards compatibility - but I'm sure Bob and/or Randy
could shed more light on that...

Cheers

-- Martin

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> A vector has an index range built into the language C++.
> It was stated that type based indexing together with
> attributes helps both the writer and the compiler.
> No programmer effort needed.
 >
> Elsewhere you say that it is possible and does make sense
> to work around this lack using compile time assertions,
> carfully placing them close to the object to which they are somehow
> related. (Effectively creating an ad-hoc meta-language written in
> templates. Only shows that the thing is indeed missing in C++.)
> 
> It makes sense to know the bounds of a container,
> possibly in advance. Are you declaring that std::vector and
> not knowing the bounds is the only reasonable thing to do in
> programming?
> 
> Type attributes are a mode of expression, available with
> types in Ada. You can build algorithms around language provided
> attributes, for example bounds, without having to resort to
> mere conventions and the hope that the compiler will do something
> useful with the conventional items.


OK, I think you are right. C++ lacks these, and I wonder why additional 
keywords enabling this are not added in language proposals for future 
standard revision (C++0x).



> 
>> For fixed size arrays and containers it is true, the compiler does not 
>> catch at compile time any out of boundaries access. However we can do 
>> this explicitly, by using compile-time checked assertions.
> 
> 
> In other words, C++ array like types don't have these properties.
> I'm not saying this is catastrophic. It's just not available
> unless you roll your own. This has consequences for how you write
> your software. It has consequences for what your compiler can do.
> Some of them are interesing, because of template computing.
> 
> 
>>  > No. I mean a double subtype whose values range from N.M to N'.M'.
>>
>>
>> May you give an example for a container along with such a subtype?
> 
> 
> It was given, starting this "sub"thread.
> 
>>  > Here you can see one point that you might want to demonstrate:
>>  > The compiler won't tell you that there is something wrong
>>  > with
>>  >
>>  >   doors[10].SetOpen().SetNoVan();
>>  >
>>  > Worse, the program won't tell you either. This shows the missing
>>  > link between vector indexing and the base type system in your
>>  > approach. You could use
>>  >
>>  >   doors.at(10).SetOpen().SetNoVan();
>>  >
>>  > and handle the exception _at run time_.
>>  > In Ada, the compiler will tell you: "index value 10 is no good!"
>>  > because the array "doors" can only be indexed by values effectively
>>  > between 0 .. 9. These and only these are the values of the type
>>  > enumerating the ten doors, and only these are allowed as index
>>  > values x in expressios doors(x).
>>  > No exception handling, no .at() needed when you listen to your
>>  > compiler and fix the indexing error before you deliver a program.
>>  > You get this for free as a result of the language's type handling
>>  > at compile time.
>>
>>
>> Will the Ada compiler tell you this, for user-defined types too?
> 
> 
> An enum is a user defined type.
> Any unconstrained type (including more than array types)
> entails constrained objects, and the compiler may have a word
> in this.
> Maybe, if one gets used to template programming, the basis of the
> language is deliberately ignored?
> Ada just doesn't need templates for many things that are tried
> using templates in C++, because the things are already in the
> language.
> 
> 
>> Or is this restricted to built-in arrays? If the latest is true, then 
>> its value isn't that much.
> 
> 
> Every bug that is found at compile time is worth a lot
> to me.
> 
> Try telling someone that useful array attributes, and type attributes
> and object attributes in general, aren't of much value.
> What else are .begin() and .end() other than roll-my-own replacements
> for something that C style arrays lack, *language-wise*?
>   Those working for an insurance company, in a stocks related business,
> in math related computing, statistics, etc. use *Array Programming
> Languages*. Why would they be doing this if good array support
> isn't worth something? What is the value of good array support in
> all those valuable Fortran computing libraries?
> 
> Are you saying that a robust base type system isn't worth it because
> of the STL?
> Consider the effort is takes to get a useful STL made of
> basically, at-least-so-many-bits integers, pointers, and malloc().
> 
> Please answer this question:
> Why is vector not implemented using vector? (I'm serious.)


OK I get your point, and you are right. These things would be nice to 
have in C++, and I think it is possible to have them just by introducing 
new keywords in the language, without breaking backwards compatibility. 
I do not know why there is no proposal for these.



> The fastest possible element access in C++ is dereferencing a pointer.
> The fastest possible element access in STL/C++ is varying with container
> and method.
> 
> Compare
> 
>    type Floor_Number is -2 .. 52;
>      --  sky scraper
> 
>    type Door_Count is array(Floor_Number) of Natural;
> 
> versus
> 
>     typedef char Floor_Number;
>     typedef std::map<Floor_Number, unsigned int> Door_Count;


char does not feel well, one could use short but probably will use int.



> We are discussing fastest access, and type based indexing.


I can't understand why your code has faster access (I assume you mean 
run-time efficiency).


> So my question again, what does it take, in C++, to replace
> Floor_Number as typedefed above with something that matches
> the given building's floors exactly?


I assume a vector that permits defining negative indices, and this is 
easy to be defined. However I may assume that since no such vector 
container is provided (even third-party), I may assume that either it is 
not considered as needed, or it is believed that maps and hash_maps can 
do the job.


To give another example, .NET does not provide such an array container 
either, in its own containers collection. So why such a mainstream 
framework does not provide an array type with negative indexing either?


This is not some kind of general proof, but for me it is an indication. 
Again, I agree that boundary checking etc are useful and should be added 
in C++ perhaps with additional keywords.


> The point is, how does a language help you writing
> correct and efficient programs. C++ the language doesn't
> have fixed size built in arrays. In some problem domains,
> fixed size arrays are very useful, if not essential.
> 
> This is why many programming languages have them.



Just to be technically accurate. C++ has fixed size built in arrays. It 
doesn't provide range checking for them though.


int array[4];

is a fixed size, stack based, built in array.


Fixed size in the heap:

int *parray= new int[4];


Also, standard library containers with fixed size are valarray and bitset.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Martin Dowie wrote:

> It will have multiple inheritance of interfaces (a la Java) in
> Ada2005 - is that enough?


For application programming only, it is usually enough. I am not sure if 
in library writing it is enough though.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

adaworks@sbcglobal.net wrote:

> OK.  I read your C++ example with care and interest.
> Then I compared it, once again, with the example I wrote.
> 
> I wonder if you truly think the two examples are equlivalent
> in all respects.    I must confess that, if the C++ example
> were an accurate representation of how one would solve
> this problem in that language, I would abandon C++ for
> all time.
> 
> A key goal of Ada is to produce readable code, not simply
> writeable solutions in cryptic code.   Who, upon encountering
> the C++ example in your post, would be able to quickly
> apprehend the meaning, the intent, or the result of this
> code?


Believe it or not, I do not understand most of Ada code, apart from some 
Pascal-like constructs here and there. :-)



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Martin Dowie wrote:

> That 'problem' isn't unique to Ada - I can't think of another
> language that *does* define a pre-processor.
> 
> And if you like a preprocessor - just use one! You can always write
> a makefile/.bat/.com/<whatever> to invoke the preprocessor before the
> compiler is called. GNAT comes with an Ada-centric preprocessor but
> there is nothing to stop you using the 'C' one.


Here is an interesting link BTW:

http://boost-consulting.com/tmpbook/preprocessor.html



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> �C++ adds concurrency support to the C++ type system, at a somewhat
> lower level of abstraction than Ada.


Concurrency is a hot issue, currently considered system-specific in C++. 
It will be included in C++0x (I hope the right choices will be made).

There is also OpenMP of course (http://www.openmp.org).


> Still, �C+++ reimports the weaknesses of the precursor languages.
> Sad, but successful because of mass momentum.


I keep hearing about this �C++, may you provide a relevant link? I 
couldn't find anything in google, is the first character a Greek 
character? It appears as the Greek character 'm' in my screen.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Georg Bauhaus]

Jerry Coffin wrote:

> Some areas are somewhat more questionable -- calling a class a "tagged
> record" is clearly a mistake, but it's open to question whether it
> should be classified under poor expression of the concept, or just
> general idiocy.

http://groups-beta.google.com/group/comp.lang.ada/browse_thread/thread/8b8748382fcfacc1/f6536ae8243e253c?q=%22class+type%22+group:comp.lang.ada+author:dewar#f6536ae8243e253c

     class type T is ...

instead of

     type T is tagged ...



> In C++ you can throw an arbitrary type of object with an arbitrary
> value.

How well does this style of passing information work across thread
boundaries? (Not debating the usefulness of the mechanism. Although
I think it deserves to be separated from exception handling.)

Georg 

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

[Larry Kilgallen]

In article <1111607633.301232.62490@z14g2000cwz.googlegroups.com>, "Jerry Coffin" <jcoffin@taeus.com> writes:

> Some of the cited cases provide checks that are free in terms of
> run-time, but run-time is hardly the major cost in most software.

Really ?

Even programs I write for my own personal use are run _many_ more times
than they are compiled.  Personally, I often spend compile time thinking
some more about the problem, sometimes to good advantage :-)

> Just for one obvious example, Ada doesn't provide an easy way to
> express/do most of the things one can do with the C or C++
> preprocessor.

It does not provide a preprocessor, for safety reasons.

But what programming step (as distinguished from construction trick)
can only be performed from a preprocessor ?

> Some areas are somewhat more questionable -- calling a class a "tagged
> record" is clearly a mistake, but it's open to question whether it
> should be classified under poor expression of the concept, or just
> general idiocy.

I see no mistake.  Is it possible your background in Pascal is inadequate
and overwhelmed by your background in C* languages.

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

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

>    2.  Your example did not use "straight" C++. Instead, you relied
>         on the Vector template.

I'm not sure why that's not "straight".  That feature is a standard part
of C++, so it seems fair to use it in an example.

What's not fair is to claim that it's the same thing as a fixed-length
array, or to claim that map is equivalent to vector.

> Regarding number 3, I wish Ada had a good model of multiple
> inheritance.

Ada 2005 has interfaces, which were inspired by Java.

- Bob

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

> And you can do really handy stuff passing arrays not indexed from 0,
> and accessing the attributes:
> 
> -- No particular purpose but to demo 
>   type MyString is array (Integer range <>) of Integer;
> 
>   procedure UpdateString (Blob : in out MyString; K : Integer) is
>    begin
> 
>       if Blob'Length = 0 then
>          return;
>       elsif Blob'Length = 1 then
>          Blob (Blob'First) := Blob (Blob'First) + K;
>          return;
>       else
>          UpdateString (Blob (Blob'First .. Blob'First+Blob'Length/2-1), 19);
>          UpdateString (Blob (Blob'First+Blob'Length/2 .. Blob'Last),    27);
>          return;
>       end if;
> 
>    end UpdateString;
> ...
>    UpdateString (Fred (10 .. 19), 0);


If you provide some explanations, I will give you the C++ equivalent.

What does this mean?

Blob : in out MyString



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Matthew Heaney]

Jerry Coffin wrote:
>
> char[] and wchar_t[] are arrays, not strings.

Well, that's true of Ada's String and Wide_String.


> C++ really only has one
> string type: std::basic_string. std::string and std::wstring are not
> types of their own at all, but simply typedefs as:
>
> typedef std::basic_string<char> string;
> typedef std::basic_string<wchar_t> wstring;

That's more or less what type Unbounded_String is, too.

There appears to be a difference in terminology.  I and every other
developer I know refers to type const char* as a string.  (For example,
H&S Ch. 13 is titled "String Processing.")

In any event, that's probably how the OP was using the term when he
said "Ada has 5 string types."  If you don't regard arrays as members
of the class of string types, then you can reduce Ada's count
accordingly.


> In addition, one of the major arguments the Ada fans have used here
is
> that Ada's strings are built-in, NOT added as a class like in C++. If
> C++ had been designed from the beginning with a string class, the
> array-based "stuff" probably wouldn't exist at all.

I don't see what difference it makes whether the type is built-in or
not.  What's wrong with an added class?  Perhaps they were refering to
the fact that you can declare array objects (strings) with non-static
bounds on the stack (since clearly Unbounded_String is not a built-in
type).


> BTW, in case anybody really cares, yes I apply the same standard to
> C++: while its string handling facilities are fewer and IMO better
than
> Ada's, they're still far short of perfect.

I prefer string handling in C++ too, but not being able to declare an
array (on the stack) with non-static bounds is a real pain sometimes
(although std::string mostly compensates for this).  I agree that Ada's
string handling facilities aren't as nice, but they do get the job
done.

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

[Ioannis Vranos]

Georg Bauhaus wrote:

>> In C++ you can throw an arbitrary type of object with an arbitrary
>> value.
> 
> 
> How well does this style of passing information work across thread
> boundaries?


Do you mean throwing an exception in one thread and catch it in another?


> (Not debating the usefulness of the mechanism. Although
> I think it deserves to be separated from exception handling.)



Actually it is bot separated, in C++ all standard library exception 
classes are (ordinary classes) derived from the base class exception 
defined in <exception>.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> 
> 
> I keep hearing about this µC++, may you provide a relevant link? I 
> couldn't find anything in google, is the first character a Greek 
> character? It appears as the Greek character 'm' in my screen.


http://plg.uwaterloo.ca/~usystem/

Seems like µ, or μ, is not a good search term. Try "uSystem".

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

[Robert A Duff]

"Jerry Coffin" <jcoffin@taeus.com> writes:

> In addition, one of the major arguments the Ada fans have used here is
> that Ada's strings are built-in, NOT added as a class like in C++.

*Some* Ada fans have used that argument, but I'm an Ada fan, and I don't
agree with it.  I happen to think that (other things being equal) it's
better to put functionality into libraries than to build them into the
syntax and semantics of the language.

- Bob

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1111613984.430545@athnrd02...

> What does this mean?
>
> Blob : in out MyString
>
It about the same as a non-constant reference.

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

[Robert A Duff]

Martin Dowie <martin.dowie@btopenworld.com> writes:

> Jerry Coffin wrote:
> >  And, once
> > again, the addition of tagged records to Ada 95 testifies to the fact
> > that even its own designers recognized the improvement this adds in
> > general, but (whether due to shortsightedness, concerns for backward
> > compatibility or whatever) didn't allow this improvement to be applied
> > in this situation.
> 
> Almost certainly backwards compatibility - but I'm sure Bob and/or Randy
> could shed more light on that...

Well, actually, during the Ada 9X design I tried to push for a
class-hierarchy of exceptions.  I don't like every detail of the way C++
does it, but at least in *this* regard, it's better than Ada.

Jerry Coffin is wrong that Ada does not allow attaching information to
exception, by the way.  Ada allows attaching Strings, which is
admittedly a kludge.  Using the class-hierarchy, as Jerry advocates,
would be cleaner, and type safe.

- Bob

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

[Robert A Duff]

"Jerry Coffin" <jcoffin@taeus.com> writes:

>...effort that's put into
> compile-time checks more or less directly translates into time and
> effort that was NOT put into better code generation and optimization.

True, but I think you misunderstood Peter Amey's point.  I believe he's
not talking about run-time checks that can be optimized away with some
compiler effort, but about purely compile time rules.  For example, both
languages have visibility rules, but I find Ada's visibility rules to be
less error prone than those of C++.

> Maybe...or maybe not. IME, absolute statements about generalities (e.g.
> all implementations of a language) are rarely accurate. Ada compilers
> vary quite widely, and I've certainly seen some emit code that included
> checks that were logically unnecessary. I'd guess that the current
> compilers are better, but perfection in this respect would surprise me.

It would surprise me, too, since it's provably impossible!
This is what Appel calls the full employment act for compiler
writers: no matter how smart a compiler is at optimizing,
you can always make it smarter.  And that's formally provable.

The real question is to what extent can checks be optimized away,
and how often one needs to resort to suppressing them, and this question
can only be answered via measurement.  By "measurement" I don't mean
bogus benchmarks written to make a point on one side or the other.  ;-)

By the way, *most* of the work a compiler does to optimize away checks
is the same as for other optimizations (despite what some Ada fans have
claimed in this thread), so optimizing away checks is not as costly as
you seem to think (in terms of compiler-writer's effort).

> Some areas are somewhat more questionable -- calling a class a "tagged
> record" is clearly a mistake, ...

Sorry, but if you think a class is called a tagged record in Ada,
you don't understand the language.

>... but it's open to question whether it
> should be classified under poor expression of the concept, or just
> general idiocy.

;-)

- Bob

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

[Georg Bauhaus]

Ioannis Vranos wrote:


>> The fastest possible element access in C++ is dereferencing a pointer.
>> The fastest possible element access in STL/C++ is varying with container
>> and method.
>>
>> Compare
>>
>>    type Floor_Number is -2 .. 52;
>>      --  sky scraper
>>
>>    type Door_Count is array(Floor_Number) of Natural;
>>
>> versus
>>
>>     typedef char Floor_Number;
>>     typedef std::map<Floor_Number, unsigned int> Door_Count;


> I can't understand why your code has faster access (I assume you mean 
> run-time efficiency).

Door_Count array access is faster because while it acts like
std::map<Floor_Number, unsigned int>, it is really an array.

Omitting the association of the indexing number numbers (-2 .. 52) with
the floors for the moment, these tests should demonstrate:

#include <map>
#include <hash_map>  // GNU: #include <ext/hash_map>, __gnu_cxx::hash_map
#include <valarray>
#include <vector>

#define M 55  // array size
#define N 10000  // assigments
#define R 5000  // runs


struct Test {    // compare random access to keyed access

  void arrays() {
    int a[M];
    
    for (int k = 0; k < N; ++k)
      a[k % M] = k;
  }

  void valarrays() {
    std::valarray<int> a(M);
    
    for (int k = 0; k < N; ++k)
      a[k % M] = k;
  }

  void vectors() {
    std::vector<int> a(M);
    
    for (int k = 0; k < N; ++k)
      a[k % M] = k;
  }

  void maps() {
    std::map<int, int> a;
    
    for (int k = 0; k < N; ++k)
      a[k % M] = k;
  }

  void hash_maps() {
    std::hash_map<int, int> a;
    
    for (int k = 0; k < N; ++k)
      a[k % M] = k;
  }

};

int main()
{
  Test t;

  for (int run = 0; run < R; ++run)
    t.arrays();
    // t.valarrays();
    // t.vectors();
    // t.maps();
    // t.hash_maps();

  return 0;
}

> To give another example, .NET does not provide such an array container 
> either, in its own containers collection. So why such a mainstream 
> framework does not provide an array type with negative indexing either?

C# does provide fixing arrays.

I think we can't buy high speed computing components from the
producers of .NET. However, Fortran for .NET is available. (Doesn't mean
the producers of libraries will use non-default index value in Fortran code.)
So is APL.


> This is not some kind of general proof, but for me it is an indication. 
> Again, I agree that boundary checking etc are useful and should be added 
> in C++ perhaps with additional keywords.

Have you had a look at D?

 
> Just to be technically accurate. C++ has fixed size built in arrays. It 
> doesn't provide range checking for them though.

OK. And lets see what happens when the C99 arrays will be adopted.

Georg 

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

[Jerry Coffin]

Larry Kilgallen wrote:
> In article <1111607633.301232.62490@z14g2000cwz.googlegroups.com>,
"Jerry Coffin" <jcoffin@taeus.com> writes:
>
> > Some of the cited cases provide checks that are free in terms of
> > run-time, but run-time is hardly the major cost in most software.
>
> Really ?
>
> Even programs I write for my own personal use are run _many_ more
> times than they are compiled.  Personally, I often spend compile
> time thinking some more about the problem, sometimes to good
> advantage :-)

Being compiled isn't the major cost either.

For an awful lot of software, being run multitudes of times doesn't
make speed important -- interactive software (for one example) has
something on the order of really soft real-time requirements. I.e. too
slow is mildly annoying, but any response time under 100 ms or so
qualifies as "instant", and after that making it 100 or even a million
times faster rarely accomplishes much.

> > Just for one obvious example, Ada doesn't provide an easy way to
> > express/do most of the things one can do with the C or C++
> > preprocessor.
>
> It does not provide a preprocessor, for safety reasons.

Look again at the wording -- I spoke in terms of the capabilities that
C happens to provide as what's generally called the preprocessor.  I
could say "phases 1 through 6 of translation" if I wanted to be more
formal, but it's utterly irrelevant.

Regardless of the wording, however, I think this is (mostly) a
red-herring. What do you consider unsafe about (for example) some chunk
of code being compiled only when I want it to be? If I really believe
in the compiler's optimizer, I can already do things like "if False" in
Ada, and that code clearly won't ever execute. It just happens that C
and C++ provide a simple and practical method of doing the same things
in a way that's easy to externally control.

> But what programming step (as distinguished from construction trick)
> can only be performed from a preprocessor ?

Attempting to separate programming from constructing (a program) seems
to me a strong indication that you don't really know much of what
you're talking about. Regardless of this, however, the fact is that
even in Ada people who have a preprocessor available (e.g. with GNAT)
frequently find it extremely useful -- but using it renders the code
completely non-portable.

> > Some areas are somewhat more questionable -- calling a class a
> > "tagged record" is clearly a mistake, but it's open to question
> > whether it should be classified under poor expression of the
> > concept, or just general idiocy.
>
> I see no mistake.

There is none so blind as he who will not see. The biggest problem is
that "tagged record" is a low-level description -- i.e. it's about the
implementation, not the real concept. A secondary problem is that in
other Pascal-family languages (e.g. Pascal, Modula II, Modula 3 and
probably Oberon), a "tag" is the distinguishing characteristics of a
variant record, having nothing to do with object orientation.

> Is it possible your background in Pascal is inadequate
> and overwhelmed by your background in C* languages.

Pascal has records, but not "tagged records". I don't believe Modula
II, Modula 3 or Oberon uses such poor terminology either. I don't see
how background in C signifies at all, since it doesn't use "record",
"tagged record" or "class" at all. I suppose one could point out that C
uses names that reasonably accurately reflect what's being discussed,
but I have a hard time calling that a bad thing...

OTOH, if you look through a language-neutral book on object oriented
programming, you'll "class" used to name a rather general concept quite
routinely. By contrast, I've yet to see "tagged record" used to
describe anything except the syntax of Ada 95.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[adaworks]

"kevin cline" <kevin.cline@gmail.com> wrote in message
news:1110830710.027630.241160@g14g2000cwa.googlegroups.com...
>
> adaworks@sbcglobal.net wrote:
>
> >
> > 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.
>
> But not all lines of source code are created equally.  Written in a
> more expressive language the application might be only half that size,
> or most likely even less.
>
Ada is every bit as expressive as C++.  There is not likely to be
any improvement in the number of KSLOC using C++.  Oh, yes,
if we choose to use a cryptic form of C++, with all the little
shortcuts that make the code less readable, we might achieve
some reduction in the KSLOC, but at what cost in understandability?

Richard Riehle

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

[adaworks]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1111611723.490897@athnrd02...
> adaworks@sbcglobal.net wrote:
>
> > OK.  I read your C++ example with care and interest.
> > Then I compared it, once again, with the example I wrote.
> >
> > I wonder if you truly think the two examples are equlivalent
> > in all respects.    I must confess that, if the C++ example
> > were an accurate representation of how one would solve
> > this problem in that language, I would abandon C++ for
> > all time.
> >
> > A key goal of Ada is to produce readable code, not simply
> > writeable solutions in cryptic code.   Who, upon encountering
> > the C++ example in your post, would be able to quickly
> > apprehend the meaning, the intent, or the result of this
> > code?
>
>
> Believe it or not, I do not understand most of Ada code, apart from some
> Pascal-like constructs here and there. :-)
>
I am not asking, which non-C++  programmer will understand the code.  I am
suggesting that the code will be less-than obvious to many C++ programmers.
Certainly, after careful study, the experienced C++ programmer might be
able to read your example, but there is room for misinterpretation unless
one is supplied a fair amount of documentation.

Also, if you are unfamiliar with Ada to the point where you cannot read
the code, I find it strange that you are so willing to publicly criticize it.

I am required to understand C++ code because of my daily working
conditions.   My criticisms of it are mostly due to my direct experience
with it.   Your criticisms of Ada seem to derive from your lack of
experience.  Perhaps a little more study and preparation would be
helpful.  In fact, once you understand contemporary Ada, you might
be a bit less quick to criticize it.

Richard Riehle

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> http://plg.uwaterloo.ca/~usystem/
> 
> Seems like µ, or μ, is not a good search term. Try "uSystem".


I prefer to stick with C++, OpenMP and system-specific multithreading 
for the moment.

Boost also provides a multithreading library.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

adaworks@sbcglobal.net wrote:

> I am not asking, which non-C++  programmer will understand the code.  I am
> suggesting that the code will be less-than obvious to many C++ programmers.
> Certainly, after careful study, the experienced C++ programmer might be
> able to read your example, but there is room for misinterpretation unless
> one is supplied a fair amount of documentation.


Any intermediate C++ programmer should be able to understand my examples.


> Also, if you are unfamiliar with Ada to the point where you cannot read
> the code, I find it strange that you are so willing to publicly criticize it.


Who said I am criticizing it? As I have mentioned many times already I 
like Ada (for me it is something like Pascal as it should have been in 
the first place), and will probably learn it some time in the future.

However I am trying to set some things straight regarding unfair C++ 
criticisms (and when they prove fair, it's OK with me), and argue a bit, 
on how this and that can be done in Ada and which is better.

My conclusion is that both languages share some common ideals and both 
languages offer things that the other does not offer. Now which one 
offers the most of them, is an entirely other subject.

In summary wecan say that both languages are mature and *both* do their 
job. So it will be *unfair* to say that one of them is insufficient to 
do application development or systems programming.


> I am required to understand C++ code because of my daily working
> conditions.   My criticisms of it are mostly due to my direct experience
> with it.   Your criticisms of Ada seem to derive from your lack of
> experience.


Personally I do not like Pascal. However I like Ada! And yes, I do not 
know Ada. Also I do not think I am doing criticism, I am just checking 
some features and arguing with Ada programmers which language provides 
them better.


In this thread of course, there may be others who do not like Ada or C++ 
in any way. :-)




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Wed, 23 Mar 2005 23:39:44 +0200, Ioannis Vranos wrote:

> Dr. Adrian Wrigley wrote:
> 
>> And you can do really handy stuff passing arrays not indexed from 0,
>> and accessing the attributes:
>> 
>> -- No particular purpose but to demo 
>>   type MyString is array (Integer range <>) of Integer;
>> 
>>   procedure UpdateString (Blob : in out MyString; K : Integer) is
>>    begin
>> 
>>       if Blob'Length = 0 then
>>          return;
>>       elsif Blob'Length = 1 then
>>          Blob (Blob'First) := Blob (Blob'First) + K;
>>          return;
>>       else
>>          UpdateString (Blob (Blob'First .. Blob'First+Blob'Length/2-1), 19);
>>          UpdateString (Blob (Blob'First+Blob'Length/2 .. Blob'Last),    27);
>>          return;
>>       end if;
>> 
>>    end UpdateString;
>> ...
>>    UpdateString (Fred (10 .. 19), 0);
> 
> 
> If you provide some explanations, I will give you the C++ equivalent.

UpdateString takes an array indexed by integers, updating bottom
and top halves recursively in some obscure way.

The point is that the input parameter is an array with upper and lower
bounds which are arbitrary, and are different at each level of
recursion.  I have created the arguments to the recursive call
by slicing the input parameter into two half arrays, with the
help of the array attributes ('First, 'Last, 'Length).  Normally,
this takes place without any copying.  No heap allocation is
required, and any accesses outside the intended array range for
updating at each level of recursion are excepted.

The most obvious C++ implementation is with vectors, but I think
you need three additional parameters and several checks to get
equivalent semantics.  The three new parameters might be
'StartElement' 'EndElement' and 'BaseOffset'.  You need the
BaseOffset to accommodate the vectors always starting at 0,
so you can find the problem-domain start.

You may get into problems if the procedure needs to call
other functions that take a vector, if they are unable to
take upper and lower limits to process.  Can you make a
vector which is a slice of another vector without copying
all the elements in and out?

This kind of recursive slicing of arrays is something I
have found *much* more natural and reliable in Ada than in C,
where hacking with pointer arithmetic and extra parameters
would be the usual solution.

Hope this helps.
-- 
Adrian

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> Door_Count array access is faster because while it acts like
> std::map<Floor_Number, unsigned int>, it is really an array.
> 
> Omitting the association of the indexing number numbers (-2 .. 52) with
> the floors for the moment, these tests should demonstrate:
> 
> #include <map>
> #include <hash_map>  // GNU: #include <ext/hash_map>, __gnu_cxx::hash_map
> #include <valarray>
> #include <vector>
> 
> #define M 55  // array size
> #define N 10000  // assigments
> #define R 5000  // runs
> 
> 
> struct Test {    // compare random access to keyed access
> 
>  void arrays() {
>    int a[M];
>       for (int k = 0; k < N; ++k)
>      a[k % M] = k;
>  }
> 
>  void valarrays() {
>    std::valarray<int> a(M);
>       for (int k = 0; k < N; ++k)
>      a[k % M] = k;
>  }
> 
>  void vectors() {
>    std::vector<int> a(M);
>       for (int k = 0; k < N; ++k)
>      a[k % M] = k;
>  }
> 
>  void maps() {
>    std::map<int, int> a;
>       for (int k = 0; k < N; ++k)
>      a[k % M] = k;
>  }
> 
>  void hash_maps() {
>    std::hash_map<int, int> a;
>       for (int k = 0; k < N; ++k)
>      a[k % M] = k;
>  }
> 
> };
> 
> int main()
> {
>  Test t;
> 
>  for (int run = 0; run < R; ++run)
>    t.arrays();
>    // t.valarrays();
>    // t.vectors();
>    // t.maps();
>    // t.hash_maps();
> 
>  return 0;
> }



I am not sure what you mean with the above, perhaps to use the 
facilities of <ctime> to measure their performance? Of course vector is 
faster than map.



> C# does provide fixing arrays.


You mean it can use signed indices? Look, just to be technically 
accurate, C++ can also use negative indices, but I avoided mentioning it 
because I considered it an unnecessary feature (again why then someone 
did not provide an array container with signed indices as the default, 
since it can be done?). But here is an example:


#include <iostream>
#include <vector>

int main()
{
     using namespace std;

     vector<int> vec(10);

     vector<int>::iterator pi= vec.begin()+4;

     // Makes vec[2]== 4.
     pi[-2]= 4;

     pi[1]= 3;

     pi[0]= 9;


     //built in array
     int somearray[4];

     int *p= somearray+2;

     //Makes somearray[1]== 9
     p[-1]= 9;
}



> I think we can't buy high speed computing components from the
> producers of .NET. However, Fortran for .NET is available. (Doesn't mean
> the producers of libraries will use non-default index value in Fortran 
> code.)
> So is APL.


In any case, with C++/CLI, C++ becomes the systems programming language 
of .NET.


>> Just to be technically accurate. C++ has fixed size built in arrays. 
>> It doesn't provide range checking for them though.
> 
> 
> OK. And lets see what happens when the C99 arrays will be adopted.

Do you mean C99's built in Variable Length Arrays (VLAs)? I do not think 
they will be adopted in C++.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Jerry Coffin]

Martin Dowie wrote:
> Jerry Coffin wrote:
> > Just for one obvious example, Ada doesn't provide an easy way to
> > express/do most of the things one can do with the C or C++
> > preprocessor. It provides some alternative in _some_ cases, but
> > quite frankly, these are really the exceptions rather than the
> > rule.
>
> That 'problem' isn't unique to Ada - I can't think of another
> language that *does* define a pre-processor.

A preprocessor per so, no. The type of capabilities is a different
story. For example, Lisp includes macros. Most assemblers include (much
more extensive) macros as well as an eqiuvalent of C's
#if/#ifdef/#ifndef/#endif. Literal defininitons in PL/M provided some
of the same capabilities as C macros. I could go on for a while, but
you get the general idea -- the general capabilities aren't entirely
unique to C and C++, but are almost entirely missing from Ada.

> And if you like a preprocessor - just use one! You can always write
> a makefile/.bat/.com/<whatever> to invoke the preprocessor before the
> compiler is called. GNAT comes with an Ada-centric preprocessor but
> there is nothing to stop you using the 'C' one.

This merely changes the problem rather than solving it. Many typical
uses of the preprocessor in C are to deal with portability issues, but
you're asking that they be dealt with by adding yet another program to
be ported.

Even ignoring that, the system is essentially unusable. C and C++
compilers (admittedly, more or less out of necessity) provide
directives so the preprocessor can specify which line in the original
source code resulted in a particular line that was given to the
compiler. This allows the compiler to refer error messages back to the
correct line in the original source code quite easily, and the
compilers do so quite dependably. TTBOMK, Ada compilers don't
(normally) support such directives, rendering the system impractical at
best because error messages are essentially always incorrect.

[ ... ]

> See Ada.Exceptions - perhaps not as elegant but it does the job and
> back when the first exception mechanism for Ada was designed, I doubt
> there was much call for anything other than a 'this fault has
> occured' style exception. At the time, I'd guess that 90%+ of all
> code in exsistance was COBOL, C or FORTRAN - none of which had any
> exception handling!

Having no exceptions at all means you report errors in some other
fashion, and you're free to design one that's as expressive as you
need. The exception handling in Ada is inadequate to the job (at least
IME), but its presence makes it virtually impossible to convince
anybody to accept anything else either.

In many cases, having a feature in an inadequate form is really _worse_
than not having it at all, even if the basic idea of the feature is a
good one. Having the feature rules out alternatives (in may people's
minds), even when they're really superior.

>  > Only exact matches
>  > are supported and no information is included beyond the identity
>  > of the exception.
>
> True for Ada83 but not so in Ada95 - again see Ada.Exceptions and
> getting expanded again in Ada2005.

This clearly allows more information to be transmitted, which I'd
consider an improvement. Perhaps I'm missing something, but I still
don't see a provision for anything equivalent to catching a reference
to a base class in C++, at least as of Ada 95. Is this being added in
Ada 2005, or have I mis-read things?

> >  And, once
> > again, the addition of tagged records to Ada 95 testifies to the
> > fact that even its own designers recognized the improvement this
> > adds in general, but (whether due to shortsightedness, concerns
> > for backward compatibility or whatever) didn't allow this
> > improvement to be applied in this situation.
>
> Almost certainly backwards compatibility - but I'm sure Bob and/or
> Randy could shed more light on that...

That certainly seems like the obvious guess. In the end, it may explain
the situation, but doesn't really improve it. The same, of course,
applies to C++, which clearly makes some sacrifices to maintain a high
degree of compatibility with C. At the same time, I have to say that
IMO, C++ gains more (e.g. C has a much larger user base) while
sacrificing less (C compatibility has produced minor annoyances into
C++, but IMO Ada's exception handling is sufficiently broken that it
seriously detracts from the language).

-- 
    Later,
    Jerry.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

>>Dr. Adrian Wrigley wrote:
>>
>>
>>>And you can do really handy stuff passing arrays not indexed from 0,
>>>and accessing the attributes:
>>>
>>>-- No particular purpose but to demo 
>>>  type MyString is array (Integer range <>) of Integer;
>>>
>>>  procedure UpdateString (Blob : in out MyString; K : Integer) is
>>>   begin
>>>
>>>      if Blob'Length = 0 then
>>>         return;
>>>      elsif Blob'Length = 1 then
>>>         Blob (Blob'First) := Blob (Blob'First) + K;
>>>         return;
>>>      else
>>>         UpdateString (Blob (Blob'First .. Blob'First+Blob'Length/2-1), 19);
>>>         UpdateString (Blob (Blob'First+Blob'Length/2 .. Blob'Last),    27);
>>>         return;
>>>      end if;
>>>
>>>   end UpdateString;
>>>...
>>>   UpdateString (Fred (10 .. 19), 0);
>>
>>
>>If you provide some explanations, I will give you the C++ equivalent.
> 
> 
> UpdateString takes an array indexed by integers, updating bottom
> and top halves recursively in some obscure way.


OK.


> 
> The point is that the input parameter is an array with upper and lower
> bounds which are arbitrary, and are different at each level of
> recursion.


Which provides no real benefit at least in this function.


>  I have created the arguments to the recursive call
> by slicing the input parameter into two half arrays, with the
> help of the array attributes ('First, 'Last, 'Length).  Normally,
> this takes place without any copying.  No heap allocation is
> required, and any accesses outside the intended array range for
> updating at each level of recursion are excepted.
> 
> The most obvious C++ implementation is with vectors, but I think
> you need three additional parameters and several checks to get
> equivalent semantics.  The three new parameters might be
> 'StartElement' 'EndElement' and 'BaseOffset'.  You need the
> BaseOffset to accommodate the vectors always starting at 0,
> so you can find the problem-domain start.
> 
> You may get into problems if the procedure needs to call
> other functions that take a vector, if they are unable to
> take upper and lower limits to process.  Can you make a
> vector which is a slice of another vector without copying
> all the elements in and out?
> 
> This kind of recursive slicing of arrays is something I
> have found *much* more natural and reliable in Ada than in C,
> where hacking with pointer arithmetic and extra parameters
> would be the usual solution.


One can use two iterators while passing the length as an extra function 
parameter.

Besides that, nothing else changes.


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Jerry Coffin]

Robert A Duff wrote:
> "Jerry Coffin" <jcoffin@taeus.com> writes:
>
> > In addition, one of the major arguments the Ada fans have used here
> > is that Ada's strings are built-in, NOT added as a class like in
> > C++.
>
> *Some* Ada fans have used that argument, but I'm an Ada fan, and I
> don't agree with it.  I happen to think that (other things being
> equal) it's better to put functionality into libraries than to build
> them into the syntax and semantics of the language.

You're right. I did not intend to put words in your mouth (or anybody
else's for that matter). What I said was wrong, and I apologize.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Matthew Heaney]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> I think an associative container like map fits better to this. What do
> you do in Ada if you want to associate product names with prices, in
> the style:
> 
> productlist["something"]= 71.2;

Ada 2005 comes with a standard container library, very similar to the
C++ STL.  For example:

declare
  package Map_Types is
    new Ada.Containers.Indefinite_Ordered_Maps
     (String,
      Float);

  M : Map_Types.Map;
begin
  M.Include (Key => "something", New_Item => 71.2);
end;

There's also a standard hashed map.


> or a name with a number (string with string) in an address book
> application for example?
> 
> 
> namelist["Obry Pascal"]="321-45563";

See above.  The element type in this case is String instead of Float.


> Also may you tell me if that famous compile-time boundary checking
> applies (can be used) to user-defined containers too?

I guess the answer is yes, since subtype constraints are inherited from
generic actual types.  For example, if we have:

  type My_Float is new Float range 0.0 .. 42.0;

and you instantiate the map with My_Float, then you'll get
Constraint_Error if you attempt to insert a float value outside the
range of the subtype.

-Matt

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

[Jim Rogers]

Ioannis Vranos <ivr@remove.this.grad.com> wrote in news:1111607860.485769
@athnrd02:

> Pascal Obry wrote:
> 
>> We have vector.
> 
> 
> If it is also defined in std namespace, I am going to smile.

Ada does not have anything called std namespace.

Ada packages provide encapsulation and namespaces. 
Ada does provide a package named Standard, but that is where
fundamental data types are defined such as Standard.Integer.

No containers are defined in Standard. There is no need for 
this in Ada.

Jim Rogers

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

[Matthew Heaney]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> BTW does Ada provide dynamic arrays like vector/deque?

If you know the capacity at the time of declaration, then you can just
use an array.  That has always been true since Ada83.

Otherwise you can use the new vector container, which is basically the
same as the C++ std::vector.

-Matt

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

[Jerry Coffin]

Robert A Duff wrote:

[ ... ]

> By the way, *most* of the work a compiler does to optimize away
> checks is the same as for other optimizations (despite what some
> Ada fans have claimed in this thread), so optimizing away checks is
> not as costly as you seem to think (in terms of compiler-writer's
> effort).

First of all, I'm not saying the cost is necessarily particularly high,
only that _very_ few things are free, even when the cost isn't
necessarily obvious.

Second, as far as the optimization itself goes, it should be basically
constant folding followed dead-code elimination. It's certainly true
that most optimizing compilers are already likely to include both, and
it's also true that techniques for both have been well-known for some
time (I'm pretty sure the Dragon book includes examples of each).
Nonetheless, while doing them to at least some extent is well-known,
each is typically open to at least some improvement. At least to me, it
appears that producing efficient output from Ada source code depends
more upon them being done well than is the case for most other
languages.

> > Some areas are somewhat more questionable -- calling a class a
> > "tagged record" is clearly a mistake, ...
>
> Sorry, but if you think a class is called a tagged record in Ada,
> you don't understand the language.

I'll openly admit that my knowledge of Ada 95 is _extremely_ limited
(I'm afraid I quit using Ada before 1995). Perhaps I need to take
another look in this area.

OTOH, doing a bit more looking, if I've misunderstood the situation, at
least I have some company.  For example:

http://en.wikibooks.org/wiki/Programming:Ada:Types:record

claims that "The tagged record is what in other languages is called a
class."

Likewise:

http://www.adaic.com/docs/95style/html/sec_9/9-2-1.html

while less explicit about the equivalence, makes statements that
certainly make a tagged record look and sound a great deal like a class
in C++.

Perhaps you can provide a better explanation?

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Jim Rogers]

One Ada feature that cannot be implemented through any container library
is the ability to define a range-restricted floating point type. You can
do this in C++, but not through the use of a template. Templates cannot 
take floating point values as parameters.

For instance, in Ada it is trivial to define a floating point type with
10 decimal digits of precision and all values in the range of 0.0 through 
1.0.

This sort of type is very useful for defining normalized values.

type Normalized is digits 10 range 0.0..1.0;

I used this technique for robotic control systems. The value read
from a joystick indicating a turn could be normalized, sent across
an RF link to the robotic vehicle, and then converted to the dynamic
range available to the target actuator. The joystick could employ a
14-bit a/d converter, or it could employ a 10-bit a/d converter. The
actuator never saw a difference. The joystick output was decoupled
from the actuator input while providing excellent control 
capabilities.

The compiler could ensure that all normalized values were within
the required range of 0.0 through 1.0. This allowed me to eliminate
explicit error checking in my code while retaining data correctness.

Jim Rogers

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> Georg Bauhaus wrote:
>>
>> struct Test {    // compare random access to keyed access
>>

>>  for (int run = 0; run < R; ++run)
>>    t.arrays();

> I am not sure what you mean with the above, perhaps to use the 
> facilities of <ctime> to measure their performance? Of course vector is 
> faster than map.

You say "of course" now? I don't really understand then
why you asked me why my Ada _array_ code is faster than your
C++ std::_map_ code.

>> C# does provide fixing arrays.
> 
> 
> 
> You mean it can use signed indices?

Not at all. I mean that C# arrays can be dynamic or fixed size.
They always start at 0, IIRC.

>Look, just to be technically 
> accurate, C++ can also use negative indices,

Actually, there is no negative index in your example.
There are some offset computations, resulting in index
values no less than 0.
 By the same argument I could say that a 10-element
C-array can be indexed by the number 100000 by first
decrementing the pointer and then adding 100000 as an
offset. But you do not get the element number 100000,
because there is no such element. 

Index types are conceptually different from offsets from
the first element.

As a clever trick, this is nice though. I like the power
of assembly think.
 

>     vector<int>::iterator pi= vec.begin()+4;
> 
>     // Makes vec[2]== 4.
>     pi[-2]= 4;

>> OK. And lets see what happens when the C99 arrays will be adopted.
> 
> 
> Do you mean C99's built in Variable Length Arrays (VLAs)? I do not think 
> they will be adopted in C++.

Let's see.

Georg 

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Matthew Heaney]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> inline int doubleF(const int &arg) { return 2*arg; }
> 
> vector<int>someArray(10, 1);
> 
> transform( someArray.begin(), someArray.end(),
>             someArray.begin(), doubleF );

You can do this in Ada something like:

declare
  V : Integer_Vectors.Vector := To_Vector (1, 10);

  procedure Double_Arg (C : Cursor) is
     procedure Process (I : in out Integer) is
     begin
        I := 2 * I;
     end;
  begin
     Update_Element (C, Process'Access);
  end;
begin
  V.Iterate (Double_Arg'Access);
end;

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Ioannis Vranos wrote:

> One can use two iterators while passing the length as an extra function 
> parameter.


On second thought, I think no extra parameter is required. I think this 
qualifies as the C++ equivalent:


#include <vector>

typedef std::vector<int>::iterator iter;

void UpdateString(const iter iFirst, const iter iSecond, int K)
{
     const int SIZE= iSecond-iFirst;

     if(SIZE== 0)
       return;

     else if(SIZE==1)
     {
         *iSecond+=K;
         return;
     }

     else
     {
         UpdateString(iFirst, iFirst+ SIZE/2 -1, 19);
         UpdateString(iFirst+ SIZE/2, iSecond, 27);
         return;
     }
}


int main()
{
     using std::vector;

     vector<int> vec(10);

     // Pass a subrange
     UpdateString(vec.begin(), vec.begin()+4, 0);
}



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Matthew Heaney]

Jim Rogers <jimmaureenrogers@att.net> writes:

> No containers are defined in Standard. 

I think the language model is that library-level declarations are
"logically" nested within package Standard, so you could make an
argument that the containers are indeed "defined in Standard."


> There is no need for this in Ada.

Hmmm... not sure what you mean.  There certainly is a need to partition
the global namespace, which is why we have the Ada, System, Interface,
etc, package hierarchies.  This is no different from what C++ does.

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

[Ioannis Vranos]

Jim Rogers wrote:

> One Ada feature that cannot be implemented through any container library
> is the ability to define a range-restricted floating point type. You can
> do this in C++, but not through the use of a template. Templates cannot 
> take floating point values as parameters.
> 
> For instance, in Ada it is trivial to define a floating point type with
> 10 decimal digits of precision and all values in the range of 0.0 through 
> 1.0.
> 
> This sort of type is very useful for defining normalized values.
> 
> type Normalized is digits 10 range 0.0..1.0;
> 
> I used this technique for robotic control systems. The value read
> from a joystick indicating a turn could be normalized, sent across
> an RF link to the robotic vehicle, and then converted to the dynamic
> range available to the target actuator. The joystick could employ a
> 14-bit a/d converter, or it could employ a 10-bit a/d converter. The
> actuator never saw a difference. The joystick output was decoupled
> from the actuator input while providing excellent control 
> capabilities.
> 
> The compiler could ensure that all normalized values were within
> the required range of 0.0 through 1.0. This allowed me to eliminate
> explicit error checking in my code while retaining data correctness.



There are C++ libraries that provide such functionality. I suppose one 
of them is GMP:

http://www.swox.com/gmp


http://www.swox.com/gmp/manual/Floating-point-Functions.html#Floating-point%20Functions



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Jim Rogers]

"Jerry Coffin" <jcoffin@taeus.com> wrote in news:1111619568.938415.90010
@g14g2000cwa.googlegroups.com:

> 
> Regardless of the wording, however, I think this is (mostly) a
> red-herring. What do you consider unsafe about (for example) some chunk
> of code being compiled only when I want it to be? If I really believe
> in the compiler's optimizer, I can already do things like "if False" in
> Ada, and that code clearly won't ever execute. It just happens that C
> and C++ provide a simple and practical method of doing the same things
> in a way that's easy to externally control.

The kinds of things that were considered unsafe with a pre-processor are
those things that are not type-safe. These problems sometimes arise in
the use of macros.

For instance the following macro can cause some serious problems when
mis-applied:

#define SWAP(A,B)  ((temp) = (A);(A) = (B); (B) = (temp))

char s1[30];
int i;

SWAP(S1, i);

In many cases it is safer to define an in-line function than to
define a macro.

Jim Rogers

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

[Wes Groleau]

adaworks@sbcglobal.net wrote:
> There are lots of good uses for multiple inheritance.  However,
> there are also lots of dangers in it.  Ada correctly comes down
> on the side of safety, but I do sometimes wish it were available.

One thing I've never quite understood is the argument of ambiguity.
Ada allows other things that have a potential of ambiguity.  The
solution there is that when something _actually_ has two meanings
(as opposed to _potentially_) then you get neither.

That is the approach perl takes to multiple inheritance.  At least
I think so--I haven't finished studying it.  What does C++ or Eiffel
do when multiple inheritance creates two meanings for the same name?

-- 
Wes Groleau
    "Would the prodigal have gone home if
     the elder brother was running the farm?"
                       -- James Jordan

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

[Matthew Heaney]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> Also the lack of a "STL like" library in Ada until now probably sounds
> like that Ada lacks much of the high-level abstraction that C++
> provides.

It had nothing to do with language features.  Except for a few little
things (mostly having to do with syntax), the Ada 2005 standard
container library could have been written in Ada95 or Ada83.

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

[Ioannis Vranos]

Georg Bauhaus wrote:

> You say "of course" now? I don't really understand then
> why you asked me why my Ada _array_ code is faster than your
> C++ std::_map_ code.


I suppose I did not notice that you were comparing with std::map at that 
point. Direct comparison of an Ada fixed size array should be vs vector 
or better, valarray.


> Actually, there is no negative index in your example.
> There are some offset computations, resulting in index
> values no less than 0.
> By the same argument I could say that a 10-element
> C-array can be indexed by the number 100000 by first
> decrementing the pointer and then adding 100000 as an
> offset. But you do not get the element number 100000,
> because there is no such element.


Actually this example produces undefined behaviour, since valid 
behaviour is to point/access within the sequence or point (and not 
access) one past the end element of the sequence.


But in a case where


vector<int> vec(10);

vector<int>::iterator pi= vec.begin()+4;

// ...

pi[-2]= 4;


it accesses an actual object (there is an actual object) there.


I can not understand why in an array with index range [-200, -100] there 
is an object in -199 "more" than the example above.



> Index types are conceptually different from offsets from
> the first element.


In C++, index is always (has the notion of) an offset.


> As a clever trick, this is nice though. I like the power
> of assembly think.


Yes I think it's cool too. :-)


Not to mention that we can treat any part of a built in array or an 
object as a sequence of unsigned chars (bytes).



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Wes Groleau]

Larry Kilgallen wrote:
> In article <1111607633.301232.62490@z14g2000cwz.googlegroups.com>, "Jerry Coffin" <jcoffin@taeus.com> writes:
> 
>>Some of the cited cases provide checks that are free in terms of
>>run-time, but run-time is hardly the major cost in most software.
> 
> Really ?

He's right.  Most software is written in languages where
debugging time is the major cost.  :-)

-- 
Wes Groleau

   Armchair Activism: http://www.breakthechain.org/armchair.html

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

[Jim Rogers]

Ioannis Vranos <ivr@remove.this.grad.com> wrote in
news:1111631889.495954@athnrd02: 

> Jim Rogers wrote:
>> For instance, in Ada it is trivial to define a floating point type
>> with 10 decimal digits of precision and all values in the range of
>> 0.0 through 1.0.
>> 
>> This sort of type is very useful for defining normalized values.
>> 
>> type Normalized is digits 10 range 0.0..1.0;
>> 
> 
> 
> There are C++ libraries that provide such functionality. I suppose one
> of them is GMP:
> 
> http://www.swox.com/gmp
> 
> 
> http://www.swox.com/gmp/manual/Floating-point-Functions.html#Floating-p
> oint%20Functions 

My reading of the information at that url indicates that GMP allows
the specification of precision, but not the specification of a limited
range of valid values.

The Ada example above specifies a precision of 10 digits and also
specifies a range of valid values from 0.0 through 1.0. 

Jim Rogers

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

[Wes Groleau]

adaworks@sbcglobal.net wrote:
> if we choose to use a cryptic form of C++, with all the little
> shortcuts that make the code less readable, we might achieve
> some reduction in the KSLOC, but at what cost in understandability?

And at what cost in development time?  If the reader can't
understand the code, chances are the writer doesn't understand it
as well as he thinks he does (or she).

"If it ain't broke, don't fix it."

    "With all due respect, sir, if nobody understands it, it's broke."


-- 
Wes Groleau

    In any formula, constants (especially those obtained
    from handbooks) are to be treated as variables.

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

[Ioannis Vranos]

Wes Groleau wrote:

> That is the approach perl takes to multiple inheritance.  At least
> I think so--I haven't finished studying it.  What does C++ or Eiffel
> do when multiple inheritance creates two meanings for the same name?


What do you mean by two meanings?



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ed Falis]

On 23 Mar 2005 18:16:42 -0800, Jerry Coffin <jcoffin@taeus.com> wrote:

>> Sorry, but if you think a class is called a tagged record in Ada,
>> you don't understand the language.
> I'll openly admit that my knowledge of Ada 95 is _extremely_ limited
> (I'm afraid I quit using Ada before 1995). Perhaps I need to take
> another look in this area.
> OTOH, doing a bit more looking, if I've misunderstood the situation, at
> least I have some company.  For example:


This is just a matter of simile.  A tagged type and derivatives of tagged  
types provide dispatching and other typical OOP facilities.  Where the  
concept differs from the class concept is that visibility is orthogonal,  
provided by packages and other more traditional Ada facilities, while the  
class concept combines the two.

- Ed

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

[Wes Groleau]

Ioannis Vranos wrote:
> Wes Groleau wrote:
> 
>> That is the approach perl takes to multiple inheritance.  At least
>> I think so--I haven't finished studying it.  What does C++ or Eiffel
>> do when multiple inheritance creates two meanings for the same name?
> 
> What do you mean by two meanings?

Class Wagon has method Draw.
Class Picture has method Draw.

If you multiply inherit to make
Class Picture_Of_A_Wagon, what does the method Draw do?

This was one of the arguments against having multiple
inheritance.  But I think it's a silly argument.  One
could just as logically argue that the "use" clause
should not exist because two packages might have Draw
subprograms.  Or that overloading should not be allowed
because it's possible to write something ambiguous.

Ada's answer for the former is that if and only if the
situation _actually_ arises, neither of the choices is visible.

For the latter, the code just won't compile.

-- 
Wes Groleau

    "There ain't nothin' in this world that's worth being a snot over."
                                  -- Larry Wall

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

[Ed Falis]

On Wed, 23 Mar 2005 21:42:58 -0500, Wes Groleau  
<groleau+news@freeshell.org> wrote:

> That is the approach perl takes to multiple inheritance.  At least
> I think so--I haven't finished studying it.  What does C++ or Eiffel
> do when multiple inheritance creates two meanings for the same name?
>


Eiffel has very nice and elegant facilities for resolving ambiguities.  A  
lot of thought went into the situation of "diamond inheritance", where an  
ultimate base class is inherited via two distinct ancestors, and how to  
resolve it.  Eiffel is in many ways Ada's beautiful niece.  But Ada is a  
lot more portable.

- Ed

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

[Ioannis Vranos]

Jim Rogers wrote:

> My reading of the information at that url indicates that GMP allows
> the specification of precision, but not the specification of a limited
> range of valid values.

Since I have had enough with this signed value range of Ada, here is a 
quick implementation of mine and some uses of it.

I am sure one can create a better one or a container directly that 
supports ranges, if he devotes some time, so the question again arises, 
since it is possible and nothing exists, probably it is not considered 
useful to have such a feature in C++:


#include <vector>
#include <algorithm>
#include <cstdlib>

template <class T>
class range
{
     std::vector<T> array;
     T min, max;

     public:
         range(const T &mi, const T &ma):array(ma-mi+1), min(mi), max(ma)
         {
             using namespace std;

             if(max-min<=0)
                ;//throw some exception

             for(typename vector<T>::size_type i=0; i<array.size(); ++i)
                array[i]=min+i;
         }

         const T &operator[](const T &index)
         {
             // Add range checking max>=index>=min if desirable

             return array[index-min+1];
         }

         operator T() { return array.size(); }

};


int main()
{
     using namespace std;

     range<int> r(-100, -20);

     vector<int> vec(r);

     vec[r[-65]]=3;
}




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Ioannis Vranos wrote:
> 
> Jim Rogers wrote:
> 
>> My reading of the information at that url indicates that GMP allows
>> the specification of precision, but not the specification of a limited
>> range of valid values.
> 
> 
> Since I have had enough with this signed value range of Ada, here is a 
> quick implementation of mine and some uses of it.
> 
> I am sure one can create a better one or a container directly that 
> supports ranges, if he devotes some time, so the question again arises, 
> since it is possible and nothing exists, probably it is not considered 
> useful to have such a feature in C++:
> 
> 
> #include <vector>
> #include <algorithm>
> #include <cstdlib>
> 
> template <class T>
> class range
> {
>     std::vector<T> array;
>     T min, max;
> 
>     public:
>         range(const T &mi, const T &ma):array(ma-mi+1), min(mi), max(ma)
>         {
>             using namespace std;
> 
>             if(max-min<=0)
>                ;//throw some exception
> 
>             for(typename vector<T>::size_type i=0; i<array.size(); ++i)
>                array[i]=min+i;
>         }
> 
>         const T &operator[](const T &index)
>         {
>             // Add range checking max>=index>=min if desirable

             fixed: return array[index-min];
>         }
> 
>         operator T() { return array.size(); }
> 
> };
> 
> 
> int main()
> {
>     using namespace std;
> 
>     range<int> r(-100, -20);
> 
>     vector<int> vec(r);
> 
>     vec[r[-65]]=3;
> }


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Ioannis Vranos]

Wes Groleau wrote:

> Class Wagon has method Draw.
> Class Picture has method Draw.
> 
> If you multiply inherit to make
> Class Picture_Of_A_Wagon, what does the method Draw do?


In C++ you will get an error message until you define a newer version of 
Draw for Picture_Of_A_Wagon class.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Jerry Coffin]

Jim Rogers wrote:

[ ... ]

> For instance the following macro can cause some serious problems when
> mis-applied:
>
> #define SWAP(A,B)  ((temp) = (A);(A) = (B); (B) = (temp))
>
> char s1[30];
> int i;
>
> SWAP(S1, i);
>
> In many cases it is safer to define an in-line function than to
> define a macro.

I don't see a particularly serious problem here -- the code simply
won't compile. At the moment you have some syntactical problems and
sloppiness that's overlooked by Ada comilers (because Ada is
case-insensitive).

Even ignoring those, however, it will fail because of a
type-difference. To give a concrete example, after (partially) fixing
your code above, Visual C++ says:

swap.cpp(7) : error C2440: '=' : cannot convert from 'int' to 'char
[30]'
        There are no conversions to array types, although there are
        conversions to references or pointers to arrays

Modulo trivial things like ':=' vs. '=', 'int' vs. 'Integer', etc., I
suspect that's on the same general order as you'd expect to see from an
Ada compiler given code that attempted to assign an Integer to an array
of characters.

I think most C++ programmers, however, would tend to agree that in this
case you'd generally be better off using std::swap.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Georg Bauhaus]

Ioannis Vranos wrote:

 
>             fixed: return array[index-min];

See? This is when proper language support comes in handy.


Georg 

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

[Georg Bauhaus]

Ioannis Vranos wrote:
> Jim Rogers wrote:
> 
>> My reading of the information at that url indicates that GMP allows
>> the specification of precision, but not the specification of a limited
>> range of valid values.

Jim doesn't mention fpt ranges in the context of arrays.
Just a floating point type whose values range between 0.0 and 1.0.
And a description of the use of this type that has a range constraint.
No arrays or signs in sight.


> Since I have had enough with this signed value range of Ada,

Forget about the sign, as you did in your code with min and max.
This is not a sign issue. This isn't limited to array bounds
checking. It has to do with types and with values that match at compile
time.
 For a start, add a template parameter to class range from which
the compiler can infer the min and max values.

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

[Jerry Coffin]

Wes Groleau wrote:

[ ... ]

> Class Wagon has method Draw.
> Class Picture has method Draw.
>
> If you multiply inherit to make
> Class Picture_Of_A_Wagon, what does the method Draw do?

In C++ the result would be simple: attempting to call Draw without
qualification would cause an error due to ambiguity. Note that the mere
existence of the situation doesn't lead to an ambiguity or a compiler
error -- only when/if you attempt to use the name without qualification
does the error arise.

This ambiguity would typically be resolved by qualifying the name (i.e.
explicitly calling Wagon::Draw() or Picture::Draw()). If you think it
makes sense for the derived class to normally call one instead of the
other, a using declaration or a forwarding function can provide that.
For example, if we wanted the derived Draw to resolve to Picture::Draw,
here's how it looks with a using declaration:

#include <iostream>

struct Picture {
    virtual void Draw() {
        std::cout << "Drawing Picture";
    }
};

struct Wagon {
    virtual void Draw() {
        std::cout << "Drawing Wagon";
    }
};

struct Picture_Of_A_Wagon : Wagon, Picture {
    using Picture::Draw;
};

For explicit forwarding you'd do this instead:

struct Picture_Of_A_Wagon : Wagon, Picture {
    void Draw() { Picture::Draw(); }
};

Of course, in well-written code, you just wouldn't do anything like
this at all -- a picture of a wagon is NOT a wagon, and does not
satisfy the Liskov Substitution Principle, so having Picture_Of_A_Wagon
derive (publicly) from Wagon is just plain wrong.

For better or worse, however, compilers (at least for C++) aren't quite
smart enough to recognize such problems yet, so it would be up to a
person to point out that the code above is broken beyond repair.

Multiple inheritance can make sense, but should be restricted to
situations where a derived object really can be substituted for either
(or any) of the base types. Examples would be having an object with a
particular function made from a particular material:

class piece_of_aluminium {
    int alloy;
    std::string heat_treatment;
    std::string hardness;
    int density;
};

class pipe{
    int diameter;
    int wall_thickness;
    int length;
};

class aluminium_pipe : public piece_of_aluminium, public pipe {

};

Now we have a perfectly reasonable situation: an aluminium pipe that
can be treated as either a piece of aluminium or as a pipe.
Unfortunately, right now I can't think of a name that would really make
good sense in both base classes, so we don't have a potential
ambiguity.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Larry Kilgallen]

In article <1111619568.938415.90010@g14g2000cwa.googlegroups.com>, "Jerry Coffin" <jcoffin@taeus.com> writes:
> Larry Kilgallen wrote:

>> But what programming step (as distinguished from construction trick)
>> can only be performed from a preprocessor ?
> 
> Attempting to separate programming from constructing (a program) seems
> to me a strong indication that you don't really know much of what
> you're talking about.

Your reliance on ad-hominem attacks makes me believe the rest of
what you say will not be worthwhile either.

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

[Jerry Coffin]

Ioannis Vranos wrote:
> Wes Groleau wrote:
>
> > Class Wagon has method Draw.
> > Class Picture has method Draw.
> >
> > If you multiply inherit to make
> > Class Picture_Of_A_Wagon, what does the method Draw do?
>
> In C++ you will get an error message until you define a newer version
> of Draw for Picture_Of_A_Wagon class.

Not so -- until or unless you _call_ the function (without qualifying
its name) there's no ambiguity. When/if ambiguity does arise, you can
resolve it without adding a function to the derived class.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

[Martin Krischik]

adaworks@sbcglobal.net wrote:

> C++ continues to evolve, but much of that evolution seems to follow a
> course of shoring up things already in the language that don't quite work
> as one might prefer, or adding a truss here and a buttress there to
> prevent or enable deficiencies in the language; e.g., cast-away const,
> a truly silly addition to the language.

Needed for calling broken functions in 3td party libraries. There are still
libraries around which won't mark unmodified parameters with "const" to be
compatible with older compilers. 

I am not saying it's good. And of course the library vendors are just hiding
there laziness behing a "compatiblity" argument:

#if COMPILER_X_VERSION < 2.0
#define const
#endif

Martin

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

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

[Dmitry A. Kazakov]

On Wed, 23 Mar 2005 21:42:58 -0500, Wes Groleau wrote:

> adaworks@sbcglobal.net wrote:
>> There are lots of good uses for multiple inheritance.  However,
>> there are also lots of dangers in it.  Ada correctly comes down
>> on the side of safety, but I do sometimes wish it were available.
> 
> One thing I've never quite understood is the argument of ambiguity.
> Ada allows other things that have a potential of ambiguity.  The
> solution there is that when something _actually_ has two meanings
> (as opposed to _potentially_) then you get neither.

Of course it not an argument. A real argument I think is view conversions,
they would be impossible to do without a distributed overhead (as it takes
place in C++.) I think that MI from concrete types should be allowed, later
when Ada will have "tagged" by-value types without tags carved on the
object. For those one could allow full MI, for others only multiple
interfaces but single implementation inheritance (as in Ada 2005.)

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

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

[Dmitry A. Kazakov]

On 23 Mar 2005 17:01:56 -0500, Robert A Duff wrote:

> Martin Dowie <martin.dowie@btopenworld.com> writes:
> 
>> Jerry Coffin wrote:
>>>  And, once
>>> again, the addition of tagged records to Ada 95 testifies to the fact
>>> that even its own designers recognized the improvement this adds in
>>> general, but (whether due to shortsightedness, concerns for backward
>>> compatibility or whatever) didn't allow this improvement to be applied
>>> in this situation.
>> 
>> Almost certainly backwards compatibility - but I'm sure Bob and/or Randy
>> could shed more light on that...
> 
> Well, actually, during the Ada 9X design I tried to push for a
> class-hierarchy of exceptions.  I don't like every detail of the way C++
> does it, but at least in *this* regard, it's better than Ada.

I think it is a question whether exception hierarchy has to be mapped on
(1) types, (2) subtypes or (3) value ranges. C++ sticks to (1) which is
problematic without ad-hoc supertypes. Presently it ends up with a mess in
the list of catch'es. I think that (3) may have a chance.

> Jerry Coffin is wrong that Ada does not allow attaching information to
> exception, by the way.  Ada allows attaching Strings, which is
> admittedly a kludge.  Using the class-hierarchy, as Jerry advocates,
> would be cleaner, and type safe.

The problems with that:

1. An exception object referring to a scope that does not exist (mounting
accessibility rules?)

2. The target of an dispatching method is out of scope.

3. The whole scope of the exception type is finalized before "catch".

4. How to check that choices don't intersect? (C++ dependency of the order
of catch is error-prone.)

5. The hierarchy of types may not reflect the hierarchy needed by an
exception handler. How to do enumeration and ranges of exception objects
having different types?

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

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

[Martin Krischik]

Hyman Rosen wrote:

> adaworks@sbcglobal.net wrote:
>> I wish Ada had a good model of multiple inheritance.
>  > I don't mean the somewhat haphazard model of C++
> 
> What's wrong with C++'s model?

As allways: the default behaviour. Default is static inheritance.

Take the following example:

class X : public A, public B { };

This causes a problem when you have 

class A: public C {};

class B public C {};

Of couse C++ has a perfectly good solution:

class A: virtual public C {};

class B virtual public C {};

All very well, only I know C++ programmers which had 2 to 7+ years
experience in C++ and did not know about it until I told them. And not just
one programmer: the whole team of about 20!

Side note: This puts all the "good programmers do than/don't do that"
arguments into an instersting new light: In this case only 1 in 20 of the
C++ programmers realy knew his trade and that one is now an Ada
advocate ;-) .

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

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

[Peter Amey]

Ioannis Vranos wrote:
[snip]
> 
> At first, it is easy to write a container in C++ that accepts a 
> specified range for indexes. The only reason that there is not one, is 
> because it does not make sense in C++ (when I learned some Pascal in the 
> past, I could not understand what was the use of the ability to use 
> negative indexes in arrays. The [0, +] style maps closely what is 
> happening in the machine.

Of all the comments in this rambling (but remarkably bloodless) thread, 
this is the one that, for me, gets closest to the fundamental 
philosophical difference between the C language family and Ada.

The [0, +] styles does indeed map closely to what is happening in the 
machine; however, for me, what is happening in the machine is generally 
much less interesting than what is being represented in my problem 
domain.  I am always struck by the way a C user's first thought always 
seems to be about how many bits he needs to represent something where an 
Ada user is concerned with real-world values and leaves the bit size to 
be chosen by the compiler.  Of course, when writing an interface to a 
hardware device, we have to worry about bit patterns but I certainly 
want to stop doing that as soon as possible and worry about the problem 
domain instead.

So, for an array, I want to index it with a problem domain entity and 
let the compiler turn that into a wholy uninteresting set of address 
offsets.

Ionnis wanted an example of negative indexes.  How about:

type X_Values is range -5 .. 5;
type Y_Values is range  0 .. 25;
type Graph is array (X_Values) of Y_Values;
Squares : constant Graph := (25, 16, 9, 4, 1, 0, 1, 4, 9, 16, 25);

> 
> [snip]

Peter

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

[Martin Krischik]

Ioannis Vranos wrote:

> Jim Rogers wrote:
> 
>> My reading of the information at that url indicates that GMP allows
>> the specification of precision, but not the specification of a limited
>> range of valid values.
> 
> Since I have had enough with this signed value range of Ada, here is a
> quick implementation of mine and some uses of it.
> 
> I am sure one can create a better one or a container directly that
> supports ranges, if he devotes some time, so the question again arises,
> since it is possible and nothing exists, probably it is not considered
> useful to have such a feature in C++:

Shure it is usefull, very usefull indeed. Only you started off wrong:

namespace Ada
    {
    template <
        class Base_Type,
        Base_Type The_First,
        Base_Type The_Last>
    class Range
        {
        .....
        }

    template <
        class Element_Type,
        class Index_Type>  // derived from Range.
    class Array
        {
        .....
        }
    }

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

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

[Martin Dowie]

Hyman Rosen wrote:
> Martin Dowie wrote:
>> GNAT comes with an Ada-centric preprocessor but
>> there is nothing to stop you using the 'C' one.
>
> Yes there is. The C preprocessor works with C tokens, and Ada's
> use of the single quote character for attributes will utterly
> confuse it.

Ok - but the only part of the C preprocessor that I've ever even
seen used embedded in Ada code was some "#ifdef" to allow
types to have different ranges on different platforms.

Personally, I'd rather use a separate package and a rename and
let the build process take care of everything - but that's how this
one company had decided to do it.

Cheers

-- Martin

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

[Ioannis Vranos]

Peter Amey wrote:

> Of all the comments in this rambling (but remarkably bloodless) thread, 
> this is the one that, for me, gets closest to the fundamental 
> philosophical difference between the C language family and Ada.
> 
> The [0, +] styles does indeed map closely to what is happening in the 
> machine; however, for me, what is happening in the machine is generally 
> much less interesting than what is being represented in my problem 
> domain.  I am always struck by the way a C user's first thought always 
> seems to be about how many bits he needs to represent something where an 
> Ada user is concerned with real-world values and leaves the bit size to 
> be chosen by the compiler.  Of course, when writing an interface to a 
> hardware device, we have to worry about bit patterns but I certainly 
> want to stop doing that as soon as possible and worry about the problem 
> domain instead.
> 
> So, for an array, I want to index it with a problem domain entity and 
> let the compiler turn that into a wholy uninteresting set of address 
> offsets.
> 
> Ionnis wanted an example of negative indexes.  How about:
> 
> type X_Values is range -5 .. 5;
> type Y_Values is range  0 .. 25;
> type Graph is array (X_Values) of Y_Values;
> Squares : constant Graph := (25, 16, 9, 4, 1, 0, 1, 4, 9, 16, 25);


I have to say that for simple cases of things like that - in case we 
want to associate the x ranges with the y values - in C++ we "keep in 
mind" that [0] is for -5, etc, in the style:


unsigned is used for Y_Values.


// Indices stand for [-5, 5] X values
vector<unsigned> Graph(11);

Graph[0]= 25;


For much more ranges one can use a map. If a map is considered 
expensive, a way I can think is using a vector of pairs:

// first for X_Values, second for Y_Values
vector<pair<int, unsigned> > Graph(11);


Graph[[0].first= -5;
Graph[0].second= 25;


// Range checked
Graph.at(1).first= -4;
Graph.at(1).second= 16;


It isn't that incomprehensible if you are used to programming in C++.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Dmitry A. Kazakov]

On Thu, 24 Mar 2005 11:47:10 +0100, Martin Krischik wrote:

> Hyman Rosen wrote:
> 
>> adaworks@sbcglobal.net wrote:
>>> I wish Ada had a good model of multiple inheritance.
>>  > I don't mean the somewhat haphazard model of C++
>> 
>> What's wrong with C++'s model?
> 
> As allways: the default behaviour. Default is static inheritance.

As it will be with interfaces in Ada 2005, I suppose...

> Take the following example:
> 
> class X : public A, public B { };
> 
> This causes a problem when you have 
> 
> class A: public C {};
> 
> class B public C {};
> 
> Of couse C++ has a perfectly good solution:
> 
> class A: virtual public C {};
> 
> class B virtual public C {};

Actually neither solution is automatically good. Consider:

class A : public AbstractList {};
class B : public AbstractList {};
class X : public A, public B {}; -- Participates in both lists

The problems of C++ model lie elsewhere:

1. It is difficult if possible to express more complex groupings when the
same base is sometimes shared and sometimes not, all in the same type
hierarchy.

2. Decision about "virtuality" has to be made too early in wrong place. In
the example above, it is X, which should decide.

3. C++ model has distributed space overhead.

Perhaps, the bases should be subject of overriding in the same way one
overrides methods to achieve desired flexibility. So conflicts could be
resolved by either renaming=overloading (~non-virtual) or overriding
(~virtual).

IMO, it was wise not to rush for MI during Ada 95 design... Though MI
should be, that's no question.

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

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

[Ioannis Vranos]

Martin Krischik wrote:

> As allways: the default behaviour. Default is static inheritance.
> 
> Take the following example:
> 
> class X : public A, public B { };
> 
> This causes a problem when you have 
> 
> class A: public C {};
> 
> class B public C {};
> 
> Of couse C++ has a perfectly good solution:
> 
> class A: virtual public C {};
> 
> class B virtual public C {};
> 
> All very well, only I know C++ programmers which had 2 to 7+ years
> experience in C++ and did not know about it until I told them. And not just
> one programmer: the whole team of about 20!


Perhaps it was in the pre-standard era? :-)) I do not think there is any 
intermediate level C++ programmer that does not know virtual bases.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

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

[Vinzent 'Gadget' Hoefler]

Ioannis Vranos wrote:

> I have to say that for simple cases of things like that - in case we
> want to associate the x ranges with the y values - in C++ we "keep in
> mind" that [0] is for -5, etc, in the style:
[...]
> It isn't that incomprehensible if you are used to programming in C++.

Of course it's not "incomprehensible", for me it's inconvinient.

Once I actually got used to range types (these days I use them heavily,
although not so often with negative indices) it appears to me that I
sometimes just get confused when everything starts at zero, because
then I always have to keep in mind where and how a real world range is
biased.

This distracts me from the original problem I am trying to solve.


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

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

[Vinzent 'Gadget' Hoefler]

Ioannis Vranos wrote:

>  I do not think there is any
> intermediate level C++ programmer that does not know virtual bases.

That would simply depend on your definition of "intermediate". :)

Little story: Yesterday, a colleague of mine didn't believe me that
realloc() would copy the memory contents if necessary until I showed
him the reference. And he is doing C for more than ten years now.


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

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

[Martin Krischik]

Jerry Coffin wrote:

> Speaking of strings, I'll digress for a moment: personally, I find it a
> bit humorous when Ada advocates talk about things like having five
> string types as an advantage. IMO, the need, or even belief, that five
> string types are necessary or even useful is a _strong_ indication that
> all five are wrong.

Actualy there are only 3 of them. And they are usefull - two examples:

I have worked a lot with SQL and I allways wound it cumbersome to map the
SQL string type to C++. Most SQL string types are bounded - they have a
maximum size. std::string (and IBM's IString) is unbounded - so before you
can store your string inside the database you have to make a sanity check.
In Ada I could use Ada.Strings.Bounded_Strings instead.

The other example is CORBA. CORBA has two string types: string and
sting<size>. In C++ both a mapped to std::string - and the CORBA/C++
mapping must check the size of the sting. In Ada they are mapped to
Ada.Strings.Unbounded_Strings and Ada.Strings.Bounded_Strings.
 
> Ada's exception handling is also primitive at best (exceptionally so,
> if you'll pardon a pun). In particular, in Ada what you throw is
> essentially an enumaration -- a name that the compiler can match up
> with the same name in a handler, but nothing more. Only exact matches
> are supported and no information is included beyond the identity of the
> exception.

Well, Ada 95 added a 200 character informations string.

> In C++ you can throw an arbitrary type of object with an arbitrary
> value. All the information relevant to the situation at hand can be
> expressed cleanly and directly. The usual inheritance rules apply, so
> an exception handler can handle not only one specific exception, but an
> entire class of exceptions. Again, this idea can be expressed directly
> rather than as the logical OR of the individual values. And, once
> again, the addition of tagged records to Ada 95 testifies to the fact
> that even its own designers recognized the improvement this adds in
> general, but (whether due to shortsightedness, concerns for backward
> compatibility or whatever) didn't allow this improvement to be applied
> in this situation.

All true. But does that powerfull contruct works inside a multi tasking
environment. It is indeed true that Ada exeptions are restricted - but they
are thread save. And thead save means that an exception may be raised in
one thead and caugth in another. Exceptions raised inside an rendevous may
even be caught in both threads participating in the rendevous.

And tread save is not all. An Ada system implementing the (optional) Annex E
needs exeptions which can be passed from one process to another. Both
processed runing on different computers. Just like CORBA exceptions.

With Regards

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

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

[Martin Krischik]

Jerry Coffin wrote:

> OTOH, doing a bit more looking, if I've misunderstood the situation, at
> least I have some company.  For example:
> 
> http://en.wikibooks.org/wiki/Programming:Ada:Types:record
> 
> claims that "The tagged record is what in other languages is called a
> class."

Well, I wrote that and I going to redo the text and incorporate a bit more
from http://en.wikibooks.org/wiki/Programming:Ada:OO to clarify the meaning
of the tagged type. 

Martin

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

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

[Martin Krischik]

Ioannis Vranos wrote:

> Georg Bauhaus wrote:
> 
>>> In C++ you can throw an arbitrary type of object with an arbitrary
>>> value.
>> 
>> 
>> How well does this style of passing information work across thread
>> boundaries?
> 
> 
> Do you mean throwing an exception in one thread and catch it in another?

Yes, and process/system boundaries when Annex E is implemented.

Martin

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

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

[Martin Krischik]

Ioannis Vranos wrote:

> Martin Krischik wrote:
> 
>> As allways: the default behaviour. Default is static inheritance.
>> 
>> Take the following example:
>> 
>> class X : public A, public B { };
>> 
>> This causes a problem when you have
>> 
>> class A: public C {};
>> 
>> class B public C {};
>> 
>> Of couse C++ has a perfectly good solution:
>> 
>> class A: virtual public C {};
>> 
>> class B virtual public C {};
>> 
>> All very well, only I know C++ programmers which had 2 to 7+ years
>> experience in C++ and did not know about it until I told them. And not
>> just one programmer: the whole team of about 20!
> 
> 
> Perhaps it was in the pre-standard era? :-)) I do not think there is any
> intermediate level C++ programmer that does not know virtual bases.

They started off in the pre-standard area an never learned any new
tricks ;-) . However the pre-standard  IBM compiler they used was advanced
enough to have virtual base classes and I used them alot.

Martin

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

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

[Martin Krischik]

Dmitry A. Kazakov wrote:

> On Thu, 24 Mar 2005 11:47:10 +0100, Martin Krischik wrote:
> 
>> Hyman Rosen wrote:
>> 
>>> adaworks@sbcglobal.net wrote:
>>>> I wish Ada had a good model of multiple inheritance.
>>>  > I don't mean the somewhat haphazard model of C++
>>> 
>>> What's wrong with C++'s model?
>> 
>> As allways: the default behaviour. Default is static inheritance.
> 
> As it will be with interfaces in Ada 2005, I suppose...

It make no difference with interfaces as interfaces hold no data. Tha's the
Java trick.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[fabio de francesco]

Ioannis Vranos wrote:
> fabio de francesco wrote:

[skip some lines]

> > What's more in Ada is that you can, in a standardised way, directly
> > create low-level representation of user defined types with a lot of
> > attributes that C++ doesn't provide. Ada programmers prefer to
build
> > their own types rather than using built-in Integer, Float,
Long_Float
> > (int, float, double) and so on in order to gain a much finer
control.
> >
> > In Ada you can decide representation attributes like range, digit,
> > delta, mod, address, alignment, size, byte-order (little or big
endian)
> > in record component, and many other things like these. As an
example
> > you can write:
> >
> > type Counter is new Integer;
> > for Counter'Size use 48;
> > for Counter'Alignment use 16;
> >
> > What's more, you get a compiler error if your machine can't use
some
> > sort of representation you need in order to free you from knowing
how
> > much space a type can provide.
> >
> > You said that real C++ code hardly need to specify ranges, because
you
> > should be careful not to assign a value that can't be held by a
> > variable of some specific type. Imagine you have know a variable is
to
> > hold numbers not larger than 99_999 and you choose to store them in
an
> > "int" knowing that you have enough space. When later you port your
> > program to a machine where "int" is 16 bits you don't have any
warning
> > from a C++ compiler and program run for years until for some reason
> > that variable is assigned with say 86_000. I think you know what
> > happens..
>
>
> The standard guarantees the minimum ranges, for int can hold at least

> 16-bit values and long at least 32-bit values.

Sorry, maybe I was unable to explain the concept because of my poor
English. Try please to re-read the latest paragraph, because you're
missing the point. I know that standard guarantees minimum number of
bits per types.

I was reasoning upon porting a C++ code from a machine providing C++
"int"(s) with 32 bits capacity to another machine where "int"(s) are
only 16 bits. In that situation if you forget to substitute every "int"
with "long" you don't get any error from the compiler. That ported
program can execute for years without any problem. When that variable
is assigned a value like 32768 you get -32768 and then negative numbers
increasing towards zero for each "++var;". Remember that this
assignment was considered allowable, since the programmer chose an
"int" type for that variable knowing that it is stored in 32 bits in
his development machine.

Maybe that won't crash your program yet it is worse, because a bug has
been inserted and it may pass unnoticed for years.

What I want to say is that in C++ (1) you must know how many bits are
reserved for every type you use and (2) you must carefully change types
when compiling to different targets.

Instead in Ada a programmer can just write code that is portable across
different platforms without worrying of bits of storage for types. Just
ask the compiler "I need to store values between -80_000 and 80_000, so
please choose yourself how many bits I need", and you can be sure that
it won't raise any bug porting code from a machine with 32 bits "int"
to a 16 bits "int".

The interesting thing in Ada is that either you can let your compiler
to choose how to internally reserve storage, or you can force a lot of
attributes for representation like the example that I provided:

type Counter is new Integer;
for Counter'Size use 48;
for Counter'Alignment use 16;

The above mentioned type declaration is something can't be done with
C++, as far as I know. In order to do same kind of things you must use
some no-standard compiler extension. Ada is simultaneously lower-level
and higher-level than C++.

Ciao,

fabio de francesco


> > If you had that type declared as "type Var_T is range 0 ..
99_999;", at
> > the very moment you port your program to this new machine the
compiler
> > would choose the correct size to hold values of that type so
program is
> > no more restricted to this 16 bits C++ "int" and consequently won't
> > raise this bug.
> >
> > Do you still think you don't need ranges?
>
>
> Ranges are a nice thing to have, however if you are provided with
> minimum range guarantees, this also does the job.
>
>
> I would prefer compiler error messages for out of range assignments
> though. And I wonder what backwards compatibility (apart from -1
> assignment to unsigned integral types) this would break.
> 
> 
> 
> -- 
> Ioannis Vranos
> 
> http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Thu, 24 Mar 2005 14:38:39 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Thu, 24 Mar 2005 11:47:10 +0100, Martin Krischik wrote:
>> 
>>> Hyman Rosen wrote:
>>> 
>>>> adaworks@sbcglobal.net wrote:
>>>>> I wish Ada had a good model of multiple inheritance.
>>>>  > I don't mean the somewhat haphazard model of C++
>>>> 
>>>> What's wrong with C++'s model?
>>> 
>>> As allways: the default behaviour. Default is static inheritance.
>> 
>> As it will be with interfaces in Ada 2005, I suppose...
> 
> It make no difference with interfaces as interfaces hold no data.

Of course it does. Diamond diagram is as valid for interfaces as for
implementations (data). If you allow interfaces to be derived from other
interfaces (I don't know if Ada 2005 will), then:

C -> A (both are interfaces)
C -> B (both are interfaces)

Let X implements both A and B. Now: A's C of X = B's C of X?

Example:

C = Generic device driver interface
A = Generic block device driver interface
B = Generic socket interface
X = File-to-socket router. Here A.C /= B.C

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Thu, 24 Mar 2005 14:16:49 +0100, Martin Krischik wrote:

> Jerry Coffin wrote:
> 
>> Speaking of strings, I'll digress for a moment: personally, I find it a
>> bit humorous when Ada advocates talk about things like having five
>> string types as an advantage. IMO, the need, or even belief, that five
>> string types are necessary or even useful is a _strong_ indication that
>> all five are wrong.
> 
> Actualy there are only 3 of them. And they are usefull - two examples:

How so?

1. String
2. Wide_String
3. Unbounded_String
4. Wide_Unbounded_String
5. xN bounded character string, each instantiation separate
6. xM bounded wide character string, each instantiation separate

In fact, it is far more than 5, it is close to infinite number of them. OK
taking a 64-bit machine N is about 2**64! (:-))

> I have worked a lot with SQL and I allways wound it cumbersome to map the
> SQL string type to C++. Most SQL string types are bounded - they have a
> maximum size. std::string (and IBM's IString) is unbounded - so before you
> can store your string inside the database you have to make a sanity check.
> In Ada I could use Ada.Strings.Bounded_Strings instead.
> 
> The other example is CORBA. CORBA has two string types: string and
> sting<size>. In C++ both a mapped to std::string - and the CORBA/C++
> mapping must check the size of the sting. In Ada they are mapped to
> Ada.Strings.Unbounded_Strings and Ada.Strings.Bounded_Strings.

Clearly, in Ada spirit should rather be constraining and cloning an
existing type:

type My_Interface_String is new Other_String (<appropriate constraint>);

To be honest, there is no any advantage in having n-independent string
types, especially when some of them are arrays and some are not. All string
types should to be related and that includes not only the allocation
strategy dimension: fixed - bounded - variable (+ user-pool allocated +
task-safe + etc), but also the encoding one: Latin-1 - UCS-2 (+ EBCDIC +
UTF-8 + UTF-n + whatsoever would come at us.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Julián Albo]

Martin Krischik wrote:

>>> All very well, only I know C++ programmers which had 2 to 7+ years
>>> experience in C++ and did not know about it until I told them. And not
>>> just one programmer: the whole team of about 20!
>> 
>> Perhaps it was in the pre-standard era? :-)) I do not think there is any
>> intermediate level C++ programmer that does not know virtual bases.
> 
> They started off in the pre-standard area an never learned any new
> tricks ;-) . However the pre-standard  IBM compiler they used was advanced
> enough to have virtual base classes and I used them alot.

In this type of discussions people always does the same: in the langauage
they like they talk about all features they know and the most recent
version of the language is considered, in the language they dislike, only
the most commonly used features are taken into account, and 'but many
people still use old versions' is mentioned. In a language the best
paractices are suppossed to be used for anything in the world, in the other
one talk about the worse programmers and programs they have seen.

-- 
Salu2

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Martin Krischik wrote:

[ ... ]

> I have worked a lot with SQL and I allways wound it cumbersome to map
> the SQL string type to C++. Most SQL string types are bounded - they
> have a maximum size. std::string (and IBM's IString) is unbounded -
> so before you can store your string inside the database you have to
> make a sanity check. In Ada I could use Ada.Strings.Bounded_Strings
> instead.

While bounded vs. unbounded strikes me as a reasonable distinction, I'm
not at all convinced that two separate string classes are necessary to
accomplish it. I see nothing here that can't be accomplished by single
class with a parameter specifying its bound (or lack thereof). In fact,
std::basic_string in the C++ library indirectly supports that right
now: what we're reallly talking about is the memory allocation for the
string, and std::basic_string takes a parameter to specify the
allocator to use. All that's needed for a bounded_string is an
allocator that only ever allocates a block of the initially-specified
size.

That does leave a minor bit of room for discussion over terminology --
basic_string is a template, so instantiating it over a different
allocator does technically produce a separate class. Since it's one
piece of code, I generally think/speak of it as a single class except
in those situations where it really matters that two separate
instantiations aren't really the same class.

>From that viewpoint, C++ doesn't have just one or two string classes --
rather, it has a potentially unbounded set of string classes. OTOH,
from a viewpoint of coding, all the string-specific behavior for all
those classes is defined in one place.

In the end, you can call that what you will, and depending on how you
call it, my original statement about the multiplicity of classes
indicating a problem might need to be re-phrased.

> > Ada's exception handling is also primitive at best (exceptionally
> > so, if you'll pardon a pun). In particular, in Ada what you throw
> > is essentially an enumaration -- a name that the compiler can
> > match up with the same name in a handler, but nothing more. Only
> > exact matches are supported and no information is included beyond
> > the identity of the exception.
>
> Well, Ada 95 added a 200 character informations string.

Actually, looking through the specification, it has technically added
two strings (name and information) so what I said was clearly wrong in
Ada as currently defined, and I apologize for that.

OTOH, this doesn't really seem to change the point much -- I've yet to
see anybody claim that the current situation in Ada in anywhere close
to optimal.

[ ... ]

> All true. But does that powerfull contruct works inside a multi
> tasking environment.

No multitasking is included in the C++ specification, so it's
impossible to answer that about C++ in general.

> It is indeed true that Ada exeptions are restricted - but they
> are thread save. And thead save means that an exception may be
> raised in one thead and caugth in another. Exceptions raised
> inside an rendevous may even be caught in both threads
> participating in the rendevous.

With the proviso above, yes -- at least in the implmentations I've used
in environments that supported multi-threading, C++ exception handling
was thread-safe.

I feel obliged to add that exception handling is an unusually simple
case to make thread safe. First we care little about speed. Second,
throwing the exception halts the throwing thread, so there's really
only one thread active at a time, and the switch from one thread to
another is easily predictable.

> And tread save is not all. An Ada system implementing the (optional)
> Annex E needs exeptions which can be passed from one process to
> another. Both processed runing on different computers. Just like
> CORBA exceptions.

Again, the C++ standard simply doesn't include an analog, but as you've
pointed out, CORBA supports them. The middleware market is sufficiently
competitive that almost any major feature in one will be present in the
others as well...

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[adaworks]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1111634628.927041@athnrd02...
>
> Since I have had enough with this signed value range of Ada, here is a
> quick implementation of mine and some uses of it.
>
Are you under the illusion that the code [your code included below] is
actually expressive?

About forty years ago, when I was working in a Fortran shop, we were awarded
a contract for an inventory management system.  At that time, we were mostly
focused on missile defense software, but our DoD customer was persuaded by
our marketing people that we could do the job.

An argument ensued in our programming group about what language to use.  I
was trying to convince my colleagues that we should use COBOL since, at that
time, it was the dominant language for business applications.  In my view, COBOL
best expressed the kind of solutions we needed for the problem at hand.

Many of my colleagues were adamant about Fortran.  Each example I gave of how
something would be done in COBOL, they countered with an example of how it
"could" be done in Fortran.   As this debate continued, some of the Fortran
solutions
began to look more and more bizzare.   Our manager finally concluded, correctly,
that the problem could best be solved in COBOL.

From this experience, I concluded that there were two important considerations
in
language selection:   1)  how well does this language express the kind of
solutions
required for the problem to be solved, and 2) is it possible to solve the
problem
using a given language, even it the solution is a little ugly?

The first I called expressiveness.   The second I called expressibility.   In
the years
since then, others have come to similar views and that is why new languages are
designed from time to time.

A solution to almost any programming problem can be expressed in almost any
language.  This is expressibility.    When a language allows one to express that
solution with concisely and with ease, that is expressiveness.   Expressible?
Expressive?  Which is more appropriate for solving problems?

While you solution demonstrates expressibility, it fails to meet the test of
expressiveness.

I admit that one must be a little careful when using the expressiveness test in
evaluating a language design.   Some expressive syntax might be expressive,
but fail other tests.  For example, the popular,

                      +=
                      *=
                      and other operator=

constructs of the C family of language are wonderfully expressive of a simple
idea, but their use fails the test of compile-time confirmability.  That is,
they
are highly expressive but some of them are also error-prone.   The example
from Ada,

          type Index is range -42 .. 453;

is confirmable every place it is used.  It is expressive of a simple idea.  It
does
not involve any unusual behavior at any point in the program where it is used.
It can be checked by the compiler for validity.  It can raise run-time errors
without the programmer inserting specialized code.   It is expressive of the
idea of a static range of values for a named type.

No doubt that, when you evaluate your solution in the context of expressiveness
versus expressibility, you will see the difference.

------------------------------------------------------------------------------

> I am sure one can create a better one or a container directly that
> supports ranges, if he devotes some time, so the question again arises,
> since it is possible and nothing exists, probably it is not considered
> useful to have such a feature in C++:
>
>
> #include <vector>
> #include <algorithm>
> #include <cstdlib>
>
> template <class T>
> class range
> {
>      std::vector<T> array;
>      T min, max;
>
>      public:
>          range(const T &mi, const T &ma):array(ma-mi+1), min(mi), max(ma)
>          {
>              using namespace std;
>
>              if(max-min<=0)
>                 ;//throw some exception
>
>              for(typename vector<T>::size_type i=0; i<array.size(); ++i)
>                 array[i]=min+i;
>          }
>
>          const T &operator[](const T &index)
>          {
>              // Add range checking max>=index>=min if desirable
>
>              return array[index-min+1];
>          }
>
>          operator T() { return array.size(); }
>
> };
>
>
> int main()
> {
>      using namespace std;
>
>      range<int> r(-100, -20);
>
>      vector<int> vec(r);
>
>      vec[r[-65]]=3;
> }
>
>
>
>
> -- 
> Ioannis Vranos
>
> http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[adaworks]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:1111628011.160315.134740@o13g2000cwo.googlegroups.com...
> Martin Dowie wrote:
> > Jerry Coffin wrote:

> A preprocessor  ... almost entirely missing from Ada.
>
When programming in C++, almost every use of the preprocessor
is to make up for a shortcoming of the language.  For example,

         #IFDEF
         #IFINDEF

Other uses include some that are deprecated.  For example,

         #DEFINE

Since Ada does not have these shortcomings,  preprocessors are not
as necessary.   That being said, I do know of Ada shops that have
written their own preprocessors for such things as being able to
ignore certain blocks of code prior to compilation, code instrumentation,
and similar things.   This turns out to be quite simple to do.   I'm
not sure why it is even being discussed as an issue since the C family
of preprocessor statements are something of a kludge.

Richard Riehle

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pascal Obry]

"Jerry Coffin" <jcoffin@taeus.com> writes:

> While bounded vs. unbounded strikes me as a reasonable distinction, I'm
> not at all convinced that two separate string classes are necessary to
> accomplish it. I see nothing here that can't be accomplished by single
> class with a parameter specifying its bound (or lack thereof). 

What would be the gain for the end user ?

Of course in an implementation point of view both can certainly share lot of
code (this is the case for GNAT).

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

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Pascal Obry]

Jim Rogers <jimmaureenrogers@att.net> writes:

> One Ada feature that cannot be implemented through any container library
> is the ability to define a range-restricted floating point type. You can
> do this in C++, but not through the use of a template. Templates cannot 
> take floating point values as parameters.

Is that still true ? I have never understood why there was such
restriction...

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

Re: Teaching new tricks to an old dog (C++ -->Ada)

[adaworks]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:1111682141.541662.113720@o13g2000cwo.googlegroups.com...
>
> While bounded vs. unbounded strikes me as a reasonable distinction, I'm
> not at all convinced that two separate string classes are necessary to
> accomplish it.
>
I love my Swiss Army pocket knife.   I have one of the little ones
for daily use.  It includes a scissors, a flatblade screwdriver, a
small knife, a toothpick, a tweezers, and a little ball-point pen.
For emergencies, it is really useful.

For serious work, I tend to dislike all-in-one tools.   If I have the
choice between a socket wrench of exactly the right size, I will
select that instead of one of the many adjustable wrenches in
my toolbox.

The long-cherished notions of cohesion and coupling come into
play when building software.  I like components that do one thing
well, and do not need all kinds of adjustment to make them reliable.

The bounded strings package has very unique properties that are
not required for unbounded strings.  Unbounded strings, especially
their implementation, are quite different from bounded strings.  I
actually prefer being able to pick the right tool for the job at hand.

As for the Swiss Army Knife analogy, I also like special-purpose
languages for some applications.  It always comes down, in the
final analysis, to picking the right tool for the right job.

Richard Riehle

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

adaworks@sbcglobal.net wrote:

[ ...]

> C++ continues to evolve, but much of that evolution seems to follow a
> course of shoring up things already in the language that don't quite
> work as one might prefer, or adding a truss here and a buttress there
> to prevent or enable deficiencies in the language; e.g., cast-away
> const, a truly silly addition to the language.

IMO, this is _quite_ an inaccurate characterization.

C++ has changed exactly once since it was originally standardized. I do
not believe that _any_ of what was changed was to change behavior at
all -- rather, it was almost entirely changes in the standard to make
the wording more accurately reflect what was desired all along.

The most visible change was in the requirements for std::vector. The
original C++ standard never _quite_ requires that std::vector use
contiguous storage. That has now been changed so its storage must be
contiguous.

TTBOMK, nobody has ever implemented (or even designed) a version of
std::vector that didn't use contiguous storage. I'm not sure anybody
has really even proven that a version using non-contiguous storage
could even meet the standard's requirements for std::vector. It's
pretty clear from reading books written by committee members that most
(if not all) thought from the beginning of std::vector as using
contiguous storage.

IMO, your characterization bears no more than an extremely distant
relationship with reality.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[kevin cline]

adaworks@sbcglobal.net wrote:
> "kevin cline" <kevin.cline@gmail.com> wrote in message
> news:1110830710.027630.241160@g14g2000cwa.googlegroups.com...

> Ada is every bit as expressive as C++.  There is not likely to be
> any improvement in the number of KSLOC using C++.  Oh, yes,
> if we choose to use a cryptic form of C++, with all the little
> shortcuts that make the code less readable, we might achieve
> some reduction in the KSLOC, but at what cost in understandability?
>
> Richard Riehle

C++ is more expressive because of implicit generic/template function
instantiation.  The limitations of Ada's explicit instantiation have
been shown to be a major impediment to creating advanced type systems,
e.g. modeling physical units.

Christopher Grein writes at
http://www.adapower.com/index.php?Command=Class&ClassID=Advanced&CID=215:

[Attempting to model physical units in Ada]
"Our attempt leads us to a plethora of overloaded functions. The number
of function definitions afforded runs into the hundreds...

...One could object that this definition has to be made only once and
for all in a reusable package, and later-on the package can simply be
withed and used without any need for the user to care about the
package's complexity, but unfortunately the argument is not fully
correct. Apart from the most probable compile time explosion, it takes
into account only simple multiplication and division. Operations like
exponentiation an and root extraction root (n, a) are not representable
at all.

So we have to confess that our attempt to let the compiler check
equations at compile time has miserably failed. The only proper way to
deal with dimensions in full generality is either to handle them as
attributes of the numeric values that are calculated and checked at
run-time or to use preprocessors. Also for these methods, there are
many examples to be found in literature."

Grein again, at
http://home.t-online.de/home/Christ-Usch.Grein/Ada/Dimension.html:

"A C++ solution, which is very similar to the Ada one presented here -
it does however not include fractional powers - can be found at
http://www.fnal.gov/docs/working-groups/fpcltf/html/SIunits-summary.html.
The big difference is that C++ templates allow type checking during
compile-time, so that no overhead neither in memory space nor in
runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
than Ada generics."   [Emphasis mine]

In my experience, C++ templates have allowed me to write fully
type-safe programs at a very high level, an ability which Ada generics
simply can not match.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jimmaureenrogers]

Pascal Obry wrote:
> Jim Rogers <jimmaureenrogers@att.net> writes:
>
> > One Ada feature that cannot be implemented through any container
library
> > is the ability to define a range-restricted floating point type.
You can
> > do this in C++, but not through the use of a template. Templates
cannot
> > take floating point values as parameters.
>
> Is that still true ? I have never understood why there was such
> restriction...

I believe this is still true. I hope I will be corrected by a C++
expert if I am wrong.

My understanding is that C++ cannot rely on a particular floating point
representation across platforms. This inability to define type
representation appears to make template parameter instantiation
difficult
for C++. I am guessing that this is a side-effect of the C and C++
type system for primitive types, where the type is very strongly
related to its physical representation.

Jim Rogers

Re: Teaching new tricks to an old dog (C++ -->Ada)

[T Beck]

I'm with Ioannis on this one...  I fail to see how p[-1] is any less an
index on an array than somearray[1] is.  They're using the exact same
compile-time methods to get to where their data is, and if you really
want to use -1 as an index, it's allowing you to do exactly that.  Is
there something magical about being able to declare it yourself that
makes it a "proper" index?  Or would you just rather see Perl-style
negative indices?  (which would make no sense in the way I've seen
people describe using negative indices in this discussion)

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

"Jerry Coffin" <jcoffin@taeus.com> writes:

> Martin Dowie wrote:
> > Jerry Coffin wrote:
> > > Just for one obvious example, Ada doesn't provide an easy way to
> > > express/do most of the things one can do with the C or C++
> > > preprocessor. It provides some alternative in _some_ cases, but
> > > quite frankly, these are really the exceptions rather than the
> > > rule.
> >
> > That 'problem' isn't unique to Ada - I can't think of another
> > language that *does* define a pre-processor.
> 
> A preprocessor per so, no. The type of capabilities is a different
> story. For example, Lisp includes macros. Most assemblers include (much
> more extensive) macros as well as an eqiuvalent of C's
> #if/#ifdef/#ifndef/#endif.

Lisp macros are _not_ a preprocessor and they are _vastly_ more
capable than what people typically think of when they see/hear
"macros".  Lisp macros are full code analyzing and generating
constructs.  Things like C/C++ preprocessor/"macro" simplistic text
substitutions are not in any way related to them.  You can literally
create entire new languages with them, create embedded domain specific
languages, and/or create extensions to the "core" language _within_
Lisp itself.  You can also domain specific code _optimizers_ in like
fashion.  None of this is at all doable _in_ things like
C++/Ada/Eiffel/<pretty-much-you-name-it>.  You would have to write a
compiler (or at least optimizer/code generator)_with_ those languages
_for_ the new language/constructs/optimization, etc.

Robert Duff made a comment a while ago about how silly most (I would
say without much hyperbole 99+%) of the points in these threads would
be to Lisp (and Smalltalk) folks.  I couldn't agree more.  You are all
arguing over differences that mean almost nothing looked at from these
other perspectives.  Exceptions is another good example.  Neither Ada
nor C++ nor Eiffel has anything even _remotely_ as potent as the
condition system in Common Lisp.  Same goes for the so called "OO"
capabilities in these languages in comparison with CLOS. And the level
of _expressive capability_ in either Ada or C++ or Eiffel or ?? is so
_low_ that it again is simply amazing to see people so vehemently
arguing over differences that are almost invisible.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Chad R. Meiners]

Ioannis Vranos wrote:
>>Pascal Obry wrote:
>> For a domain problem where you have to create an area centered on
(0,0)
>> for example. What about a vector representing altitude, the sub-zero
values
>> being under the water. Just some examples, I bet you'll be able to
think about
>> lot more :)

>I think an associative container like map fits better to this.

What do you do when you need to map the data structure to a specific
space in memory for a memory-mapped sensor array e.g. the temperature
sensors for levels -2 to 8 in a building?

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Georg Bauhaus]

T Beck wrote:
> I'm with Ioannis on this one...  I fail to see how p[-1] is any less an
> index on an array than somearray[1] is.

One difference is a 1:1 correspondence of index values and
indexed items. This suggests not using p[-1] or somearray[1]
interchangeably:

There is one named index type.
There is one named array type.
The index type is used in the declaration of the array type,
stating the set of permissible array index values.

    type Item_Array is array (Index_Type) of Item;

Values in the index type designate items in the problem domain.
This propagates into the declaration of the array type.
It also propagates into its use.

Ioannis really started, I think, from this 1:1 correspondence.
He had (intuitively?) mapped these kinds of array to std::map
in sample programs. Conceptually this seems right because the
specific index values and the items are associated 1:1 in the
array.

 From this perspective, after choosing an associative container
for representing the (index, item) pairs, you can no longer
use somemap[-1] or somemap[1] interchangeably. The perspective
has shifted from computing offsets to an association. 1 is
associated with one item in the array, -1 is associated with
another.

In this sense, p[-1] and somearray[1] are different.
In a sense, -1 and 1 are treated as names rather than
computable index values.

(Ada-like arrays have STL's key_type so to speak.)


Georg

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Robert A Duff]

"Ed Falis" <falis@verizon.net> writes:

> On 23 Mar 2005 18:16:42 -0800, Jerry Coffin <jcoffin@taeus.com> wrote:
> 
> >> Sorry, but if you think a class is called a tagged record in Ada,
> >> you don't understand the language.
> > I'll openly admit that my knowledge of Ada 95 is _extremely_ limited
> > (I'm afraid I quit using Ada before 1995). Perhaps I need to take
> > another look in this area.
> > OTOH, doing a bit more looking, if I've misunderstood the situation, at
> > least I have some company.  For example:
> 
> This is just a matter of simile.  A tagged type and derivatives of
> tagged  types provide dispatching and other typical OOP facilities.

I don't see it that way.  Tagged types provide inheritance and type
extension.  Ada's *class* feature provides run-time polymorphism
(i.e. dispatching calls).

That is, you can use tagged types all you like, but you'll never get any
dispatching until you say 'Class.  Ada's notion of "class" (i.e. "class
of types") doesn't exactly match what C++ calls "class".

> Where the  concept differs from the class concept is that visibility is
> orthogonal,  provided by packages and other more traditional Ada
> facilities, while the  class concept combines the two.

Yeah, that, too.  C++ wraps all three things into one language feature
(well, sort of -- there are namespaces), whereas Ada splits them out.
I was a bit taken aback by Jerry Coffin's "idiocy" remark, since I
can see advantages of both ways.  I somewhat prefer the Ada "splitting"
way.  Or maybe his "idiocy" comment was merely directed at the words:
"tagged record".  (Of course, it's usually "tagged private", not "tagged
record".)

Ada is not the only language that splits things up differently from the
mainstream OOP languages.  CLOS, for example, comes to mind.

- Bob

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Martin Krischik wrote:

> Shure it is usefull, very usefull indeed. Only you started off wrong:
> 
> namespace Ada
>     {
>     template <
>         class Base_Type,
>         Base_Type The_First,
>         Base_Type The_Last>
>     class Range
>         {
>         .....
>         }
> 
>     template <
>         class Element_Type,
>         class Index_Type>  // derived from Range.
>     class Array
>         {
>         .....
>         }
>     }



I did not thought up the code, I just typed a quick, limited demonstration.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Robert A Duff]

Martin Krischik <martin@krischik.com> writes:

> All true. But does that powerfull contruct works inside a multi tasking
> environment.

I see no reason why such powerful exception handling features cannot be
task/thread safe.  In fact, many languages are superior to *both* Ada
and C++ in this regard.

> And tread save is not all. An Ada system implementing the (optional) Annex E
> needs exeptions which can be passed from one process to another. Both
> processed runing on different computers. Just like CORBA exceptions.

Same comment for distribution: "I see no reason..."
Of course, exceptions with attached information need some flattening
to be passed across partitions.

Followups disobeyed, sorry.  I mean, you're answering somebody who's
probably *not* reading comp.lang.ada, so I thought he should see *my*
response.

- Bob

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Robert A Duff]

"Jerry Coffin" <jcoffin@taeus.com> writes:

> While bounded vs. unbounded strikes me as a reasonable distinction, I'm
> not at all convinced that two separate string classes are necessary to
> accomplish it. I see nothing here that can't be accomplished by single
> class with a parameter specifying its bound (or lack thereof). In fact,
> std::basic_string in the C++ library indirectly supports that right
> now: what we're reallly talking about is the memory allocation for the
> string, and std::basic_string takes a parameter to specify the
> allocator to use. All that's needed for a bounded_string is an
> allocator that only ever allocates a block of the initially-specified
> size.

Bounded strings should be allocated on the stack (or inside the
containing record or whatever) and should not incur the inefficiency of
the indirection required for unboundedness.  I'm not sure how to
accomplish that with memory allocators (storage pools, in Ada terms).

- Bob

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Thu, 24 Mar 2005 17:59:39 -0500, jayessay wrote:

...
> of _expressive capability_ in either Ada or C++ or Eiffel or ?? is so
> _low_ that it again is simply amazing to see people so vehemently
> arguing over differences that are almost invisible.

I think the point that many of the enthusiasts here claim is that
C++ and Ada have very different *outcomes* in real-world programming
tasks.  The differences may be small in Computer Science terms,
and may be small in relation to CLOS/Prolog/Lisp, but in practical
commercial terms, the differences are (it is being claimed)
hugely significant.

The Ada claims are very bold in terms of better code defect density,
portability, total cost and maintainability for large projects -
particularly with real-time and/or distributed aspects.
The C++ claims are equally bold in terms of expressiveness,
performance and conciseness (what else?).

*I* think the evidence is now very strong that programming language
choice *is* massively important for overall success of large projects.
The problem is a lack of scientific method in determining this,
resulting in a big analytical problem with (also massive)
confounding factors.


one snippet from a Google search:
"Gartner is now saying 70% of all Java projects so far have failed"
but only "40% of all projects fail."

and
"C++ programs typically have roughly six times the lifetime ownership
costs of equivalent programs written in C, Ada or Fortran, and fewer
than one third of programming projects begun in C++ are completed."

It will be really interesting if The Navy switches mainly to
Java, to see if it affects reliability or cost.  This should be
taken as a golden opportunity to research the outcome (but
still falls short of a controlled study).

Can anybody post links quantifying how much better C++ is
than C or Ada (in terms of project cost and outcome)?

Of course I enjoy programming in C/C++ very much, having
been using them for a decade or two.   But I do find the
total debugging time so much shorter in Ada (I've almost
forgotten how to use the debugging tools!).  This must
have an impact on the bottom line.
-- 
Adrian

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

fabio de francesco wrote:

> Sorry, maybe I was unable to explain the concept because of my poor
> English. Try please to re-read the latest paragraph, because you're
> missing the point. I know that standard guarantees minimum number of
> bits per types.
> 
> I was reasoning upon porting a C++ code from a machine providing C++
> "int"(s) with 32 bits capacity to another machine where "int"(s) are
> only 16 bits. In that situation if you forget to substitute every "int"
> with "long" you don't get any error from the compiler.


True. I wish we got such errors/warnings. I still see no reason why 
compiler-writers do not implement such errors/warnings and it is not 
part of the standard requirement.


> That ported
> program can execute for years without any problem. When that variable
> is assigned a value like 32768 you get -32768 and then negative numbers
> increasing towards zero for each "++var;". Remember that this
> assignment was considered allowable, since the programmer chose an
> "int" type for that variable knowing that it is stored in 32 bits in
> his development machine.


Yes. Also I see no reason why explicit use of ranges and constraints 
can't be introduced in a future standard revision as additional keywords 
without breaking existing code.



> Maybe that won't crash your program yet it is worse, because a bug has
> been inserted and it may pass unnoticed for years.
> 
> What I want to say is that in C++ (1) you must know how many bits are
> reserved for every type you use and (2) you must carefully change types
> when compiling to different targets.


Yes C++ is more unsafe than Ada (but still more safe than C).



> Instead in Ada a programmer can just write code that is portable across
> different platforms without worrying of bits of storage for types. Just
> ask the compiler "I need to store values between -80_000 and 80_000, so
> please choose yourself how many bits I need", and you can be sure that
> it won't raise any bug porting code from a machine with 32 bits "int"
> to a 16 bits "int".


OK, I already know that Ada is more safe than C++, when talking about 
"implicit" safety as opposed to "explicit" safety, and C++ *is* the 
second. Also I consider C++ being more "implicit" *paradigm-expressive* 
than Ada, as opposed to explicit-expressiveness (about the same that 
someone mentioned as expressiveness and expressibility in another message).


In other words I expect an intermediate C++ programmer (like myself) to 
know how to write bullet-proof code.



> The interesting thing in Ada is that either you can let your compiler
> to choose how to internally reserve storage, or you can force a lot of
> attributes for representation like the example that I provided:
> 
> type Counter is new Integer;
> for Counter'Size use 48;
> for Counter'Alignment use 16;
> 
> The above mentioned type declaration is something can't be done with
> C++, as far as I know. In order to do same kind of things you must use
> some no-standard compiler extension. Ada is simultaneously lower-level
> and higher-level than C++.


If you mean "more" I disagree. It simply provides more "implicit" safety 
than C++. In the low-level part I think they are about the same 
"implicit"-expressive, about the high level part (abstraction) I think 
C++ is better than Ada and with more complete paradigm-support 
("implicit" expressiveness).



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Chad R. Meiners wrote:

> What do you do when you need to map the data structure to a specific
> space in memory for a memory-mapped sensor array e.g. the temperature
> sensors for levels -2 to 8 in a building?


I am not sure I understood what you mean by this, but in C++ you can do 
use a specific numeric address in memory in the style:


int *p= reinterpret_cast<int *>(0x5556);


Of course this is system-specific and if nothing exists there will be a 
problem. :-)


You can also do:


// Complete safe and portable
#include <new>

class SomeClass {};


int main()
{
     // 1000 bytes in the stack
     unsigned char array[1000];

     // Create SomeClass object in the beginning of the array
     SomeClass *p= new(array)SomeClass;

     // Create a second SomeClass object after the first
     SomeClass *r= new(array+sizeof(*r))SomeClass;
}


With placement new you can create objects wherever you want. Also you 
can define your own versions of placement new, new, delete, new[], 
delete[] etc both globals and as parts of a class:


#include <cstddef>
#include <new>
#include <iostream>


class SomeClass
{
   static std::size_t occupied;
   static unsigned char *buffer;
   static const std::size_t MAX_SIZE=5*1024;

   public:

   ~SomeClass() { std::cout<<"Destructor called!\n"; }

   void *operator new(std::size_t size)
   {
    using namespace std;

    cout<<"Class member operator new was called!\n";

    if(occupied+size>MAX_SIZE)
      throw bad_alloc();

    occupied+=size;

    return buffer+occupied-size;
   }

   void operator delete(void *p)
   {
    std::cout<<"Class member operator delete was called!\n";

    occupied-=sizeof(SomeClass);
   }
};

std::size_t SomeClass::occupied=0;
unsigned char *SomeClass::buffer=new unsigned char[MAX_SIZE];


int main()
{
  // The member operator new is called implicitly
   SomeClass *p=new SomeClass;

   delete p;
}


So objects can undertake their memory management. C++ standard library 
containers use allocators, with the default one using the default new, 
and gives the ability to define your own ones, as also provides 
facilities to manage raw memory manually, but I do not know these yet.



Some pieces of Chapter 19 of TC++PL3 on the later:


"Implementers of containers often allocate() and deallocate() objects 
one at a time. For a naive implementation of allocate(), this implies 
lots of calls of operator new , and not all implementations of operator 
new are efficient when used like that. As an example of a user-defined
allocator, I present a scheme for using pools of fixed-sized pieces of 
memory from which the allocator can allocate() more efficiently than can 
a conventional and more general operator new().

I happen to have a pool allocator that does approximately the right 
thing, but it has the wrong interface (because it was designed years 
before allocators were invented). This Pool class implements the notion 
of a pool of fixed-sized elements from which a user can do fast 
allocations and deallocations. It is a low-level type that deals with 
memory directly and worries about alignment:"


Some other facilities:

"19.4.4 Uninitialized Memory

In addition to the standard allocator , the <memory > header provides a 
few functions for dealing with uninitialized memory. They share the 
dangerous and occasionally essential property of using a type name T to 
refer to space sufficient to hold an object of type T rather than to a 
properly constructed object of type T .

The library provides three ways to copy values into uninitialized space:"

and it talks about uninitialized_copy, uninitialized_fill and uninitial 
ized_fill_n.


Then, other facilities are mentioned like

"Algorithms often require temporary space to perform acceptably. Often, 
such temporary space is best allocated in one operation but not 
initialized until a particular location is actually needed.

Consequently, the library provides a pair of functions for allocating 
and deallocating uninitialized space:

template <class T> pair <T *,ptrdiff_t > get_temporary_buffer(ptrdiff_t 
); // allocate, don�t initialize

template <class T> void return_temporary_buffer(T *); // deallocate, 
don�t destroy

A get_temporary_buffer<X >(n) operation tries to allocate space for n or 
more objects of type X .

If it succeeds in allocating some memory, it returns a pointer to the 
first uninitialized space and the number of objects of type X that will 
fit into that space; otherwise, the second value of the pair is zero. 
The idea is that a system may keep a number of fixed-sized buffers ready 
for fast allocation so that requesting space for n objects may yield 
space for more than n . It may also yield less, however, so one way of 
using get_temporary_buffer() is to optimistically ask for a lot and then 
use what happens to be available."


And other stuff, it is an entire chapter.



C++ is very customizable, you can define handling functions for cases 
that uncaught exceptions occur, define your own behaviour when memory 
allocation error occurs instead of the default throwing of bad_alloc etc.


One of C++ design ideals has been

"Leave no room for a lower level language except assembly".



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Fri, 25 Mar 2005 03:34:24 +0200, Ioannis Vranos wrote:

> In other words I expect an intermediate C++ programmer (like myself) to
> know how to write bullet-proof code.

As bullet-proof as Microsoft Windows(TM)?
-- 
Adrian

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Georg Bauhaus wrote:

> One difference is a 1:1 correspondence of index values and
> indexed items. This suggests not using p[-1] or somearray[1]
> interchangeably:
> 
> There is one named index type.
> There is one named array type.
> The index type is used in the declaration of the array type,
> stating the set of permissible array index values.


Again, one can easily define an array container that accepts user 
defined indexes. The philosophical question that arises is *why no one 
has done it to this day*.

However I am going to make such one in some weekend (perhaps this!) to 
see if I can find any real use of it. Doing it sounds really simple:


template<class T, const int MIN, const int MAX >
class Array: public vector
{
  //  Only provide definitions for operator at() and operator[] that
  //  really *only* explicitly call the base ones with the proper index.
  //  And the few constructors doing the same, *only* explicitly passing
  //  the *same* arguments to the base constructors plus checking MIN and
  //  MAX (only once).
};


I think it is *that* simple.

Of course it is only about container index ranges, not stored value ranges.



>    type Item_Array is array (Index_Type) of Item;
> 
> Values in the index type designate items in the problem domain.
> This propagates into the declaration of the array type.
> It also propagates into its use.
> 
> Ioannis really started, I think, from this 1:1 correspondence.
> He had (intuitively?) mapped these kinds of array to std::map
> in sample programs. Conceptually this seems right because the
> specific index values and the items are associated 1:1 in the
> array.


For simple things I have been using a vector like this:


[real situation comment:]
// For [-200, -101] values of Something
vector<int> counter(100);


[something is in range of -200, -101 (by concept)]
counter[something-200]++;


For more diverse things, maps are suitable (I guess in Ada too).


>  From this perspective, after choosing an associative container
> for representing the (index, item) pairs, you can no longer
> use somemap[-1] or somemap[1] interchangeably. The perspective
> has shifted from computing offsets to an association. 1 is
> associated with one item in the array, -1 is associated with
> another.
> 
> In this sense, p[-1] and somearray[1] are different.
> In a sense, -1 and 1 are treated as names rather than
> computable index values.
> 
> (Ada-like arrays have STL's key_type so to speak.)


key_type is used only in maps!



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Robert A Duff wrote:

[ ... ]

> Yeah, that, too.  C++ wraps all three things into one language
> feature (well, sort of -- there are namespaces), whereas Ada
> splits them out. I was a bit taken aback by Jerry Coffin's
> "idiocy" remark, since I can see advantages of both ways.  I
> somewhat prefer the Ada "splitting" way.  Or maybe his "idiocy"
> comment was merely directed at the words: "tagged record".  (Of
> course, it's usually "tagged private", not "tagged record".)

>From a practical viewpoint, I've seen little real advantage to
requiring another construct to control visibility -- though given the
pre-existence of packages in Ada, continuing to use them when OO
support was added can hardly be seen as a surprise.

My real objection was (and is) entirely the terminology -- even in
assembly language, I think 'tagged' would be better avoided in this
situation as being far too closely tied to the implementation rather
than the meaning. In anything that attempts to provide even slightly
more abstraction, it strikes me as truly egregious.

At the same time, I'll also admit that the spelling used for a keyword
or two is rarely a good reason to condemn (or condone) an entire
language. In the end, if somebody's reading or writing code in either
Ada or C++, they should be sufficiently familiar with the language to
get past minor things like this -- that, however, doesn't excuse the
offense, but merely makes it easier to ignore. Furthermore, one of the
advantages often claimed for Ada is readability to people who don't use
the language on a regular basis -- but that doesn't seem (at least to
me) to be the case here.

I don't question Ada's expressiveness in a few specific areas, but IMO,
calling it even "fair" would qualify as quite generous at least wrt to
exception handling, object orientation or generics. I find this
particularly interesting since among mainstream langauges it was
essentially the first to support generics at all, and predated
primarily by PL/I in exception handling.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Martin Krischik wrote:

> It make no difference with interfaces as interfaces hold no data. Tha's the
> Java trick.

Being technically accurate, I have to say it is not a trick. It is a 
subset of the OO paradigm.

ISO C++ provides both the ability to define and inherit both interfaces 
and complete classes.


Here is an interface:

#include <iostream>

class SomeInterface
{
     public:
         virtual void somefunc() =0;

         // Place some definition if you want!
         // Only one method needs to be pure ( =0)
         virtual void func() { /* ... */ }

         virtual ~SomeInterface() {}
};


class SomeClass: public SomeInterface
{
     public:
         void somefunc()
         {
             std::cout<<"SomeClass::somefunc() was called!\n";
         }
};


int main()
{
     // Error: No instances of SomeInterface can be created
     // since it contains pure methods.
    // SomeInterface obj;

    SomeInterface *p= new SomeClass;

    p->somefunc();

    delete p;
}


C:\c>temp
SomeClass::somefunc() was called!

C:\c>



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Vinzent 'Gadget' Hoefler wrote:

> That would simply depend on your definition of "intermediate". :)


... which is knowing between 50%-75% of the language.



> Little story: Yesterday, a colleague of mine didn't believe me that
> realloc() would copy the memory contents if necessary until I showed
> him the reference. And he is doing C for more than ten years now.


Then he is definitely less than intermediate level in C. Besides that, 
C90 is relatively small, and he should have learned it *all* by reading 
K&R 2 in a matter of a few months, in a not-in-a-hurry mode.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Martin Krischik wrote:

> Yes, and process/system boundaries when Annex E is implemented.
> 
> Martin


ISO C++ defines no threading facilities so far (but *care has been 
taken* to be easy implementing the algorithms and container operations 
as thread-safe).

The only multithreading I know is the .NET lock-based multithreading. I 
can't understand how in such an environment you can expect to catch 
exceptions reliably. I can only assume that Ada's built in 
multithreading mechanism is not lock-based.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Martin Krischik wrote:

> Actualy there are only 3 of them. And they are usefull - two examples:
> 
> I have worked a lot with SQL and I allways wound it cumbersome to map the
> SQL string type to C++. Most SQL string types are bounded - they have a
> maximum size. std::string (and IBM's IString) is unbounded - so before you
> can store your string inside the database you have to make a sanity check.
> In Ada I could use Ada.Strings.Bounded_Strings instead.
> 
> The other example is CORBA. CORBA has two string types: string and
> sting<size>. In C++ both a mapped to std::string - and the CORBA/C++
> mapping must check the size of the sting. In Ada they are mapped to
> Ada.Strings.Unbounded_Strings and Ada.Strings.Bounded_Strings.


What about using const string.


>  
> 
>>Ada's exception handling is also primitive at best (exceptionally so,
>>if you'll pardon a pun). In particular, in Ada what you throw is
>>essentially an enumaration -- a name that the compiler can match up
>>with the same name in a handler, but nothing more. Only exact matches
>>are supported and no information is included beyond the identity of the
>>exception.
> 
> 
> Well, Ada 95 added a 200 character informations string.
> 
> 
>>In C++ you can throw an arbitrary type of object with an arbitrary
>>value. All the information relevant to the situation at hand can be
>>expressed cleanly and directly. The usual inheritance rules apply, so
>>an exception handler can handle not only one specific exception, but an
>>entire class of exceptions. Again, this idea can be expressed directly
>>rather than as the logical OR of the individual values. And, once
>>again, the addition of tagged records to Ada 95 testifies to the fact
>>that even its own designers recognized the improvement this adds in
>>general, but (whether due to shortsightedness, concerns for backward
>>compatibility or whatever) didn't allow this improvement to be applied
>>in this situation.
> 
> 
> All true. But does that powerfull contruct works inside a multi tasking
> environment. It is indeed true that Ada exeptions are restricted - but they
> are thread save. And thead save means that an exception may be raised in
> one thead and caugth in another. Exceptions raised inside an rendevous may
> even be caught in both threads participating in the rendevous.
> 
> And tread save is not all. An Ada system implementing the (optional) Annex E
> needs exeptions which can be passed from one process to another. Both
> processed runing on different computers. Just like CORBA exceptions.


In C++, multithreading is platform-specific. I think this is better than 
Ada, but may be I am just used to it.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Martin Krischik wrote:

 >>> At first, in this and other messages you had set the follow-ups to
 >>> comp.lang.ada which means we can not follow the discussion anymore!]


Martin Krischik wrote:

 > Actualy there are only 3 of them. And they are usefull - two examples:
 >
 > I have worked a lot with SQL and I allways wound it cumbersome to map the
 > SQL string type to C++. Most SQL string types are bounded - they have a
 > maximum size. std::string (and IBM's IString) is unbounded - so 
before you
 > can store your string inside the database you have to make a sanity 
check.
 > In Ada I could use Ada.Strings.Bounded_Strings instead.
 >
 > The other example is CORBA. CORBA has two string types: string and
 > sting<size>. In C++ both a mapped to std::string - and the CORBA/C++
 > mapping must check the size of the sting. In Ada they are mapped to
 > Ada.Strings.Unbounded_Strings and Ada.Strings.Bounded_Strings.



What about using const string.


 >
 >
 >> Ada's exception handling is also primitive at best (exceptionally so,
 >> if you'll pardon a pun). In particular, in Ada what you throw is
 >> essentially an enumaration -- a name that the compiler can match up
 >> with the same name in a handler, but nothing more. Only exact matches
 >> are supported and no information is included beyond the identity of the
 >> exception.
 >
 >
 >
 > Well, Ada 95 added a 200 character informations string.
 >
 >
 >> In C++ you can throw an arbitrary type of object with an arbitrary
 >> value. All the information relevant to the situation at hand can be
 >> expressed cleanly and directly. The usual inheritance rules apply, so
 >> an exception handler can handle not only one specific exception, but an
 >> entire class of exceptions. Again, this idea can be expressed directly
 >> rather than as the logical OR of the individual values. And, once
 >> again, the addition of tagged records to Ada 95 testifies to the fact
 >> that even its own designers recognized the improvement this adds in
 >> general, but (whether due to shortsightedness, concerns for backward
 >> compatibility or whatever) didn't allow this improvement to be applied
 >> in this situation.
 >
 >
 >
 > All true. But does that powerfull contruct works inside a multi tasking
 > environment. It is indeed true that Ada exeptions are restricted - 
but they
 > are thread save. And thead save means that an exception may be raised in
 > one thead and caugth in another. Exceptions raised inside an 
rendevous may
 > even be caught in both threads participating in the rendevous.
 >
 > And tread save is not all. An Ada system implementing the (optional) 
Annex E
 > needs exeptions which can be passed from one process to another. Both
 > processed runing on different computers. Just like CORBA exceptions.



In C++, multithreading is platform-specific. I think this is better than 
Ada, but may be I am just used to it.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys





-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Martin Krischik wrote:

--->> At first, in this and other messages you had set the follow-ups to
--->> comp.lang.ada which means we can not follow the discussion
--->> anymore!]


 > It make no difference with interfaces as interfaces hold no data.
 > Tha's the Java trick.


Being technically accurate, I have to say it is not a trick. It is a 
subset of the OO paradigm.

ISO C++ provides both the ability to define and inherit both interfaces 
and complete classes.


Here is an interface:

#include <iostream>

class SomeInterface
{
     public:
         virtual void somefunc() =0;

         // Place some definition if you want!
         // Only one method needs to be pure ( =0)
         virtual void func() { /* ... */ }

         virtual ~SomeInterface() {}
};


class SomeClass: public SomeInterface
{
     public:
         void somefunc()
         {
             std::cout<<"SomeClass::somefunc() was called!\n";
         }
};


int main()
{
     // Error: No instances of SomeInterface can be created
     // since it contains pure methods.
    // SomeInterface obj;

    SomeInterface *p= new SomeClass;

    p->somefunc();

    delete p;
}


C:\c>temp
SomeClass::somefunc() was called!

C:\c>



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

--->> At first, in this and other messages you had set the follow-ups to
--->> comp.lang.ada which means we can not follow the discussion
--->> anymore!]


Martin Krischik wrote:

 > Yes, and process/system boundaries when Annex E is implemented.
 >
 > Martin



ISO C++ defines no threading facilities so far (but *care has been 
taken* to be easy implementing the algorithms and container operations 
as thread-safe).

The only multithreading I know is the .NET lock-based multithreading. I 
can't understand how in such an environment you can expect to catch 
exceptions reliably. I can only assume that Ada's built in 
multithreading mechanism is not lock-based.



Here is a .NET example:


#using <mscorlib.dll>

using namespace System;
using namespace System::Threading;


class SomeException
{};


__gc class SomeClass
{
  int index;

  //...

  public:

  // ...


  void DoSomething()
  {
     Monitor::Enter(this);

     throw SomeException();

    // Modify index

     Monitor::Exit(this);
  }

  void DoSomethingElse()
  {
     Monitor::Enter(this);

     // Modify index

     Monitor::Exit(this);
   }

// ...
};


int main() try
{
     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();
}

catch(SomeException)
{
     Console::WriteLine("SomeException caught in main thread!\n");
}


How can you expect to catch the exception in the main thread for 
example, since it terminates immediately after the two calls in the try 
block?



The proper way in .NET (this isn't production-level code BTW):



#using <mscorlib.dll>

using namespace System;
using namespace System::Threading;

class SomeException
{};

__gc class SomeClass
{
  int index;

  //...

  public:

  // ...


  void DoSomething() try
  {
     Monitor::Enter(this);

     throw SomeException();

    // Modify index

     Monitor::Exit(this);
  }

  ==> Handle inside the specific thread locally
  catch(SomeException)
  {
         // ...
  }

  void DoSomethingElse()
  {
     Monitor::Enter(this);

     // Modify index

     Monitor::Exit(this);
   }

// ...
};


int main() try
{
     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();
}

catch(Exception *pe)
{
     Console::WriteLine("{0}", pe->Message);
}




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

--->> At first, in this and other messages you had set the follow-ups to
--->> comp.lang.ada which means we can not follow the discussion
--->> anymore!]


Martin Krischik wrote:

 > Yes, and process/system boundaries when Annex E is implemented.
 >
 > Martin



ISO C++ defines no threading facilities so far (but *care has been 
taken* to be easy implementing the algorithms and container operations 
as thread-safe).

The only multithreading I know is the .NET lock-based multithreading. I 
can't understand how in such an environment you can expect to catch 
exceptions reliably. I can only assume that Ada's built in 
multithreading mechanism is not lock-based.



Here is a .NET example:


#using <mscorlib.dll>

using namespace System;
using namespace System::Threading;


class SomeException
{};


__gc class SomeClass
{
  int index;

  //...

  public:

  // ...


  void DoSomething()
  {
     Monitor::Enter(this);

     throw SomeException();

    // Modify index

     Monitor::Exit(this);
  }

  void DoSomethingElse()
  {
     Monitor::Enter(this);

     // Modify index

     Monitor::Exit(this);
   }

// ...
};


int main() try
{
     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();
}

catch(SomeException)
{
     Console::WriteLine("SomeException caught in main thread!\n");
}


How can you expect to catch the exception in the main thread for 
example, since it terminates immediately after the two calls in the try 
block?



The proper way in .NET (this isn't production-level code BTW):



#using <mscorlib.dll>

using namespace System;
using namespace System::Threading;

class SomeException
{};

__gc class SomeClass
{
  int index;

  //...

  public:

  // ...


  void DoSomething() try
  {
     Monitor::Enter(this);

     throw SomeException();

    // Modify index

     Monitor::Exit(this);
  }

  ==> Handle inside the specific thread locally
  catch(SomeException)
  {
         // ...
  }

  void DoSomethingElse()
  {
     Monitor::Enter(this);

     // Modify index

     Monitor::Exit(this);
   }

// ...
};


int main() try
{
     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();
}

catch(Exception *pe)
{
     Console::WriteLine("{0}", pe->Message);
}




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jeremy J]

> And the level
> of _expressive capability_ in either Ada or C++ or Eiffel or ?? is so
> _low_

You don't even know which languages you are talking about!?!?  You
have to compare lisp to language "??". Please avoid posting flamebait
such as this. Or maybe create a newsgroup called
comp.lang.expressiveness and mail me in a few years when you compile a
FAQ.

Jeremy J.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

In article <1111718335.705081@athnrd02>, Ioannis Vranos <ivr@remove.this.grad.com> writes:
> Vinzent 'Gadget' Hoefler wrote:

>> Little story: Yesterday, a colleague of mine didn't believe me that
>> realloc() would copy the memory contents if necessary until I showed
>> him the reference. And he is doing C for more than ten years now.
> 
> 
> Then he is definitely less than intermediate level in C. Besides that, 
> C90 is relatively small, and he should have learned it *all* by reading 
> K&R 2 in a matter of a few months, in a not-in-a-hurry mode.

Is "intermediate" intended to describe what portion someone knows
of all possible information about a language ?

Or is "intermediate" intended to describe where someone ranks in
language knowledge across all programmers who use that language ?

I am reminded of humorist Garrison Keillor describing a community
quite proud that all it's children are above average.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jared]

jayessay <nospam@foo.com> wrote in 
> Lisp macros are _not_ a 
<snip>
> Lisp macros are full
<snip>
> Things like C/C++ preprocessor/"macro" simplistic text
> substitutions are not
<snip>
> You can literally create 
<snip>
> You can also 
<snip>
> None of this is at all doable _in_ things like
<snip>
> You would have to write a
<snip>

And that is why $YOUR_LANGUAGE should allow arbitrary array indices.  Or 
should have all types be anonymous.  Or should use structural type 
equivalence.  Or should combine data and method declarations for object 
types.  <Looks around guiltily.>  Or should have a preprocessor.  Or 
infer all types.  Or whatever.  Just like $MY_LANGUAGE.

There's a reason I don't use your language.  I assume there's a reason 
you don't use mine.  In my case, it's because I'm a hobbyist; I go with 
whatever appeals to me.  ML does and so does Piccola, and so do Cecil and 
Aldor, to a certain extent, and I'll learn them when I get around to it.  
I'm here because Ada appeals to me, although that's obscured by the 
cross-posting.  Most of the people here seem to be professionals; they 
use whatever they're told to use.  Thus the cynical comments about Ada 
and C++, describing the way they were, rather than the way they are now.

> Robert Duff made a comment a while ago about how silly most (I would
> say without much hyperbole 99+%) of the points in these threads would
> be to Lisp (and Smalltalk) folks.  I couldn't agree more.  You are all
> arguing over differences that mean almost nothing looked at from these
> other perspectives.

This is quite correct, but also largely irrelevant.  The general context 
of a language flamewar is that every feature $YOUR_LANGUAGE has that 
$MY_LANGUAGE doesn't have is unnecessary, and a clear sign of its 
inferiority.  Any feature $MY_LANGUAGE has that $YOUR_LANGUAGE lacks is 
absolutely essential, and a clear sign of its superiority.

A functional language like Lisp lacks many of the features being argued 
about here; the obvious conclusion is that Ada and C++ are painfully 
inferior.  Similarly, most of Lisp's features, such its the macro system 
or Currying, are absent from the imperative languages; a clear sign of 
Lisp's superiority.

Yes, a person can do all kinds of neat things in Lisp.  A good programmer 
can do all kinds of neat things elegantly in any language, and a bad 
programmer cannot.

In the interest of full disclosure, I should add that I am not a good 
programmer.


> And the level
> of _expressive capability_ in

Aldor?

> is so
> _low_ that it again is simply amazing to see people so vehemently
> arguing over differences that are almost invisible.

I'm sure you meant expressive convenience.  Turing completeness ensures 
that "_expressive capability_" is equivalent, at least, for functional 
computation.  On the other hand, you seem so vehement about it, I'm not 
really sure.  I've already dealt with the conclusion I draw from your 
personal expressive capability in these languages.

Anyway, first, a quote:

"The sooner we can forget that FORTRAN has ever existed, the better, for 
as a vehicle of thought it is no longer adequate: it wastes our 
brainpower, is too risky and therefore too expensive to use."
 - E.W. Dijkstra, EWD 340

The arguments being carried on here echo this complaint.  Implicit in the 
arguments for both sides is that the one wastes brainpower while the 
other conserves it.  That's fairly important, given that brainpower is 
the only tool a programmer really has.  As for myself, I side with Ada, 
and provide as evidence the followup to one of the many code fragments in 
this thread.  "A clever trick."  Dijkstra again:

"The competent programmer is fully aware of the strictly limited size of 
his own skull; therefore he approaches the programming task in full 
humility, and among other things he avoids clever tricks like the 
plague."

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

Jerry Coffin wrote:
> Of course, in well-written code, you just wouldn't do anything like
> this at all -- a picture of a wagon is NOT a wagon, and does not
> satisfy the Liskov Substitution Principle, so having Picture_Of_A_Wagon
> derive (publicly) from Wagon is just plain wrong.

It was just an illustration of the concept, which does not
hold sufficient interest for me to spend hours engineering
the question.

-- 
Wes Groleau

Is it an on-line compliment to call someone a Net Wit ?

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

Jerry Coffin wrote:
> In the end, you can call that what you will, and depending on how you
> call it, my original statement about the multiplicity of classes
> indicating a problem might need to be re-phrased.

Ada 83 had one string type.

Ada 95 added one due to the need to support more than 256 characters.

Bounded String and Unbounded String are add-on packages created to
support particular implementation needs.

-- 
Wes Groleau

    I've noticed lately that the paranoid fear of computers becoming
    intelligent and taking over the world has almost entirely disappeared
    from the common culture.  Near as I can tell, this coincides with
    the release of MS-DOS.
                                  -- Larry DeLuca

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

Jerry Coffin wrote:
> In the end, you can call that what you will, and depending on how you
> call it, my original statement about the multiplicity of classes
> indicating a problem might need to be re-phrased.

Can I say that the multiplicity of container classes indicates
somebody didn't think hard enough about how to much a truly
universal container?

-- 
Wes Groleau
    "Would the prodigal have gone home if
     the elder brother was running the farm?"
                       -- James Jordan

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

Ioannis Vranos wrote:
> In C++, multithreading is platform-specific. I think this is better than 
> Ada, but may be I am just used to it.

Of course it's better--it's job security.
Why would anyone want to write a program
and then draw unemployment while the company
re-compiles and runs it effortlessly on a
new platform?

-- 
Wes Groleau
   "Grant me the serenity to accept those I cannot change;
    the courage to change the one I can;
    and the wisdom to know it's me."
                                -- unknown

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Wes Groleau wrote:

> Of course it's better--it's job security.
> Why would anyone want to write a program
> and then draw unemployment while the company
> re-compiles and runs it effortlessly on a
> new platform?


Actually .NET multithreading is standard-based, part of the CLI standard 
(.NET is a CLI-compliant VM) so it is portable to all CLI VMs (e.g. 
Mono, DotGNU).


About portability to non-CLI VMs, well such an application can not be 
straight-portable anyway, but multithreading as part of ISO C++ could 
mean less porting efforts probably.


C++0x will have multithreading support, and one benefit of being 
somewhat late on this, is perhaps more mature multithreading support. :-)




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Dr. Adrian Wrigley wrote:

[ ... ]

> one snippet from a Google search:
[ ... ]
> "C++ programs typically have roughly six times the lifetime ownership
> costs of equivalent programs written in C, Ada or Fortran, and fewer
> than one third of programming projects begun in C++ are completed."

Unfortunately, quotes like this tend to mean a lot less than they
initially look like they might. Considering the first item: what
constitutes "equivalent programs"? I've never in my life seen two
programs (at anything beyond the VERY most trivial level) that were
actually equivalent -- even when/if the same person/people attempt(s)
to reproduce an identical program, it's nearly inevitable that during a
rewrite at least a few things change, sometimes for the worse (second
system effect) and sometimes for the better (more experience,
refactoring, etc.)

Now, in fairness, I should add that in my own experience C++ programs
_have_ had higher long-term costs than (initally) roughly similar
programs I've written in other languages. That sounds bad, but in
reality it's exactly the opposite -- the reason the others had lower
long-term costs was that they were enough less maintainable that they
were discarded and replaced much sooner. Doing some looking through my
company database it looks like our C++ programs have cost just under
twice as much on average as their counterparts written in other
languages -- but their average useful lifetime has been better than
three times as long (so far -- most of the C++ programs are still in
regular use).

The real measure is not the long term cost of a particular program, but
the long-term cost of carrying out a particular task. Unfortunately,
that's generally much more difficult to measure, and (worse) attempts
at measuring it are much less common.

Looking at the second part, we get an even worse problem. I would
postulate that a typical programming project is basically a business
venture. Studies have shown for _years_ that the vast majority of
business ventures fail -- but most fail simply due to inadequate
startup capital, so they simply can't stay in business long enough to
become profitable.

Programming languages fit into this fairly nicely: when Ada is chosen,
it's mostly by a relatively large company with adequate funding that
hires experienced managers, has a clear goal and a reasonable idea of
how to reach it.

At the opposite end of the spectrum, if you look at an unfunded startup
consisting of one or two guys straight out of college who are certain
that in six months they're going to become billionaires by creating the
next Netscape, their language of choice is most likely Java, with C++
in second place, and Ada basically not even in the picture at all.

It takes only minimal business acumen to figure out which project is
more likely to succeed -- but even less to realize that IF each had
chosen the other language, the answer would be unaffected.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Hyman Rosen wrote:

> Martin Krischik wrote:
>> As allways: the default behaviour. Default is static inheritance.
> 
> You can't just go willy-nilly making base classes virtual.
> For one thing, constructor arguments for virtual bases must
> be provided by the most derived class.

I don't consider that to be a disadvantage - I do it anyway.

> For another, why do 
> you imagine that there is something wrong with having two
> separate "C" base classes in your example?

That of course depends on the situation. In so far is C++ right to provide
both options. I only criticise the default which is  based on speed and not
on what is right most of the time.

From my 10+ years of experience I know that you need virtual inheritance in
95% of the cases where a diamond inheritance tree is involved. However,
because static inheritance is default 99.9% of all inheritance is static.

And worse: If it is a 3rd party lib you can't even fix it.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Juliï¿œn Albo wrote:

> Martin Krischik wrote:
> 
>>>> All very well, only I know C++ programmers which had 2 to 7+ years
>>>> experience in C++ and did not know about it until I told them. And not
>>>> just one programmer: the whole team of about 20!
>>> 
>>> Perhaps it was in the pre-standard era? :-)) I do not think there is any
>>> intermediate level C++ programmer that does not know virtual bases.
>> 
>> They started off in the pre-standard area an never learned any new
>> tricks ;-) . However the pre-standard  IBM compiler they used was
>> advanced enough to have virtual base classes and I used them alot.
> 
> In this type of discussions people always does the same: in the langauage
> they like they talk about all features they know and the most recent
> version of the language is considered, in the language they dislike, only
> the most commonly used features are taken into account, and 'but many
> people still use old versions' is mentioned. In a language the best
> paractices are suppossed to be used for anything in the world, in the
> other one talk about the worse programmers and programs they have seen.

You are right. Most languages come together now: Fortran 2003 ist object
orientated, C99 got dynamic arrays, Ada 2005 got an STL clone. And to most
of us none of it is available right now :-( .

Mind you: I have got all three ISO standards for Ada, C and C++. And I do
take an interest in all of them.

And the "never learned any new tricks" is taken from real live experience.
Not a theoretical argument: It actualy realy happend.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Dmitry A. Kazakov wrote:

> On Thu, 24 Mar 2005 14:38:39 +0100, Martin Krischik wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>>> On Thu, 24 Mar 2005 11:47:10 +0100, Martin Krischik wrote:
>>> 
>>>> Hyman Rosen wrote:
>>>> 
>>>>> adaworks@sbcglobal.net wrote:
>>>>>> I wish Ada had a good model of multiple inheritance.
>>>>>  > I don't mean the somewhat haphazard model of C++
>>>>> 
>>>>> What's wrong with C++'s model?
>>>> 
>>>> As allways: the default behaviour. Default is static inheritance.
>>> 
>>> As it will be with interfaces in Ada 2005, I suppose...
>> 
>> It make no difference with interfaces as interfaces hold no data.
> 
> Of course it does. Diamond diagram is as valid for interfaces as for
> implementations (data). If you allow interfaces to be derived from other
> interfaces (I don't know if Ada 2005 will), then:
> 
> C -> A (both are interfaces)
> C -> B (both are interfaces)
> 
> Let X implements both A and B. Now: A's C of X = B's C of X?

Where is the problem? There is no data in C, C only consists of its tag (or
virtual function table). But the tag (or virtual function table) is a
singelton and A's C and B's C are both the same.

And even if the tag is physically copied - after elaboration it's constant
as well - so even than it's only a waste of space but still makes not
difference.

And that is indeed the way Java gets around the MI problems.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Ioannis Vranos wrote:

> Martin Krischik wrote:
 
> I did not thought up the code, I just typed a quick, limited
> demonstration.

Well, I actualy got the working version ;-)  - well array is a bit out of
date (no namespaces for the IBM compiler) an need fixing.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Fri, 25 Mar 2005 10:50:46 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Thu, 24 Mar 2005 14:38:39 +0100, Martin Krischik wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>> 
>>>> On Thu, 24 Mar 2005 11:47:10 +0100, Martin Krischik wrote:
>>>> 
>>>>> Hyman Rosen wrote:
>>>>> 
>>>>>> adaworks@sbcglobal.net wrote:
>>>>>>> I wish Ada had a good model of multiple inheritance.
>>>>>>  > I don't mean the somewhat haphazard model of C++
>>>>>> 
>>>>>> What's wrong with C++'s model?
>>>>> 
>>>>> As allways: the default behaviour. Default is static inheritance.
>>>> 
>>>> As it will be with interfaces in Ada 2005, I suppose...
>>> 
>>> It make no difference with interfaces as interfaces hold no data.
>> 
>> Of course it does. Diamond diagram is as valid for interfaces as for
>> implementations (data). If you allow interfaces to be derived from other
>> interfaces (I don't know if Ada 2005 will), then:
>> 
>> C -> A (both are interfaces)
>> C -> B (both are interfaces)
>> 
>> Let X implements both A and B. Now: A's C of X = B's C of X?
> 
> Where is the problem? There is no data in C, C only consists of its tag (or
> virtual function table). But the tag (or virtual function table) is a
> singelton and A's C and B's C are both the same.

That's the point, whether they be same or not is to be defined solely by X,
not per language design.

Forget about data, it is irrelevant. Primitive operations are data and data
are primitive operations. If C has abstract Foo, then may/shall X implement
X.A.C.Foo and X.B.C.Foo differently? Is it the same primitive operation of
X or is it two different operations? Or else, will Foo's dispatching table
split into two branches or not?

The answer is: it depends on the design. Because both variants are needed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Rendezvous based mutithreading.

[Martin Krischik]

Ioannis Vranos wrote:

> --->> At first, in this and other messages you had set the follow-ups to
> --->> comp.lang.ada which means we can not follow the discussion
> --->> anymore!]

Sorry about that. Knode is a bit restrictive on cross posts.
 
> Martin Krischik wrote:
> 
>  > Yes, and process/system boundaries when Annex E is implemented.
> 
> ISO C++ defines no threading facilities so far (but *care has been
> taken* to be easy implementing the algorithms and container operations
> as thread-safe).
> 
> The only multithreading I know is the .NET lock-based multithreading. I
> can't understand how in such an environment you can expect to catch
> exceptions reliably. I can only assume that Ada's built in
> multithreading mechanism is not lock-based.

Ada has two multithreading paradigms implemented. There are protected types
which are lock based (but you don't start new threads with them) and task
types which are rendezvous based (these are the types which actualy start
new threads):

http://en.wikibooks.org/wiki/Programming:Ada:Tasking

In rendezvous based mutitheading two task meet at rendezvous points (hence
the name). An exeptions happening inside a rendezvous points need to be
handled by both theads participating at the redevous.

Also: expections happening inside the "contructor" (C++ talk - the Ada terms
are different) of an task type need to be handeled by the originating
thread. Reason: the newly created thread is ready the handle exeptions
since it is only in its contruction phase.

At first I it was quite difficult for me to understand rendezvous based
multithreading - I was only used to lock based multithreading from C (OS/2)
C++ (OCL) and Java (java threads). But once I understand how it works I
found it far easier to use and more stable in respect of dead locks. It
also works with all all operating system I know of.

But I think it would be quite a challenge to create rendezvous based
multithreading on top of C++ templates - and yet keep it easy to use for
the programmer. 

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Dmitry A. Kazakov wrote:

> On Fri, 25 Mar 2005 10:50:46 +0100, Martin Krischik wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>>> On Thu, 24 Mar 2005 14:38:39 +0100, Martin Krischik wrote:
>>> 
>>>> Dmitry A. Kazakov wrote:
>>>> 
>>>>> On Thu, 24 Mar 2005 11:47:10 +0100, Martin Krischik wrote:
>>>>> 
>>>>>> Hyman Rosen wrote:
>>>>>> 
>>>>>>> adaworks@sbcglobal.net wrote:
>>>>>>>> I wish Ada had a good model of multiple inheritance.
>>>>>>>  > I don't mean the somewhat haphazard model of C++
>>>>>>> 
>>>>>>> What's wrong with C++'s model?
>>>>>> 
>>>>>> As allways: the default behaviour. Default is static inheritance.
>>>>> 
>>>>> As it will be with interfaces in Ada 2005, I suppose...
>>>> 
>>>> It make no difference with interfaces as interfaces hold no data.
>>> 
>>> Of course it does. Diamond diagram is as valid for interfaces as for
>>> implementations (data). If you allow interfaces to be derived from other
>>> interfaces (I don't know if Ada 2005 will), then:
>>> 
>>> C -> A (both are interfaces)
>>> C -> B (both are interfaces)
>>> 
>>> Let X implements both A and B. Now: A's C of X = B's C of X?
>> 
>> Where is the problem? There is no data in C, C only consists of its tag
>> (or virtual function table). But the tag (or virtual function table) is a
>> singelton and A's C and B's C are both the same.
> 
> That's the point, whether they be same or not is to be defined solely by
> X, not per language design.
> 
> Forget about data, it is irrelevant. Primitive operations are data and
> data are primitive operations. If C has abstract Foo, then may/shall X
> implement X.A.C.Foo and X.B.C.Foo differently? Is it the same primitive
> operation of X or is it two different operations? Or else, will Foo's
> dispatching table split into two branches or not?
> 
> The answer is: it depends on the design. Because both variants are needed.

Yes, I see your point and foregot something here (silly me): At least one A
ore B need to be an interfaces as well (If we consider the Java approch).
And that resolves is:

If A is interface than X.A.C.Foo
If B is interface then X.B.C.Foo
If A and B are interfaces then X.Foo

Whatever the situation there is only one Foo.

Of course I do see the advantages of full MI as well.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Thu, 24 Mar 2005 22:28:22 -0800, Jerry Coffin wrote:

...
> Programming languages fit into this fairly nicely: when Ada is chosen,
> it's mostly by a relatively large company with adequate funding that
> hires experienced managers, has a clear goal and a reasonable idea of
> how to reach it.

I was particularly focusing on large software projects.  These always
have high levels of resources - perhaps $100m+.  Something like
a Social Security administration system, or an Air Traffic Control
system.  The stakeholders really can't afford to have projects
collapsing at the rate of 50%-70%.

> At the opposite end of the spectrum, if you look at an unfunded startup
> consisting of one or two guys straight out of college who are certain
> that in six months they're going to become billionaires by creating the
> next Netscape, their language of choice is most likely Java, with C++
> in second place, and Ada basically not even in the picture at all.
> 
> It takes only minimal business acumen to figure out which project is
> more likely to succeed -- but even less to realize that IF each had
> chosen the other language, the answer would be unaffected.

You are saying that the large software projects have a significantly
lower failure rate?  And this is obvious to those with business
acumen?  And obvious that the large project's success is independent
of the language choice?

I have not come across any studies that support these "obvious"
findings.  But I haven't looked into this very much, and I'd
be pleased to have pointers to such studies.

Curiously, if the C++ community says language choice is irrelevant
to project success, but the Ada community says it matters, perhaps
managers should always hedge their bets by choosing Ada(?)

I was at a seminar by the project leader of the Canadian ATC system
a few years ago.  He explained all the management and engineering
approaches taken to get the best outcome.  He seemed very proud
to have developed one of the most robust, well budgeted, successful
projects in its class.  This is contrasted to the "issues" which
have arisen in the new US ATC system, or the UK system.
At the end I asked "was language choice a factor in success and which
languages were used?".  He replied that it was almost entirely Ada,
and this played a big role in the positive outcome.  But he didn't
seem to want to introduce the issue in his presentation, because
it could be so controversial.

But again, this is anecdotal evidence.

More tangibly (but at the small end of the scale):

another snippet:

"In one of the few times a manager has performed the same project
several times using similarly experienced teams but with different
programming tools, the use of Ada significantly boosted project
success rates. At SUNY Plattsburgh, Professor John McCormick has
assigned the same real-time programming project to his class for nine
years."

"Working in teams of three or four, McCormick's students must write
15,000 lines of code to control a system that would need about 150
switches to operate using hardware alone. In the five years students
used C, no team completed the project -- even when more than half of
the code was provided. With Ada, however, half of the teams completed
the project before any support code had even been written. With some
support code now provided, three out of four teams finish the project."

In summary:
It simply isn't good enough for a language community to claim
language choice is irrelevant, without giving real-world evidence.
And why would such a claim attract us to the community?

If choice is claimed to be irrelevant, why focus on small-scale
issues like arrays vs. containers or contract vs. non-contract
template models?

Or to put it another way:
How come "more expressive" templates, "better exception handling",
or "less verbose" syntax is not claimed to improve project success?

Maybe I (still) don't get it.
-- 
Adrian

Re: Rendezvous based mutithreading.

[Dmitry A. Kazakov]

On Fri, 25 Mar 2005 13:42:31 +0100, Martin Krischik wrote:

> But I think it would be quite a challenge to create rendezvous based
> multithreading on top of C++ templates - and yet keep it easy to use for
> the programmer. 

We did it in our proprietary C++ library, and without any templates, BTW.
The pattern is:

1. A rendezvous queue type either to derive task objects from or to mix-in.
A task periodically polls the queue, it can also wait for a queuing event.

2. An abstract rendezvous object type to queue. User-defined rendezvous
objects were derived from there. When rendezvous happened a virtual method
was called.

We supported timed calls, and even a kind of re-queuing to mimic this
extremely useful feature of Ada 95.

Of course it is not as easy to use it as Ada's rendezvous, but it is usable
and works fine. The advantages rendezvous have over queues are that as in
Ada there is no need to marshal parameters here and there, no need in any
locks, no problem to have results.

The most difficult problem is exception handling. In Ada, rendezvous
exceptions are propagated in both caller and callee. This is impossible to
mimic in C++, because there seems no way to throw same-as-this exception in
C++. So we had to fuse all exceptions on the caller's side ...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Teaching new tricks to an old dog (C++ -->Ada)

[adaworks]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1111719129.745924@athnrd02...
>
> In C++, multithreading is platform-specific. I think this is better than
> Ada, but may be I am just used to it.
>
Better is a relative assessment, in this case.

When concurrency is a part of the programming language,
the language is simpler.  If Ada did not have concurrency,
many other things in the language would be much easier.
The addition of concurrency, as part of the language
definition, does place some restrictions on some features
that some designers might find less restrictive in other
languages.

On the other hand, Ada's expressive power includes the
ability to write concurrent program units that are checked
for consistency by the compiler.   An important idea
in Ada concurrency is that the tasks (Ada's primary
unit for concurrency) are as type safe as the rest of
the program.   They are also portable across many
different platforms.

The ability to write type-safe, portable concurrent software
has proven its value in many projects.

There are always tradeoffs.  When we compare any set
of languages, feature by feature, we have to realize that
someone can easily highlight some set of features in one
that is present or absent in some form or other.  Further,
some of us will find a feature of a language ugly, difficult,
or ask "Why would I even want to do that?" when others
will revel in their good their good fortune as having such
a feature available.

The example of C++ templates versus Ada generics has
been cited.   I understand the very interesting instantiation
model of C++.  In fact, I had to explain it to a colleague
about a year ago who was stymied by its seemingly
obfuscating nature in a program he was trying to read.
And, I am not one of those who is particularly enamoured
of it.   Ada generics, with the exception of generic formal
package parameters, are wonderfully easy to understand,
and have consistenly provided a good model for writing
easy to understand code.   On the other hand, with generic
formal package parameters, a more difficult concept (but
one I have tried to clarify in my Ada Letters article several
years ago),  we can accomplish things that can be done
with C++ templates, and some of those things a little
better.

In this thread, we have discussed C++ templates as a
way to do the equivalent of Ada's range definitions;  posted
code to prove that Ada is better than C++ or that C++ is
better than Ada;  lamented that language A does not have
the features of language B;  argued that language A does
not really need the features of language B; and retaliated
to ad hominen attacks by lobbing code grenades across
the entire set of comp.?.? Newsgroups.

By now it should be clear that some of us prefer Ada for
some kinds of programming.  Some of us who also use
C++ understand that we have to live with it, and that it
can be useful for certain classes of programming.   Those
who prefer C++ are unlikely to ever succumb to the
charms of Ada.   It is reminiscent of the old saw "He
convinced against his will, is of the same opinion still."

So is there a common ground for the two sides?   I suppose
we could agreee that neither language is ideal.   There are
features I would like to see in Ada.   There are things I
would like to have in C++.   Java is not an option, not for
the kind of programming I do.   Eiffel comes pretty close
to being a good option.  I prefer it to C++, but still lean
toward Ada, at present.

At present there is no way for anyone to win this debate,
certainly not as long as we restrict the conversation to
a comparison between two imperfect languages.   Then
again, I defy anyone to introduce a third language into the
debate that is not imperfect.  I don't don't think there is
one.

Dr. Richard Hamming, a pioneer in computer science I
once had the honor of knowing, once said of our profession,
"We stand on the toes of giants."    It is strange that any of
us have the audacity to proclaim that our preferred language
deserved such reverence when we all know that they all
fall short of what we really need to build the kind of software
necessary for the coming century.

Richard Riehle

Re: Rendezvous based mutithreading.

[Martin Krischik]

Dmitry A. Kazakov wrote:

> On Fri, 25 Mar 2005 13:42:31 +0100, Martin Krischik wrote:
> 
>> But I think it would be quite a challenge to create rendezvous based
>> multithreading on top of C++ templates - and yet keep it easy to use for
>> the programmer.
> 
> We did it in our proprietary C++ library, and without any templates, BTW.
> The pattern is:
> 
> 1. A rendezvous queue type either to derive task objects from or to
> mix-in. A task periodically polls the queue, it can also wait for a
> queuing event.
> 
> 2. An abstract rendezvous object type to queue. User-defined rendezvous
> objects were derived from there. When rendezvous happened a virtual method
> was called.
> 
> We supported timed calls, and even a kind of re-queuing to mimic this
> extremely useful feature of Ada 95.
> 
> Of course it is not as easy to use it as Ada's rendezvous, but it is
> usable and works fine. The advantages rendezvous have over queues are that
> as in Ada there is no need to marshal parameters here and there, no need
> in any locks, no problem to have results.
> 
> The most difficult problem is exception handling. In Ada, rendezvous
> exceptions are propagated in both caller and callee. This is impossible to
> mimic in C++, because there seems no way to throw same-as-this exception
> in C++. So we had to fuse all exceptions on the caller's side ...

Cool. Sad that it is not open source.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ed Falis]

On Fri, 25 Mar 2005 18:06:01 GMT, <adaworks@sbcglobal.net> wrote:

> Dr. Richard Hamming, a pioneer in computer science I
> once had the honor of knowing, once said of our profession,
> "We stand on the toes of giants."   ...

That reminds me of Per Brinch-Hansen's article about Java's concurrency  
features, which he summarized as ignoring 30+ years of operating system  
and programming language research.

- Ed

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Georg Bauhaus]

Ioannis Vranos wrote:
> Georg Bauhaus wrote:
> 
>> One difference is a 1:1 correspondence of index values and
>> indexed items. This suggests not using p[-1] or somearray[1]
>> interchangeably:
>>
>> There is one named index type.
>> There is one named array type.
>> The index type is used in the declaration of the array type,
>> stating the set of permissible array index values.
> 
> 
> 
> Again, one can easily define an array container that accepts user 
> defined indexes.

I have not seen one so far, only some handcoded range checking,
which is not the point. Handcoded range checking does not replace
the definition of a type in terms of two other types. Note carefully:
types. Range checking is not the same thing as a type. Neither in
source text read by a human, nor in source text read by a compiler.
Whatever the language is.

In C++ terms:

namespace Adalike {

  template  <typename T, typename Index>
  class vector {
       ...
  };
}

Can you see the essential and important difference?
Just like std::map, Adalike::vector has two (!) non-default
parameters: one for the item type, the other for the index
type. This is the essential difference between std::vector
and Adalike::vector.

The compiler will use the information present in Index
to establish properties of the Adalike::vector type such that
Adalike::vector indexing (an operation) is based on properties
of Index (Index is a type! It is not an algorithm base on min
and max int parameters).

This has something to do with making the base types int, long, etc.
class types. When they are class types, you can invoke their
methods, derive other number types, and then you can use
their interface to build an array that is using the information
provided by int or provided by a type derived from int.

Ada:

   type Year_of_Interest is new Integer range 1815 .. 1914;

   type History is array (Year_of_Interest) of String;


It is not possible to express this using types in C++:

   class Year_of_Interest : int {  // Not C++
     ...
   };

   typedef array<Year_of_Interest, std::string> History;

(Because there is no such thing as array<typename Index, typename T>
in STL afaik. Association is characteristic of map, not of vector
etc. This is different in Ada, where association is readily availably
by associating an index type with an array in an array type
declaration.)


> The philosophical question that arises is *why no one 
> has done it to this day*.

It has been done for associative containers only. It could be done for
array-like containers if C++ had introduced the base types as base
classes.

> However I am going to make such one in some weekend (perhaps this!) to 
> see if I can find any real use of it. Doing it sounds really simple:
> 
> 
> template<class T, const int MIN, const int MAX >

A solution will have this parameterization and checks:

   template<class T, class Index>
> class Array: public vector
> {
>  //  Only provide definitions for operator at() and operator[] that
>  //  really *only* explicitly call the base ones with the proper index.
>  //  And the few constructors doing the same, *only* explicitly passing
>  //  the *same* arguments to the base constructors.
    //   Check indexing precondition Index::contains(v) in at(v) and
    //  operator[](v).
> };

> I think it is *that* simple.

O.K., I'll wait.

> For more diverse things, maps are suitable (I guess in Ada too).

Maps are not needed here, in Ada and other languages supporting
different kinds of arrays. For example, why should I use

   std::map<someEnum, T>,

when I can use something much more efficient to express the
same concept, and still the thing is an array, technically?
In pseudo-C++ terms, Ada *does* provide

   std::valarray<someIndex, T>  (Yes, 2 parameters here!)


>> (Ada-like arrays have STL's key_type so to speak.)

> key_type is used only in maps!

In Ada, key_type *is* used in arrays, because that's a feature
provided by the language.

This is what I'm trying to explain.


Georg

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dr. Adrian Wrigley]

On Fri, 25 Mar 2005 20:37:42 +0100, Georg Bauhaus wrote:

> In C++ terms:
> 
> namespace Adalike {
> 
>   template  <typename T, typename Index>
>   class vector {
>        ...
>   };
> }
> 
> Can you see the essential and important difference?
> Just like std::map, Adalike::vector has two (!) non-default
> parameters: one for the item type, the other for the index
> type. This is the essential difference between std::vector
> and Adalike::vector.
> 
> The compiler will use the information present in Index
> to establish properties of the Adalike::vector type such that
> Adalike::vector indexing (an operation) is based on properties
> of Index (Index is a type! It is not an algorithm base on min
> and max int parameters).
> 
> This has something to do with making the base types int, long, etc.
> class types. When they are class types, you can invoke their
> methods, derive other number types, and then you can use
> their interface to build an array that is using the information
> provided by int or provided by a type derived from int.
> 
> Ada:
> 
>    type Year_of_Interest is new Integer range 1815 .. 1914;
> 
>    type History is array (Year_of_Interest) of String;
> 
> 
> It is not possible to express this using types in C++:
> 
>    class Year_of_Interest : int {  // Not C++
>      ...
>    };
> 
>    typedef array<Year_of_Interest, std::string> History;
> 
> (Because there is no such thing as array<typename Index, typename T>
> in STL afaik. Association is characteristic of map, not of vector
> etc. This is different in Ada, where association is readily availably
> by associating an index type with an array in an array type
> declaration.)
> 
> 
>> The philosophical question that arises is *why no one 
>> has done it to this day*.
> 
> It has been done for associative containers only. It could be done for
> array-like containers if C++ had introduced the base types as base
> classes.

I think this expresses a key aspect quite well.

The C++ FAQ lite has some nice explanations:

http://www.parashift.com/c++-faq-lite/containers.html#faq-34.3

A key point is that C arrays are considered 'evil' to C++ programmers.

C arrays:
1) don't have their subscripts checked
2) often need heap allocation and manual deletion
3) cannot be returned (when 'auto')
4) are rather mixed up with bug-prone pointer based code

Ada arrays almost completely eliminate these issues.  Ada Arrays
are 'good' not 'evil'.  The C++ response was to start again
with completely new (to C) container classes, trying to consign C
arrays to the realms of history.  The problem is that C arrays
are essential to much C++ programming, because of the C libraries
commonly used, and because of obsolescent programming practices.

Curiously, "pointers are evil" and "macros are evil" too, according
to the FAQ.  It's a pity that the evil wasn't destroyed or fixed
in the design of C++.

Ada has successfully (virtually) eliminated the evils of arrays,
pointers, and macros.  The outcome is a language giving less choice
to programmers to use these evil ways.  Maybe a C++ source code
checker (like 'lint') could prohibit the evil(?)  That way, people
would be forced out of old C habits.
-- 
Adrian

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Dr. Adrian Wrigley wrote:

[ ... ]

> I was particularly focusing on large software projects.  These always
> have high levels of resources - perhaps $100m+.  Something like
> a Social Security administration system, or an Air Traffic Control
> system.  The stakeholders really can't afford to have projects
> collapsing at the rate of 50%-70%.

Precisely -- you were originally discussing large projects, but nothing
in what you quoted from Google says it was doing the same. It's
_possible_ they were talking strictly about large, well-funded,
well-managed, (etc.) projects -- but nothing I saw in what you quoted
said or even suggested any such thing.

[ ... ]

> You are saying that the large software projects have a significantly
> lower failure rate?  And this is obvious to those with business
> acumen?  And obvious that the large project's success is independent
> of the language choice?

I'm saying that those that are well funded and carefully managed have
lower failure rates, and yes, I'm reasonably certain this is fairly
obvious. I did not say that the project's success was independent of
the language choice -- I said that in these specific cases, the
language choice was exceptionally unlikely to affect the the outcome.

Language choice is a factor, but is far from the ONLY factor, and in
the overall scheme of things is a relatively minor factor.

> I have not come across any studies that support these "obvious"
> findings.

It seems unlikely to me that you'd find any number of studies, no
matter how explicit the findings, to be convincing.  Just for an
obvious example, Ada advocates like to point out how Boeing chose Ada
for the control systems in the 777. By contrast, Airbus is currently
using the SCADE toolset which is a C IDE (though in fairness, the
programmers do little work directly in C).

Boeing has an extremely large market share, but has recently been
relatively stagnant, and recently seems to have retreated from pushing
the envelope and moving toward relatively small projects (e.g. the
7E7).  Airbus is growing (mostly at Boeing's expense) and working on
some of the largest projects of their type ever contemplated (e.g. the
A380). Looking at safety statistics on the Boeing web site at:
http://www.boeing.com/news/techissues/pdf/statsum.pdf
doesn't seem to show any major problems with reliability or safety in
the Airbus designs (and it hardly seems likely that Boeing would cover
up their competitor's shortcomings).

I'm the last to attribute these facts directly to C vs. Ada, but it
doesn't seem to indicate that using Ada is particularly crucial to
either economic or technical success in this market, which places about
as high an emphasis on reliability as any. I'd also note that SCADE is
routinely used in other high-reliability markets as well, including
other transportation and nuclear plant control.

> Curiously, if the C++ community says language choice is irrelevant
> to project success, but the Ada community says it matters, perhaps
> managers should always hedge their bets by choosing Ada(?)

First of all, I've seen nobody claim that language choice is
irrelevant. Second, I think a claim that choosing language X will
greatly improve chances of success (at least where X is replaced by
either C++ or Ada) says a great deal about the level of zeal vs. sense
in the speaker, and very little about the languages themselves.

In fairness, I should add that in _some_ cases, language choice really
can make a huge difference -- usually when one language is oriented
quite specifically toward the problem at hand. Obvious cases would be
things like databases or symbolic math, where a language aimed
specifically at the problem domain may reduce development time by
orders of magnitude.

> "In one of the few times a manager has performed the same project
> several times using similarly experienced teams but with different
> programming tools, the use of Ada significantly boosted project
> success rates. At SUNY Plattsburgh, Professor John McCormick has
> assigned the same real-time programming project to his class for nine
> years."
>
> "Working in teams of three or four, McCormick's students must write
> 15,000 lines of code to control a system that would need about 150
> switches to operate using hardware alone. In the five years students
> used C, no team completed the project -- even when more than half of
> the code was provided. With Ada, however, half of the teams completed
> the project before any support code had even been written. With some
> support code now provided, three out of four teams finish the
project."

The next time I have a tiny project to be developed by a small team
with no experience, I'll keep this in mind. :-)

> In summary:
> It simply isn't good enough for a language community to claim
> language choice is irrelevant, without giving real-world evidence.
> And why would such a claim attract us to the community?

TTBOMK, nobody has said it's irrelevant -- I've said it's only one of
many factors, and rarely the ultimate determining factor. I, at least,
am attracted to people who make claims that appear to be honest and
reasonable, and mostly repeled by those whose claims seem based more
religious zeal than honesty, intelligence or simply good sense.

[ ... ]

> How come "more expressive" templates, "better exception handling",
> or "less verbose" syntax is not claimed to improve project success?

Other factors _dominate_, but do not _exclude_ language factors.

I don't mean it as an attack on you, but you really do seem _extremely_
prone to treating things as absolutes, and IME absolutes are really
quite rare.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Hyman Rosen]

Dr. Adrian Wrigley wrote:
> It's a pity that the evil wasn't destroyed or fixed
> in the design of C++.

That would have taken the "C" out of C++. It might have
made for a better language, but no one would have used it.
Like Ada :-)

> Maybe a C++ source code checker (like 'lint') could prohibit the evil(?)
 > That way, people would be forced out of old C habits.

Never happen.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Hyman Rosen]

Dr. Adrian Wrigley wrote:
> Or to put it another way:
> How come "more expressive" templates, "better exception handling",
> or "less verbose" syntax is not claimed to improve project success?
> Maybe I (still) don't get it.

To claim improved project success, you have to do some pretty difficult
basic research. Most of us here are programmers, not software engineering
researchers, so most of us at best have only anecdotal evidence. Therefore
when we compare languages we do so from the basis of things that affect us
as programmers.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Hyman Rosen]

> Can I say that the multiplicity of container classes indicates
> somebody didn't think hard enough about how to much a truly
> universal container?

Sure, but you'll sound really dumb.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

jayessay wrote:

[ ... ]

> > A preprocessor per so, no. The type of capabilities is a different
> > story. For example, Lisp includes macros. Most assemblers include
> > (much more extensive) macros as well as an eqiuvalent of C's
> > #if/#ifdef/#ifndef/#endif.
>
> Lisp macros are _not_ a preprocessor and they are _vastly_ more
> capable than what people typically think of when they see/hear
> "macros".  Lisp macros are full code analyzing and generating
> constructs.

I very specifcally said they were not in a preprocessor, and merely
that they provide capabilities similar to those available in the
preprocessor in C++. It's true that they provide considerably more in
addition, but it's more or less beside the point -- which was that Ada
provides substantially less still.

Lisp only came into the conversation at all because it was implied that
the C preprocessor was _so_ unusual that nothing else provided even
vaguely similar capabilities. The substantially more capable Lisp
macros were mentioned only to point out that my comparison was not to
something utterly unique. I certainly did not mean to imply any
particularly strong similarity between C macros and those in Lisp. As
far as that goes, most assemblers have far more macro capability as
well -- but again, it's more or less beside the point.

> Robert Duff made a comment a while ago about how silly most (I would
> say without much hyperbole 99+%) of the points in these threads would
> be to Lisp (and Smalltalk) folks.  I couldn't agree more.

As usualy, I disagree -- and I also use Lisp part of the time, and have
not only used Smalltalk, but written a fairly substantial part of a
Smalltalk implementation.

Then again, I also remember watching/listening to arguments between
people using various flavors of Lisp (before CL came along) about
things like whether it was correct to equate an empty list with
"false". IIRC, I probably used Pascal at the time, and compared to the
differences between FORTRAN IV and Pascal, these differences could have
been seen as quite trivial.

Nonetheless, I didn't and don't see the arguments as silly from either
direction. I see people who have chosen particular areas in which to
pursue their vision of perfection. While I consider it perfectly
reasonable to disagree with them, I hope I never become so
self-satisfied or condescending as to pronounce their concerns or
vision as "silly" or anything like it.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

Hyman Rosen wrote:
>> Can I say that the multiplicity of container classes indicates
>> somebody didn't think hard enough about how to much a truly
>> universal container?
> 
> Sure, but you'll sound really dumb.

My point exactly.  Did you notice I was replying to a guy who
said having five string types suggests Ada is poorly designed?

-- 
Wes Groleau

Expert, n.:
         Someone who comes from out of town and shows slides.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Wes Groleau]

Jerry Coffin wrote:
> The real measure is not the long term cost of a particular program, but
> the long-term cost of carrying out a particular task. Unfortunately,
> that's generally much more difficult to measure, and (worse) attempts
> at measuring it are much less common.

Indeed.  There have been a few times that someone has actually had
an Ada group and a group with another language tackle the same
requirements.  This has not happened enough times for a clear
verdict.  However, I can state that in AKK the (few) cases I am
aware of, Ada was the winner each time.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau/Wes

Re: Teaching new tricks to an old dog (C++ -->Ada)

[adaworks]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> wrote:
>
> A key point is that C arrays are considered 'evil' to C++ programmers.
>
> C arrays:
> 1) don't have their subscripts checked
> 2) often need heap allocation and manual deletion
> 3) cannot be returned (when 'auto')
> 4) are rather mixed up with bug-prone pointer based code
>
And this doesn't even address the issues of multi-dimensional
arrays, which, in Ada, are true multi-dimensional arrays.

      type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
      type Index is range 1..31;
      type TwoDMatrix is array(Day, Index) of Boolean;

      or if you wish,

      type DayVector is array(Day) of Boolean;
      type Month is array(Index) of DayVector;

      and one is not limited to two dimensions for true arrays.

      type ThreeDMatrix is array(1..20,  1..400, 1..2000) of Integer;
      TDM1 : ThreeDMatrix;

      ...

      for TDM1'Range(1)
           loop
                for TDM1'Range(2)
                    loop
                        for TDM1'Range(3)
                             loop
                                 -- Do something to Integer element
                             end loop;
                    end loop;
           end loop;

      where the parenthetical values specify which dimension is being
      evaluated.

      Multi-dimensional array processing in Ada is so easy to do.  Moreover,
      it is easy, no trivial, to create generic templates to take advantage of
      this capability to create portable, generalized, and and easy to use
      generic components.   Easier, I think, than the equivalent capability
      in most other languages, especially C++.

Richard Riehle

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:

> On Thu, 24 Mar 2005 17:59:39 -0500, jayessay wrote:
> 
> ...
> > of _expressive capability_ in either Ada or C++ or Eiffel or ?? is so
> > _low_ that it again is simply amazing to see people so vehemently
> > arguing over differences that are almost invisible.
> 
> *I* think the evidence is now very strong that programming language
> choice *is* massively important for overall success of large projects.

I concur completely.  Those who think otherwise largely fall back on
the old "Turing equivalent" argument which, since all the languages
under discussion are TE, is basically irrelevant.

> The problem is a lack of scientific method in determining this,
> resulting in a big analytical problem with (also massive)
> confounding factors.

This is also true, but it is not something that will likely ever
change due to massive economic reasons.  I suspect you understand this
by your "(..massive) confounding factors" comment.


> one snippet from a Google search:
> "Gartner is now saying 70% of all Java projects so far have failed"
> but only "40% of all projects fail."

One of the problems here is that the vast majority of Java projects
are handled mostly by a horde (colony?) of "code monkeys".
Personally, I think Java sucks, but I don't think you can conclude
much from those stats though.


> and
> "C++ programs typically have roughly six times the lifetime ownership
> costs of equivalent programs written in C, Ada or Fortran, and fewer
> than one third of programming projects begun in C++ are completed."

This is _much_ more believable, but again such stats are intrinsically
suspect.


> Can anybody post links quantifying how much better C++ is than C or
> Ada (in terms of project cost and outcome)?

Sure, but again all these things are either a) toy examples, or b)
completely uncontrolled experiments leading to c) dodgy information.


> Of course I enjoy programming in C/C++ very much, having

C, sure.  C++?  You have my sympathies.


> total debugging time so much shorter in Ada (I've almost

I'm here because I still do follow Ada and cla a bit as I always
thought it was at least reasonbly well thought out.  At the moment I
have the great fortune of using Common Lisp.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

Jared <nowhere@nowhere.nowhere> writes:

> And that is why $YOUR_LANGUAGE should allow arbitrary array indices.
  Or 
> should have all types be anonymous.  Or should use structural type 
> equivalence.  Or should combine data and method declarations for object 
> types.  <Looks around guiltily.>  Or should have a preprocessor.  Or 
> infer all types.  Or whatever.  Just like $MY_LANGUAGE.

I don't buy this total "relativism".  It smacks of the "Turing
equivalent" arguments.


> > Robert Duff made a comment a while ago about how silly most (I would
> > say without much hyperbole 99+%) of the points in these threads would
> > be to Lisp (and Smalltalk) folks.  I couldn't agree more.  You are all
> > arguing over differences that mean almost nothing looked at from these
> > other perspectives.
> 
> This is quite correct, but also largely irrelevant.  The general context 

I suppose you are correct here.  I'm here because I still do follow
(at least in passing) how Ada is doing and what it's followers are up
to.  I try not to get into these things, but the comment from J.Coffin
comparing Lisp macros to a "preprocessor" was too much to ignore.
It's sad really how very little people here have even the ghost of an
idea of what something like Common Lisp is, can provide, and can do.


> of a language flamewar is that every feature $YOUR_LANGUAGE has that
> $MY_LANGUAGE doesn't have is unnecessary, and a clear sign of its
> inferiority.  Any feature $MY_LANGUAGE has that $YOUR_LANGUAGE lacks
> is absolutely essential, and a clear sign of its superiority.

Well, now _that_ is certainly on target.


> A functional language like Lisp lacks many of the features being argued 

Lisp is not really a functional language, though it can be used as
one.  It is very much multiparadigm.


> Yes, a person can do all kinds of neat things in Lisp.  A good programmer 
> can do all kinds of neat things elegantly in any language, and a bad 
> programmer cannot.

This again sounds like a TE argument and so not particularly good.
The key thing aboug Lisp is that it is a programmable programming
language and thus can incorporate at any point any construct from any
language seamlessly and transparently into it.  Does that make it
_necessarily_ superior to anything else?  No - that typically is
heavily context dependent.  But after having analyzed and used all
these "lesser" languages it is clear to me that in _most_ cases it is
definitely superior.  Nobody here is going to believe any of this.
Then again, next to nobody here even has the ghost of a clue about the
facts that would undermine their belief.


> > And the level
> > of _expressive capability_ in
> 
> Aldor?
> 
> > is so
> > _low_ that it again is simply amazing to see people so vehemently
> > arguing over differences that are almost invisible.
> 
> I'm sure you meant expressive convenience.  Turing completeness ensures 

No, I meant expressive capability also called expressivness, or
expressivity.  Turing equivalence is totally irrelevant.  If it had
any meaning in such discussions we would all be toggling in programs
as 1' and 0's at consoles.


> "The sooner we can forget that FORTRAN has ever existed, the better, for 
> as a vehicle of thought it is no longer adequate: it wastes our 
> brainpower, is too risky and therefore too expensive to use."
>  - E.W. Dijkstra, EWD 340
> 
> The arguments being carried on here echo this complaint.  Implicit in the 
> arguments for both sides is that the one wastes brainpower while the 
> other conserves it.  That's fairly important, given that brainpower is 
> the only tool a programmer really has.

Yes, indeed.  This is very on target and is at the heart of the issue.
Which brings us full circle to the point here that the differences
being argued, from the perspective of Lisp (or Smalltalk) are so small
as to be meaningless.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

"Jerry Coffin" <jcoffin@taeus.com> writes:

> jayessay wrote:
> 
> [ ... ]
> 
> > > A preprocessor per so, no. The type of capabilities is a different
> > > story. For example, Lisp includes macros. Most assemblers include
> > > (much more extensive) macros as well as an eqiuvalent of C's
> > > #if/#ifdef/#ifndef/#endif.
> >
> > Lisp macros are _not_ a preprocessor and they are _vastly_ more
> > capable than what people typically think of when they see/hear
> > "macros".  Lisp macros are full code analyzing and generating
> > constructs.
> 
> I very specifcally said they were not in a preprocessor, and merely
> that they provide capabilities similar to those available in the
> preprocessor in C++.

And this is just _completely_ untrue.  Not even close.


> but it's more or less beside the point -- which was that Ada
> provides substantially less still.

While I agree with you on this, I don't really care.


> Lisp only came into the conversation at all because it was implied that
> the C preprocessor was _so_ unusual that nothing else provided even
> vaguely similar capabilities.

Lisp coming into the conversation here is just a _bad_ thing to do.
Not because you are wrong about "preprocessors" being unusual (you're
right - they aren't.), but because you "equate" (in any sense) Lisp
macros as being a "preprocessor".  They aren't.  Indeed due to they
way they are defined they _can't_ be.  And it is this _way_ in which
they are defined that makes them so totally different and _vastly_
more capable.  If you were stupid enough to waste your time doing so,
you could write a C++ compiler _as_ Lisp macros.


> something utterly unique. I certainly did not mean to imply any
> particularly strong similarity between C macros and those in Lisp. As
> far as that goes, most assemblers have far more macro capability as
> well

OK, thanks.  And I agree with the macro assembler comment as well.


> > Robert Duff made a comment a while ago about how silly most (I would
> > say without much hyperbole 99+%) of the points in these threads would
> > be to Lisp (and Smalltalk) folks.  I couldn't agree more.
> 
> As usualy, I disagree -- and I also use Lisp part of the time, and have
> not only used Smalltalk, but written a fairly substantial part of a
> Smalltalk implementation.

Then you don't really understand the fundamental aspect of Lisp.  Just
hacking a line or two of Scheme or even CL is not "using" Lisp.


> Nonetheless, I didn't and don't see the arguments as silly from either
> direction. I see people who have chosen particular areas in which to
> pursue their vision of perfection. While I consider it perfectly
> reasonable to disagree with them, I hope I never become so
> self-satisfied or condescending as to pronounce their concerns or
> vision as "silly" or anything like it.


Too late.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Georg Bauhaus wrote:

>> template<class T, const int MIN, const int MAX >
> 
> 
> A solution will have this parameterization and checks:
> 
>   template<class T, class Index>
> 
>> class Array: public vector
>> {
>>  //  Only provide definitions for operator at() and operator[] that
>>  //  really *only* explicitly call the base ones with the proper index.
>>  //  And the few constructors doing the same, *only* explicitly passing
>>  //  the *same* arguments to the base constructors.
> 
>    //   Check indexing precondition Index::contains(v) in at(v) and
>    //  operator[](v).
> 
>> };
> 
> 
>> I think it is *that* simple.
> 
> 
> O.K., I'll wait.


Unfortunately, I just tried to do it, however I have to use allocators, 
and I do not know allocators yet. It looks like each of my compilers 
uses its own one, different from the others, and when I used 
allocator_type instead I still got errors.


Anyway, this has been my short progress. I could add run-time checks but 
did not proceed since I stuck with allocators.


// Implementation-defined:
// typedef implementation defined iterator; // See 23.1
// typedef implementation defined const_iterator; // See 23.1
// typedef implementation defined size_type; // See 23.1
// typedef implementation defined difference_type;// See 23.1

#include <iostream>

#include <vector>


using namespace std;


template<class T, class A>
class Varray: public std::vector<T>
{
     const A MIN, MAX;

     public:
         explicit Varray(const Allocator &al = Allocator(),
              const A min, const A max): vector<T>(al), MIN(min), 
MAX(max) {}

         explicit Varray(size_type n, const T& value = T(),
         const Allocator &al = Allocator(), const A min, const A max):
             vector(n, value, al), MIN(min), MAX(max) {}

         template <class InputIterator>
         Varray(InputIterator first, InputIterator last,
         const Allocator &al = Allocator(), const A min, const A max):
              vector(first, last, al), MIN(min), MAX(max) {}

         // ==> To be implemented
         Varray(const Varray<T,Allocator>& x){}

         Varray() {}

         // ==> All the following to be implemented
         // Varray<T,Allocator>& operator=(const Varray<T,Allocator>& x) {}
         // template <class InputIterator>
         // void assign(InputIterator first, InputIterator last);
         // void assign(size_type n, const T& u);
         // Allocator get_allocator() const;

  //  Only provide definitions for operator at() and operator[] that
  //  really *only* explicitly call the base ones with the proper index.

  //   Check indexing precondition Index::contains(v) in at(v) and
  //  operator[](v).
};


int main()
{
     using namespace std;
}



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Ioannis Vranos wrote:

> Unfortunately, I just tried to do it, however I have to use allocators, 
> and I do not know allocators yet.


Of course, this does not mean that it can not be done. :-)



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Rendezvous based mutithreading.

[Dmitry A. Kazakov]

On Fri, 25 Mar 2005 19:21:18 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Fri, 25 Mar 2005 13:42:31 +0100, Martin Krischik wrote:
>> 
>>> But I think it would be quite a challenge to create rendezvous based
>>> multithreading on top of C++ templates - and yet keep it easy to use for
>>> the programmer.
>> 
>> We did it in our proprietary C++ library, and without any templates, BTW.
>> The pattern is:
>> 
>> 1. A rendezvous queue type either to derive task objects from or to
>> mix-in. A task periodically polls the queue, it can also wait for a
>> queuing event.
>> 
>> 2. An abstract rendezvous object type to queue. User-defined rendezvous
>> objects were derived from there. When rendezvous happened a virtual method
>> was called.
>> 
>> We supported timed calls, and even a kind of re-queuing to mimic this
>> extremely useful feature of Ada 95.
>> 
>> Of course it is not as easy to use it as Ada's rendezvous, but it is
>> usable and works fine. The advantages rendezvous have over queues are that
>> as in Ada there is no need to marshal parameters here and there, no need
>> in any locks, no problem to have results.
>> 
>> The most difficult problem is exception handling. In Ada, rendezvous
>> exceptions are propagated in both caller and callee. This is impossible to
>> mimic in C++, because there seems no way to throw same-as-this exception
>> in C++. So we had to fuse all exceptions on the caller's side ...
> 
> Cool. Sad that it is not open source.

There is Ada for that!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On Fri, 25 Mar 2005 21:33:36 GMT, Hyman Rosen wrote:

> Dr. Adrian Wrigley wrote:
>> Or to put it another way:
>> How come "more expressive" templates, "better exception handling",
>> or "less verbose" syntax is not claimed to improve project success?
>> Maybe I (still) don't get it.
> 
> To claim improved project success, you have to do some pretty difficult
> basic research. Most of us here are programmers, not software engineering
> researchers, so most of us at best have only anecdotal evidence. Therefore
> when we compare languages we do so from the basis of things that affect us
> as programmers.

Yes, this is of course true.

Yet it is very difficult to find competent C++ programmers. Even people
with years of practical experience are unable to do very basic things
already at the level of *using* a class/template library in a proper way.
To ask them to write reusable code... Then that evil C heritage, I see it
again and again, people doing some quite silly C-ish micro optimizations in
a loop where they create and destroy 10 string objects. It is not a science
it is just psychology...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Jerry Coffin wrote:

> I'm the last to attribute these facts directly to C vs. Ada, but it
> doesn't seem to indicate that using Ada is particularly crucial to
> either economic or technical success in this market, which places about
> as high an emphasis on reliability as any. I'd also note that SCADE is
> routinely used in other high-reliability markets as well, including
> other transportation and nuclear plant control.

You are aware that SCADE supports more then one target programming language? 

http://www.esterel-technologies.com/products/scade-suite/code-generation.html

On the one hand this supports you claim -  If you use SCADE then programming
language is indeed irrelevant.

On the other hand, looking at the code sample I guess no one ever need to do
any editing inside the generated code. I suspect that programming is done
in "SCADE" not C or Ada.

Martin

PS: I find the order they give in there drop-down box quite telling with
SPARK-Ada at the top and Standart C at the bottom while at the same time
all marketing texts say first C then Ada. I supports my suspicion that
languages are more often chosen marketing effort then by actual facts.
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

jayessay wrote:

[ ... ]

> > I very specifcally said they were not in a preprocessor, and merely
> > that they provide capabilities similar to those available in the
> > preprocessor in C++.
>
> And this is just _completely_ untrue.  Not even close.

I see. So what is it that (you incorrectly believe) the C preprocessor
can do that a Lisp macro can't do?

> Lisp coming into the conversation here is just a _bad_ thing to do.
> Not because you are wrong about "preprocessors" being unusual (you're
> right - they aren't.), but because you "equate" (in any sense) Lisp
> macros as being a "preprocessor".

I never made such an "equation" -- if you saw such a thing in what I
said, it's entirely your own delusion.

[ ... ]

> > As usual, I disagree -- and I also use Lisp part of the time, and
> > have not only used Smalltalk, but written a fairly substantial part
> > of a Smalltalk implementation.
>
> Then you don't really understand the fundamental aspect of Lisp.

I wish I was still sufficiently young and inexperienced to draw such
solid conclusions based on such a complete lack of evidence or
knowledge.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Georg Bauhaus wrote:

> Ioannis Vranos wrote:
>> Georg Bauhaus wrote:

>> Again, one can easily define an array container that accepts user
>> defined indexes.
> 
> I have not seen one so far, only some handcoded range checking
> which is not the point.

I have got one:

http://cvs.sourceforge.net/viewcvs.py/adacl/CppCL/Include/AdaArray.H?view=markup

> The compiler will use the information present in Index
> to establish properties of the Adalike::vector type such that
> Adalike::vector indexing (an operation) is based on properties
> of Index (Index is a type! It is not an algorithm base on min
> and max int parameters).
> 
> This has something to do with making the base types int, long, etc.
> class types. When they are class types, you can invoke their
> methods, derive other number types, and then you can use
> their interface to build an array that is using the information
> provided by int or provided by a type derived from int.

That's on my TODO list. Using the following class:

http://cvs.sourceforge.net/viewcvs.py/adacl/CppCL/Include/Ada-Range.hpp?view=markup

Martin

Disclaimer: Both sources might not be in working order - everytime I switch
compiler (IBM C++ -> MS-C++ -> G++) the code need reworking and the switch
to GNU is not finished yet.

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Class hierarchy of exceptions (Ada, C++)

[Ludovic Brenta]

Robert A Duff writes:
> Well, actually, during the Ada 9X design I tried to push for a
> class-hierarchy of exceptions.  I don't like every detail of the way
> C++ does it, but at least in *this* regard, it's better than Ada.
>
> Jerry Coffin is wrong that Ada does not allow attaching information
> to exception, by the way.  Ada allows attaching Strings, which is
> admittedly a kludge.  Using the class-hierarchy, as Jerry advocates,
> would be cleaner, and type safe.

I kind of like Ada exceptions as they are now.  Because one cannot
carry much information in them (apart from the kluge you mentioned),
one tends not to rely on them for the normal flow of operations.  I
have seen Java programs that would rely on exceptions for all kinds of
things, leading to spaghetti code.  In C++ I find it a bit odd that I
can throw and catch an entire hash table as an exception if I want to.

The C++ way of catching all exceptions of a class and its derived
classes can lead to confusion.  One can have multiple exception
handlers for the same exception and it may not be immediately obvious
to the reader which one is called.  I see this as a maintenance
problem.

Another concern of mine with exception classes is that they'd have to
be allocated on the heap.  There are situations where there is no heap
to allocate from, or where dynamic allocation is forbidden.  I think
it necessary to provide a simple exception mechanism that does not
require any dynamic allocation, much less dynamic dispatching.

Perhaps a good middle-ground would be an addition to Ada along the
lines of:

package Ada.Exceptions.Extra is
   type Extra_Information is abstract tagged null record;

   procedure Raise_Exception (E : in Exception_Id;
                              Information : in Extra_Information'Class);

   function Exception_Information (X : Exception_Occurrence)
      return Extra_Information'Class;
end Ada.Exceptions.Extra;

Programs that want to carry rich information with exceptions would be
allowed to do so, while "pragma Restrictions (No_Dispatch)" or
"No_Dynamic_Allocation" would guarantee, to those interested, that no
such thing happens.

I am aware that all this would require the compiler to provide two
exception mechanisms and two kinds of Exception_Occurrences, so I may
have opened a can of worms here.  Just thinking out loud :)

-- 
Ludovic Brenta.

Re: Class hierarchy of exceptions (Ada, C++)

[Dmitry A. Kazakov]

On Sat, 26 Mar 2005 11:19:18 +0100, Ludovic Brenta wrote:

> Robert A Duff writes:
>> Well, actually, during the Ada 9X design I tried to push for a
>> class-hierarchy of exceptions.  I don't like every detail of the way
>> C++ does it, but at least in *this* regard, it's better than Ada.
>>
>> Jerry Coffin is wrong that Ada does not allow attaching information
>> to exception, by the way.  Ada allows attaching Strings, which is
>> admittedly a kludge.  Using the class-hierarchy, as Jerry advocates,
>> would be cleaner, and type safe.
> 
> I kind of like Ada exceptions as they are now.  Because one cannot
> carry much information in them (apart from the kluge you mentioned),
> one tends not to rely on them for the normal flow of operations.  I
> have seen Java programs that would rely on exceptions for all kinds of
> things, leading to spaghetti code.  In C++ I find it a bit odd that I
> can throw and catch an entire hash table as an exception if I want to.
> 
> The C++ way of catching all exceptions of a class and its derived
> classes can lead to confusion.  One can have multiple exception
> handlers for the same exception and it may not be immediately obvious
> to the reader which one is called.  I see this as a maintenance
> problem.
> 
> Another concern of mine with exception classes is that they'd have to
> be allocated on the heap.  There are situations where there is no heap
> to allocate from, or where dynamic allocation is forbidden.  I think
> it necessary to provide a simple exception mechanism that does not
> require any dynamic allocation, much less dynamic dispatching.
> 
> Perhaps a good middle-ground would be an addition to Ada along the
> lines of:
> 
> package Ada.Exceptions.Extra is
>    type Extra_Information is abstract tagged null record;
> 
>    procedure Raise_Exception (E : in Exception_Id;
>                               Information : in Extra_Information'Class);
> 
>    function Exception_Information (X : Exception_Occurrence)
>       return Extra_Information'Class;
> end Ada.Exceptions.Extra;
> 
> Programs that want to carry rich information with exceptions would be
> allowed to do so, while "pragma Restrictions (No_Dispatch)" or
> "No_Dynamic_Allocation" would guarantee, to those interested, that no
> such thing happens.
> 
> I am aware that all this would require the compiler to provide two
> exception mechanisms and two kinds of Exception_Occurrences, so I may
> have opened a can of worms here.

You had. (:-))

>  Just thinking out loud :)

A pair of simple questions:

1. Dispatching to non-existing methods of Extra_Information?

2. Accessibility rules for members of Extra_Information. Technically
Extra_Information is a sort of result value. As such it requires special
handling of all access values (pointers) it may do to local objects.

3. Extra_Information should probably be controlled, what about finalization
rules?

4. Two copies of Extra_Information if the exception was raised in a
rendezvous? Protected type Extra_Information? (protected types are still
untagged)

5. When and where Extra_Information gets deallocated?

I think that before making any detailed proposals we should consider a
contract model of exceptions. Points 1..5 might look very different if
there were exception contracts.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Class hierarchy of exceptions (Ada, C++)

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> On Sat, 26 Mar 2005 11:19:18 +0100, Ludovic Brenta wrote:

>>Perhaps a good middle-ground would be an addition to Ada along the
>>lines of:
>>
>>package Ada.Exceptions.Extra is
>>   type Extra_Information is abstract tagged null record;
>>
>>   procedure Raise_Exception (E : in Exception_Id;
>>                              Information : in Extra_Information'Class);
>>
>>   function Exception_Information (X : Exception_Occurrence)
>>      return Extra_Information'Class;
>>end Ada.Exceptions.Extra;


How about

declare
     ...
     procedure bounce is
     begin
        set_up_information_to_pass;
     end;
begin
    raise with bounce'access;
end;

>>Programs that want to carry rich information with exceptions would be
>>allowed to do so, while "pragma Restrictions (No_Dispatch)" or
>>"No_Dynamic_Allocation" would guarantee, to those interested, that no
>>such thing happens.

> A pair of simple questions:

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Martin Krischik wrote:

[ ... ]

> You are aware that SCADE supports more then one target programming
> language?

Yes, I'm aware that Ada is mentioned in their marketing information,
but looking through several 3rd-party web sites, I haven't been able to
find any mention of anybody ever having actually used this ability. I
was talking specifically about Airbus' use, and looking at:

http://www.esil.univ-mrs.fr/~spc/rcs02/slides/Baufreton.pdf
and:
http://www.systemes-critiques.org/jslc2001_slides/FrancoisXavier_Dormoy.ppt

indicates that they're consistently using C, not Ada. I also mentioned
use in other transport, and if you look at slide 12 of the second link
above, you'll notice where it specifically says this was done with C
code as well.

So far, I've found several references that mention generating C code,
some that don't specify the language, zero that mention having
generated Ada.

> On the one hand this supports you claim -  If you use SCADE then
> programming language is indeed irrelevant.

First of all, I don't recall having made any such claim. What I have
said is that choice of programming language is but one factor among
many, and that I believe it's only rarely the single most important
factor.

Second, this seems to assume that all the code is generated by SCADE,
and none written directly. This does NOT seem to be the case -- if you
look at page 6 of:

http://scilabsoft.inria.fr/events/05_11_03/ESTEREL.pdf

you'll see that they only claim 70% of the code was generated by SCADE.
Given the size of project we're talking about, the remaining 30% is a
_significant_ amount of code. It seems likely to me that if they were
using Ada for the hand-written code, they'd generate Ada as well.

[ ... ]

> PS: I find the order they give in there drop-down box quite telling
> with SPARK-Ada at the top and Standart C at the bottom while at the
> same time all marketing texts say first C then Ada. I supports my
> suspicion that languages are more often chosen marketing effort
> then by actual facts.

Even if we assume that all the references I've found that didn't
specify a programming language were using Ada, it still appears that C
is being used considerably more than Ada.

What I find telling is that somebody is so desparate to find _anything_
to favor their position that they'll read the order of strings in a
listbox as really meaning something -- especially when they're
apparently just in alphabetical order!

I think it's also worth noting that SCADE itself appears to be written
in C++. While they don't specify this directly, the API they supply to
make it programmable is specifically stated as being for C++ (e.g.
http://www.liveware.com.br/pdf/telelogic_scade.pdf
page 23). While they could undoubtedly provide a C++ API from Ada, it
seems most likely to me that if it was written in Ada, use from Ada
would be supported (and mentioned). I'm sure writing in Ada and ONLY
supporting C++ is a theoretical possibility, but it strikes me as quite
unlikely.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

"Jerry Coffin" <jcoffin@taeus.com> writes:

> jayessay wrote:
> 
> [ ... ]
> 
> > > I very specifcally said they were not in a preprocessor, and merely
> > > that they provide capabilities similar to those available in the
> > > preprocessor in C++.
> >
> > And this is just _completely_ untrue.  Not even close.
> 
> I see. So what is it that (you incorrectly believe) the C preprocessor
> can do that a Lisp macro can't do?

Nothing, but then I never indicated otherwise.  The point was (not as
clear as it should have been indicated) that the phrase "they provide
capabilities _similar_ to those available in the preprocessor"
(emphasis added) is wrong.  They don't.  For many reasons.  They are
in no way anything like a preprocessor.


> > Lisp coming into the conversation here is just a _bad_ thing to do.
> > Not because you are wrong about "preprocessors" being unusual (you're
> > right - they aren't.), but because you "equate" (in any sense) Lisp
> > macros as being a "preprocessor".
> 
> I never made such an "equation" -- if you saw such a thing in what I
> said, it's entirely your own delusion.

Yeah right.  You specifically state otherwise in the quote at the
start (please note the "in any sense").


> > > As usual, I disagree -- and I also use Lisp part of the time, and
> > > have not only used Smalltalk, but written a fairly substantial part
> > > of a Smalltalk implementation.
> >
> > Then you don't really understand the fundamental aspect of Lisp.
> 
> I wish I was still sufficiently young and inexperienced to draw such
> solid conclusions based on such a complete lack of evidence or
> knowledge.

You have provided a mass of evidence to support the conclusion.  The
fact that you don't understand this is actually even more evidence.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Class hierarchy of exceptions (Ada, C++)

[Ioannis Vranos]

Ludovic Brenta wrote:

> I kind of like Ada exceptions as they are now.  Because one cannot
> carry much information in them (apart from the kluge you mentioned),
> one tends not to rely on them for the normal flow of operations.  I
> have seen Java programs that would rely on exceptions for all kinds of
> things, leading to spaghetti code.  In C++ I find it a bit odd that I
> can throw and catch an entire hash table as an exception if I want to.


Being able to do whatever you want can certainly cause confusion for 
anyone who is used to be helped how to program.

However, if you know the language, you know what to do and what to not 
do. Also this way is more powerful.


> The C++ way of catching all exceptions of a class and its derived
> classes can lead to confusion.  One can have multiple exception
> handlers for the same exception and it may not be immediately obvious
> to the reader which one is called.  I see this as a maintenance
> problem.


:-) Being able to walk alone can also lead to confusion. Isn't it better 
if you walk with assistance?



> Another concern of mine with exception classes is that they'd have to
> be allocated on the heap. 


No, they do not have to. One can (and in most times does) throw an 
exception object on the stack.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Owen Jacobson]

On Thu, 24 Mar 2005 00:01:20 +0000, adaworks wrote:

> I am suggesting that the code will be less-than obvious to many C++
> programmers. Certainly, after careful study, the experienced C++
> programmer might be able to read your example, but there is room for
> misinterpretation unless one is supplied a fair amount of documentation.

I haven't read this entire thread, but I just paged back up to your Ada
example and read both it and Ioannis' C++ example.  I'm a C++ developer by
trade, and don't know Ada, but, yes, the Ada example was extremely
readable.  So was the C++ example: the intent of both programs was
immediately clear.

This doesn't mean either example is inherently clear, just that a random
passer-by found both of them to be clear.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

jayessay wrote:
> "Jerry Coffin" <jcoffin@taeus.com> writes:
>
> > jayessay wrote:
> >
> > [ ... ]
> >
> > > > I very specifcally said they were not in a preprocessor, and
> > > > merely that they provide capabilities similar to those
> > > > available in the preprocessor in C++.
> > >
> > > And this is just _completely_ untrue.  Not even close.
> >
> > I see. So what is it that (you incorrectly believe) the C
> > preprocessor can do that a Lisp macro can't do?
>
> Nothing, but then I never indicated otherwise.

You clearly don't understand even the simplest logic. Being able to do
all the same things directly implies having similar capabilities.

[ ... ]

> Yeah right.  You specifically state otherwise in the quote at the
> start (please note the "in any sense").

[ ... ]

> You have provided a mass of evidence to support the conclusion.  The
> fact that you don't understand this is actually even more evidence.

100% pure, triple distilled nonsense.

I might be a bit worried by your condemnation, but looking through your
posts elsewhere makes it clear that even on cll you're known primarily
for flaming. e.g.:

http://groups-beta.google.com/group/comp.lang.lisp/msg/a302a7e69b52ca77

My reaction is about the same as theirs: run along now, child.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

"Jerry Coffin" <jcoffin@taeus.com> writes:

> jayessay wrote:
> > "Jerry Coffin" <jcoffin@taeus.com> writes:
> >
> > > jayessay wrote:
> > >
> > > [ ... ]
> > >
> > > > > I very specifcally said they were not in a preprocessor, and
> > > > > merely that they provide capabilities similar to those
> > > > > available in the preprocessor in C++.
> > > >
> > > > And this is just _completely_ untrue.  Not even close.
> > >
> > > I see. So what is it that (you incorrectly believe) the C
> > > preprocessor can do that a Lisp macro can't do?
> >
> > Nothing, but then I never indicated otherwise.
> 
> You clearly don't understand even the simplest logic. Being able to do
> all the same things directly implies having similar capabilities.

You don't understand plain English.  What you are saying is just
irrelevant.


> > You have provided a mass of evidence to support the conclusion.  The
> > fact that you don't understand this is actually even more evidence.
> 
> 100% pure, triple distilled nonsense.

Hardly.  Your problem is simple.  You made an incorrect statement but
for reasons that are beyond me you can't come to grips with that fact.
Your technique here is just to keep reiterating your mistake and
posturing as if you had a clue.  You don't.  And it is becoming
painfully clear.


> posts elsewhere makes it clear that even on cll you're known primarily
> for flaming. e.g.:

Hardly.  But if it soothes your ego to think so, I'm fine with that.
I don't really understand why you are so obsessed with trying to not
come to grips with your mistake here.  It's not as if it's that big a
deal.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Jerry Coffin wrote:

> Martin Krischik wrote:

> So far, I've found several references that mention generating C code,
> some that don't specify the language, zero that mention having
> generated Ada.

IMHO: One of the greatest mistakes Ada using companies do is keep quite
about it. It hurts the language a lot. Of course that means we never know. 

But I am not a dreamer: There will be more C then Ada out there. It's just
the way it is.
 

>> PS: I find the order they give in there drop-down box quite telling
>> with SPARK-Ada at the top and Standart C at the bottom while at the
>> same time all marketing texts say first C then Ada. I supports my
>> suspicion that languages are more often chosen marketing effort
>> then by actual facts.
> 
> Even if we assume that all the references I've found that didn't
> specify a programming language were using Ada, it still appears that C
> is being used considerably more than Ada.

I know :-( . 

> What I find telling is that somebody is so desparate to find _anything_
> to favor their position that they'll read the order of strings in a
> listbox as really meaning something -- especially when they're
> apparently just in alphabetical order!

No, I was making a different point here. You are right: they are
alphabetical and I have overlooked that. But the important part of my
question was: but why didn't marketing use an alphabetical order when
writing the web side?

So my point stands: marketing effort or perhaps "coolness" has more to
influence then actual technical facts. Which I find sad, but is true for as
long I can think back for all sorts of technologies.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Martin Krischik wrote:

> IMHO: One of the greatest mistakes Ada using companies do is keep quite
> about it. It hurts the language a lot. Of course that means we never know. 


The same complaint exists in C++ community, that the companies do not advertise the 
language that they use. :-)


> But I am not a dreamer: There will be more C then Ada out there. It's just
> the way it is.


Well, if it becomes more freely available, no permission from any ministry for making a 
compiler or something is required, I think it can become mainstream. I think it would make 
more sense if Delphi was based on Ada than Object Pascal for example.


> No, I was making a different point here. You are right: they are
> alphabetical and I have overlooked that. But the important part of my
> question was: but why didn't marketing use an alphabetical order when
> writing the web side?


It is about the audience numbers I guess. But trust me this doesn't do any harm in 
reality. As it wouldn't make any difference for C++ if some site mentions a library 
"suitable for Java, Cobol and C++". :-)



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90. If someone finds it 
inconvenient, please let me know].

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Martin Krischik wrote:

[ ... ]

> > What I find telling is that somebody is so desparate to find
> > _anything_ to favor their position that they'll read the order
> > of strings in a listbox as really meaning something --
> >especially when they're apparently just in alphabetical order!
>
> No, I was making a different point here. You are right: they are
> alphabetical and I have overlooked that. But the important part of my
> question was: but why didn't marketing use an alphabetical order when
> writing the web side?

Look at it from their perspective for a moment: why would they?

> So my point stands: marketing effort or perhaps "coolness" has more
> to influence then actual technical facts. Which I find sad, but is
> true for as long I can think back for all sorts of technologies.

Marketing people generally think none of this stuff is even sligtly
"cool" or anything like it. They are influenced very strongly by facts,
but under the circumstances, the facts they care about almost certainly
come from their accounting department. IOW, they emphasize C over Ada
not because they think it's cool but because it makes money.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dmitry A. Kazakov]

On 27 Mar 2005 06:38:30 -0800, Jerry Coffin wrote:

> they emphasize C over Ada
> not because they think it's cool but because it makes money.

Rather they think it would make more money because it is cool ...

----
There is no scientifically strong data about language influence on either
project success or financial success. Though unscientific belief is that
one can sell almost any rubbish.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Martin Krischik]

Jerry Coffin wrote:

> Look at it from their perspective for a moment: why would they?

Indeed why would they :-( .
 
> IOW, they emphasize C over Ada
> not because they think it's cool but because it makes money.

For marketing people that's the same: Cool is only what makes money - but
that does not make the world a better place, don't it.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[adaworks]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1111919334.573846@athnrd02...
>
> Well, if it [Ada] becomes more freely available, no permission from any
ministry for making a
> compiler or something is required, I think it can become mainstream. I think
it would make
> more sense if Delphi was based on Ada than Object Pascal for example.
>
It is rather odd that, after all these years, many people still think Ada is
the property of the U.S. Government.   The Ada Language Reference
Manual contains the specification for the language.  Anyone who wants
to create a compiler is free to do so.   Ada is being used for military
and non-military projects all over the world.   One of the largest military
projects in the world that uses Ada is in Mainland China.  In fact, the
Chinese have created their own Ada compilers.    My book, Ada Distilled,
has been downloaded by people in places such as Oman, Cuba,
Iran, France, Sweden, and many other places.  I'm pretty sure that
any downloading my book is also downloading the GNAT Ada
compiler.

Certain Ada libraries, such as the Common Ada Missiles Package
(CAMP) are classified.  The software written in Ada for weapons
systems is classified.   But the language itself is free for everyone to
use, in any way they wish.

Richard Riehle

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Chad R. Meiners]

Jerry Coffin wrote
> I was talking specifically about Airbus' use, and looking at:
>http://www.esil.univ-mrs.fr/~spc/rcs02/slides/Baufreton.pdf
>and:
>http://www.systemes-critiques.org/jslc2001_slides/FrancoisXavier_Dorm...
>indicates that they're consistently using C, not Ada.

No the slides do not indicate this.  For all we know the project that
the slides are talking about has to target hardware for which there is
only a C compiler.  It could be that Airbus only uses such tools on
such hardware.

Using presentation slides as such an indicator is usually a bad idea.
Presentation slides are made for a specific context, and time frame.
They often lack full and complete information.  The slides don't
explicitly support your claim.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Chad R. Meiners]

Jerry Coffin wrote:

> Second, this seems to assume that all the code is generated by SCADE,
> and none written directly. This does NOT seem to be the case -- if
you
> look at page 6 of:
>http://scilabsoft.inria.fr/events/05_11_03/ESTEREL.pdf
>you'll see that they only claim 70% of the code was generated by
SCADE.
>Given the size of project we're talking about, the remaining 30% is a
>_significant_ amount of code. It seems likely to me that if they were
>using Ada for the hand-written code, they'd generate Ada as well.

First, this nine slide sales pitch doesn't actually mention any
language other than SCADE.  Second, the 70% could have been the user
interface, which communicated with a seperate subsystem that made up
the bulk of the the remaining 30%.  If a language like SCADE can't
generate 95-99% of the code that it needs for a project, it isn't a
very good formal tool.  30% is an aweful lot of room to invalidate any
assurances that SCADE provided about the 70%.  It would be my educated
guess that SCADE was used in a subsystem which represented about 70% of
the total code of the complete system.  Anyway, when you deal with code
generators size is deceptive.  Generated code can be bloated very
easily.

As I mentioned previously, you are jumping to conclusions that are not
supported by your evidence

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Chad R. Meiners]

Jerry Coffin wrote

>You clearly don't understand even the simplest logic. Being able to do
>all the same things directly implies having similar capabilities.

If we were using that destinction, discussing the differences being
Turing-complete languages would be pretty pointless.  That would be the
logical conclusion of what you just said. ;-)

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Hyman Rosen]

Martin Krischik wrote:
> Disclaimer: Both sources might not be in working order - everytime I switch
> compiler (IBM C++ -> MS-C++ -> G++) the code need reworking and the switch
> to GNU is not finished yet.

I looked at Ada Array and immediately found errors
(eg., in 'typename TheIndex const First;' the 'typename'
keyword is not permitted). I suggest you try out your
code on Comeau, God's Own C++ Compiler (they ought to
trademark that phrase :-) It's available on the web at
<http://www.comeaucomputing.com/tryitout/>.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Hyman Rosen]

Jerry Coffin wrote:
> I see. So what is it that (you incorrectly believe) the C preprocessor
> can do that a Lisp macro can't do?

Can Lisp macros manipulate the text of the macro arguments?
For example,

     #define cat1(a, b) a ## b
     #define cat2(a, b) cat1(a, b)

     #define A x
     #define B y
     cat1(A, B) // produces AB
     cat2(A, B) // produces xy

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Hyman Rosen]

Wes Groleau wrote:
> My point exactly.  Did you notice I was replying to a guy who
> said having five string types suggests Ada is poorly designed?

Oops, sorry about that. No, I didn't notice.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Martin Krischik wrote:

[ ... ]

> For marketing people that's the same: Cool is only what makes money -
> but that does not make the world a better place, don't it.

I'd say rather the opposite: a large part of the reason capitalism is
so successful is that there really _is_ a fairly strong correlation
between making money and making the world better -- and no need to
point out the multitudes of exceptions -- I'm aware of them, which is
why I said "fairly strong."

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Chad  R. Meiners wrote:

> > Second, this seems to assume that all the code is generated by
SCADE,
> > and none written directly. This does NOT seem to be the case -- if
> > you look at page 6 of:
> > http://scilabsoft.inria.fr/events/05_11_03/ESTEREL.pdf
> > you'll see that they only claim 70% of the code was generated by
> > SCADE. Given the size of project we're talking about, the remaining
> > 30% is a _significant_ amount of code. It seems likely to me that
if
> > they were using Ada for the hand-written code, they'd generate Ada
> > as well.
>
> First, this nine slide sales pitch doesn't actually mention any
> language other than SCADE.

And so? What part of "it seems likely" don't you understand?

> Second, the 70% could have been the
> user interface, which communicated with a seperate subsystem that
> made up the bulk of the the remaining 30%.

And so? The point is that picking the language for that 70% seems to
take one choice in one list box -- i.e. the most utterly trivial amount
of work possible. With that given, are you honestly suggesting that
it's particularly likely that they'd choose to generate C if they were
planning to write the remainder in Ada?

> If a language like
> SCADE can't generate 95-99% of the code that it needs for a
> project, it isn't a very good formal tool.

I don't recall anybody here having suggested that SCADE is the be-all
and end-all of format tools. OTOH, I have to point out that unless
their claims are flat-out falsehoods, it's been selected by people
you'd expect to be reasonably well-qualified to be used in some
projects that give every appearance of being quite important to those
involved.

> 30% is an aweful lot
> of room to invalidate any assurances that SCADE provided about
> the 70%.  It would be my educated guess that SCADE was used in
> a subsystem which represented about 70% of the total code of
> the complete system.  Anyway, when you deal with code
> generators size is deceptive.  Generated code can be bloated very
> easily.
>
> As I mentioned previously, you are jumping to conclusions that are
not
> supported by your evidence

I drew exactly two conclusions: 1) that 100% minus 70% leaves 30%, and
2) that these _seem_ to be sufficiently large projects that 30% of them
still constitutes a substantial amount of code.

Since you claim that my conclusions (plural) are unsupported by the
evidence, and I only drew two conclusions to start with, your claim
must apply to both. So, let's start with the first: please expound on
your form of math in which 100 minus 70 doesn't equal 30.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Dave Thompson]

On 21 Mar 2005 16:00:23 -0500, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

> azdo_b@yahoo.es (Alberto) writes:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<1lr611thktbau$.1dj95z21h7l5v.dlg@40tude.net>...
<snip>
> > > 2. C++ is unable to allocate objects of indefinite size on the stack.
> > 
> > Well, we have alloca() for this ;)
> 
> Is alloca part of the C++ standard?  I thought not, but I could be
> wrong.  Anyway, alloca doesn't really do all that Ada can do in this

No, nor standard C either.

> regard (avoiding heap usage for dynamic-sized things).  In this case,
> the Ada feature is both more efficient and safer than alloca.
> 
Where available, alloca does allocate on the stack. AFAICS this can
do, at a lower/less-safe level, everything Ada can do at function
scope. It can't do allocation _and deallocation_ for a block within a
function, nor cross-function like function-return-unconstrained. It
almost has to be special-cased/inlined so it should be efficient.


- David.Thompson1 at worldnet.att.net

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Paul Mensonides]

Hyman Rosen wrote:
> Jerry Coffin wrote:
>> I see. So what is it that (you incorrectly believe) the C
>> preprocessor can do that a Lisp macro can't do?
>
> Can Lisp macros manipulate the text of the macro arguments?
> For example,
>
>     #define cat1(a, b) a ## b
>     #define cat2(a, b) cat1(a, b)
>
>     #define A x
>     #define B y
>     cat1(A, B) // produces AB
>     cat2(A, B) // produces xy

Lisp macros cannot produce partial syntax either, whereas C/C++ macros can (e.g. 
on macro can create a '{' and another separate invocation can create the closing 
'}').  In the general case (obviously) Lisp (and Scheme) macros are far more 
powerful than C/C++ macros.

As an aside, given suitable input, it is possible to create a compiler or 
interpreter with the C/C++ preprocessor--with a relatively small number of 
macros.

Jerry is correct to say that they do similar things--they parametize code with 
code.  The main differences is that in Lisp (etc.) their are syntactic 
constraints (which is both good and bad in various scenarios) and that Lisp 
executes in an environment (even when compiled) that can interpret code created 
at runtime.

Regards,
Paul Mensonides

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Chad  R. Meiners wrote:
> Jerry Coffin wrote
> > I was talking specifically about Airbus' use, and looking at:
> >http://www.esil.univ-mrs.fr/~spc/rcs02/slides/Baufreton.pdf
> >and:
>
>http://www.systemes-critiques.org/jslc2001_slides/FrancoisXavier_Dorm...
> >indicates that they're consistently using C, not Ada.
>
> No the slides do not indicate this.  For all we know the project that
> the slides are talking about has to target hardware for which there
> is only a C compiler.  It could be that Airbus only uses such tools
> on such hardware.

First of all, at least in my dictionary, "indicate" is defined with
words like "points to" and "suggests", NOT "proves" or anything very
similar.

Second, I have to wonder whether you really have a good idea of the
size of project we're talking about. Just for example, Airbus is
currently working on the A350, which is fairly based fairly closely on
the A340, to the point that it's expected to share a common type rating
with the 340 (meaning as far as flying them goes, they're considered
the same plane).

Despite that derivation, the A350 is expected to take about 6 years and
cost (at least) 3,500,000,000 Euros to develop. Developing an entirely
new plane runs in the vicinity of twice that.

This leads to two points: first of all, neither Airbus nor anybody else
is designing hundreds or even dozens of these at a time -- IOW, knowing
what they're doing in only one or two projects really _does_ tell you a
lot about what the company as a whole is doing, and for an extended
period of time at that.

Second, unless porting Ada compilers is a LOT more expensive than
porting C++ compilers, pre-existing availability of a particular
compiler is NOT much of a consideration for this size of project. Just
for the sake of argument, let's assume a compiler port costs a half
million US dollars. If you figure that up in terms of how time spent on
the project, it comes to a matter of hours -- i.e. the compiler port
would only have to save them a couple of hours overall to pay for
itself.

Now, it's certainly true that software alone doesn't account for nearly
all the expenditure -- but it's significant enough to figure in the
same basic terms. The compiler might have to save a whole day to pay
for itself, but almost certainly would not have to save (say) a whole
month to pay off.

> Using presentation slides as such an indicator is usually a bad idea.
> Presentation slides are made for a specific context, and time frame.
> They often lack full and complete information.  The slides don't
> explicitly support your claim.

I'll openly admit that the slides don't absolutely _prove_ nearly as
much as we'd like to know. They're generally vague, lacking detail,
definition or rigor -- but despite that they still constitute roughly
95% of the hard evidence presented so far in this entire thread!

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Chad  R. Meiners wrote:
> Jerry Coffin wrote
>
> >You clearly don't understand even the simplest logic. Being able to
> >do all the same things directly implies having similar capabilities.
>
> If we were using that destinction, discussing the differences being
> Turing-complete languages would be pretty pointless.  That would be
> the logical conclusion of what you just said. ;-)

If I ever teach a class, anybody who tries to abuse Turing completeness
like this will be requird to write his entire treatise on the
blackboard several times as punishment.

Turing's theorem shows, in essence, that a programming language can
implement any algorithm, but that's about it.

If you look at the percentage of a typical program that's devoted
strictly to implementing the fundamental algorithms, you'll quickly
realize that this is FAR from the entire set of capabilities of a real
language.

I should also point out that while C++'s templates are Turing complete,
C's macros are not, so Turing completeness is clearly misplaced as a
consideration here.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: Class hierarchy of exceptions (Ada, C++)

[Ludovic Brenta]

"Dmitry A. Kazakov" writes:
> Ludovic Brentawrites:
[...]
>> package Ada.Exceptions.Extra is
>>    type Extra_Information is abstract tagged null record;
>> 
>>    procedure Raise_Exception (E : in Exception_Id;
>>                               Information : in Extra_Information'Class);
>> 
>>    function Exception_Information (X : Exception_Occurrence)
>>       return Extra_Information'Class;
>> end Ada.Exceptions.Extra;
[...]

> A pair of simple questions:
>
> 1. Dispatching to non-existing methods of Extra_Information?

You'd have to "down-cast", which would raise Constraint_Error if the
Extra_Information was not of the expected type.

> 2. Accessibility rules for members of Extra_Information. Technically
> Extra_Information is a sort of result value. As such it requires special
> handling of all access values (pointers) it may do to local objects.

I would say that the actual type (that extends Exra_Information) must
be visible in the exception handler and at the point of
Raise_Exception.

> 3. Extra_Information should probably be controlled, what about
> finalization rules?

I hadn't thought about that.  For the mechanism to be useful, I
suppose that finalization would have to occur at the end of the
exception handler.  However it may not be desirable that
Extra_Information be controlled, as this would make it possible for
Deallocate to raise an exception.

> 4. Two copies of Extra_Information if the exception was raised in a
> rendezvous? Protected type Extra_Information? (protected types are
> still untagged)

The Extra_Information doesn't have to be protected, it can contain an
access to a protected object.  This would make it quite easy to raise
two copies of it in two tasks.

> 5. When and where Extra_Information gets deallocated?

I would say, at the end of the last exception handler (i.e. the one
that doesn't reraise the exception).

> I think that before making any detailed proposals we should consider a
> contract model of exceptions. Points 1..5 might look very different if
> there were exception contracts.

What do you have in mind?

-- 
Ludovic Brenta.

Re: Class hierarchy of exceptions (Ada, C++)

[Ludovic Brenta]

Georg Bauhaus writes:
> How about
>
> declare
>      ...
>      procedure bounce is
>      begin
>         set_up_information_to_pass;
>      end;
> begin
>     raise with bounce'access;
> end;

You mean that the "Extra_Information" I was contemplating would be
replaced with an access-to-procedure, and the exception handler would
be free to call the procedure?

Maybe this would address Dmitry's concerns about accessibility and
finalization.  The existing accessibility rules are quite clear on
what procedure Bounce can see, and also prevent passing an access to
it to places where Bounce does not exist.

Your proposal is quite interesting.

-- 
Ludovic Brenta.

Re: Class hierarchy of exceptions (Ada, C++)

[Ludovic Brenta]

Ioannis Vranos writes:
> Ludovic Brenta wrote:
>
>> I kind of like Ada exceptions as they are now.  Because one cannot
>> carry much information in them (apart from the kluge you
>> mentioned), one tends not to rely on them for the normal flow of
>> operations.  I have seen Java programs that would rely on
>> exceptions for all kinds of things, leading to spaghetti code.  In
>> C++ I find it a bit odd that I can throw and catch an entire hash
>> table as an exception if I want to.
>
>
> Being able to do whatever you want can certainly cause confusion for
> anyone who is used to be helped how to program.
>
> However, if you know the language, you know what to do and what to
> not do. Also this way is more powerful.

Ah, that same old argument again.  I don't know about you; you may be
the Perfect Programmer Who Knows What They're Doing, in which case I
don't know excactly why you are even condescending to read mere
mortals' babbling.  As for me, I have been programming in 10 languages
or so for 15 years, and I still appreciate all the help I can get.  In
fact, the more experience I get, the more I appreciate it.

But my point was not just about being helped; it was also about the
mathematical purity of the concept of exceptions.  If an exception can
be anything at all, then what is so exceptional about it?  I'm not
entirely decided on this point (being a mere engineer and not a
mathematician), I'm just uneasy at the thought, and I remember
badly-written programs I've seen before.

Pascal Obry once made an interesting remark: what is important for the
safety of a language is not what it allows but what it forbids.

>> The C++ way of catching all exceptions of a class and its derived
>> classes can lead to confusion.  One can have multiple exception
>> handlers for the same exception and it may not be immediately
>> obvious to the reader which one is called.  I see this as a
>> maintenance problem.
>
>
> :-) Being able to walk alone can also lead to confusion. Isn't it
> better if you walk with assistance?

Ah but *I* am the one assisting people, not to walk but to fly
aircraft.  To some extent, they depend on me for their lives, and I
take that seriously.  So, yes, as a program maintainer, I appreciate
any and all help, assurance and guarantees I can get.

A C++ program that throws a Window or a Button object or a
Database_Connection object violates the Law of Least Astonishment.  If
I read C++ code, I must be prepared to see such things happen, and be
astonished.  If I read Ada code, I know that this cannot happen, so I
can move on to more interesting considerations.

>> Another concern of mine with exception classes is that they'd have
>> to be allocated on the heap.
>
>
> No, they do not have to. One can (and in most times does) throw an
> exception object on the stack.

Please explain.  I am not a compiler writer, and I fail to understand
how the compiler can allocate on the stack, and then propagate the
exception up the stack.

-- 
Ludovic Brenta.

Re: Class hierarchy of exceptions (Ada, C++)

[Ioannis Vranos]

Ludovic Brenta wrote:

> But my point was not just about being helped; it was also about the
> mathematical purity of the concept of exceptions.  If an exception can
> be anything at all, then what is so exceptional about it?

As a means of error handling.



> Pascal Obry once made an interesting remark: what is important for the
> safety of a language is not what it allows but what it forbids.


You can't protect a bad programmer from doing bad programming, unless you forbid him to 
continue programming. :-)


> Ah but *I* am the one assisting people, not to walk but to fly
> aircraft.  To some extent, they depend on me for their lives, and I
> take that seriously.  So, yes, as a program maintainer, I appreciate
> any and all help, assurance and guarantees I can get.


So if you like to be as much constrained as possible, I think VB is much better for this. 
Or even Logo. Plus it provides a turtle to help you.


> A C++ program that throws a Window or a Button object or a
> Database_Connection object violates the Law of Least Astonishment.  If
> I read C++ code, I must be prepared to see such things happen, and be
> astonished.



I have never seen code that throws a button as an exception, although it is feasible to do 
that. The language is supposed to provide some protection from accidental mistakes, not 
from intentional coding or irrational minds.


> Please explain.  I am not a compiler writer, and I fail to understand
> how the compiler can allocate on the stack, and then propagate the
> exception up the stack.


#include <iostream>


class SomeException: public std::exception
{
     const char *errorMessage;

     public:
         SomeException(const char *error):errorMessage(error) {}

         const char *what( ) const throw()
         {
             return errorMessage;
         }
};


int main() try
{
     throw SomeException("Something is wrong!");
}


catch(std::exception &e)
{
     std::cerr<<e.what()<<"\n";
}


C:\c>temp
Something is wrong!

C:\c>



The exception gets copied as it is propagated up to the stack (with the use of the copy 
constructor). I am not a compiler writer either.


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as: 
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

Re: Class hierarchy of exceptions (Ada, C++)

[Ludovic Brenta]

Ioannis Vranos writes:
> So if you like to be as much constrained as possible, I think VB is
> much better for this. Or even Logo. Plus it provides a turtle to
> help you.

Ah yes, embedded, real-time, certified Logo :)  Come on.

> #include <iostream>
>
>
> class SomeException: public std::exception
> {
>      const char *errorMessage;
>
>      public:
>          SomeException(const char *error):errorMessage(error) {}
>
>          const char *what( ) const throw()
>          {
>              return errorMessage;
>          }
> };
>
>
> int main() try

            ^
Isn't there a missing { here?

> {
>      throw SomeException("Something is wrong!");
> }
>
>
> catch(std::exception &e)
> {
>      std::cerr<<e.what()<<"\n";
> }

And a missing } here?  In which case I don't see any propagation of
your exception up the stack, as there is only one stack frame.

> C:\c>temp
> Something is wrong!
>
> C:\c>
>
>
>
> The exception gets copied as it is propagated up to the stack (with
> the use of the copy constructor). I am not a compiler writer either.

Since you don't provide a copy constructor, only a shallow copy takes
place.  Where is the message string allocated, and how do you know it
is still accessible when you catch the exception in a location remote
from the throw statement?

Also, copying the exception once for each stack frame seems quite
inefficient to me.  I doubt that compiler writers would do that,
especially in the general case of C++ where the exception object can
be arbitrarily large.

-- 
Ludovic Brenta.

Re: Class hierarchy of exceptions (Ada, C++)

[Dmitry A. Kazakov]

On Mon, 28 Mar 2005 12:24:56 +0200, Ludovic Brenta wrote:

> "Dmitry A. Kazakov" writes:
>> Ludovic Brentawrites:
> [...]
>>> package Ada.Exceptions.Extra is
>>>    type Extra_Information is abstract tagged null record;
>>> 
>>>    procedure Raise_Exception (E : in Exception_Id;
>>>                               Information : in Extra_Information'Class);
>>> 
>>>    function Exception_Information (X : Exception_Occurrence)
>>>       return Extra_Information'Class;
>>> end Ada.Exceptions.Extra;
> [...]
> 
>> A pair of simple questions:
>>
>> 1. Dispatching to non-existing methods of Extra_Information?
> 
> You'd have to "down-cast", which would raise Constraint_Error if the
> Extra_Information was not of the expected type.

What if Extra_Information is extended:

type My_Extra_Information is new Extra_Information with private;
procedure Say (Info : My_Extra_Information);

At some non-library level Say gets overridden. Then this new object is
attached to an exception which is propagated out of the scope of the
override. A handler then makes a dispatching call to Say. What happens?

One possible solution is to force the attached object to the base class
when the child type gets out of scope. But then things become even more
interesting, because Say might be abstract! Then object need to be
partially finalized etc. That would be quite sort of C++! (:-))

Another solution is to route the exception to Program_Error when anything
from My_Extra_Information gets out of scope. This would be bullet proof,
but I don't believe many would enjoy it.

>> 2. Accessibility rules for members of Extra_Information. Technically
>> Extra_Information is a sort of result value. As such it requires special
>> handling of all access values (pointers) it may do to local objects.
> 
> I would say that the actual type (that extends Exra_Information) must
> be visible in the exception handler and at the point of
> Raise_Exception.

But how would you check it? The exception handler knows nothing about any
derived types. Yet it can dispatch ... to something that no more exists.

>> 3. Extra_Information should probably be controlled, what about
>> finalization rules?
> 
> I hadn't thought about that.  For the mechanism to be useful, I
> suppose that finalization would have to occur at the end of the
> exception handler.

I thought about controlled components and pointers to controlled objects.
They may get out of scope before a handler catches the exception.

> However it may not be desirable that
> Extra_Information be controlled, as this would make it possible for
> Deallocate to raise an exception.

>> 4. Two copies of Extra_Information if the exception was raised in a
>> rendezvous? Protected type Extra_Information? (protected types are
>> still untagged)
> 
> The Extra_Information doesn't have to be protected, it can contain an
> access to a protected object.  This would make it quite easy to raise
> two copies of it in two tasks.

Also it will be two copies of Extra_Information? I definitely do not like
it. This would mean that the behavior will vary depending on where
exception was raised.

I do prefer present by-value semantics of Ada model. But if it gets
extended, and the direction is tagged types, then that is another
semantics: tagged types are by-reference. The only possible logical
consequence of this is that user-defined exception objects have to be
protected.

>> 5. When and where Extra_Information gets deallocated?
> 
> I would say, at the end of the last exception handler (i.e. the one
> that doesn't reraise the exception).

OK that means that the mechanics will be pretty inefficient. Upon
Raise_Exception, the object will always be copied.

>> I think that before making any detailed proposals we should consider a
>> contract model of exceptions. Points 1..5 might look very different if
>> there were exception contracts.
> 
> What do you have in mind?

Let's consider a model based on [sub]types. If there are exception
contracts then all possible exception types are known in each handler
context. If you don't allow open-end things like exception'Class in
contracts then there is nothing to surprise you in any handler. OK, that
would probably be too rigid. We could relax it by allowing classes
constrained to ranges of types: sort of

type E1 is new exception with ...;
...
type EN is new EN-1 with ...;

procedure Foo
   exception E1'Class (EN) | Constraint_Error | ...;

or

procedure Foo
   exception E1..EN | Constraint_Error | ...;

The point is that Foo knows what it will raise, the handler knows if the
body may call Foo. Further Foo cannot raise anything defined within Foo.
Same is applicable to any scope. If I try

declare
   My_Exception is new exception;
begin
   ...
end;

Then I'll get compile error telling that My_Exception may propagate out of
the scope.

declare
   My_Exception is new exception;
   Old_Style_Exception : exception; -- That's OK, no new type here
begin
   ...
exception
   when My_Exception =>
       ... -- Alright now
end;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Class hierarchy of exceptions (Ada, C++)

[Ioannis Vranos]

Ludovic Brenta wrote:

>>int main() try
> 
> 
>             ^
> Isn't there a missing { here?


No.

> 
> 
>>{
>>     throw SomeException("Something is wrong!");
>>}
>>
>>
>>catch(std::exception &e)
>>{
>>     std::cerr<<e.what()<<"\n";
>>}
> 
> 
> And a missing } here?  In which case I don't see any propagation of
> your exception up the stack, as there is only one stack frame.


The code is ISO C++ compliant as it is. The exception on the stack works in whatever stack 
depth as far as the copy constructor is accessible (exists and is public).


> Since you don't provide a copy constructor, only a shallow copy takes
> place.


Which is the copying of the pointer value.


>  Where is the message string allocated, and how do you know it
> is still accessible when you catch the exception in a location remote
> from the throw statement?


The string literal exists in an implementation defined space and is guaranteed to be 
accessible as long as it gets accessed.


> Also, copying the exception once for each stack frame seems quite
> inefficient to me.  I doubt that compiler writers would do that,
> especially in the general case of C++ where the exception object can
> be arbitrarily large.


Yes the compiler writers are free and do optimise this. However the copy constructor is 
required to be accessible for those who do not optimise it.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as: 
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Dave Thompson wrote:

> Where available, alloca does allocate on the stack. AFAICS this can
> do, at a lower/less-safe level, everything Ada can do at function
> scope. It can't do allocation _and deallocation_ for a block within a
> function, nor cross-function like function-return-unconstrained. It
> almost has to be special-cased/inlined so it should be efficient.


In C++ you can always do:

#include <new>


class SomeClass
{
};


void somefunc()
{
     unsigned char obj[sizeof(SomeClass)];

     SomeClass *p= new(obj)SomeClass;

     delete p;
}


as also:


#include <new>


class SomeClass
{
};


SomeClass *somefunc()
{
     static unsigned char obj[sizeof(SomeClass)];

     return new(obj)SomeClass;
}


int main()
{
     SomeClass *p= somefunc();

     delete p;
}


Here the object is created in the stack.


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as: 
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1112022773.497341@athnrd02...
> In C++ you can always do:
>
> #include <new>
>
>
> class SomeClass
> {
> };
>
>
> void somefunc()
> {
>      unsigned char obj[sizeof(SomeClass)];
>
>      SomeClass *p= new(obj)SomeClass;
>
>      delete p;
> }
>
>
> as also:
>
>
> #include <new>
>
>
> class SomeClass
> {
> };
>
>
> SomeClass *somefunc()
> {
>      static unsigned char obj[sizeof(SomeClass)];
>
>      return new(obj)SomeClass;
> }
>
>
> int main()
> {
>      SomeClass *p= somefunc();
>
>      delete p;
> }
>
>
> Here the object is created in the stack.
>
>
> -- 
> Ioannis Vranos
>
These will mostly fail on systems with alignment constraints (SPARC, PPC,
etc.).

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Ioannis Vranos wrote:

> In C++ you can always do:
> 
> #include <new>
> 
> 
> class SomeClass
> {
> };
> 
> 
> void somefunc()
> {
>     unsigned char obj[sizeof(SomeClass)];
> 
>     SomeClass *p= new(obj)SomeClass;
> 
>     delete p;
> }
> 
> 
> as also:
> 
> 
> #include <new>
> 
> 
> class SomeClass
> {
> };
> 
> 
> SomeClass *somefunc()
> {
>     static unsigned char obj[sizeof(SomeClass)];
> 
>     return new(obj)SomeClass;
> }
> 
> 
> int main()
> {
>     SomeClass *p= somefunc();
> 
>     delete p;
> }
> 
> 
> Here the object is created in the stack.


Of course, one can also do:

#include <iostream>
#include <new>


class SomeClassA
{
     int array[1024];
};

class SomeClassB
{
     public:
         SomeClassB() { std::cout<<"Constructor called!\n"; }
         ~SomeClassB() { std::cout<<"Destructor called!\n"; }
};


void somefunc()
{
     SomeClassA objA;

     SomeClassB *p= new(&objA) SomeClassB;

     delete p;
}



int main()
{
     somefunc();
}


corrupting objA in this way and invoking undefined behaviour.

But C++ is an enabling language, and not a prohibiting language. You can really do 
whatever you want, and provides some protection from accidental mistakes only, and not 
from intentional coding.




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as: 
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

Re: Class hierarchy of exceptions (Ada, C++)

[Pascal Obry]

Ioannis Vranos <ivr@remove.this.grad.com> writes:

> > Pascal Obry once made an interesting remark: what is important for the
> > safety of a language is not what it allows but what it forbids.
> 
> 
> You can't protect a bad programmer from doing bad programming, unless you
> forbid him to continue programming. :-)

But you can propose a easy path that is safer. In this case there is lot of
more chance than the programmer will choose it. Easier is always appreciated :)
And a language must make it harder to do unsafe thing, like deallocation on
Ada. You have a instanciate Unchecked_Deallocation. The meaning is clear and
nobody can do that without noticing.

As Ludovic I appreciate a lot the help of the compiler and never try to fight
it. If it tells me there is something wrong I really have to have a look and
yes I'm building using all the warnings and checks on. I even have all the
GNAT style checks activated.

I don't want a language that let me do the same thing with hundredth ways among
which there is only one safe path. I'm not a gamer, fiddling with a piece of
code hours to find the good way is not what I'm looking for :)

> So if you like to be as much constrained as possible, I think VB is much
> better for this. Or even Logo. Plus it provides a turtle to help you.

You are really trying hard to fail to understand. All this is a trade off. We
all need lot of power (what VB or Logo won't give to us) but the power must be
*controlled* and it must come with a well defined *semantic*.

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

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

REH wrote:

> These will mostly fail on systems with alignment constraints (SPARC, PPC,
> etc.).

Why?


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as: 
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

Re: Class hierarchy of exceptions (Ada, C++)

[Ioannis Vranos]

Pascal Obry wrote:

> But you can propose a easy path that is safer. In this case there is lot of
> more chance than the programmer will choose it. Easier is always appreciated :)
> And a language must make it harder to do unsafe thing, like deallocation on
> Ada. You have a instanciate Unchecked_Deallocation. The meaning is clear and
> nobody can do that without noticing.
> 
> As Ludovic I appreciate a lot the help of the compiler and never try to fight
> it. If it tells me there is something wrong I really have to have a look and
> yes I'm building using all the warnings and checks on. I even have all the
> GNAT style checks activated.
> 
> I don't want a language that let me do the same thing with hundredth ways among
> which there is only one safe path. I'm not a gamer, fiddling with a piece of
> code hours to find the good way is not what I'm looking for :)
> 
> 
>>So if you like to be as much constrained as possible, I think VB is much
>>better for this. Or even Logo. Plus it provides a turtle to help you.
> 
> 
> You are really trying hard to fail to understand. All this is a trade off. We
> all need lot of power (what VB or Logo won't give to us) but the power must be
> *controlled* and it must come with a well defined *semantic*.


Actually most compilers provide warnings for lots of stuff and provide an option to 
display all warnings (e.g. /Wall), even comparison between signed and unsigned integers 
generates a warning. And they can also treat all warnings as *errors* if you specify so.

However the default is to display warnings for anything that is not required by the 
standard to be treated as an error, and compile it.


In most cases, one fixes *all* warnings. However there *are* some cases where the 
programmer knows better.

C++ is enabling by default, which I suppose is the opposite direction of Ada, and that's 
why I think we can't understand one another. :-)


C++ being less restrictive as the default, doesn't mean a compiler does not generate lots 
of warnings!



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as: 
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

Re: Class hierarchy of exceptions (Ada, C++)

[Ioannis Vranos]

Ioannis Vranos wrote:

> Actually most compilers provide warnings for lots of stuff and provide 
> an option to display all warnings (e.g. /Wall), even comparison between 
> signed and unsigned integers generates a warning. And they can also 
> treat all warnings as *errors* if you specify so.
> 
> However the default is to display warnings for anything that is not 
> required by the standard to be treated as an error, and compile it.
> 
> 
> In most cases, one fixes *all* warnings. However there *are* some cases 
> where the programmer knows better.
> 
> C++ is enabling by default, which I suppose is the opposite direction of 
> Ada, and that's why I think we can't understand one another. :-)
> 
> 
> C++ being less restrictive as the default, doesn't mean a compiler does 
> not generate lots of warnings!


An example. First compile with the default behaviour, then with all warnings turned on:

int main()
{
     int i=0;

     unsigned j=4;

     j<i;
}


C:\c>g++ temp.cpp -o temp.exe

C:\c>g++ -Wall temp.cpp -o temp.exe
temp.cpp: In function `int main()':
temp.cpp:7: warning: comparison between signed and unsigned integer expressions
temp.cpp:7: warning: statement has no effect

C:\c>




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as: 
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1112026376.920221@athnrd02...
> REH wrote:
>
> > These will mostly fail on systems with alignment constraints (SPARC,
PPC,
> > etc.).
>
> Why?
>
>
> -- 

Well, suppose your class contains a variable of type double, which on some
systems is 8 bytes and requires 8 byte alignment.  The array you are
defining to hold the class is a character array, which only requires 1 byte
alignment.  If it is created with a 1 byte alignment, when you create the
class in it using placement new, now the double is misaligned.  When you
access it nasty things can happen.  Intel processors can handled misaligned
variables, but take extra clock cycles to do so.  On a SPARC or PowerPC, you
will throw a hardware exception (segmentation fault or machine check most
likely).  A way around this problem is to either 1) make an array of
doubles, 2) union the array with a double, or 3) allocate from the heap.

REH

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1112022773.497341@athnrd02...
> In C++ you can always do:
>
> #include <new>
>
>
> class SomeClass
> {
> };
>
>
> void somefunc()
> {
>      unsigned char obj[sizeof(SomeClass)];
>
>      SomeClass *p= new(obj)SomeClass;
>
>      delete p;
> }
>
>
> as also:
>
>
> #include <new>
>
>
> class SomeClass
> {
> };
>
>
> SomeClass *somefunc()
> {
>      static unsigned char obj[sizeof(SomeClass)];
>
>      return new(obj)SomeClass;
> }
>
>
> int main()
> {
>      SomeClass *p= somefunc();
>
>      delete p;
> }
>
>
> Here the object is created in the stack.
>
Another problem with this is you cannot use delete on a pointer returned
from placement new.  You must instead call the destructor directly:
p->~SomeClass();

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Larry Kilgallen]

In article <d29c80$mpp3@cui1.lmms.lmco.com>, "REH" <bogus@nowhere.net> writes:
> 
> "Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
> news:1112026376.920221@athnrd02...
>> REH wrote:
>>
>> > These will mostly fail on systems with alignment constraints (SPARC,
> PPC,
>> > etc.).
>>
>> Why?
>>
>>
>> -- 
> 
> Well, suppose your class contains a variable of type double, which on some
> systems is 8 bytes and requires 8 byte alignment.  The array you are
> defining to hold the class is a character array, which only requires 1 byte
> alignment.  If it is created with a 1 byte alignment, when you create the
> class in it using placement new, now the double is misaligned.  When you
> access it nasty things can happen.  Intel processors can handled misaligned
> variables, but take extra clock cycles to do so.  On a SPARC or PowerPC, you
> will throw a hardware exception (segmentation fault or machine check most
> likely).  A way around this problem is to either 1) make an array of
> doubles, 2) union the array with a double, or 3) allocate from the heap.

This can depend on the operating system.

On Alpha (and I presume on Itanium) VMS catches such exceptions and fixes
them up.  It slows things down, but the result is still correct.

Re: Class hierarchy of exceptions (Ada, C++)

[Tapio Kelloniemi]

Ioannis Vranos <ivr@remove.this.grad.com> wrote:
>Ioannis Vranos wrote:
>
>> Actually most compilers provide warnings for lots of stuff and provide
>> an option to display all warnings (e.g. /Wall), even comparison between
>> signed and unsigned integers generates a warning. And they can also
>> treat all warnings as *errors* if you specify so.
>>
>> However the default is to display warnings for anything that is not
>> required by the standard to be treated as an error, and compile it.
>>
>>
>> In most cases, one fixes *all* warnings. However there *are* some cases
>> where the programmer knows better.
>>
>> C++ is enabling by default, which I suppose is the opposite direction of
>> Ada, and that's why I think we can't understand one another. :-)
>>
>>
>> C++ being less restrictive as the default, doesn't mean a compiler does
>> not generate lots of warnings!

The question is not only about compiler warnings or errors. Ada (as a
language) has been designed so that it is possible for the
compiler to check many mistakes which may cause bad results at run time.
Ada also makes it easier for the user to notice this kind of errors.
For example:

procedure X is

   type Metres is new Natural;
   type Seconds is new Natural;

   M : Metrses := 0;
   S : Seconds := 10;
begin
   if M < S then --  Error, < is not defined for these types
      ...
   end if;
end X;

This is a bit more verbose than using pure int instead of Metres and
Seconds, but if I wanted a C++ compiler to check this kind of error, I'm
afread that the resulting C++ code would be much more verbose.

Such mistakes as using a pointer to nothing and writing past the array
bounds don't often happen in Ada.

>An example. First compile with the default behaviour, then with all warnings tu
>rned on:
>
>int main()
>{
>     int i=0;
>
>     unsigned j=4;
>
>     j<i;
>}

procedure Temp is
   I : Integer := 0;
   J : Natural := 4;
begin
   I < J;
end Temp;

Without any warnings:
# gnatmake temp
gcc -c temp.adb
temp.adb:5:05: missing ":="
gnatmake: "temp.adb" compilation error

Notice how the language prevents doing useless things.

If a replace I < J; with null; the result is:
gcc -c -gnatg temp.adb
temp.adb:2:04: warning: "I" is not modified, could be declared constant
temp.adb:2:04: warning: variable "I" is not referenced
temp.adb:3:04: warning: "J" is not modified, could be declared constant
temp.adb:3:04: warning: variable "J" is not referenced
gnatmake: "temp.adb" compilation error

-- 
Tapio

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

REH wrote:

> Well, suppose your class contains a variable of type double, which on some
> systems is 8 bytes and requires 8 byte alignment.  The array you are
> defining to hold the class is a character array, which only requires 1 byte
> alignment.  If it is created with a 1 byte alignment, when you create the
> class in it using placement new, now the double is misaligned.


But we can treat a double variable as a sequence of unsigned chars/plain chars plus copy 
it byte by byte (char/unsigned char) to a new unsigned char/char sequence and have an 
exact working copy of the original. So since we can do this for stand alone 
doubles/sequences of doubles, then why can't we do this in the double contained in a class 
case?



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

REH wrote:

> Another problem with this is you cannot use delete on a pointer returned
> from placement new.  You must instead call the destructor directly:
> p->~SomeClass();


However in TC++PL 3, on page 576, there is a version of delete for placement new and 
delete[] for placement new[]:


"void *operator new(size_t, void *p) throw() { return p; } // placement (10.4.11)
  void operator delete(void *p, void *) throw() { }
  void *operator new[](size_t, void *p) throw() { return p; }
  void operator delete[](void *p, void *) throw() { }"



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1112034544.645999@athnrd02...
> REH wrote:
>
> > Well, suppose your class contains a variable of type double, which on
some
> > systems is 8 bytes and requires 8 byte alignment.  The array you are
> > defining to hold the class is a character array, which only requires 1
byte
> > alignment.  If it is created with a 1 byte alignment, when you create
the
> > class in it using placement new, now the double is misaligned.
>
>
> But we can treat a double variable as a sequence of unsigned chars/plain
chars plus copy
> it byte by byte (char/unsigned char) to a new unsigned char/char sequence
and have an
> exact working copy of the original. So since we can do this for stand
alone
> doubles/sequences of doubles, then why can't we do this in the double
contained in a class
> case?
>
I never said you couldn't.  I was just pointing out that what you wrote was
not portable, and would not work for any arbitrary class.  Besides, why
would you incur the extra time and complexity of manually moving the data
back and forth, byte-by-byte instead of just insuring the correct alignment
and letting the compiler take care of it?

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1112035652.831337@athnrd02...
> REH wrote:
>
> > Another problem with this is you cannot use delete on a pointer returned
> > from placement new.  You must instead call the destructor directly:
> > p->~SomeClass();
>
>
> However in TC++PL 3, on page 576, there is a version of delete for
placement new and
> delete[] for placement new[]:
>
>
> "void *operator new(size_t, void *p) throw() { return p; } // placement
(10.4.11)
>   void operator delete(void *p, void *) throw() { }
>   void *operator new[](size_t, void *p) throw() { return p; }
>   void operator delete[](void *p, void *) throw() { }"
>
OK, that's news to me.  But how does the compiler know to call this version
of delete just from:

delete p;

?

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

REH wrote:

>>But we can treat a double variable as a sequence of unsigned chars/plain
> 
> chars plus copy
> 
>>it byte by byte (char/unsigned char) to a new unsigned char/char sequence
> 
> and have an
> 
>>exact working copy of the original. So since we can do this for stand
> 
> alone
> 
>>doubles/sequences of doubles, then why can't we do this in the double
> 
> contained in a class
> 
>>case?
>>
> 
> I never said you couldn't.


What I meant, is that the above is a safe and portable operation to do. It is guaranteed 
by the standard.


>  I was just pointing out that what you wrote was
> not portable, and would not work for any arbitrary class.  Besides, why
> would you incur the extra time and complexity of manually moving the data
> back and forth, byte-by-byte instead of just insuring the correct alignment
> and letting the compiler take care of it?


This question can be rephrased to: "Why is memcpy() needed?".



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

REH wrote:

> OK, that's news to me.  But how does the compiler know to call this version
> of delete just from:
> 
> delete p;
> 
> ?


Forget what I said, it looks like I am wrong, and you are right:

http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.10



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Ioannis Vranos wrote:

> REH wrote:
> 
>> OK, that's news to me.  But how does the compiler know to call this 
>> version
>> of delete just from:
>>
>> delete p;
>>
>> ?
> 
> 
> 
> Forget what I said, it looks like I am wrong, and you are right:
> 
> http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.10


The default delete operators provided and accompany the default placement operators new, 
perform no action.






-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1112039976.169686@athnrd02...

> >  I was just pointing out that what you wrote was
> > not portable, and would not work for any arbitrary class.  Besides, why
> > would you incur the extra time and complexity of manually moving the
data
> > back and forth, byte-by-byte instead of just insuring the correct
alignment
> > and letting the compiler take care of it?
>
>
> This question can be rephrased to: "Why is memcpy() needed?".
>
>
>
> -- 
No, it is not about whether memcpy() is a necessary function.  You purposely
over simplified what I did.  I don't want to appear rude, but your whole
statement about moving a double byte-by-byte to avoid alignment issues is
just nonsense.  You didn't take portability into account when you wrote the
snippets of code using placement new, and now you wish to backpedal.  You
really are not going to convince me that you intended write all your classes
to copy all the bytes of variables with alignment needs greater than one,
instead of just fixing the alignment.  Do you really expect my to believe
you would write:

struct foo {
    foo(double d) : m_dbl(d) {}
    double get() const
    {
        double tmp;
        memcpy(&tmp, &m_dbl, sizeof(tmp));
        return tmp;
    }

private:
    double m_dbl;
}

char buf[sizeof(foo)];

foo* pf = new(buf) foo();
double d = pf->get();


instead of:

struct foo {
    foo(double d) : m_dbl(d) {}
    double get() const {return m_dbl;}

private:
    double m_dbl;
}

union data_type {
    double align;
    char buf[sizeof(foo)];
} data;

foo* pf = new(data.buf) foo();
double d = pf->get();

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

Hyman Rosen <hyrosen@mail.com> writes:

> Jerry Coffin wrote:
> > I see. So what is it that (you incorrectly believe) the C preprocessor
> > can do that a Lisp macro can't do?
> 
> Can Lisp macros manipulate the text of the macro arguments?

They don't manipulate text at all, but they _do_ manipulate the
_un_evaluated forms passed to them.

Here is a "top 5" list of why Lisp macros aren't anything like C
preprocessor stuff.  At the bottom I give an example.



Top five reasons why Lisp macros are not similar to the C/C++
preprocessor in any meaningful sense.


Number 5:

The/a cpp is a, well, preprocessor.  Typically a separate program
even.  While you could dilute the meaning here to the point where a
compiler is a preprocessor for a linker is a processor for a loader is
a preprocessor for a cpu etc., the typical meaning is that such things
perform minor transformations on a block of input and had the result
to the primary processor.

Lisp macros are tightly bound up with both the definition of the total
language and any implmentation of it.  Also expansion time is
interwoven with compilation, interpretation, or explicit evaluation.
They are available and can be defined during any phase: compile, load,
and execute/runtime.


Number 4:

The/a cpp is not Turing complete.

Lisp macros are Turing complete.


Number 3:

The/a cpp processes text, typically from a text stream such as (most
typically) a text file.

Lisp macros process _data structures_.  In particular the syntax trees
output from the parser.  Text is long gone before macros are involved
at all.


Number 2:

The/a cpp doesn't know or have any access to the full language, user
defined functions, or its environment.

Lisp macros are just Lisp functions which can make use of the entire
language, and any other user defined functions and macros in libraries
or the running image.  They also have access to their lexical
environment information (such as type and profile information) as well
as any public aspects of the global system/application.


And the Number 1 reason why Lisp macros are not similar to the C/C++
preprocessor in any meaningful sense:

Jerry Coffin thinks they are.


;-) and just to make sure :-) :-)


-----------------------------

The astute reader will have noticed that it is C++ _templates_ which
are slighly similar to Lisp macros.  And they would be right.
Templates are significantly less expressive and mind numbingly painful
to use in comparison, but they are Turing complete and you can do some
interesting things with them.

For example, while it might take several pages of code, I think it is
_physically_ possible (i.e., humanly doable not just theoretically
doable) to achieve the (somewhat contrived) following example with
templates.  Note: I don't see how you can do this _in_ Ada at all.


Allow a user/programmer to define a dictionary like object while
ensuring at compile time that the size of the table implementing it is
a prime number.



(defun small-primep (n)
  (and (< 0 n most-positive-fixnum)
       (the-primes :from n :to n)))


(deftype prime () `(and integer (satisfies small-primep)))


(defmacro define-dictionary
  ((name &key (size 101) (test #'eql) (hash #'sxhash)) &body body)
  (assert (symbolp name) nil
          "Dictionary names must be symbols.  ~A is of type ~A"
          name (type-of name))
  (assert (typep size 'prime) nil
          (prime-failure-message size name))
  `(defvar ,name
     ,(if body
          `(let ((it (make-hash-table
                       :test ,test :size ,size :hash-function ,hash)))
             ,@(mapcar #'(lambda (p)
                           `(setf (gethash ,(car p) it) ,(cdr p)))
                       body)
             it)
        `(make-hash-table
          :test ,test :size ,size :hash-function ,hash))))


(defun prime-failure-message (n name)
  (concatenate
   'string
   (format nil "Dictionary ~A: " name)
   (cond
    ((not (integerp n))
     (format nil "~A of type ~A is not a number" n (type-of n)))
    ((< n 0)
     (format nil "~A < 0; Dictionary sizes must > 0 and prime numbers" n))
    ((> n most-positive-fixnum)
     (format nil "Dictionary sizes must be prime numbers < ~A"
             most-positive-fixnum))
    (t
     (format nil "~A is not prime; Next prime larger than ~A is ~A"
             n n (first (the-primes :from n :to (+ 1000 n))))))))


At _compile_ time

(define-dictionary (foo :size 20))

produces:

Error: Dictionary FOO: 20 is not prime; Next prime larger than 20 is 23


(define-dictionary (foo :size 23)
  (1 . "one")
  (2 . "two")
  (3 . "three"))

Compiles, passes checks and produces the dictionary with the given entries.
This generates the following code:

(DEFVAR FOO
    (LET ((IT (MAKE-HASH-TABLE
                :TEST #<Function EQL>
                :SIZE 23
                :HASH-FUNCTION #<Function SXHASH>)))
     (SETF (GETHASH 1 IT) "one")
     (SETF (GETHASH 2 IT) "two")
     (SETF (GETHASH 3 IT) "three")
    IT))


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

REH wrote:

> No, it is not about whether memcpy() is a necessary function.  You purposely
> over simplified what I did.  I don't want to appear rude, but your whole
> statement about moving a double byte-by-byte to avoid alignment issues is
> just nonsense.


My point was that we can create objects in a low level way like that.



 > You didn't take portability into account when you wrote the
> snippets of code using placement new, and now you wish to backpedal.


I considered them to be portable (apart from the non-explicit call of destructors mistake).



>  You
> really are not going to convince me that you intended write all your classes
> to copy all the bytes of variables with alignment needs greater than one,
> instead of just fixing the alignment.
 >
>  Do you really expect my to believe
> you would write:
> 
> struct foo {
>     foo(double d) : m_dbl(d) {}
>     double get() const
>     {
>         double tmp;
>         memcpy(&tmp, &m_dbl, sizeof(tmp));
>         return tmp;
>     }
> 
> private:
>     double m_dbl;
> }
> 
> char buf[sizeof(foo)];
> 
> foo* pf = new(buf) foo();
> double d = pf->get();
> 
> 
> instead of:
> 
> struct foo {
>     foo(double d) : m_dbl(d) {}
>     double get() const {return m_dbl;}
> 
> private:
>     double m_dbl;
> }
> 
> union data_type {
>     double align;
>     char buf[sizeof(foo)];
> } data;
> 
> foo* pf = new(data.buf) foo();
> double d = pf->get();



Yes the first one is also always guaranteed to work. In summary, the standard guarantees 
that you can read *any* POD type as a sequence of chars/unsigned chars and copy them to a 
new char/unsigned char array and you will have an exact, working copy of the original 
*POD* type.

For non-POD types, you can only read them as sequences of unsigned chars only, but if you 
copy them it is *not* guaranteed that you will have either exact or working copies of the 
original.

No alignment is mentioned about this anywhere.


Now this means, that strictly speaking my code with the class having the defined 
constructor and destructor is not portable since is a non-POD type, and thus should not 
had used it in clc++, since strict theoretical portability is important in here.


However the following code *is* portable:


#include <iostream>
#include <cstring>

class SomeClass
{
     public:

     double d;
     int i;
     float f;
     long l;
};


int main()
{
     using namespace std;

     unsigned char array[sizeof(SomeClass)];

     SomeClass obj= {1, 2, 3, 4};

     memcpy(array, &obj, sizeof(obj));

     SomeClass *p= reinterpret_cast<SomeClass *>(array);

     cout<<p->d<<" "<<p->i<<" "<<p->f<<" "<<p->l<<"\n";
}


C:\c>temp
1 2 3 4

C:\c>


So since this is *guaranteed* to be portable, why this isn't?


#include <iostream>
#include <cstring>

class SomeClass
{
     public:

     double d;
     int i;
     float f;
     long l;
};


int main()
{
     using namespace std;

     unsigned char array[sizeof(SomeClass)];

     SomeClass obj= {1, 2, 3, 4};

     SomeClass *p= new(array)SomeClass(obj);

     cout<<p->d<<" "<<p->i<<" "<<p->f<<" "<<p->l<<"\n";
}


C:\c>temp
1 2 3 4

C:\c>


-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

"Paul Mensonides" <leavings@comcast.net> writes:

> Hyman Rosen wrote:
> > Jerry Coffin wrote:
> >> I see. So what is it that (you incorrectly believe) the C
> >> preprocessor can do that a Lisp macro can't do?
> >
> > Can Lisp macros manipulate the text of the macro arguments?

You use _reader_ macros for that sort of thing.


> Lisp macros cannot produce partial syntax either, whereas C/C++
> macros can (e.g.  on macro can create a '{' and another separate
> invocation can create the closing '}').

Again, that would be the sort of thing you would use reader macros.
It's worth noting again that Lisp macros (the kind you generally mean
when unqualified) do not work on text, they work on the syntax trees
passed to them.


> Jerry is correct to say that they do similar things--they parametize
> code with code.

But that is not really what they do.  It is _one_ thing you can _use_
them to do.


>  The main differences is that in Lisp (etc.) their

I think the main differences are the ones I listed.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[REH]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1112045099.679682@athnrd02...

> However the following code *is* portable:
>
>
> #include <iostream>
> #include <cstring>
>
> class SomeClass
> {
>      public:
>
>      double d;
>      int i;
>      float f;
>      long l;
> };
>
>
> int main()
> {
>      using namespace std;
>
>      unsigned char array[sizeof(SomeClass)];
>
>      SomeClass obj= {1, 2, 3, 4};
>
>      memcpy(array, &obj, sizeof(obj));
>
>      SomeClass *p= reinterpret_cast<SomeClass *>(array);
>
>      cout<<p->d<<" "<<p->i<<" "<<p->f<<" "<<p->l<<"\n";
> }
>
>
> C:\c>temp
> 1 2 3 4
>
> C:\c>
>
>
> So since this is *guaranteed* to be portable, why this isn't?
>
>
> #include <iostream>
> #include <cstring>
>
> class SomeClass
> {
>      public:
>
>      double d;
>      int i;
>      float f;
>      long l;
> };
>
>
> int main()
> {
>      using namespace std;
>
>      unsigned char array[sizeof(SomeClass)];
>
>      SomeClass obj= {1, 2, 3, 4};
>
>      SomeClass *p= new(array)SomeClass(obj);
>
>      cout<<p->d<<" "<<p->i<<" "<<p->f<<" "<<p->l<<"\n";
> }
>
>
> C:\c>temp
> 1 2 3 4
>
> C:\c>
>
>
> -- 
> Ioannis Vranos
>
No, NEITHER is portable!  That both have alignment issues!  Both exihibit
undefined behavior.  Show me where in the standard is says you may cast a
pointer to a char array to a pointer of any other type (other than another
signed/unsigned char*) and access it.  You do this on a system that cannot
handle misaligned accesses, and your program will most likely crash!

Re: Class hierarchy of exceptions (Ada, C++)

[Ludovic Brenta]

Tapio Kelloniemi writes:
> If a replace I < J; with null; the result is:
> gcc -c -gnatg temp.adb
> temp.adb:2:04: warning: "I" is not modified, could be declared constant
> temp.adb:2:04: warning: variable "I" is not referenced
> temp.adb:3:04: warning: "J" is not modified, could be declared constant
> temp.adb:3:04: warning: variable "J" is not referenced
> gnatmake: "temp.adb" compilation error

This is an excellent example of the power of GNAT.  I think this would
deserve more publicity in future presentations of the language and of
GNAT.

-- 
Ludovic Brenta.

Re: Class hierarchy of exceptions (Ada, C++)

[Randy Brukardt]

"Ludovic Brenta" <ludovic.brenta@insalien.org> wrote in message
news:87oed6wvyx.fsf_-_@insalien.org...
...
> The C++ way of catching all exceptions of a class and its derived
> classes can lead to confusion.  One can have multiple exception
> handlers for the same exception and it may not be immediately obvious
> to the reader which one is called.  I see this as a maintenance
> problem.

If Ada had some sort of exception classes, there certainly would be a
overlapping handler check. Having two different handlers for any possible
exeception would be prohibited (it certainly is now). So I don't find this
much a reason for not having this capability. The reasons for not having it
are finalization, memory allocation, and compatibility with Ada 83 & Ada 95.
(And mainly that the person working on it ran out of energy for it, and no
one else picked it up.)

                         Randy.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Chad R. Meiners]

Jerry Coffin wrote:

> And so? What part of "it seems likely" don't you understand?

I was commenting that the slides you quoted were irrelevant to your
comment

> It seems likely to me that if
> they were using Ada for the hand-written code, they'd generate Ada
> as well.

I would appreciate if did resort to begging the question when
responding.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Chad R. Meiners]

Jerry Coffin wrote:

> If I ever teach a class,

If you teach a class the way you argue in newsgroups, your students
would not approve.  You would frustrate them because you would be
putting words in their mouth and insulting them instead of listening to
what they are saying, and you would be ignoring arguments that show you
are error instead of admitting error and going back to find the truth.

> anybody who tries to abuse Turing completeness like this

I haven't abused the definition of Turing completeness.  I was making
as comment how your statement

> >You clearly don't understand even the simplest logic. Being able to
> >do all the same things directly implies having similar capabilities.


didn't address what Jayessay was talking about.

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

REH wrote:

>>#include <iostream>
>>#include <cstring>
>>
>>class SomeClass
>>{
>>     public:
>>
>>     double d;
>>     int i;
>>     float f;
>>     long l;
>>};
>>
>>
>>int main()
>>{
>>     using namespace std;
>>
>>     unsigned char array[sizeof(SomeClass)];
>>
>>     SomeClass obj= {1, 2, 3, 4};
>>
>>     memcpy(array, &obj, sizeof(obj));
>>
>>     SomeClass *p= reinterpret_cast<SomeClass *>(array);
>>
>>     cout<<p->d<<" "<<p->i<<" "<<p->f<<" "<<p->l<<"\n";
>>}
>>
>>
>>C:\c>temp
>>1 2 3 4
>>
>>C:\c>
>>
>>
>>So since this is *guaranteed* to be portable, why this isn't?
>>
>>
>>#include <iostream>
>>#include <cstring>
>>
>>class SomeClass
>>{
>>     public:
>>
>>     double d;
>>     int i;
>>     float f;
>>     long l;
>>};
>>
>>
>>int main()
>>{
>>     using namespace std;
>>
>>     unsigned char array[sizeof(SomeClass)];
>>
>>     SomeClass obj= {1, 2, 3, 4};
>>
>>     SomeClass *p= new(array)SomeClass(obj);
>>
>>     cout<<p->d<<" "<<p->i<<" "<<p->f<<" "<<p->l<<"\n";
>>}
>>
>>
>>C:\c>temp
>>1 2 3 4
>>
>>C:\c>
>>
>>
>>-- 
>>Ioannis Vranos
>>
> 
> No, NEITHER is portable!  That both have alignment issues!  Both exihibit
> undefined behavior.  Show me where in the standard is says you may cast a
> pointer to a char array to a pointer of any other type (other than another
> signed/unsigned char*) and access it.  You do this on a system that cannot
> handle misaligned accesses, and your program will most likely crash!



Perhaps you are right. If you have the standard, have a look at 3.9-2, 3.9-4, and 3.9-5 
which I think agrees with you.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: Class hierarchy of exceptions (Ada, C++)

[Jean-Pierre Rosen]

Ludovic Brenta a �crit :
> Pascal Obry once made an interesting remark: what is important for the
> safety of a language is not what it allows but what it forbids.
> 
Actually, I think he borrowed it from my "pensees" web page (sorry, it 
is in French) at http://www.adalog.fr/publicat/pensees.htm)


-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

C++ language support.

[Martin Krischik]

Hyman Rosen wrote:

> Martin Krischik wrote:
>> Disclaimer: Both sources might not be in working order - everytime I
>> switch compiler (IBM C++ -> MS-C++ -> G++) the code need reworking and
>> the switch to GNU is not finished yet.
 
> I looked at Ada Array and immediately found errors
> (eg., in 'typename TheIndex const First;' the 'typename'
> keyword is not permitted).

I know the code is full of problem zones and I think I fixed that in
"Ada::Range" allready. The sad thing is that it did compile with one
compiler and it won't with the next.

The last fix I did was "throw ( ... )" - IBM accepts it. MS even warns you
about missing features if you try anthing else. 

The GNU compiler immediately moaned about it. I checked the ISO standard and
hey "throw ( ... )" isn't part of the ISO standart. You never stop
learning!

So I changed to "throw ( std::exeption )" knowing that this will result in
warnings in MS-C++ (and splint and pc-lint for that matter).

> I suggest you try out your 
> code on Comeau, God's Own C++ Compiler (they ought to
> trademark that phrase :-) It's available on the web at
> <http://www.comeaucomputing.com/tryitout/>.

I try that after I got a working GNU version. 

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: C++ language support.

[Alf P. Steinbach]

* Martin Krischik:
> 
> The last fix I did was "throw ( ... )" - IBM accepts it. MS even warns you
> about missing features if you try anthing else. 

"throw (...)" is not standard C++ syntax.

 
> The GNU compiler immediately moaned about it. I checked the ISO standard and
> hey "throw ( ... )" isn't part of the ISO standart. You never stop
> learning!
> 
> So I changed to "throw ( std::exeption )" knowing that this will result in
> warnings in MS-C++ (and splint and pc-lint for that matter).

Why not "throw std::exception();", or, if you're rethrowing, "throw;".

Btw., could you Ada folks please stop spouting new disconnected threads or
else at least indicate wherever the hell your postings originated, perhaps
also with a note mentioning the crossposting.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Alex R. Mosteo]

Pascal Obry wrote:
> Ioannis Vranos <ivr@remove.this.grad.com> writes:
> 
> 
>>Now may you explain how the ability to use negative subranges for built in
>>array indices makes Ada better for any domain problem?
> 
> 
> For a domain problem where you have to create an area centered on (0,0)
> for example. What about a vector representing altitude, the sub-zero values
> being under the water. Just some examples, I bet you'll be able to think about
> lot more :)

One classical example is solving the eight queens problem. There's an 
elegant solution using arrays with ranges starting at several values.

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Paul Mensonides]

jayessay wrote:
> Hyman Rosen <hyrosen@mail.com> writes:
>
>> Jerry Coffin wrote:
>>> I see. So what is it that (you incorrectly believe) the C
>>> preprocessor can do that a Lisp macro can't do?
>>
>> Can Lisp macros manipulate the text of the macro arguments?
>
> They don't manipulate text at all, but they _do_ manipulate the
> _un_evaluated forms passed to them.
>
> Here is a "top 5" list of why Lisp macros aren't anything like C
> preprocessor stuff.  At the bottom I give an example.

Nobody said that the mechanisms are equivalent.  Lisp macros are like C/C++ 
macros in a pretty major way: they parametize code with code.

> Number 5:
>
> The/a cpp is a, well, preprocessor.  Typically a separate program
> even.  While you could dilute the meaning here to the point where a
> compiler is a preprocessor for a linker is a processor for a loader is
> a preprocessor for a cpu etc., the typical meaning is that such things
> perform minor transformations on a block of input and had the result
> to the primary processor.
>
> Lisp macros are tightly bound up with both the definition of the total
> language and any implmentation of it.  Also expansion time is
> interwoven with compilation, interpretation, or explicit evaluation.
> They are available and can be defined during any phase: compile, load,
> and execute/runtime.

So what?  Where and when they can be evaluated doesn't mean that the mechanisms 
are totally dissimilar.

> Number 4:
>
> The/a cpp is not Turing complete.

Yes it is.

> Number 3:
>
> The/a cpp processes text, typically from a text stream such as (most
> typically) a text file.

No, a C or C++ preprocessor processes tokens, not text.

> Lisp macros process _data structures_.  In particular the syntax trees
> output from the parser.  Text is long gone before macros are involved
> at all.

So what?  A syntax tree is code, as is source code text.

> Number 2:
>
> The/a cpp doesn't know or have any access to the full language, user
> defined functions, or its environment.

So what?  This is the same thing as your fifth reason.  When or where it can be 
evaluated doesn't change what it does.

> Lisp macros are just Lisp functions which can make use of the entire
> language, and any other user defined functions and macros in libraries
> or the running image.  They also have access to their lexical
> environment information (such as type and profile information) as well
> as any public aspects of the global system/application.

Again, so what?  There is no doubt that Lisp macros are superior to C/C++ macros 
in most categories.  However, that doesn't change what they fundamentally do: 
parametize code with code.

> -----------------------------
>
> The astute reader will have noticed that it is C++ _templates_ which
> are slighly similar to Lisp macros.  And they would be right.
> Templates are significantly less expressive and mind numbingly painful
> to use in comparison, but they are Turing complete and you can do some
> interesting things with them.

C++ templates are similar to Lisp macros also, but C/C++ macros are much closer. 
The template mechanism parametizes code with types (primarily) and only 
indirectly parametizes code with code.

To reiterate: nobody has said that C/C++ macros are as powerful as Lisp or 
Scheme macros.  However, despite everything you say, Lisp and Scheme macros 
parametize code with code--regardless of when or where that can happen.  That is 
the same capability that C/C++ macros have.  Does Lisp do it better?  Yes.  Does 
Scheme do it better still?  Yes.  Neither of those answers precludes the 
similarity in what the mechanisms do, nor do any of your reasons.

Regards,
Paul Mensonides

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Paul Mensonides]

jayessay wrote:
> "Paul Mensonides" <leavings@comcast.net> writes:

>> Lisp macros cannot produce partial syntax either, whereas C/C++
>> macros can (e.g.  on macro can create a '{' and another separate
>> invocation can create the closing '}').
>
> Again, that would be the sort of thing you would use reader macros.
> It's worth noting again that Lisp macros (the kind you generally mean
> when unqualified) do not work on text, they work on the syntax trees
> passed to them.

Neither do macros in C or C++.  They operate on tokens.  In any case, the 
difference is meaningless.  The only thing that matters is what the semantics 
are (such as name binding).  Lisp macros are easily inferior to Scheme macros in 
that sense.

>> Jerry is correct to say that they do similar things--they parametize
>> code with code.
>
> But that is not really what they do.  It is _one_ thing you can _use_
> them to do.

That is exactly what they do.  It is irrelevant whether that code is in the form 
of a syntax tree or not.  The kind of thing that you seem to be referring to is 
what Haskell does instead.

>>  The main differences is that in Lisp (etc.) their
>
> I think the main differences are the ones I listed.

Obviously.

Regards,
Paul Mensonides

Re: Class hierarchy of exceptions (Ada, C++)

[Florian Weimer]

* Ludovic Brenta:

>> int main() try
>
>             ^
> Isn't there a missing { here?

No, although this particular syntax is usually used for constructors
only.

Re: C++ language support.

[Martin Krischik]

Alf P. Steinbach wrote:

> * Martin Krischik:
>> 
>> The last fix I did was "throw ( ... )" - IBM accepts it. MS even warns
>> you about missing features if you try anthing else.

> "throw (...)" is not standard C++ syntax.

I did say that a few lines later. It's actually down there is the quote:

>> The GNU compiler immediately moaned about it. I checked the ISO standard
>> and hey "throw ( ... )" isn't part of the ISO standart. You never stop
>> learning!
>> 
>> So I changed to "throw ( std::exeption )" knowing that this will result
>> in warnings in MS-C++ (and splint and pc-lint for that matter).
> 
> Why not "throw std::exception();", or, if you're rethrowing, "throw;".

You missunderstood. I speak about:

void f ()
   throw (std::exception)
   {
   ....
   }

as stated in ISO/IEC14882(15.4). I know it's one of the C++ features which
are seldomly used and using it is an uphill struggle - just like using
const was when it first appeared. But that never stops me.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

"Paul Mensonides" <leavings@comcast.net> writes:

> Nobody said that the mechanisms are equivalent.  Lisp macros are like C/C++ 
> macros in a pretty major way: they parametize code with code.

No, they are fundamentally code _transformers_, not parametric
substituters.


> > Lisp macros are tightly bound up with both the definition of the total
> > language and any implmentation of it.  Also expansion time is
> > interwoven with compilation, interpretation, or explicit evaluation.
> > They are available and can be defined during any phase: compile, load,
> > and execute/runtime.
> 
> So what?  Where and when they can be evaluated doesn't mean that the
> mechanisms are totally dissimilar.

OK, you would then also claim that the preprocessor is basically
similar to the C++ compiler.  Fine.  I think that makes the term
basically meaningless.


> > The/a cpp is not Turing complete.
> 
> Yes it is.

No, it is not.  The only way to get it to act as such is to run it in
phases over its own output.


> > The/a cpp processes text, typically from a text stream such as (most
> > typically) a text file.
> 
> No, a C or C++ preprocessor processes tokens, not text.

No, the _input_ is _text_.  Of course it turns that into _tokens_ but
that is _irrelevant_


> > Lisp macros process _data structures_.  In particular the syntax trees
> > output from the parser.  Text is long gone before macros are involved
> > at all.
> 
> So what?  A syntax tree is code, as is source code text.

You can't be serious.  OK, so the source code of a C++ program is the
same as the AST produced by the frontend.  You have again rendered the
term "syntax tree" basically meaningless.


> > The/a cpp doesn't know or have any access to the full language, user
> > defined functions, or its environment.
> 
> So what?  This is the same thing as your fifth reason.  When or
> where it can be evaluated doesn't change what it does.

No it is not the same, and it is telling that you think it is.  And it
makes a huge difference.  You can write programs with Lisp macros
pretty much like you write any other program.  You write them _in_ the
language, not as some adjunct separate aspect to the language.  That
level of expressivity and use of previously defined libraries of
functions is as important as being able to use class libraries and
language intrincs in typical programs.  I don't see how you can
plausibly disagree with this.



> > Lisp macros are just Lisp functions which can make use of the entire
> > language, and any other user defined functions and macros in libraries
> > or the running image.  They also have access to their lexical
> > environment information (such as type and profile information) as well
> > as any public aspects of the global system/application.
> 
> Again, so what? 

See above.  To claim that this is a "so what" is to claim that there
is no need or anything particularly useful about being able to use any
language construct and/or library in programming any program.  I
suppose you don't realize that that is what you are actually saying
here, because I can't believe you would actually think this.


> There is no doubt that Lisp macros are superior to C/C++ macros in
> most categories.  However, that doesn't change what they
> fundamentally do: parametize code with code.

I'm afraid that saying its so doesn't make it so.  They are code
transformers.  Of couse you can use them to "parameterize" code, but
that is a single _use_ case.


> > The astute reader will have noticed that it is C++ _templates_ which
> > are slighly similar to Lisp macros.  And they would be right.
> > Templates are significantly less expressive and mind numbingly painful
> > to use in comparison, but they are Turing complete and you can do some
> > interesting things with them.
> 
> C++ templates are similar to Lisp macros also, but C/C++ macros are
> much closer.

Not in their more fundamental character.  Templates are about
metaprogramming - not very potent example, but metaprogramming
nonetheless.  Lisp macros are still _the_ most capable extent example
of metaprogramming.

>  The template mechanism parametizes code with types (primarily) and
> only indirectly parametizes code with code.

That's pretty irrelevant.


> To reiterate: nobody has said that C/C++ macros are as powerful as
> Lisp or Scheme macros.  However, despite everything you say, Lisp
> and Scheme macros parametize code with code

And to reiterate, that is not what they primarily do.


> better still?  Yes.  Neither of those answers precludes the
> similarity in what the mechanisms do, nor do any of your reasons.

That basically eliminates any meaning in most of the terms:
"preprocessor", "compiler", "metaprogramming", "code transformer".
Fine.  But I think that's pretty extreme thing to do simply to try to
pretend that C/C++ macros are anything like Lisp macros.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

"Paul Mensonides" <leavings@comcast.net> writes:

> jayessay wrote:
> > "Paul Mensonides" <leavings@comcast.net> writes:
> 
> >> Lisp macros cannot produce partial syntax either, whereas C/C++
> >> macros can (e.g.  on macro can create a '{' and another separate
> >> invocation can create the closing '}').
> >
> > Again, that would be the sort of thing you would use reader macros.
> > It's worth noting again that Lisp macros (the kind you generally mean
> > when unqualified) do not work on text, they work on the syntax trees
> > passed to them.
> 
> Neither do macros in C or C++.  They operate on tokens.  In any
> case, the difference is meaningless.

Actually the difference is very important.


>  The only thing that matters is what the semantics are

Indeed.


> (such as name binding).  Lisp macros are easily inferior to Scheme
> macros in that sense.

No, they are a proper superset of Scheme macros.  The hygiene issue
is largely irrelevant due to CL being a lisp2 (while Scheme is a
lisp1).


> >> Jerry is correct to say that they do similar things--they parametize
> >> code with code.
> >
> > But that is not really what they do.  It is _one_ thing you can _use_
> > them to do.
> 
> That is exactly what they do.

No, but I don't think you will understand this anytime soon.  Let me
ask you here, just _why_ do you think this?  Maybe more to the point,
what do you think "parameterization" means here?  It may be that we
are just not on the same page with the term definitions.


> in the form of a syntax tree or not.  The kind of thing that you
> seem to be referring to is what Haskell does instead.

No, plain Haskell has no facility for this, but there are macro
systems that have been placed on it to provide some of the capability.


> >>  The main differences is that in Lisp (etc.) their
> >
> > I think the main differences are the ones I listed.
> 
> Obviously.

;-)


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Class hierarchy of exceptions (Ada, C++)

[Pascal Obry]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Actually, I think he borrowed it from my "pensees" web page (sorry, it is in
> French) at http://www.adalog.fr/publicat/pensees.htm)

No I think I read that in your book about Ada (don't have the name handy).

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

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Chad R. Meiners]

Jerry Coffin wrote:

>The point is that picking the language for that 70% seems to
>take one choice in one list box -- i.e. the most utterly trivial
amount
>of work possible.

What are you trying to say with this sentence?  It seems devoid of any
relavent information or meaning.

>are you honestly suggesting that
>it's particularly likely that they'd choose to generate C if they were
>planning to write the remainder in Ada?

Now I don't have to be pigeon holed into only that suggestion.  There
are more reasonable suggestions.  For instance, they could be reusing
libraries written in Ada for maybe 10% of the remaining code.  Another
15% could use this libraries and thus be written in Ada.

> I don't recall anybody here having suggested that SCADE is the be-all
> and end-all of format tools.

I never said you did.  I was assuming that SCADE is a decent formal
tool which implies that they use SCADE to generate a most complete
subsystem that represented about 70% of the code base.

>I drew exactly two conclusions: 1) that 100% minus 70% leaves 30%, and
>2) that these _seem_ to be sufficiently large projects that 30% of
them
>still constitutes a substantial amount of code.

Exactly two huh?  What about

>It seems likely to me that if
>they were using Ada for the hand-written code, they'd generate Ada
>as well.

That looks like a conclusion to me.   That sentence that you are
misquoting applies to all you conclusions and implicit implications.
Furthermore, if are calling

> 100% minus 70% leaves 30%

a conclusion as oppose to an assertion.  One should expect that it was
preceeded by an arguement or proof of some sort.  Being that you didn't
provide either, this "conclusion" is either a) actually an assertion
and disqualified to be member of your "exactly two conclusions" or b) a
conclusion that you jumped to by not providing an arguement to support
it.

And just for kicks

> please expound on your form of math in which 100 minus 70 doesn't
equal 30. 

when the numbers are in base 8 of course ;-)

Re: Teaching new tricks to an old dog (C++ -->Ada)

[Chad R. Meiners]

Jerry Coffin wrote:

>First of all, at least in my dictionary, "indicate" is defined with
>words like "points to" and "suggests", NOT "proves" or anything very
>similar.

Really?

http://dictionary.reference.com/search?q=indicates
entry four
"To state or express briefly (e.g. indicated his wishes in a letter;
indicating her approval with a nod.)"

seems to provide the most appropriate definition, which just happens to
support my statement.  You should also note that the "points to" and
"suggests" entries have other very important words next to them which
render them as inappropriate to use for the meaning of the word
"indicate" in this dialog.

>Second, I have to wonder whether you really have a good idea of the
>size of project we're talking about.

Yes, I have a decent idea as to the size of the project.  However, this
is irrelevent.

> Second, unless porting Ada compilers is a LOT more expensive than
> porting C++ compilers
<and so on>

I thought we were talking about C compilers.   Anyway my point is that
is that if SCADE already generates C code and the subsystem that they
are targetting with SCADE has a C compiler.  Why should they commision
an Ada compiler so that they could generate Ada code only to compile it
back to machine code when the C compiler will generate the machine
code?  C (in the can of SCADE) is the intermediate language because it
has the available compilers for the targetted platform.

>I'll openly admit that the slides don't absolutely _prove_ nearly as
>much as we'd like to know.

Wow! I am impressed by the extent of you admission.  We have made real
progress here in your admission of the trivial.

> They're generally vague, lacking detail,
>definition or rigor -- but despite that they still constitute roughly
>95% of the hard evidence presented so far in this entire thread!

I submit this paperweight as hard evidence.  I am not sure as to what
it is evidence of, but I know it is hard.  That was demonstrates when I
dropped it on my foot ;-)  So now this paperweight makes up 25% percent
of the evidence.

I am curious how these three presentations can make of 95%  of
something.  75% I can see but 95%?

Re: Class hierarchy of exceptions (Ada, C++)

[Jean-Pierre Rosen]

Pascal Obry a �crit :
> Jean-Pierre Rosen <rosen@adalog.fr> writes:
> 
> 
>>Actually, I think he borrowed it from my "pensees" web page (sorry, it is in
>>French) at http://www.adalog.fr/publicat/pensees.htm)
> 
> 
> No I think I read that in your book about Ada (don't have the name handy).
> 
Yes, it is in both... I just took the opportunity for a shameless plug :-)

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Class hierarchy of exceptions (Ada, C++)

[Peter Koch Larsen]

"Tapio Kelloniemi" <spam17@thack.org> skrev i en meddelelse 
news:IQX1e.4368$sO2.1682@reader1.news.jippii.net...
> Ioannis Vranos <ivr@remove.this.grad.com> wrote:
>>Ioannis Vranos wrote:
>>
>>> Actually most compilers provide warnings for lots of stuff and provide
>>> an option to display all warnings (e.g. /Wall), even comparison between
>>> signed and unsigned integers generates a warning. And they can also
>>> treat all warnings as *errors* if you specify so.
>>>
>>> However the default is to display warnings for anything that is not
>>> required by the standard to be treated as an error, and compile it.
>>>
>>>
>>> In most cases, one fixes *all* warnings. However there *are* some cases
>>> where the programmer knows better.
>>>
>>> C++ is enabling by default, which I suppose is the opposite direction of
>>> Ada, and that's why I think we can't understand one another. :-)
>>>
>>>
>>> C++ being less restrictive as the default, doesn't mean a compiler does
>>> not generate lots of warnings!
>
> The question is not only about compiler warnings or errors. Ada (as a
> language) has been designed so that it is possible for the
> compiler to check many mistakes which may cause bad results at run time.
> Ada also makes it easier for the user to notice this kind of errors.
> For example:
>
> procedure X is
>
>   type Metres is new Natural;
>   type Seconds is new Natural;
>
>   M : Metrses := 0;
>   S : Seconds := 10;
> begin
>   if M < S then --  Error, < is not defined for these types

But now you have problems calculating the velocity, right?

type Velocity is new Natural;
V: Velocity = M/S; // probably a compiler error.
>      ...
>   end if;
> end X;
>
> This is a bit more verbose than using pure int instead of Metres and
> Seconds, but if I wanted a C++ compiler to check this kind of error, I'm
> afread that the resulting C++ code would be much more verbose.

Not so. There is an excellent library which does exactly what you want - 
using templates, of course.
>
> Such mistakes as using a pointer to nothing and writing past the array
> bounds don't often happen in Ada.
What makes you believe they happen regularly in C++?
>
>>An example. First compile with the default behaviour, then with all 
>>warnings tu
>>rned on:
>>
>>int main()
>>{
>>     int i=0;
>>
>>     unsigned j=4;
>>
>>     j<i;
>>}
>
> procedure Temp is
>   I : Integer := 0;
>   J : Natural := 4;
> begin
>   I < J;
> end Temp;
>
> Without any warnings:
> # gnatmake temp
> gcc -c temp.adb
> temp.adb:5:05: missing ":="
> gnatmake: "temp.adb" compilation error
>
> Notice how the language prevents doing useless things.
>
> If a replace I < J; with null; the result is:
> gcc -c -gnatg temp.adb
> temp.adb:2:04: warning: "I" is not modified, could be declared constant
> temp.adb:2:04: warning: variable "I" is not referenced
> temp.adb:3:04: warning: "J" is not modified, could be declared constant
> temp.adb:3:04: warning: variable "J" is not referenced
> gnatmake: "temp.adb" compilation error

I see no real difference here between a good-quality C++ compiler and Ada.
>
> -- 
> Tapio

/Peter 

Re: Class hierarchy of exceptions (Ada, C++)

[Tapio Kelloniemi]

"Peter Koch Larsen" <pklspam@mailme.dk> wrote:
>"Tapio Kelloniemi" <spam17@thack.org> skrev i en meddelelse
>news:IQX1e.4368$sO2.1682@reader1.news.jippii.net...
>> The question is not only about compiler warnings or errors. Ada (as a
>> language) has been designed so that it is possible for the
>> compiler to check many mistakes which may cause bad results at run time.
>> Ada also makes it easier for the user to notice this kind of errors.
>> For example:
>>
>> procedure X is
>>
>>   type Metres is new Natural;
>>   type Seconds is new Natural;
>>
>>   M : Metrses := 0;
>>   S : Seconds := 10;
>> begin
>>   if M < S then --  Error, < is not defined for these types
>
>But now you have problems calculating the velocity, right?
>
>type Velocity is new Natural;
>V: Velocity = M/S; // probably a compiler error.
Yes, but I can tell the compiler that I know better:
V : Velocity := Velocity (Integer (M) / Integer (S));

Also other readers of my code now know surely that this is what I meant.

>> This is a bit more verbose than using pure int instead of Metres and
>> Seconds, but if I wanted a C++ compiler to check this kind of error, I'm
>> afread that the resulting C++ code would be much more verbose.
>
>Not so. There is an excellent library which does exactly what you want -
>using templates, of course.

That is a good thing. If all C++ programmers used it, I think their
programs would benefit a lot of it.

>> Such mistakes as using a pointer to nothing and writing past the array
>> bounds don't often happen in Ada.
>What makes you believe they happen regularly in C++?

They just happen. Why people had otherwise created such tools as valgrind
(http://valgrind.kde.org/). I also use it myself for Ada to eliminate memory
leaks. Writing past array bounds unintentionally is quite easy. In Ada
Constraint_Error is raised, but C++ program segfaults. Or even worse, it
does not segfault immediately, but when the function is exited (as the
return address has been destroyed). STL is safer, but it cannot always be
used (eg. when interfacing to foreign code).

>>>An example. First compile with the default behaviour, then with all
>>>warnings tu
>>>rned on:
[--]
>> If a replace I < J; with null; the result is:
>> gcc -c -gnatg temp.adb
>> temp.adb:2:04: warning: "I" is not modified, could be declared constant
>> temp.adb:2:04: warning: variable "I" is not referenced
>> temp.adb:3:04: warning: "J" is not modified, could be declared constant
>> temp.adb:3:04: warning: variable "J" is not referenced
>> gnatmake: "temp.adb" compilation error
>
>I see no real difference here between a good-quality C++ compiler and Ada.

Another example:

int* f()
{
  int i = 3;
  int& l = *(new int);

  l = i;
  int* p = &i; // Should be int* p = &l;

  return p;
}

int main()
{
  int* p = f();
  *p = 4;
  return 0;
}

# g++ -Wall -o temp temp.cc
#

Not even a warning and the program does not crash on my system! Valgrind
revealed the error (and thought it was a G++ bug).
If the code above is modified a bit, even the best compiler cannot
know for sure that we are doing evil things.

The same in Ada:

procedure Temp is
   type Int_Ptr is access Integer;

   function F return Int_Ptr is
      I : Integer := 3;
      L : Int_Ptr := new Integer;
      P : Int_Ptr;
   begin
      L.all := I;
      P := I'Access; --  Should be P := L;
      return P;
   end F;

   A : Int_Ptr;
begin
   A := F;
   A.all := 4;
end Temp;

# gcc -c -gnatg temp.adb
temp.adb:5:04: (style): subprogram body has no previous spec
temp.adb:11:12: prefix of "Access" attribute must be aliased

So if I really want to pass a pointer to a local to the caller, I should
change
      I : Integer := 3;
to
      I : aliased Integer := 3;

Also note that the lines which were "mistyped" are much closer to each
other in C++ than in Ada.

-- 
Tapio

Re: Class hierarchy of exceptions (Ada, C++)

[Pascal Obry]

Tapio Kelloniemi <spam17@thack.org> writes:

> >> procedure X is
> >>
> >>   type Metres is new Natural;
> >>   type Seconds is new Natural;
> >>
> >>   M : Metrses := 0;
> >>   S : Seconds := 10;
> >> begin
> >>   if M < S then --  Error, < is not defined for these types
> >
> >But now you have problems calculating the velocity, right?
> >
> >type Velocity is new Natural;
> >V: Velocity = M/S; // probably a compiler error.
>
> Yes, but I can tell the compiler that I know better:
> V : Velocity := Velocity (Integer (M) / Integer (S));

or

   function "/" (M : in Metres; S : in Seconds) return Velocity;

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

Re: Class hierarchy of exceptions (Ada, C++)

[Ioannis Vranos]

Tapio Kelloniemi wrote:

> STL is safer, but it cannot always be
> used (eg. when interfacing to foreign code).


An example?


> Another example:
> 
> int* f()
> {
>   int i = 3;
>   int& l = *(new int);
> 
>   l = i;
>   int* p = &i; // Should be int* p = &l;
> 
>   return p;
> }
> 
> int main()
> {
>   int* p = f();
>   *p = 4;
>   return 0;
> }
> 
> # g++ -Wall -o temp temp.cc
> #
> 
> Not even a warning and the program does not crash on my system! Valgrind
> revealed the error (and thought it was a G++ bug).


Strictly speaking one shouldn't use such variable names. However this is not easy to check 
all those things. C++ aims to be an *enabling* language. For example one could have 
written the following code for a system:


int* f()
{
   // For setting panel indication.
   int *p =reinterpret_cast <int *>(0x148);

   // For reading external thermometer
   volatile const int *r= reinterpret_cast<volatile const int *>(329);

   // ...

   return p;
}

int main()
{
   int* p = f();
   *p = 4;
   return 0;
}




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys

Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

Ioannis Vranos wrote:

> Perhaps you are right. If you have the standard, have a look at 3.9-2, 
> 3.9-4, and 3.9-5 which I think agrees with you.


For thread completeness, I am posting the portable versions of the codes, as things got 
clarified in another thread:


#include <new>

class SomeClass
{
};


int main()
{
     unsigned char *array= new unsigned char[sizeof(SomeClass)];

     SomeClass *p= new(array)SomeClass;

     // ...

     p->~SomeClass();

     delete[] array;
}




#include <iostream>
#include <cstring>

class SomeClass
{
     public:

     double d;
     int i;
     float f;
     long l;
};


int main()
{
     using namespace std;

     unsigned char *array= new unsigned char[sizeof(SomeClass)];

     SomeClass obj= {1, 2, 3, 4};

     memcpy(array, &obj, sizeof(obj));

     SomeClass *p= static_cast<SomeClass *>( static_cast<void *>(array) );

     cout<<p->d<<" "<<p->i<<" "<<p->f<<" "<<p->l<<"\n";

     p->~SomeClass();

     delete[] array;
}





#include <iostream>
#include <cstring>
#include <cstddef>

class SomeClass
{
     public:

     void somefunc() const { std::cout<<"somefunc() was called!\n"; }
};


int main()
{
     using namespace std;

     SomeClass obj;

     unsigned char *p= reinterpret_cast<unsigned char *>(&obj);

     unsigned char *array= new unsigned char[sizeof(obj)];

     for(size_t i=0; i<sizeof(obj); ++i)
        array[i]= p[i];

     SomeClass *obj2= static_cast<SomeClass *>( static_cast<void *>(array) );

     obj2->somefunc();

     obj2->~SomeClass();

     delete[] array;
}




-- 
Ioannis Vranos

http://www23.brinkster.com/noicys