Ada 200X

Ada 200X

[David Botton]

Where can I find out about Ada 200X

How does one
	A. Submit ideas
	B. See what ideas have been submitted
	C. See what ideas were accepted

Who is making the decisions
When are the decisions made
Where are the decisions made

All that kind of stuff and more.

Thanks,
David Botton
http://www.adapower.com

Re: Ada 200X

[Martin Dowie]

David Botton wrote:
> Where can I find out about Ada 200X
>
> How does one
> A. Submit ideas
> B. See what ideas have been submitted
> C. See what ideas were accepted
>
> Who is making the decisions
> When are the decisions made
> Where are the decisions made
>
> All that kind of stuff and more.

All this can be found here : http://www.ada-auth.org/

Cheers

-- Martin

Re: Ada 200X

[Jeffrey Carter]

Martin Dowie wrote:
> David Botton wrote:
> 
>>Where can I find out about Ada 200X
> 
> All this can be found here : http://www.ada-auth.org/

More specifically, at

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

The revision is essentially closed to new suggestions.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51

Ada 200X

[And838N]

Warren W. Gay wrote:
>...I think many would be happy to break that rule for >GNAT.IO_Aux.Get_Line, since
>there is no other way to read in a Ada string without knowing in
>advance its size...
>For my $0.02 worth, the scalars don't matter. The string is the problem
>child that needs a solution.

I'm pretty new to Ada but I have been using and tutoring C,C++, Java for over 5 years now.  When I decided to "try out" Ada one of the first things I noticed was the String problem as Warren described.  My solutions was to write procedures (functions) in a package that took a parameter of type String, then overloaded that procedure to use Unbounded_String and so on so that I could use whatever I was comfortable with.  I even overloaded procedures and functions to take the String_Access.  Anyway, my point is, for users coming out of C, C++, Java, like me, it would be a TREMENDOUS help to make the "String" transition easier.

There was one other issue I came across when writing my first Linked list in Ada.  There is no "this" keyword.  It didn't take long for me to realize that a class in Ada is not at all like a class as I understand from college (C++, Java).  The "flavor" of an Ada was C struct like to me and required passing "my" instance as a parameter to a procedure of function in a package so that I could use "this".  

My view may be somewhat biased because I'm new to Ada but the idea of an Ada class doesn't seem like a class to me at all.  It seems like putting a bunch of C methods and a struct definition into a .c file and compiling it and calling it a class.  There's obviously more to Ada than that but I described how it "seemed" for someone trying to move to Ada.

My purpose for moving to Ada is all the hype about reducing the cost of maintenance and the quicker development time.  I read a bunch of articles on how Ada is superior to other languages because once you learn it your development goes quicker and the end result requires less maintenance.  Two key things if I want to play in a global market against "inexpensive" programmers/engineering firms in places like India.

I've heard professors say they don't like Ada because it's slow and does all those "bounds" checking "things".  My opinion is; take a look at the bugs in MS code that lead to viruses because of buffer exploits and unchecked "bounds".  Ada just seems a smart way to go, especially with newer faster processors.  Most people don't recognize the speed up anyway unless the go from 300MHz to a 2.4GHz.

I've been working with Ada seriously for about a month now and the more I learn the more I like it.  It does not have the flavor of a "business" type language, even though it is perfectly useable for such applications.  But sometimes the "flavor" of the language is almost as important as the language itself!  Especially if you want to open the "market" up.
Making Ada easy to transition to would be something to consider in Ada200X, IMHBiasedO.

Ok, so now I am up to 4 cents.

Thanks!

Andrew

__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

Re: Ada 200X

[Bobby D. Bryant]

On Sun, 01 Jun 2003 17:36:27 -0400, And838 wrote:

> I've heard professors say they don't like Ada because it's slow and does
> all those "bounds" checking "things".  My opinion is; take a look at the
> bugs in MS code that lead to viruses because of buffer exploits and
> unchecked "bounds".  Ada just seems a smart way to go, especially with
> newer faster processors.

IMO programmers for the most part are far too concerned with speed and far
too little concerned with correctness.

Also, it's not uncommon to find someone who tries to do "cute" things to
optimize some local operation for speed, but then embeds it in a horribly
inefficient exponential-time algorithm.

-- 
Bobby Bryant
Austin, Texas

Re: Ada 200X

[Robert I. Eachus]

And838N@netscape.net wrote:

 > There was one other issue I came across when writing my first Linked
 > list in Ada.  There is no "this" keyword.  It didn't take long for me
 > to realize that a class in Ada is not at all like a class as I
 > understand from college (C++, Java).  The "flavor" of an Ada was C
 > struct like to me and required passing "my" instance as a parameter
 > to a procedure of function in a package so that I could use "this".

The feature that you are looking for is called an access discriminant. 
This allows an object to have a self reference, or more important, a 
reference to the containing object.  Unfortunately access discriminants 
usually break information hiding.  If you do use access discriminants to 
create linked lists, the linked list code can muck with the other 
fields, and worse, the code for the non-list related fields has to know 
it is part of an object in a list.

The alternative is to use mix-in style generics to create linked lists 
of objects.  This results in the list code knowing nothing about the 
properties of the objects in the list and the object code being 
independent of the list. Much better, especially when you want to work 
with heterogenous lists.

Which is better?  Wrong question.  Sometimes you need for an object to 
be able to pick itself up by the scruff of its neck.  Most of the time, 
you don't.

 > My view may be somewhat biased because I'm new to Ada but the idea of
 > an Ada class doesn't seem like a class to me at all.  It seems like
 > putting a bunch of C methods and a struct definition into a .c file
 > and compiling it and calling it a class.  There's obviously more to
 > Ada than that but I described how it "seemed" for someone trying to
 > move to Ada.

The thing that you are missing is that a class in Ada is more of a 
mathematical concept than a declarative object.  Declaring a tagged type 
in Ada, whether or not it is a derived type, creates a class.  However, 
there is no way to simply look at the code and see all the potential 
types that are members of the class.  The mechanics works so that units 
as they are compiled can create code that works with all members of the 
class.  However, in any compilation unit the visible operations of the 
class is a subset of all the operations (methods) for the class.

What seems even worse is that information hiding can result in a class 
having many methods/operations with the same name and parameter profile. 
  Which one you dispatch to depends on the visibility at the point of 
the call.  In practice this is not a problem at all, it is a fundamental 
principle of information hiding.  If those other definitions could 
magically appear and hide the ones you knew about, that would be bad. 
Instead the behavior of an object can be understood in terms of only 
what is visible at that point.  As you can guess from the first part of 
the message, not all objects know their own name (self).  And those that 
do may only know it in part of the scope where the object itself is visible.

 > My purpose for moving to Ada is all the hype about reducing the cost
 > of maintenance and the quicker development time.  I read a bunch of
 > articles on how Ada is superior to other languages because once you
 > learn it your development goes quicker and the end result requires
 > less maintenance.  Two key things if I want to play in a global
 > market against "inexpensive" programmers/engineering firms in places
 > like India.

