point by point advantages of Ada

point by point advantages of Ada

[Russ]

I am looking for a webpage (or any other source) that explains the
advantages of Ada over C++ and/or Java in a point by point manner. I
have seen pages that explain the advantages of Ada in a broad sense,
and I have even seen some that go into some detail, such as
http://www.informatik.uni-stuttgart.de/ifi/ps/AdaBasis/pal_1195/ada/ajpo/intro/9x-cplus.txt
, but I have yet to come across a detailed enumeration of the superior
methods of Ada.

For example, I'd like to see something like this:

1. Ada has compilable interface specifications. The advantage of this
is ...

2. Ada does runtime bound checking. ...

3. Ada has real enumeration types, whereas C and C++  ...

4. Ada allows user-defined types, as opposed to typedefs in C/C++,
which are ...

5. Ada has a more integrated environment, with less dependence on
external utilities such as "make". ...

Suggestions will certainly be appreciated.

Re: point by point advantages of Ada

[Ingo Marks]

Russ wrote:

> I am looking for a webpage (or any other source) that explains the
> advantages of Ada over C++ and/or Java in a point by point manner. I
> have seen pages that explain the advantages of Ada in a broad sense,
> and I have even seen some that go into some detail, such as ...

http://www.adahome.com/articles/1997-03/ada_vs_cpp.html (note that Point 54 
is wrong: Ada95 knows "pragma assert")

http://www.adahome.com/History/Steelman/steeltab.htm
http://www.adaic.com/whyada/ada-vs-c/cada_art.html
http://archive.adaic.com/intro/c.html
http://www.beesknees.freeserve.co.uk/articles/ada-vs-cpp.html

Regards,
Ingo

Re: point by point advantages of Ada

[Keith Thompson]

Ingo Marks <nospam_adv@region-nord.de> writes:
[...]
> http://www.adahome.com/articles/1997-03/ada_vs_cpp.html (note that Point 54 
> is wrong: Ada95 knows "pragma assert")

No, it doesn't.  pragma Assert is a GNAT extension.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: point by point advantages of Ada

[Robert A Duff]

Keith Thompson <kst@cts.com> writes:

> Ingo Marks <nospam_adv@region-nord.de> writes:
> [...]
> > http://www.adahome.com/articles/1997-03/ada_vs_cpp.html (note that Point 54 
> > is wrong: Ada95 knows "pragma assert")
> 
> No, it doesn't.  pragma Assert is a GNAT extension.

There's an AI that makes pragma Assert part of the language.
I don't know it's status, so I don't know if it is now part
of the language, or will be someday.  But I think most compilers
implement it -- not just GNAT.

- Bob

Re: point by point advantages of Ada

[Colin Paul Gloster]

I sent you an attachment-less email which bounced, so the scans I was
about to email you would not be likely to get through promptly by email
either. Perhaps you could help me to help you by providing some channel
through which I can send these to you.

By email I sent:

"Dear Russ,

I hope you succeed in championing safer software.

Due to poor OCR results today, I will in a moment email you an image taken
by a scanner of a chart which I got off Helen Byard of Ada Language UK
Limited some years ago, and images of a 22 page paper on OOP in Ada and
C++ she had sent me at the same time. She was the administrator of that
organization at the time. Instead, the group is now to be contacted via
Ada UK User Group, c/o Adaxia Limited, PO Box 376, Chesterfield, S42 7YB,
United Kingdom, fax: +44 1246 567339, adauk@Adaxia.com ,
HTTP://WWW.AdaUK.org.UK .

(I am not sending the attachments with the email you are now reading
because I do not want about one megabyte of my outbox taken up by them.)

Parts of the chart are out of date to the extent that C++ is unfairly
criticized. In particular...

Dispatching in C++ does have an expressive advantage over dispatching in
Ada 95.

Modern C++ libraries might have thread-safe exceptions.

ISO C++ does have generics (called templates in the context of C++).

There is an ISO standard for C++ (which does not yet have a full
implementation after several years).

Back to dispatching again, below is an edited reproduction of a post made
by a C++ and Ada tool vendor:

Date: Wed, 20 Nov 2002 12:51:31 -0000

"I'll back this up. I'm just in the middle of defining a "true OO" mapping
from Ada to UML. While Ada does have some useful features such as dynamic
dispatching, its cockeyed notion of sub-program roll-down is awesomely
stupid. Can you imagine a language that decides to roll-down an operation
based on the data-type of any of its parameters? but does so for only one
of
its parameters even though multiple parameters can exist? 