You will find that the hype is not hype, it is real.  And information 
hiding is a fundamental part of the benefits.  The more you can reduce 
what a programmer needs to know about an object or value, the easier and 
more bug free code becomes.  The flip side is that to get the benefits, 
you have to ruthlessly limit what is visible to what is necessary. 
Again, this gets back to the "self" discussion and linked lists.  The 
benefit of having a linked list package which knows nothing about the 
contents of the list, and objects which can't know that they are 
contained in a list should be obvious.  But to get those benefits, you 
need to use a mix-in list type.

Re: Ada 200X

[Larry Kilgallen]

In article <3EDAD07A.3010200@attbi.com>, "Robert I. Eachus" <rieachus@attbi.com> writes:
> And838N@netscape.net wrote:
> 
>  > There was one other issue I came across when writing my first Linked
>  > list in Ada.  There is no "this" keyword.  It didn't take long for me
>  > to realize that a class in Ada is not at all like a class as I
>  > understand from college (C++, Java).  The "flavor" of an Ada was C
>  > struct like to me and required passing "my" instance as a parameter
>  > to a procedure of function in a package so that I could use "this".
> 
> The feature that you are looking for is called an access discriminant. 
> This allows an object to have a self reference, or more important, a 
> reference to the containing object.  Unfortunately access discriminants 
> usually break information hiding.

I am not the original poster, but the case where I find this troublesome
is trying to replace a method for a parent type with enhanced code to:

        1. Do something special

        2. Do whatever the method for the parent type would do

        3. Do something else special

The lack of a construct to specify "corresponding method of ancestor"
seems to me to be what breaks information hiding.

Re: Ada 200X

[Hyman Rosen]

Larry Kilgallen wrote:
> The lack of a construct to specify "corresponding method of ancestor"
> seems to me to be what breaks information hiding.

Can't you just do a view conversion to the ancestor type
and call the method? That's not dispatching, so you'll
call the method defined for the ancestor type.

Re: Ada 200X

[Vinzent Hoefler]

Hyman Rosen wrote:

>Larry Kilgallen wrote:
>> The lack of a construct to specify "corresponding method of ancestor"
>> seems to me to be what breaks information hiding.
>
>Can't you just do a view conversion to the ancestor type
>and call the method?

Yes, but who is the ancestor? You always have to look for that.

I guess, Larry means something like

|inherited method (...);

instead of the specific

|ancestor.method (...)

call in Turbo (Object?) Pascal.

>That's not dispatching, so you'll
>call the method defined for the ancestor type.

Yeah, right. But it would be easier to just write the equivalent to
$WHATEVER_THE_CURRENT_ANCESTOR is instead of specifying it each time.
Sometimes the object hierarchy might change a little bit.


Vinzent.

Re: Ada 200X

[Hyman Rosen]

Vinzent Hoefler wrote:
> Yes, but who is the ancestor? You always have to look for that.

That's fine. I'm given to understand that Ada is meant to be
for the convenience of the reader, not the writer. It may be
more work for you to look up the ancestor, but then the reader
of the code will know exactly where to look for the code.

Re: Ada 200X

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>> Yes, but who is the ancestor? You always have to look for that.
>
>That's fine.

Yes, it works. :)

>I'm given to understand that Ada is meant to be
>for the convenience of the reader, not the writer. It may be
>more work for you to look up the ancestor, but then the reader
>of the code will know exactly where to look for the code.

Yes, it's ok for the first time you have to write it.
The problem sometimes is that all these view conversions should be
changed when you make a change to the object hierarchy and insert
another object, so that the former father is now suddenly the
grandfather. Because in the way the view conversion works, this is
legal, but it might be wrong. YMMV.


Vinzent.

Re: Ada 200X

[Bill Findlay]

On 2/6/03 16:04, in article bbfp40$90vu6$1@ID-175126.news.dfncis.de,
"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:

> Hyman Rosen wrote:
> 
>> Vinzent Hoefler wrote:
>>> Yes, but who is the ancestor? You always have to look for that.
>> 
>> That's fine.
> 
> Yes, it works. :)
> 
>> I'm given to understand that Ada is meant to be
>> for the convenience of the reader, not the writer. It may be
>> more work for you to look up the ancestor, but then the reader
>> of the code will know exactly where to look for the code.
> 
> Yes, it's ok for the first time you have to write it.
> The problem sometimes is that all these view conversions should be
> changed when you make a change to the object hierarchy and insert
> another object, 

Might you not want to invoke the original parent in some cases, and in other
cases the newly-interposed parent? It seems that is an issue calling for at
least a careful review of all the types in that lineage, during which such
hand-offs should be reconsidered, rather than just taking it for granted
that the default given by 'super' is the right one.

> so that the former father is now suddenly the
> grandfather. Because in the way the view conversion works, this is
> legal, but it might be wrong. YMMV.

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: Ada 200X

[Larry Kilgallen]

In article <BB012971.2FD0%yaldnifw@blueyonder.co.uk>, Bill Findlay <yaldnifw@blueyonder.co.uk> writes:

> Might you not want to invoke the original parent in some cases, and in other
> cases the newly-interposed parent? It seems that is an issue calling for at
> least a careful review of all the types in that lineage, during which such
> hand-offs should be reconsidered, rather than just taking it for granted
> that the default given by 'super' is the right one.

In the vast majority of cases "do everything my ancestors would do"
is the proper answer.  In other cases, the programmer will have specific
knowledge that something different is required.

Re: Ada 200X

[Vinzent Hoefler]

Bill Findlay wrote:

>On 2/6/03 16:04, in article bbfp40$90vu6$1@ID-175126.news.dfncis.de,
>"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:
>
>> Hyman Rosen wrote:
>> 
>>> I'm given to understand that Ada is meant to be
>>> for the convenience of the reader, not the writer. It may be
>>> more work for you to look up the ancestor, but then the reader
>>> of the code will know exactly where to look for the code.
>> 
>> Yes, it's ok for the first time you have to write it.
>> The problem sometimes is that all these view conversions should be
>> changed when you make a change to the object hierarchy and insert
>> another object, 
>
>Might you not want to invoke the original parent in some cases, and in other
>cases the newly-interposed parent?

Maybe, yes. Usually not, because in that case it would simply become a
completely new derived object then.

>It seems that is an issue calling for at
>least a careful review of all the types in that lineage, during which such
>hand-offs should be reconsidered, rather than just taking it for granted
>that the default given by 'super' is the right one.

Well, you should do such review anyway. IME, having something like
"inherited" just would make the changes easier and at least in the
cases *I* encountered thus far, less error prone. Not that I really
miss that, I could get along without that feature in Turbo Pascal 6,
but later when I got TP7 I used it quite often. It turned out to be
more easy especially in ever changing code (which, of course, you
should never have with a good design in the first place).
So sometimes I forgot the change and had an object that didn't
properly initialize its new properties because its constructor wasn't
called at all, just because the call to the parent's method directly
"skipped" to the grandfather.

Well, as I said, YMMV.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ada 200X

[Larry Kilgallen]

In article <1054565992.652258@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Vinzent Hoefler wrote:
>> Yes, but who is the ancestor? You always have to look for that.
> 
> That's fine. I'm given to understand that Ada is meant to be
> for the convenience of the reader, not the writer. It may be
> more work for you to look up the ancestor, but then the reader
> of the code will know exactly where to look for the code.

But Ada is also designed to catch errors made by the writer,
and if a new parent is inserted the procedure in question will
will be skipping a generation when that would be quite undesired
in most cases.

Re: Ada 200X

[Larry Kilgallen]

In article <bbfmo3$8nlul$1@ID-175126.news.dfncis.de>, Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> Yeah, right. But it would be easier to just write the equivalent to
> $WHATEVER_THE_CURRENT_ANCESTOR is instead of specifying it each time.
> Sometimes the object hierarchy might change a little bit.

Precisely.  It seems to me the parent should be specified only at the top.

Re: Ada 200X

[Robert I. Eachus]

Larry Kilgallen wrote:

> I am not the original poster, but the case where I find this troublesome
> is trying to replace a method for a parent type with enhanced code to:
> 
>         1. Do something special
> 
>         2. Do whatever the method for the parent type would do
> 
>         3. Do something else special
> 
> The lack of a construct to specify "corresponding method of ancestor"
> seems to me to be what breaks information hiding.

Oh, that is so easy that I never thought of people having problems with 
it.  I'll give an example:

type Foo is tagged...

procedure Bar(F: in out Foo);
...

type New_Foo is new Foo with...

procedure Bar(F: in out New_Foo);
...

procedure Bar(F: in out New_Foo) is
begin
    Do(Something_Special);
    Bar(Foo(F)); -- view conversion
    Do(Something_Else_Special);
end Bar;

The view conversion passes the Foo part of a New_Foo object to the 
parent Bar by reference.  So the parent operation only sees the parts of 
the New_Foo object that it knows about.  When writing Initialize, 
Adjust, and Finalize operations for controlled types, this idiom is 
pretty standard.

In my experience I have never needed access discriminants, but some 
smart people say they are needed for compatibility with other OO languages.

Re: Ada 200X

[Vinzent Hoefler]

Robert I. Eachus wrote:

>Larry Kilgallen wrote:
>
>> The lack of a construct to specify "corresponding method of ancestor"
>> seems to me to be what breaks information hiding.
>
>Oh, that is so easy that I never thought of people having problems with 
>it.  I'll give an example:
>
>type Foo is tagged...
>
>procedure Bar(F: in out Foo);
>...
>
>type New_Foo is new Foo with...
>
>procedure Bar(F: in out New_Foo);
>...
>
>procedure Bar(F: in out New_Foo) is
>begin
>    Do(Something_Special);
>    Bar(Foo(F)); -- view conversion
>    Do(Something_Else_Special);
>end Bar;
>
>The view conversion passes the Foo part of a New_Foo object to the 
>parent Bar by reference.

Yeah, but what happens if you insert

|type Baz is new Foo with ...
|
|procedure Bar (F : in out Baz);
|
|type New_Foo is new Baz with ...

is that you have to change every single view conversion in New_Foo's
methods from

|Bar (Foo (F));

to

|Bar (Baz (F));

Because the view conversion to a grandparent is of course allowed,
this is little tricky if not to say error prone sometime.

Well, yes, I know, you should always design your object hierarchy
beforehand. ;-)


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ada 200X

[Larry Kilgallen]

In article <bbfn73$8buuf$1@ID-175126.news.dfncis.de>, Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> Because the view conversion to a grandparent is of course allowed,
> this is little tricky if not to say error prone sometime.
> 
> Well, yes, I know, you should always design your object hierarchy
> beforehand. ;-)

And rewrite from scratch rather than ever modifying code :-)

Re: Ada 200X

[Hyman Rosen]

Vinzent Hoefler wrote:
> Yeah, but what happens if you insert
> |type Baz is new Foo with ...
> is that you have to change every single view conversion in New_Foo's
> methods from |Bar (Foo (F)); to |Bar (Baz (F));

Can't you just do
     subtype inherited is Bar;
and then just use inherited everywhere?
Then if things change, you just have one place to update.
     subtype inherited is Baz;

Re: Ada 200X

[Robert I. Eachus]

Vinzent Hoefler wrote:

> Because the view conversion to a grandparent is of course allowed,
> this is little tricky if not to say error prone sometime.
> 
> Well, yes, I know, you should always design your object hierarchy
> beforehand. ;-)

In one sense this is a valid criticism of the "Ada way" of doing things. 
  In another it is totally bogus.

Ada tagged type derivation trees tend to come in two flavors.  The first 
is one parent with a lot of children. (A bush.)  The class rooted at 
Controlled is like this.

The other common type of Ada derivation tree is a pole.  You have a 
sequence of generic instantiations in the private part of a package 
declaration, each instantiation creating a new mixin.  In the body of 
the package you have lots of view conversions.  But the view conversions 
are definitely not to parents or grandparents, they are to specific 
mixins.  Any added mixins should not change any of the current uplevel 
references.

So I have done lots of changes to type hierarchies in Ada, and I don't 
think I have ever needed to change a view conversion unless I have done 
the gun, foot, shoot, optimization.  (If you really, really need to 
change the name of an instantatiation, you have to be ready to do a 
global search and replace against the body and all child packages.  The 
problem is if you used a name originally that matches some component 
name or the like...)

Re: Ada 200X

[Larry Kilgallen]

In article <3EDBBC18.6080103@attbi.com>, "Robert I. Eachus" <rieachus@attbi.com> writes:

> Ada tagged type derivation trees tend to come in two flavors.  The first 
> is one parent with a lot of children. (A bush.)  The class rooted at 
> Controlled is like this.
> 
> The other common type of Ada derivation tree is a pole.  You have a 
> sequence of generic instantiations in the private part of a package 
> declaration, each instantiation creating a new mixin.

Presuming your survey is accurate, what basis is there to think this
would persist if Ada were widely used in a greater variety of domains ?

Re: Ada 200X

[Robert I. Eachus]

Larry Kilgallen wrote:

> Presuming your survey is accurate, what basis is there to think this
> would persist if Ada were widely used in a greater variety of domains ?