For instance

package a is
-- tagged means that operations defined to 
-- use this type can be overridden
  type t1 is tagged 
    record
      x : integer;
    end record;
  type t2 is tagged 
    record
      y : integer;
    end record;
  procedure p (P1 : t1);
  procedure q (P1 : t2);
  procedure r (P1 : t1; P2 : t2);
  procedure s (P1 : t1; P2 : t1);
end a;

In this example, procedure p and q are both legal, but procedure r is not.
Procedure s is legal. The problem is that you've defined all these
functions
as "virtual" because one of their parameters is "tagged", but you have no
way to tell the compiler which parameter you are supposed to dispatch on.
The compiler gets confused because procedure r has 2 different
dispatchable
parameters and doesn't know which one is significant.  

By comparison, in C++, the implicit "this" parameter exists for all
non-static functions, and it is the type of "this" that is used to decide
dispatching behaviour. Nice, straightforward, and you can't get the
compiler
confused.

Now why was it that anyone wanted to program in Ada?

Cheers,
	[..individual alpha]

-----Original Message-----
From: [..individual beta]
Sent: 20 November 2002 11:30
To: [..that list]
Subject: [some subject..]


> From: Peter Hermann [mailto:ica2ph@csv.ica.Uni-Stuttgart.De]

> Non-member of the ACCU 

(fairly obviously!)

> Peter Hermann

> "Colin,
> it is unbelievable how people waste their time with
> discussions
> of pitiful contents; and waste their time with programming
> languages
> requiring 3 to 5 times more time to get it right instead of
> using Ada.

Oops! What fools we must look :-)

Let's "just" use Ada then!

[..individual beta, who does not work for a vendor involved with Ada]"

May better solutions triumph!
Colin Paul Gloster

From: 18k11tm001@sneakemail.com (Russ)
Newsgroups: comp.lang.ada
Subject: point by point advantages of Ada
Date: 26 Dec 2002 13:57:23 -0800
Message-ID: news:bebbba07.0212261357.42a817b4@posting.google.com

"I am looking for a webpage (or any other source) that explains the
advantages of Ada over C++ and/or Java in a point by point manner. I
have seen pages that explain the advantages of Ada in a broad sense,
and I have even seen some that go into some detail, such as
http://www.informatik.uni-stuttgart.de/ifi/ps/AdaBasis/pal_1195/ada/ajpo/intro/9
, but I have yet to come across a detailed enumeration of the superior
methods of Ada.

For example, I'd like to see something like this:

1. Ada has compilable interface specifications. The advantage of this
is ...

2. Ada does runtime bound checking. ...

3. Ada has real enumeration types, whereas C and C++  ...

4. Ada allows user-defined types, as opposed to typedefs in C/C++,
which are ...

5. Ada has a more integrated environment, with less dependence on
external utilities such as "make". ...

Suggestions will certainly be appreciated.""

Re: point by point advantages of Ada

[chris.danx]

Russ wrote:
> I am looking for a webpage (or any other source) that explains the
> advantages of Ada over C++ and/or Java in a point by point manner. 

In what area of application?


-- 
for personal replies change spamoff to chris

Re: point by point advantages of Ada

[James S. Rogers]

"Colin Paul Gloster" <Colin_Paul_Gloster@ACM.org> wrote in message
news:1041186672.615164@ns2-ext.dcu.ie...
> Back to dispatching again, below is an edited reproduction of a post made
> by a C++ and Ada tool vendor:
>
> Date: Wed, 20 Nov 2002 12:51:31 -0000
>
> "I'll back this up. I'm just in the middle of defining a "true OO" mapping
> from Ada to UML. While Ada does have some useful features such as dynamic
> dispatching, its cockeyed notion of sub-program roll-down is awesomely
> stupid. Can you imagine a language that decides to roll-down an operation
> based on the data-type of any of its parameters? but does so for only one
> of
> its parameters even though multiple parameters can exist?
>
> For instance
>
> package a is
> -- tagged means that operations defined to
> -- use this type can be overridden
>   type t1 is tagged
>     record
>       x : integer;
>     end record;
>   type t2 is tagged
>     record
>       y : integer;
>     end record;
>   procedure p (P1 : t1);
>   procedure q (P1 : t2);
>   procedure r (P1 : t1; P2 : t2);
>   procedure s (P1 : t1; P2 : t1);
> end a;
>
> In this example, procedure p and q are both legal, but procedure r is not.
> Procedure s is legal. The problem is that you've defined all these
> functions
> as "virtual" because one of their parameters is "tagged", but you have no
> way to tell the compiler which parameter you are supposed to dispatch on.
> The compiler gets confused because procedure r has 2 different
> dispatchable
> parameters and doesn't know which one is significant.
>
> By comparison, in C++, the implicit "this" parameter exists for all
> non-static functions, and it is the type of "this" that is used to decide
> dispatching behaviour. Nice, straightforward, and you can't get the
> compiler
> confused.
>
> Now why was it that anyone wanted to program in Ada?

This is a curious complaint about Ada. The author complains that Ada
cannot do something that C++ cannot do, then concludes that this shows
a superiority of C++ over Ada.

The solution for such a need is basically the same in both C++ and Ada.
C++ provides no multiple dispatch capability. You must make such a
function static, not virtual. In Ada you do the same thing. You simply
define the procedure(s) taking more than one tagged type in another
scope. An inner package is a common choice for another scope.

package Tagged_Test is
   type A is tagged private;
   procedure Print(Item : A);
   type B is tagged private;
   procedure Print(Item : B);
   package Inner is
      procedure Print(Itema : A; Itemb : B);
   end Inner;
private
   type A is tagged record
      Message : String(1..6) := "Type A";
   end record;
   type B is tagged record
      Message : String(1..6) := "Type B";
   end record;
end Tagged_Test;

What the original author does not mention is that C++ cannot dispatch
based upon the return type of a function. This is done cleanly in Ada and
not at all in C++ (or Java).

In C++ you need to explicitly label a function as "virtual". The default is
"static". In Java the default is the equivalent of virtual, and you must
explicitly label "static" functions with the "static" keyword. In Ada
functions are primitive to a type if they are declared in the same scope
as the declaration of the type. That is, the "primitive" property is defined
by scope, and not by the presence or absence of a reserved word.
This is different from C++ and Java, but those languages also differ
from each other. Such differences do not prove superiority.

Jim Rogers

Re: point by point advantages of Ada

[Hyman Rosen]

Colin Paul Gloster wrote:
> Dispatching in C++ does have an expressive advantage over dispatching in
> Ada 95.

Does it? As far as I know, the mechanisms are exactly the same,
even though the syntactic expression is different. I wouldn't
characterize C++'s way as a particular advantage, notwithstanding
the (snipped) argument below.

> Modern C++ libraries might have thread-safe exceptions.

Threads are not part of the Standard, but when implementations
support them, I believe exceptions work correctly, and don't
interfere with other threads.

> ISO C++ does have generics (called templates in the context of C++).

And arguably better than Ada's version.

> There is an ISO standard for C++ (which does not yet have a full
> implementation after several years).

Fortunately, this has just become no longer true. The compiler sold
by Comeau, featuring a front end created by the Edison Design Group
and a library built by Dinkumware, now supports Standard C++ in its
entirety.

Re: point by point advantages of Ada

[John R. Strohm]

Hm.

It just occurs to me.

Why is it that we never hear complaints about C++ being a language "designed
by a committee", given the HUGE expansion of the language during the ISO
"standardization" process?

If the ISO standardization had been just that, standardizing current usage,
all of the existing compilers should have become standard-compliant almost
immediately.  Instead, the ISO committee undertook a HUGE expansion of the
language, and, as a direct result, it has taken YEARS for the FIRST compiler
to become compliant, and Comeau isn't exactly one of the mainstream vendors.

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:vcKP9.5429$Xc.2860@nwrddc04.gnilink.net...
> Colin Paul Gloster wrote:
> > Dispatching in C++ does have an expressive advantage over dispatching in
> > Ada 95.
>
> Does it? As far as I know, the mechanisms are exactly the same,
> even though the syntactic expression is different. I wouldn't
> characterize C++'s way as a particular advantage, notwithstanding
> the (snipped) argument below.
>
> > Modern C++ libraries might have thread-safe exceptions.
>
> Threads are not part of the Standard, but when implementations
> support them, I believe exceptions work correctly, and don't
> interfere with other threads.
>
> > ISO C++ does have generics (called templates in the context of C++).
>
> And arguably better than Ada's version.
>
> > There is an ISO standard for C++ (which does not yet have a full
> > implementation after several years).
>
> Fortunately, this has just become no longer true. The compiler sold
> by Comeau, featuring a front end created by the Edison Design Group
> and a library built by Dinkumware, now supports Standard C++ in its
> entirety.
>