It is not a matter of the nature of domains, but of the nature of Ada. 
Try it and see.  A great test is a library of container classes.  At 
first you thing that you are going to have a four or five deep 
hierarchy.  After working on it a bit you conclude that there are two 
(or three depending on who is doing it)* top level classes, and all the 
other classes are children of those.  Why is this so different from 
other OO languages?  Me I 'blame' it on information hiding and the Ada 
culture. If you create a complex structure of derived in Ada, that 
reveals some implementation details to the user, or prevents the 
implementor from choosing the best way to implement a feature. Two sides 
of the same coin.

*Hey wait a mimute you say, remembering the original Booch components, 
you need tasking and non-tasking versions, and this and that, and... 
Right, but at the base you have various forms of structures with 
sequential access, and those with keyed/random access.  (The potential 
third category above is bags and other structures without unique keys.) 
  But a tasking safe singly linked list, a non-tasking safe doubly 
linked list, and a stack are all different implementations of a single 
interface abstraction.

Whether we get interface as a keyword in Ada 0Y or not, the parent is an 
abstract limited private type, and all the children are slightly 
different implementations.  If you want you can actually have some 
non-abstract subprograms in the parent, but in practice the ones you can 
inherit are one liners anyway.

Re: Ada 200X

[Jean-Pierre Rosen]

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


"Robert I. Eachus" <rieachus@attbi.com> a �crit dans le message news:
3EDBBC18.6080103@attbi.com...
> So I have done lots of changes to type hierarchies in Ada, and I don't
> think I have ever needed to change a view conversion unless I have done
> the gun, foot, shoot, optimization.  (If you really, really need to
> change the name of an instantatiation, you have to be ready to do a
> global search and replace against the body and all child packages.  The
> problem is if you used a name originally that matches some component
> name or the like...)
<PLUG>
Or use Adasubst, available from Adalog's components page...
(http://www.adalog.fr/compo2.htm)
</PLUG>

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

Re: Ada 200X

[Vinzent Hoefler]

Robert I. Eachus wrote:

>Vinzent Hoefler wrote:
>
>> Because the view conversion to a grandparent is of course allowed,
>> this is little tricky if not to say error prone sometime.
>> 
>> Well, yes, I know, you should always design your object hierarchy
>> beforehand. ;-)
>
>In one sense this is a valid criticism of the "Ada way" of doing things. 
>  In another it is totally bogus.

I was afraid so. ;-)

>Ada tagged type derivation trees tend to come in two flavors. [...]

Mmh, well. I encounter a third variant quite often. For instance let's
take a short look at a part of the good old TurboVision object
hierarchy:

|                         +-------+
|                         ¦TObject¦
|                         +-------+
|                             |
|                          +-----+
|                          ¦TView¦
|                          +-----+
|                             |
|       +----------------------------------------------+
|       |       |        |       |      |      |       |
|  +----------+ |  +----------+  | +--------+  |   +------+
|  |TScrollBar| |  |TInputLine|  | |TCluster|  |   |TGroup|
|  +----------+ |  +----------+  | +--------+  |   +------+
|               |                |     |       |       |
|         +-----------+     +--------+ | +-----------+ +-------------+
|         ¦TStaticText¦     ¦THistory¦ | ¦TListViewer¦               |
|         +-----------+     +--------+ | +-----------+               |
|               |                      |       |                     |
|         +-----------+                |    +-----------+            |
|         |           |                |    |           |            |
|      +------+  +----------+          | +--------+ +--------------+ |
|      |TLabel|  |TParamText|          | |TListBox| |THistoryViewer| |
|      +------+  +----------+          | +--------+ +--------------+ |
|                               +------+--------+           +--------+
|                               |      |        |           |
|                               | +-----------+ |       +-------+
|                               | |TCheckBoxes| |       |TWindow|
|                               | +-----------+ |       +-------+
|                         +-------------+ +----------------+ |
|                         |TRadioButtons| |TMultiCheckBoxes| |
|                         +-------------+ +----------------+ |
|                                                    +-------------+
|                                                    |             |
|                                            +--------------+  +-------+
|                                            |THistoryWindow|  |TDialog|
|                                            +--------------+  +-------+

This rather looks like a tree. And I doubt, any medium sized OO-System
would be much different from that just because it's Ada.

So let's say, as a specific example, I am deriving MyWindow from
TWindow, slightly change one of its method and let the fathers method
do the usual rest. Now I decide to insert another object (of course I
will derive from that later) into the tree, so that TWindow is now the
grandfather of MyWindow. Because I am still calling the method of
TWindow I skip the new inbetween object's method. This might be wrong
or false depending on what it does and what I intended to do. So
having something like "inherited" in Object-Pascal that automagically
selects the right method of either the father, grandfather,
grand-grandfather, ..., in the cases where I *really* just want to use
the method of the anchestor would be nice.

Well, after a night of thought I see some problems with that,
especially that it 1) hides where exactly the method comes from
(depending on the view of information hiding this might be a good or a
bad thing) and 2) a worse case: If the anchestor, whos method I am
about to call, is really declared in another package that I didn't
even "with"ed in.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ada 200X

[Robert I. Eachus]

Vinzent Hoefler wrote:

> Mmh, well. I encounter a third variant quite often. For instance let's
> take a short look at a part of the good old TurboVision object
> hierarchy:
> 
>                         +-------+
>                         �TObject�
>                         +-------+
>                             |
>                          +-----+
>                          �TView�
>                          +-----+
>                             |
>       +----------------------------------------------+
>       |       |        |       |      |      |       |
>  +----------+ |  +----------+  | +--------+  |   +------+
>  |TScrollBar| |  |TInputLine|  | |TCluster|  |   |TGroup|
>  +----------+ |  +----------+  | +--------+  |   +------+
>               |                |     |       |       |
>         +-----------+     +--------+ | +-----------+ +-------------+
>         �TStaticText�     �THistory� | �TListViewer�               |
>         +-----------+     +--------+ | +-----------+               |
>               |                      |       |                     |
>         +-----------+                |    +-----------+            |
>         |           |                |    |           |            |
>      +------+  +----------+          | +--------+ +--------------+ |
>      |TLabel|  |TParamText|          | |TListBox| |THistoryViewer| |
>      +------+  +----------+          | +--------+ +--------------+ |
>                               +------+--------+           +--------+
>                               |      |        |           |
>                               | +-----------+ |       +-------+
>                               | |TCheckBoxes| |       |TWindow|
>                               | +-----------+ |       +-------+
>                         +-------------+ +----------------+ |
>                         |TRadioButtons| |TMultiCheckBoxes| |
>                         +-------------+ +----------------+ |
>                                                    +-------------+
>                                                    |             |
>                                            +--------------+  +-------+
>                                            |THistoryWindow|  |TDialog|
>                                            +--------------+  +-------+

> This rather looks like a tree. And I doubt, any medium sized OO-System
> would be much different from that just because it's Ada.

First, lets get a view that doesn't hide the structure:

TObject
   TView
     TScrollBar
     TStaticText
       TLabel
       TParamText
     TInputLine
     THistory
     TCluster
       TRadioButtons
       TCheckBoxes
       TMultiCheckBoxes
     TListViewer
       TListBox
       THistoryViewer
     TGroup
       TWindow
         THistoryWindow
         TDialog