Re: point by point advantages of Ada

[Hyman Rosen]

John R. Strohm wrote:
> Why is it that we never hear complaints about C++ being a language "designed
> by a committee", given the HUGE expansion of the language during the ISO
> "standardization" process?

Probably because the people given to such carping don't know enough
about C++ to realize that this is the case!

> If the ISO standardization had been just that, standardizing current usage,
> all of the existing compilers should have become standard-compliant almost
> immediately.  Instead, the ISO committee undertook a HUGE expansion of the
> language, and, as a direct result, it has taken YEARS for the FIRST compiler
> to become compliant, and Comeau isn't exactly one of the mainstream vendors.

True enough. On the other hand, we C++ programmers have been plugging along
quite usefully in the mean time. It's actually taken almost as long for
people to begin writing code that hits the difficult parts of the language.
To a certain extent, the compiler writers have been waiting for code that
would teach them the language. Anyway, Microsoft is feverishly working on
getting their compiler Standard-compliant. And I beliver the expanded form
of the language is vastly superior in most cases to the then current usage,
so I'm glad the committee did what it did.

Re: point by point advantages of Ada

[Wes Groleau]

>> Why is it that we never hear complaints about C++ being a language 
>> "designed
>> by a committee", given the HUGE expansion of the language during the ISO
>> "standardization" process?

Speaking as an "outsider" (and therefore probably wrong)
it looks like it was not designed by committee, but rather
by a large number of enthusiastic users throwing in every
'kitchen-sink' feature that suited their fancy.

> To a certain extent, the compiler writers have been waiting for code that
> would teach them the language. .....

In other words, they have job openings in
quality control--and the formal title of
the open position is "customer."

Re: point by point advantages of Ada

[Hyman Rosen]

Wes Groleau wrote:
> by a large number of enthusiastic users throwing in every
> 'kitchen-sink' feature that suited their fancy.

Or by a bunch of people asking Bjarne Stroustrup to add features.

>> To a certain extent, the compiler writers have been waiting for code that
>> would teach them the language. .....
> 
> In other words, they have job openings in quality control
 > --and the formal title of the open position is "customer."

It's not exactly a quality control problem. C++ has a number of nooks
and crannies where some very esoteric stuff has to be implemented by the
compiler. It takes a very close reading of the standard to figure some
of these out, so without code that tries to use these features, it's
possible for compiler writers to not even know that they exist.

One big problem is that the C++ standardization process did not result
in a rationale. It's likely that a lot of examples were discussed during
the standardization process, but then were not made available for
implementors to see.

Re: point by point advantages of Ada

[Wes Groleau]

>> by a large number of enthusiastic users throwing in every
>> 'kitchen-sink' feature that suited their fancy.
> 
> Or by a bunch of people asking Bjarne Stroustrup to add features.

Same difference.  He could work for Toyota: "You asked for it--you got it!"

Ada 95 has been accused of that--BUT Ada 95 had
(plug your ears!) a _committee_ that kept out
at least some of the cruft.

Now, I do not know Bjarne Stroustrup personally,
so it's entirely possible he rejected lots of cruft.
But looking at C++, it sure looks like a poorly integrated
mass of not-always-related features.  (Disclaimer: spoken
by someone who has only debugged, not written C++)

> compiler. It takes a very close reading of the standard to figure some
> of these out, so without code that tries to use these features, it's
> possible for compiler writers to not even know that they exist.

OK, I'll grant you that.  Why should a compiler writer
waste time reading the standard when application coders
will do it for him?

Re: point by point advantages of Ada

[David Thompson]

James S. Rogers <jimmaureenrogers@worldnet.att.net> wrote :
...
> The solution for such a need is basically the same in both C++ and Ada.
> C++ provides no multiple dispatch capability. You must make such a
> function static, not virtual. In Ada you do the same thing. You simply
> define the procedure(s) taking more than one tagged type in another
> scope. An inner package is a common choice for another scope.
>
static is not the opposite of virtual, see below.  In C++ you can allow
the normal, implicit dispatch on one type (virtual) and do the other(s)
explicitly; or have a nonvirtual function that does both/all.  Yes in Ada
the options are effectively the same.

...
> What the original author does not mention is that C++ cannot dispatch
> based upon the return type of a function. This is done cleanly in Ada and
> not at all in C++ (or Java).
>
Ada uses return type to resolve overloading (at compile time), but
not to dispatch (possibly at run time).  (C++ and Java do neither.)

> In C++ you need to explicitly label a function as "virtual". The default is
> "static". In Java the default is the equivalent of virtual, and you must
> explicitly label "static" functions with the "static" keyword. In Ada
> functions are primitive to a type if they are declared in the same scope
> as the declaration of the type. That is, the "primitive" property is defined
> by scope, and not by the presence or absence of a reserved word.
> This is different from C++ and Java, but those languages also differ
> from each other. Such differences do not prove superiority.
>
C++ virtual and Java *final* are opposites, and yes the default is
reversed, but *static* (in both) is quite different -- it specifies methods
or variables which are per-class not per-instance.  (As well as having
other meanings in C++, and C, for things not in a class.)

--
- David.Thompson 1 now at worldnet.att.net

Re: point by point advantages of Ada

[James S. Rogers]

"David Thompson" <david.thompson1@worldnet.att.net> wrote in message
news:24oS9.30853$p_6.2594702@bgtnsc04-news.ops.worldnet.att.net...
> James S. Rogers <jimmaureenrogers@worldnet.att.net> wrote :
> ...
> > The solution for such a need is basically the same in both C++ and Ada.
> > C++ provides no multiple dispatch capability. You must make such a
> > function static, not virtual. In Ada you do the same thing. You simply
> > define the procedure(s) taking more than one tagged type in another
> > scope. An inner package is a common choice for another scope.
> >
> static is not the opposite of virtual, see below.  In C++ you can allow
> the normal, implicit dispatch on one type (virtual) and do the other(s)
> explicitly; or have a nonvirtual function that does both/all.  Yes in Ada
> the options are effectively the same.

Another difference in C++ is that a static function does not contain
an implicit "this" variable. This means that static function calls resemble
Ada subprogram calls in the fact that all the parameters must be
passed between the parentheses.

>
> ...
> > What the original author does not mention is that C++ cannot dispatch
> > based upon the return type of a function. This is done cleanly in Ada
and
> > not at all in C++ (or Java).
> >
> Ada uses return type to resolve overloading (at compile time), but
> not to dispatch (possibly at run time).  (C++ and Java do neither.)

Quoting from "Ada as a Second Language" by Cohen:
"If a primitive function of a type T has a result of type T, but no
parameters
of type T or access T, a call on the function can be either nondispatching
or
dispatching depending on the context."

This is clearly more than simple overload resolution.

>
> > In C++ you need to explicitly label a function as "virtual". The default
is
> > "static". In Java the default is the equivalent of virtual, and you must
> > explicitly label "static" functions with the "static" keyword. In Ada
> > functions are primitive to a type if they are declared in the same scope
> > as the declaration of the type. That is, the "primitive" property is
defined
> > by scope, and not by the presence or absence of a reserved word.
> > This is different from C++ and Java, but those languages also differ
> > from each other. Such differences do not prove superiority.
> >
> C++ virtual and Java *final* are opposites, and yes the default is

I stand corrected about the relationship between static and virtual.
Thank you for the correction.

> reversed, but *static* (in both) is quite different -- it specifies
methods
> or variables which are per-class not per-instance.  (As well as having
> other meanings in C++, and C, for things not in a class.)

Static data is similar to data items defined in a package body or
specification in Ada.

Yes, C++ has provided a marvelous set of overloadings for the reserved
word "static", just as Ada has for the reserved word "new".

Jim Rogers

Re: point by point advantages of Ada

[Randy Brukardt]

James S. Rogers wrote in message ...
>"David Thompson" <david.thompson1@worldnet.att.net> wrote in message
>news:24oS9.30853$p_6.2594702@bgtnsc04-news.ops.worldnet.att.net...
>> Ada uses return type to resolve overloading (at compile time), but
>> not to dispatch (possibly at run time).  (C++ and Java do neither.)
>
>Quoting from "Ada as a Second Language" by Cohen:
>"If a primitive function of a type T has a result of type T, but no
parameters
>of type T or access T, a call on the function can be either
nondispatching or
>dispatching depending on the context."
>
>This is clearly more than simple overload resolution.