Let's actually put our Ada hats on and look at that hierarchy.  The 
TObject vs. TView looks to be methodological not logical. Notice that 
there is a descendent TListViewer, which is the only view related direct 
child.)  TView has seven children.  If you redid this in Ada, I don't 
know if TCluster and TGroup would remain as 'real' children but I am 
sure that TWindow would get elevated.  A typical Ada Model-View 
hierarchy would have Object and View as parents and most other types 
descended from one or the other.

Of course, if I were to reimplement this hierarchy in Ada, I'd try as 
hard as possible to keep the original structure.  I might or might not 
manage to swallow the naming convention though. ;-)

Re: Ada 200X

[Vinzent Hoefler]

Robert I. Eachus wrote:

>Vinzent Hoefler wrote:
>
[snip]
>> This rather looks like a tree. And I doubt, any medium sized OO-System
>> would be much different from that just because it's Ada.
>
>First, lets get a view that doesn't hide the structure:
>
>TObject
>   TView
>     TScrollBar
>     TStaticText
>       TLabel
>       TParamText
>     TInputLine
>     THistory
>     TCluster
>       TRadioButtons
>       TCheckBoxes
>       TMultiCheckBoxes
>     TListViewer
>       TListBox
>       THistoryViewer
>     TGroup
>       TWindow
>         THistoryWindow
>         TDialog
>
>Let's actually put our Ada hats on and look at that hierarchy.  The 
>TObject vs. TView looks to be methodological not logical.

It is kind of both, TObject has some more children (I mentioned it's
just a part of the whole hierarchy, but to post the whole hierarchy
would probably take a *lot* of lines), TView is simply the base object
for anything that has a Draw method to show itself on the screen, the
other children are objects that are not visible (like TPoint,
TRect[angle] or TValidator). IIRC, the reason all these are derived
from an empty base object is that the VMT has to be on the same place
for storing and loading these objects in/from streams for them. So the
decision for TObject/TView can be considered as a pure implementation
issue.

>Notice that 
>there is a descendent TListViewer, which is the only view related direct 
>child.)

It's just the name. Any children of TView can be displayed. :)

>TView has seven children.

In fact it has more.

>  If you redid this in Ada, I don't 
>know if TCluster and TGroup would remain as 'real' children but I am 
>sure that TWindow would get elevated.

Despite the quite similar name, this has very good reasons, TGroup is
for Objects that can be linked together, send their messaged through
and have appropriate Select/SelectNext methods whilst TCluster are
just objects that have a Mark method for selecting items (the
classical Radiobuttons and Checkboxes).

>  A typical Ada Model-View 
>hierarchy would have Object and View as parents and most other types 
>descended from one or the other.

Well, I don't think so. If I would redo Borland's stuff from scratch
it would probably look different but not *that* different.

>Of course, if I were to reimplement this hierarchy in Ada, I'd try as 
>hard as possible to keep the original structure.

Yes, and then you would encounter that when you do your own DialogBox
you have to call its parent's Init-Constructor (because this one will
initialize the color scheme, border, title bar and such things that
you don't want to do each time by yourself). And when after then you
decide that you implement a Dialog Box that always displays an
Ok-Button and insert it into the hierarchy inbetween your Fancy_Dialog
and the TDialog object you will encounter the problem that the
Ok-Button doesn't display because you still call the TDialog's Init
instead of the TDialog_OkBox's Init. This is where the "inherited"
keyword comes handy, so the compiler automatically selects the
TDialog_OkBox's Init and if this isn't implemented in a particular
case (in this example it would be) it selects the TDialog's Init
instead and so on... So you wouldn't have to change the code of your
new Fancy_Dialog just because you decided to save the work to insert
the Ok-Button in any of your own Dialog manually [Dialogs badly *need*
an Ok-Button, don't they? ;-)] and instead introduce another
Dialog-object in the hierarchy to do that automatically for you.

>I might or might not 
>manage to swallow the naming convention though. ;-)

Well yes, because having Pxxx for the pointer types to their Txxx
wouldn't be necessary, I guess.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ada 200X

[Robert I. Eachus]

Vinzent Hoefler wrote:

 > This is where the "inherited" keyword comes handy...

I got to this point and suddenly realized why none of what Vinzent said 
was tracking.  Everything he said had nothing to do with Ada. In Ada 
most methods are inherited by default.