But it's not quite dispatching on the tag of the result (which you can't
know). But it is dispatching on the tag of result that you need. Here is
a quick example of it:

      type T is tagged ...
      function Build_It (I : in Integer) return T; --(1)
      procedure Copy (Target : out T; Source : in T);

      type NT is new T ...
      function Build_It (I : in Integer) return NT; --(2)
      type NNT is new T ...
      function Build_It (I : in Integer) return NNT; --(3)


      procedure Do_Something (Obj : in out T'Class) is
      begin
           ...
           Copy (Obj, Build_It(10)); -- Here is the dispatching on
result type.
           ...
      end Do_Something;

This call to Copy is dispatching. The first parameter is dynamically
tagged, and the second is tag-indeterminate. Since Build_It has no
dispatching parameters, it takes the tag to dispatch on from the
enclosing call of Copy (RM 3.9.2(18)). That means that if the tag of Obj
is T, then Build_It (1) is called, if Obj is NT, then Build_It (2) is
called, and so on.

This is convinient for constructor functions, because it means that the
right one will automatically be called in a dispatching context. It also
means that the tag check (which insures that both operands have the
correct tag) can't fail for this call, so Constraint_Error can't be
raised by this call. OTOH, I've never actually used this capability in
practice.

                 Randy Brukardt.

Re: point by point advantages of Ada

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> James S. Rogers wrote in message ...
> 
>>"David Thompson" <david.thompson1@worldnet.att.net> wrote in message
>>news:24oS9.30853$p_6.2594702@bgtnsc04-news.ops.worldnet.att.net...
>>
>>>Ada uses return type to resolve overloading (at compile time), but
>>>not to dispatch (possibly at run time).  (C++ and Java do neither.)
>>
>>Quoting from "Ada as a Second Language" by Cohen:
>>"If a primitive function of a type T has a result of type T, but no
> 
> parameters
> 
>>of type T or access T, a call on the function can be either
> 
> nondispatching or
> 
>>dispatching depending on the context."
>>
>>This is clearly more than simple overload resolution.
> 
> But it's not quite dispatching on the tag of the result (which you can't
> know). But it is dispatching on the tag of result that you need. Here is
> a quick example of it:  <snip>

I thought that this might work:

    declare
       V : T'Class := ...
    begin
       ...
       V := Some_Other_Func;  - Dispatching
    end;

But GNAT (at least) reports that this assignment is "ambiguous"
and will not compile it. I would have expected that it would
resolve it at runtime, knowing the current value of V and its
current tag. Is this consistent with the LRM (IANAL)?
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: point by point advantages of Ada

[Richard Riehle]

"Warren W. Gay VE3WWG" wrote:

> I thought that this might work:
>
>     declare
>        V : T'Class := ...
>     begin
>        ...
>        V := Some_Other_Func;  - Dispatching
>     end;
>
> But GNAT (at least) reports that this assignment is "ambiguous"
> and will not compile it. I would have expected that it would
> resolve it at runtime, knowing the current value of V and its
> current tag. Is this consistent with the LRM (IANAL)?

I am not sure if you have tried this, but I often create a function
such as,

             function Get ( ... ) return T'Class;

Then, I initialize the declaration with

             V : T'Class := Get (... );

where the parameter list might be the name of a data structure,
a file, or even a simple array along with the next index.   This
works really well in solving a lot of problems with dispatching.

Richard Riehle

Re: point by point advantages of Ada

[Warren W. Gay VE3WWG]

Richard Riehle wrote:
> "Warren W. Gay VE3WWG" wrote:
>>I thought that this might work:
>>
>>    declare
>>       V : T'Class := ...
>>    begin
>>       ...
>>       V := Some_Other_Func;  - Dispatching
>>    end;
>>
>>But GNAT (at least) reports that this assignment is "ambiguous"
>>and will not compile it. I would have expected that it would
>>resolve it at runtime, knowing the current value of V and its
>>current tag. Is this consistent with the LRM (IANAL)?
> 
> I am not sure if you have tried this, but I often create a function
> such as,
> 
>              function Get ( ... ) return T'Class;
> 
> Then, I initialize the declaration with
> 
>              V : T'Class := Get (... );
> 
> where the parameter list might be the name of a data structure,
> a file, or even a simple array along with the next index.   This
> works really well in solving a lot of problems with dispatching.
> 
> Richard Riehle

Absolutely -- I love this feature. In fact the Booch components
rely on this as well, for the Iterators (I use BC a lot). For
example:

    procedure Close_Widget_List(List : in out WPD.List) is
       Iter :   WPC.Iterator'Class := WPD.New_Iterator(List);
       W :      Widget_Handle;
    begin
       while not WPC.Is_Done(Iter) loop
          W := WPC.Current_Item(Iter); -- Handle of current widget in list
          Close(W);                    -- Destroy the widget and its children
          WPC.Next(Iter);              -- Advance to the next widget in the list
       end loop;
       WPD.Clear(List);                -- Empty the list
    end Close_Widget_List;

Note the WPC.Iterator'Class type.

I was just trying to see if true runtime dispatching could occur
on the return type. It would seem that in my earlier example,
that the V := Some_Other_Func dispatch is fixed at compile
time, if it is not ambiguous.  I suppose that this is the
"safe" thing to do, and probably why it works that way.

But again, I did not try it with AONIX or any other compiler, and
I've not researched the LRM position on this.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: point by point advantages of Ada

[Randy Brukardt]

Warren W. Gay VE3WWG wrote in message <3E1B4C4C.7050205@cogeco.ca>...
>Randy Brukardt wrote:

>I thought that this might work:
>
>    declare
>       V : T'Class := ...
>    begin
>       ...
>       V := Some_Other_Func;  - Dispatching
>    end;
>
>But GNAT (at least) reports that this assignment is "ambiguous"
>and will not compile it. I would have expected that it would
>resolve it at runtime, knowing the current value of V and its
>current tag. Is this consistent with the LRM (IANAL)?

Unfortunately, the LRM has no position on this. This case is not covered
at all by the standard. The ARG has been working (slowly) on an AI to
fix this, and it finally was finished in October and approved at the
recent ARG and WG9 meetings. It's AI-196.
    http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00196.TXT

The solution is essentially to add a paragraph saying that your example
works as you expect. Now, of course, you'll have to wait for Ada
compilers to conform to this ruling. (Which will be helped when an ACATS
test gets added for it.)

               Randy.

Re: point by point advantages of Ada

[Georg Bauhaus]

Wes Groleau <wesgroleau@despammed.com> wrote:
: Now, I do not know Bjarne Stroustrup personally,
: so it's entirely possible he rejected lots of cruft.
: But looking at C++, it sure looks like a poorly integrated
: mass of not-always-related features.

"The C++ Programming Language", by Bjarne Stroustrup, also covers,
in a few remarks, the less pleasing aspects of C++,
in particular the syntax. http://www.research.att.com/~bs/3rd.html.
It is also a useful book if you intend to use the Charles library.

Re: point by point advantages of Ada

[Mark Biggar]

Randy Brukardt wrote:
> Warren W. Gay VE3WWG wrote in message <3E1B4C4C.7050205@cogeco.ca>...
> 
>>Randy Brukardt wrote:
> 
> 
>>I thought that this might work:
>>
>>   declare
>>      V : T'Class := ...
>>   begin
>>      ...
>>      V := Some_Other_Func;  - Dispatching
>>   end;
>>
>>But GNAT (at least) reports that this assignment is "ambiguous"
>>and will not compile it. I would have expected that it would
>>resolve it at runtime, knowing the current value of V and its
>>current tag. Is this consistent with the LRM (IANAL)?
> 
> 
> Unfortunately, the LRM has no position on this. This case is not covered
> at all by the standard. The ARG has been working (slowly) on an AI to
> fix this, and it finally was finished in October and approved at the
> recent ARG and WG9 meetings. It's AI-196.
>     http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00196.TXT
> 
> The solution is essentially to add a paragraph saying that your example
> works as you expect. Now, of course, you'll have to wait for Ada
> compilers to conform to this ruling. (Which will be helped when an ACATS
> test gets added for it.)

This isn't the interesting case anyway.  The interesting case
is where the function is used as a parameter to another subroutine
which has additional dispatching operands.  For example:

Type Set is tagged ...;

function Union(L, R: Set) return Set;
function Empty return Set;

Type Ordered_Set is new Set with ... ;

function Union(L, R: Ordered_Set) return Ordered_Set;
function Empty return Ordered_Set;

S: Ordered_Set'class := ...;

S := Union(S, Empty);

Now, which version of Empty is called is determined by run-time
dispatch depending of whether S is a Set or an Ordered_Set.

-- 
Mark Biggar
mark.a.biggar@attbi.com