There is a special exception for functions which return a value of the 
tagged type which is being derived from.  In that case the function is 
inherited as an abstract operation, so that if you want to use it you 
must provide a body.  This is because you normally will need additional 
initialization code in the child.  If not:

       type Foo is tagged record
         ...
       end record;

       function Create(...) return Foo;
       procedure Print(F: in Foo);
       ...
       type Bar is new Foo with null record;
       -- at this point there is a Create which returns Bar, but it
       -- doesn't work.  There is an implicitly declared Print, and
       -- it can be called immediately.

       function Create(...) return Bar;
       ...
       function Create(...) return Bar is
       -- It would be nice to be able to say here:
       -- begin return Foo(Bar'(Create(...)); end Create;
       -- but the rules of the language don't allow downward conversions
       -- of tagged types, even if the child has no new fields. :-(

However, for the Print procedure I don't have to do anything special. 
It can be called on an object of type Bar by anyone who has a with 
clause for the package declaring Bar, even if there is no with clause 
for the package specifying the Print procedure.

So Vinzent if you try to reimplement this hierarchy in Ada you will 
learn a lot, including how easy it is.  But you will also find that some 
things which are classes in other languages are better handled as 
mix-ins in Ada.  Mix-ins are perfect for attributes and behavior that 
cut across a normal class hierarchy.  For example you could make 
radio_buttons a mix-in instead of a separate class.  Then for objects 
(windows) that need radio buttons you can mix in as many buttons as a 
particular window type or singleton instance needs.

Re: Ada 200X

[Wesley Groleau]

>>...I think many would be happy to break that rule for >GNAT.IO_Aux.Get_Line, since
>>there is no other way to read in a Ada string without knowing in
>>advance its size...

function Get_String (...parameters...) return String is

    Temp : String (1 .. Some_Huge_Number);

begin

   Operation_That Reads_Characters
   (Into       => Temp,
     Last_Read => Last,
     ... other_params ... );

   return Temp (Temp'First .. Last);

end Get_String;

Re: Ada 200X

[Preben Randhol]

And838N@netscape.net wrote:

> There was one other issue I came across when writing my first Linked
> list in Ada.  There is no "this" keyword.  It didn't take long for me
> to realize that a class in Ada is not at all like a class as I
> understand from college (C++, Java).  The "flavor" of an Ada was C
> struct like to me and required passing "my" instance as a parameter to
> a procedure of function in a package so that I could use "this".  

Read http://www.adapower.com/articles/class.html for an explanation of
this.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ada 200X

[Georg Bauhaus]

And838N@netscape.net wrote:
: 
: I've heard professors say they don't like Ada because it's slow and
does all those "bounds" checking "things".  My opinion is; take a look
at the bugs in MS code that lead to viruses because of buffer exploits
and unchecked "bounds".  Ada just seems a smart way to go, especially
with newer faster processors.  Most people don't recognize the speed up
anyway unless the go from 300MHz to a 2.4GHz.
 
It's not slow either due to checks, because checking is under your control.
If you are sure you don't need them, configure them away, or add
a pragma.

: I've been working with Ada seriously for about a month now and the more
I learn the more I like it.  It does not have the flavor of a "business"
type language, even though it is perfectly useable for such applications.

It does have built in decimal types and accompanying packages;
builtin concurrency support (working, well defined) is also easily
overlooked (perhaps because it is not present in popular languages,
or not working well :-)

Re: Ada 200X

[Steve]

<And838N@netscape.net> wrote in message
news:mailman.5.1054503443.12990.comp.lang.ada@ada.eu.org...
[snip]
> I'm pretty new to Ada but I have been using and tutoring C,C++, Java for
over 5 years now.  When I decided to "try out" Ada one of the first things I
noticed was the String problem as Warren described.  My solutions was to
write procedures (functions) in a package that took a parameter of type
String, then overloaded that procedure to use Unbounded_String and so on so
that I could use whatever I was comfortable with.  I even overloaded
procedures and functions to take the String_Access.  Anyway, my point is,
for users coming out of C, C++, Java, like me, it would be a TREMENDOUS help
to make the "String" transition easier.
>

When I was new to Ada, I started using Bounded_String's instead of
Unbounded.  But considered dealing with strings to be a pain.  I've become
used to working with strings in Ada, but I still find them somewhat awk
award.

> There was one other issue I came across when writing my first Linked list
in Ada.  There is no "this" keyword.  It didn't take long for me to realize
that a class in Ada is not at all like a class as I understand from college
(C++, Java).  The "flavor" of an Ada was C struct like to me and required
passing "my" instance as a parameter to a procedure of function in a package
so that I could use "this".
>

I consider the missing "this" to be a misconception.  After years of
programming using "types" and "variables" C++ started using the same thing,
re-arranging the syntax a little, permitting inheritance, and re-branding
"types" as "classes" and "variables" as "instances".

In C++ you have:
  hdc.DrawLine( x1, y1, x2, y2 );

In Ada you have:
  DrawLine( hdc, x1, y1, x2, y2 );

They are really just different syntactic ways of representing exactly the
same thing.

> My view may be somewhat biased because I'm new to Ada but the idea of an
Ada class doesn't seem like a class to me at all.  It seems like putting a
bunch of C methods and a struct definition into a .c file and compiling it
and calling it a class.  There's obviously more to Ada than that but I
described how it "seemed" for someone trying to move to Ada.
>
> My purpose for moving to Ada is all the hype about reducing the cost of
maintenance and the quicker development time.  I read a bunch of articles on
how Ada is superior to other languages because once you learn it your
development goes quicker and the end result requires less maintenance.  Two
key things if I want to play in a global market against "inexpensive"
programmers/engineering firms in places like India.
>
> I've heard professors say they don't like Ada because it's slow and does
all those "bounds" checking "things".  My opinion is; take a look at the
bugs in MS code that lead to viruses because of buffer exploits and
unchecked "bounds".  Ada just seems a smart way to go, especially with newer
faster processors.  Most people don't recognize the speed up anyway unless
the go from 300MHz to a 2.4GHz.
>

It's unfortunate that these views come out professors these days.  It's no
wonder software reliability hasn't increased over time.

> I've been working with Ada seriously for about a month now and the more I
learn the more I like it.  It does not have the flavor of a "business" type
language, even though it is perfectly useable for such applications.  But
sometimes the "flavor" of the language is almost as important as the
language itself!  Especially if you want to open the "market" up.
> Making Ada easy to transition to would be something to consider in
Ada200X, IMHBiasedO.

A good place to start is to learn the language well.  And then add a few
more cents.

Steve
(The Duck)

Re: Ada 200X

[Gautier Write-only]

And838N@netscape.net wrote:

> I've heard professors say they don't like Ada because it's slow and does all those
> "bounds" checking "things".

They are misinformed: Ada is slow when the bounds checking is ON.
After some debugging phase, if you want, you can turn all checkings OFF !
And as you point out, better to have the possibility of bounds checking than not...
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Ada 200X

[Vinzent Hoefler]

Gautier Write-only wrote:

>And838N@netscape.net wrote:
>
>> I've heard professors say they don't like Ada because it's slow and does all those
>> "bounds" checking "things".
>
>They are misinformed: Ada is slow when the bounds checking is ON.

Well, I beg to differ. In many areas it makes not much difference
because bounds checking is usually quite cheap, because in correct
programs the jumps are never taken. :-)

In some particular heavy calculation where bounds checking takes a
quite large amount of the actual code (consider a simple loop with
just "i := i + 1" in it) you might indeed feel a difference, but
usually I don't.

The main problem I see is that it might make a program substantially
larger.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ada 200X

[Preben Randhol]

Gautier Write-only wrote:
> And838N@netscape.net wrote:
> 
>> I've heard professors say they don't like Ada because it's slow and
>> does all those "bounds" checking "things".
> 
> They are misinformed: Ada is slow when the bounds checking is ON.

Well I wouldn't say Ada is slow. I think C would be just as slow if it
*had* bounds checking.

> After some debugging phase, if you want, you can turn all checkings
> OFF !  

However be extremely careful with this. 

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ada 200X

[Lutz Donnerhacke]

* Preben Randhol wrote:
> Well I wouldn't say Ada is slow. I think C would be just as slow if it
> *had* bounds checking.

No. C has to do much more checks, because the compiler can not deduce when
the checks are not necessary.

Re: Ada 200X

[Preben Randhol]

Lutz Donnerhacke wrote:
> * Preben Randhol wrote:
>> Well I wouldn't say Ada is slow. I think C would be just as slow if it
>> *had* bounds checking.
> 
> No. C has to do much more checks, because the compiler can not deduce when
> the checks are not necessary.

Ok my point only that C would be even slower. :-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ada 200X

[Craig Carey]

On Tue, 3 Jun 2003 12:14:43 +0000 (UTC), Lutz Donnerhacke <lutz@iks-jena.de>
 wrote:

>* Preben Randhol wrote:
>> Well I wouldn't say Ada is slow. I think C would be just as slow if it
>> *had* bounds checking.
>
>No. C has to do much more checks, because the compiler can not deduce when
>the checks are not necessary.


GCC seemed faster in my tests where checking was disabled narrowly and
it was on by default. The speed difference can be under 12%. But without
the disabling of checking, GNAT Ada can easily be 30% slower.

In GNAT, checks can be enabled with the '-gnato -gnata' compiler option.

Then they can be turned off as desired using "pragma Suppress (...);",
ref RM 11-5:

   http://www.adaic.org/standards/95aarm/html/AA-11-5.html  

---

Some sample techniques for speeding up some Ada 95 programs:

* Suppressing the 'Index_Check' and 'Range_Check' checks can produce
  speed ups in numerical code. E.g. >20% speed improvement.

* Changing the types of variables from "Integer" to, say, "Positive",
"Natural", can speed up code if it reduces checking on bounds.

* Use of the "renames" statement (to rename variables) is often
worthwhile. It seems to me that use of "renames" does not slow down GNAT
code. "pragma Suppress" can slow code down. If optimizing is disabled
then "pragma Inline" can slow the final code down (but it seems unlikely
to slow down optimized GNAT code).

* I used the REDLOG Quantifier Eliminator to permit the safe adding of
 "pragma Suppress()" to a procedure that implemented a "Replace_Slice()"
for a strings package. A problem I had was the the string code in the
Charles package of Mr Heaney was too fast in comparison, which was
resolved by suppressing range checking.

      pragma Suppress (Index_Check);
      pragma Suppress (Length_Check);
      pragma Suppress (Range_Check);
      pragma Suppress (Access_Check); --  Already fast
   ...
      <<REDO_RENAME>>
      declare
         pragma Suppress (Overflow_Check);
         Str      : Vs_String renames Source.Str.all;
      begin
         if Str'Length < New_Len then
            --  Lengthen the string and alter the pointer, Source.Str
            goto REDO_RENAME;   --  Guarantee correct and rename again
         end if;

* The GNAT low level routines to process strings tend to be much faster
than user-side "for" loops subject to pragma Suppress (Index_Check,
Range_Check).

   Note: GNAT's slicing of strings is not perfected; i.e. adding
   "if .. then .. else" code to convert "S (P .. Q) := T;" and
   S := T (U .. V);", into "S := T;" can be produce a decent speed up
   for a String "Assign (L, R) procedure. (Definitely can't use ":="
   due to unexplained historic inefficiency encouraged by RM 7.6's spec
   having the missing Assign () procedure be implemented with Finalize()
   and Adjust(). 

* Turning off tag checking if tagged types are used. E.g. if dispatching
on procedures is avoided and instead "if" (or "case") statements are used:

      if X.all'Tag = A_Rec'Tag then                   --  A & no B fields
         X.all.Value := not X.all.Value;
      else
         declare          --  B_Rec case. Make visible the 2 B_Rec fields
            pragma Suppress (Tag_Check);
            B        : B_Rec renames B_Rec (X.all);   --  Both A & B fields
         begin

* Adding "pragma Inline" if optimizing enabled.

* Having arrays be on the stack and not on the heap
  ("... is array (Positive range <>) of ...") can be perhaps >=3% faster.

* When multiplying two matrices, "pragma Suppress (Index_Check);" can be
added, and the code to check the sizes of the arrays can be explicit.
Also "for K in X'Range (2) loop" could be faster than
     "for K in 1 .. X'Last (2) loop".


Craig Carey
The latest ARG considerations on reforming Ada 95:
   http://www.ada-auth.org/ai-files/REST_AIS.ZIP

Re: Ada 200X

[Martin Dowie]

"Craig Carey" <research@ijs.co.nz> wrote in message
news:jvf4evgqd71kuqeoc2c2c81mdcck01g8qa@4ax.com...
> * I used the REDLOG Quantifier Eliminator to permit the safe adding of
>  "pragma Suppress()" to a procedure that implemented a "Replace_Slice()"
> for a strings package. A problem I had was the the string code in the
> Charles package of Mr Heaney was too fast in comparison, which was
> resolved by suppressing range checking.

Sorry, can you expand on the 'too fast' statement?!?! :-)

Re: Ada 200X

[Craig Carey]

On Sun, 8 Jun 2003 11:14:28 +0000 (UTC), "Martin Dowie"
    <martin.dowie@no.spam.btopenworld.com> wrote:
...
>> for a strings package. A problem I had was the the string code in the
>> Charles package of Mr Heaney was too fast in comparison, which was
>> resolved by suppressing range checking.
>
>Sorry, can you expand on the 'too fast' statement?!?! :-)
>
Those packages are here:
http://home.earthlink.net/~matthewjheaney/charles/
http://www.ijs.co.nz/code/ada95_strings_pkg.zip (19KB

My strings package was intended to to be fast and open.
Mr H's need not be fast (but may be). The idealism includes that of
having functions return a private type (implying slicing is hidden
in the package).

Is MinGW too slow ?. Maybe someone could fix it perhaps.

The Charles code resizes strings using a factor of 2.0 (i.e. 100%).
I used 1.70 (70%) after some testing (in Windows 2000).

In 2003, the GCC compiler defaulted to using this figure for some
resizing of its garbage collector (ref gcc/gcc/doc/):

The resize factor is: Min (30% + 70% * (RAM / 1GB), 100%).

In my strings package, values outside of 1.6 and 2 (to 2.2) were
clearly slower.

So assuming a cut-off of 1.57, then MinGW GCC in Windows is suboptimally
slow when there is less 395 MB of RAM. MinGW does not have that parameter.

GNAT has a big factor of 2 so no mistakes there.


At 2003\01\27 13:01 -0600 Monday, Benjamin Kosnik wrote to gcc@gcc.gnu.org:
>
>time make
>248.736u 26.373s 4:59.60 91.8%  0+0k 0+0io 503943pf+0w
>
>time make CXXFLAGS="--param ggc-min-heapsize=8192"
>214.521u 27.306s 4:10.44 96.5%  0+0k 0+0io 512759pf+0w
>
>time make CXXFLAGS="--param ggc-min-heapsize=16384 --param ggc-min-expand=50"
>193.816u 30.121s 3:49.56 97.5%  0+0k 0+0io 524642pf+0w
>
>Erp. So, with these flags I can save a minute each recompile. C++
>compiles on templatized code end up being 25% faster.
>
>Aaaaaaaaaaghh!!!!!! Why aren't these flags documented!!!! Why aren't
>the defaults sane???
>
>-benjamin

Re: Ada 200X

[Matthew Heaney]

Craig Carey <research@ijs.co.nz> wrote in message news:<u3f8ev87r4rhf55q2j71l6fgnk59ba2b75@4ax.com>...
> >
> Those packages are here:
> http://home.earthlink.net/~matthewjheaney/charles/
> http://www.ijs.co.nz/code/ada95_strings_pkg.zip (19KB
> 
> My strings package was intended to to be fast and open.
> Mr H's need not be fast (but may be). The idealism includes that of
> having functions return a private type (implying slicing is hidden
> in the package).

You can optimize string manipulation by using Resize to preallocate
the internal buffer to a specified size, and by using To_Access to
return a pointer to the internal buffer, which eliminates copying.

The To_String and Slice operations return type String, so of course
this will construct a temporary.  If this is an issue, then use
To_Access to get a pointer to the internal buffer, and then slice that
directly:

procedure Op (SC : String_Container_Subtype) is

   Slow : String := Slice (SC, Low => 10, High => 42);
   Fast : String renames To_Access (SC) (10 .. 42);
begin


> The Charles code resizes strings using a factor of 2.0 (i.e. 100%).
> I used 1.70 (70%) after some testing (in Windows 2000).

Again, by using Resize you can choose the exact size you prefer for
the internal buffer.

As a matter of fact, you could create a pool of string containers,
each of which have different internal sizes, and then use Swap to swap
in an internal buffer having the size you need.  This would eliminate
string buffer allocation entirely.

For the pool you could use a map or set, which is ordered by internal
buffer size.  Finding a buffer would only require O (log n) in the
worst case.

http://home.earthlink.net/~matthewjheaney/charles/

Re: Ada 200X

[Matthew Heaney]

Craig Carey <research@ijs.co.nz> wrote in message news:<jvf4evgqd71kuqeoc2c2c81mdcck01g8qa@4ax.com>...
> 
> Some sample techniques for speeding up some Ada 95 programs:

At least in Charles, you can optimize string and vector container
manipulation by calling Resize, which preallocates the internal
buffer.  This is useful if you know the ultimate size of the
collection apriori:

procedure Op (S : in out String_Container_Subtype) is
begin
   Resize (S, Size => 80); //for example

   Append (S, "first");
   Append (S, "second");
   ...
end Op;

Both the string and vector containers have a To_Access function, which
returns a pointer to the internal buffer.  This allows you to
eliminate copying.  For example, instead of this:

procedure Op (S : in String_Container_Subtype) is
begin
   Put_Line (To_String (S)); -- not as efficient as below
end;

do this instead, if you're really concerned about efficiency:

procedure Op (S : in String_Container_Subtype) is
   Line : String renames To_Access (S) (1 .. Length (S));
begin
   Put_Line (Line);
end;

The string container package guarantees that To_Access always returns
a non-null access object.

The combination of Resize and To_Access should improve efficiency.

Re: Ada 200X

[Robert A Duff]

Preben Randhol <randhol+abuse@pvv.org> writes:

> Gautier Write-only wrote:
> > And838N@netscape.net wrote:
> > 
> >> I've heard professors say they don't like Ada because it's slow and
> >> does all those "bounds" checking "things".
> > 
> > They are misinformed: Ada is slow when the bounds checking is ON.
> 
> Well I wouldn't say Ada is slow. I think C would be just as slow if it
> *had* bounds checking.

Slower, actually, because C can't tell the difference between "pointer
to int" and "pointer to array of int", and would therefore have to store
extra information with every pointer, in general.

- Bob

Re: Ada 200X

[Preben Randhol]

Robert A Duff wrote:
> Preben Randhol <randhol+abuse@pvv.org> writes:
> 
>> Gautier Write-only wrote:
>> > And838N@netscape.net wrote:
>> > 
>> >> I've heard professors say they don't like Ada because it's slow and
>> >> does all those "bounds" checking "things".
>> > 
>> > They are misinformed: Ada is slow when the bounds checking is ON.
>> 
>> Well I wouldn't say Ada is slow. I think C would be just as slow if it
>> *had* bounds checking.
> 
> Slower, actually, because C can't tell the difference between "pointer
> to int" and "pointer to array of int", and would therefore have to store
> extra information with every pointer, in general.

So one could put the spin on it and say that Ada *is* faster because it
has more efficient boundary checks than C. :-) At any rate I hope that
the future will bring more software that has boundary check etc... so
that the software is safe. Like having and using the seatbelt in your
car. :-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ada 200X

[Preben Randhol]

Preben Randhol wrote:
> So one could put the spin on it and say that Ada *is* faster because it
> has more efficient boundary checks than C. :-) At any rate I hope that
> the future will bring more software that has boundary check etc... so
> that the software is safe. Like having and using the seatbelt in your
                    ^^^^^^^
               ... is safer.

> car. :-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ada 200X

[Vinzent Hoefler]

Preben Randhol wrote:

>Preben Randhol wrote:
>
>> the future will bring more software that has boundary check etc... so
>> that the software is safe. Like having and using the seatbelt in your
>                    ^^^^^^^
>               ... is safer.

Funny thing, the human language, isn't it? Uses a stronger form of
"safe" to actually mean a weaker "safe"...


Vinzent.

Re: Ada 200X

[Preben Randhol]

Vinzent Hoefler wrote:
> Preben Randhol wrote:
> 
>>Preben Randhol wrote:
>>
>>> the future will bring more software that has boundary check etc... so
>>> that the software is safe. Like having and using the seatbelt in your
>>                    ^^^^^^^
>>               ... is safer.
> 
> Funny thing, the human language, isn't it? Uses a stronger form of
> "safe" to actually mean a weaker "safe"...

Yes. Although the latter tells it is more safe relative to something
while the prior just states it is safe. I would think Popper would say
that the "is safe" has a higher information value than "is safer" as it
would only need one example of not safe to disprove the "is safe"
claim.  Like saying all swans are white and then go out and finding one
grey.  Then you can say all swans of this type are white. Now this
statment would be weaker in information according to Popper if I recall
Popper's theory correctly.

I also heard on the radio (yes I listen to the radio a lot ;-) ) a
discussion about the use of adjectives. I don't remember the whole
sentence but it was something like:

   ... the walls were very white.
   ... the walls were white.

They showed how the first sentence, while trying to say that the walls
were extremely white actually failed compared to the latter. I think the
reasoning was that the latter sentence is more cold than the prior, it
has no make-up. So yes it is funny with languages :-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Ada 200x

[Adrian Hoe]

Hi,

Is there a website for Ada200x?

Thanks.
-- 
type Dmitry is new Adrian;           -- Adrian Hoe
                                      -- http://adrianhoe.com
                                      -- Remove *nospam* to email

Re: Ada 200x

[Randy Brukardt]

Adrian Hoe wrote in message <3e0b1c78_1@news.tm.net.my>...
>Hi,
>
>Is there a website for Ada200x?

Not per se. What material there is is on the ARG site
(www.ada-auth.org).

       Randy Brukardt
       ARG Editor

Re: Ada 200x

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Adrian Hoe wrote in message <3e0b1c78_1@news.tm.net.my>...
> >Hi,
> >
> >Is there a website for Ada200x?
> 
> Not per se. What material there is is on the ARG site
> (www.ada-auth.org).

Look at the amendment AI's to see the various proposals.
In particular, search for "!class amendment"
and "!status Amendment".

- Bob