C++ virtual function mechanism in Ada ?

C++ virtual function mechanism in Ada ?

[Didier.pieroux]

Hi Ada programmers !

I am learning Ada and I have two questions relative to dynamical dispatching. As
the title said, I have a C++ background but, needless to say, I don't want to
start yet another flamewar on the relative merits of both languages... I just
want to improve my Ada understanding. Heu... yes, I should confess it: I don't
have reached the end of any of the Ada books I am reading in parallel yet. So
perhaps I am really missing something obvious :-(

As most of you know, one of the feature of C++ is the virtual function
mechanism.  It allows the right method to be called on an object of a derived
class whenever it is accessed via a pointer or a reference of a base class.  I
was first naively thinking that Ada primitive operations were playing an
equivalent role... but that's not exactly true.  

For instance, consider the following piece of code.  A tagged type T1 is
declared along with 3 primitive operations: E, F and G.  G prints its name and
calls F that prints its name and calls E that prints its name. A type T2 is also
derived from T1 and E and G are overriden. Note that G still calls the
unoverriden F primitive operation:

-- Better use a fixed size font

package Essai is
type T1 is tagged null record;
procedure E(A: in T1);
procedure F(A: in T1);      
procedure G(A: in T1);   

type T2 is new T1 with null record;
procedure E(A: in T2);
procedure G(A: in T2);
end Essai;

with Ada.Text_Io; use Ada.Text_Io;
package body Essai is
procedure E(A: in T1) is begin Put_line("E1");       end E; 
procedure F(A: in T1) is begin Put("F1:");     E(A); end F;
procedure G(A: in T1) is begin Put("G1:");     F(A); end G;

procedure E(A: in T2) is begin Put_Line("E2");       end E;
procedure G(A: in T2) is begin Put("G2:");     F(A); end G;
end Essai;

with Essai; use Essai;
procedure Main is
V2 : T2;
begin
G(V2);
end Main; 

When I run the program, I get: "G2:F1:E1". I understand well that F(...) has a
formal parameter of type T1 and thus the call E(A) in F(...) is statically
bound. So, this output is the correct one from the Ada point of vue, no problem
with that. Nevertheless, what I wanted was "G2:F1:E2", i.e. that the procedure E
of T2 be called !  This is what would happen in C++ by declaring E virtual.

One way to get the job done is to use:
procedure F(A: in T1) is begin Put("F1:");     E(T1'Class(A)); end F;
That switches the dynamical dispatching on and everybody is happy. But the bad
point is that I have the impression that extending a base type can require
modifications in that base type implementation. Too bad for code reliability,
isn't it ?

So, my first question is: knowing that a characteristic feature of primitive
operations is to call them with objects of a derived type, why did the Ada
designers choose not to use dynamical dispatching when calling a primitive
function ?  I guess that most of the time Ada programmers (as C++ programmers)
want to really call the primitive operation corresponding to the type of the
actual parameter, no ?

Second question... In order to simulate the virtual function mechanism for
primitive operation, I found the following solution.  I declare (non-primitive)
procedures with a class-wide formal argument of the Base type. The only thing
they do is to call the real primitive functions. Elsewhere in the code, these
primitive functions are never called directly but always through the class-wide
procedures. Using this, the package above becomes:


package Essai2 is
type T1 is tagged null record;
procedure E(A: in T1'Class);
procedure F(A: in T1'Class);
Procedure G(A: in T1'Class);

procedure xE(A: in T1);
procedure xF(A: in T1);      
procedure xG(A: in T1);   

type T2 is new T1 with null record;
procedure xE(A: in T2);
procedure xG(A: in T2);

end Essai2;

with Ada.Text_Io; use Ada.Text_Io;
package body Essai2 is
procedure E(A: in T1'Class) is begin xE(A); end E;
procedure F(A: in T1'Class) is begin xF(A); end F;
procedure G(A: in T1'Class) is begin xG(A); end G;

procedure xE(A: in T1) is begin Put_line("E1:");       end xE; 
procedure xF(A: in T1) is begin Put("F1:");      E(A); end xF;
procedure xG(A: in T1) is begin Put("G1:");      F(A); end xG;

procedure xE(A: in T2) is begin Put_Line("E2");        end xE;
procedure xG(A: in T2) is begin Put("G2:");      F(A); end xG;
end Essai2;

With this new version of the code, one gets G2:F1:E2 as wanted. 

=> Questions: is it the right way to simulate the C++ virtual mechanism in Ada
or is there something more clever or more "in the Ada approach" ?

Thanks !
Didier

Re: C++ virtual function mechanism in Ada ?

[Jean-Pierre Rosen]

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


"Didier.pieroux" <dpieroux.no-spam@pi.be> a �crit dans le message news: IDz77.6315$ar1.18443@www.newsranger.com...
[snipped for brievity]

> One way to get the job done is to use:
> procedure F(A: in T1) is begin Put("F1:");     E(T1'Class(A)); end F;
> That switches the dynamical dispatching on and everybody is happy. But the bad
> point is that I have the impression that extending a base type can require
> modifications in that base type implementation. Too bad for code reliability,
> isn't it ?
This is the right way to do it.

>
> So, my first question is: knowing that a characteristic feature of primitive
> operations is to call them with objects of a derived type, why did the Ada
> designers choose not to use dynamical dispatching when calling a primitive
> function ?  I guess that most of the time Ada programmers (as C++ programmers)
> want to really call the primitive operation corresponding to the type of the
> actual parameter, no ?
A fundamental question, so let's go.
There is a fundamental difference between C++ and Ada: in C++, dispatching is a property of the function (virtual or not).
Second: Ada is a language driven by types. It is always the *type* of the parameters that determines what is called. If the
(declared) specific (i.e. real) type is known at compile time, the call is static. If it is not (i.e. a class-wide type), the
binding is dynamic.
The benefit of this approach is that when you read the code, if you know the types of the parameters (and in Ada, you'd better know
that), you know what will happen, you don't have to look for information in some distant place. It also avoids the risk of ruining a
program, as in C++ when you decide to change a function from non-virtual to virtual.It is the user (i.e. the caller) who decides on
the behaviour he wants.

Now, it is true that when you write a primitive operation on a tagged type, you need to think about whether you want to redispatch
or not. That's part of the design.

Once again, the Ada solution makes the code a bit more difficult to write (you have to convert to a class-wide type) for the benefit
of the reader.

> Second question... In order to simulate the virtual function mechanism for
> primitive operation, I found the following solution.  I declare (non-primitive)
> procedures with a class-wide formal argument of the Base type. The only thing
> they do is to call the real primitive functions. Elsewhere in the code, these
> primitive functions are never called directly but always through the class-wide
> procedures. Using this, the package above becomes:
> [snip]
>
> => Questions: is it the right way to simulate the C++ virtual mechanism in Ada
> or is there something more clever or more "in the Ada approach" ?
>
This works, but brings nothing to simply converting to the class inside the primitive operation.

Another fundamental difference in the Ada model is that it distinguishes a node (T) from a subtree rooted at that node (T'Class).
There is no such distinction in other languages that I know, where a T is at the same time a real T AND valid for all descendants of
T (through pointers in C++, but not in Java).
An operation with a parameter of type T is a fundamental behaviour of the type, that may need to be redefined by descendents. An
operation with a parameter T'Class operates on the subtree, and is not redefinable; it generally calls primitive operations, and
dispatching will take place. This way, you are sure that everybody uses the same operation.

To take a concrete example, suppose I have various kinds of windows, with Put and New_Line operations:
   procedure Put (Item : String; Into : Window);
   procedure New_Line (Into : Window);

A scrollable window will redefine these operations, because it needs to keep previous lines in some buffer. Now I want to add a
Put_Line; I want Put_Line to be always equivalent to calling Put then New_Line:
   procedure Put_Line (Item : String; Into : Window'class) is
   begin
      Put (Item, Into);
      New_Line (Into);
   end Put_Line;

This way, I am certain that nobody will redefine Put_Line to do something else!

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

Re: C++ virtual function mechanism in Ada ?

[Larry Kilgallen]

In article <IDz77.6315$ar1.18443@www.newsranger.com>, Didier.pieroux<dpieroux.no-spam@pi.be> writes:

> As most of you know, one of the feature of C++ is the virtual function
> mechanism.

I think that is a very bad assumption in an Ada newsgroup.

Perhaps those who have been vocally comparing C++ features to Ada features
know C++, but that is certainly not the majority of the readership of the
comp.lang.ada newsgroup.

Re: C++ virtual function mechanism in Ada ?

[Warren W. Gay VE3WWG]

Jean-Pierre Rosen wrote:
> 
> "Didier.pieroux" <dpieroux.no-spam@pi.be> a �crit dans le message news: IDz77.6315$ar1.18443@www.newsranger.com...
> [snipped for brievity]
> 
> > One way to get the job done is to use:
> > procedure F(A: in T1) is begin Put("F1:");     E(T1'Class(A)); end F;
> > That switches the dynamical dispatching on and everybody is happy. But the bad
> > point is that I have the impression that extending a base type can require
> > modifications in that base type implementation. Too bad for code reliability,
> > isn't it ?
> This is the right way to do it.
> 
> >
> > So, my first question is: knowing that a characteristic feature of primitive
> > operations is to call them with objects of a derived type, why did the Ada
> > designers choose not to use dynamical dispatching when calling a primitive
> > function ?  I guess that most of the time Ada programmers (as C++ programmers)
> > want to really call the primitive operation corresponding to the type of the
> > actual parameter, no ?
> A fundamental question, so let's go.
> There is a fundamental difference between C++ and Ada: in C++, dispatching is a property of the function (virtual or not).
> Second: Ada is a language driven by types. It is always the *type* of the parameters that determines what is called. 

Don't forget that in Ada95, the return value type can also be important ;-)

C++ does not dispatch on the return type.

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: C++ virtual function mechanism in Ada ?

[DuckE]

"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:eO4BFW3WWD3M@eisner.encompasserve.org...
> In article <IDz77.6315$ar1.18443@www.newsranger.com>,
Didier.pieroux<dpieroux.no-spam@pi.be> writes:
>
> > As most of you know, one of the feature of C++ is the virtual function
> > mechanism.
>
> I think that is a very bad assumption in an Ada newsgroup.
>
> Perhaps those who have been vocally comparing C++ features to Ada features
> know C++, but that is certainly not the majority of the readership of the
> comp.lang.ada newsgroup.

Wanna take a vote?

I think the most of the readership does know C++, but chooses Ada as a
better choice.  At least I like to think this is the case :-)

SteveD

Re: C++ virtual function mechanism in Ada ?

[Larry Kilgallen]

In article <mRK77.407496$p33.8305450@news1.sttls1.wa.home.com>, "DuckE" <nospam_steved94@home.com> writes:
> "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
> news:eO4BFW3WWD3M@eisner.encompasserve.org...
>> In article <IDz77.6315$ar1.18443@www.newsranger.com>,
> Didier.pieroux<dpieroux.no-spam@pi.be> writes:
>>
>> > As most of you know, one of the feature of C++ is the virtual function
>> > mechanism.
>>
>> I think that is a very bad assumption in an Ada newsgroup.
>>
>> Perhaps those who have been vocally comparing C++ features to Ada features
>> know C++, but that is certainly not the majority of the readership of the
>> comp.lang.ada newsgroup.
> 
> Wanna take a vote?

Absolutely not !  Somebody started a vote in another newsgroup I follow,
and it was a real waste of bandwidth.

> I think the most of the readership does know C++, but chooses Ada as a
> better choice.

What about those of us who chose Ada before there was a C++ ?

Re: C++ virtual function mechanism in Ada ?

[Robert Dewar]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote in message news:<eO4BFW3WWD3M@eisner.encompasserve.org>...

> I think that is a very bad assumption in an Ada newsgroup.

That seems an entirely unreasonable reaction. Many well informed Ada
programmers will be aware of how major programming languages
handle things, and there are plenty of CLA readers who of course
know how C++ works. I definitely do NOT want to see elementary
tutorials on C++ appearing here! If you don't know C++ you should
probably just skip a thread with a subject like the above!

Re: C++ virtual function mechanism in Ada ?

[Robert Dewar]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote in message news:<8TC4uKLBjMDq@eisner.encompasserve.org>...

> What about those of us who chose Ada before there was a C++ ?

Hmmm! There can't be too many people in that category, if any. The
Ada language was standardized in 1983, the same year that the initial
version of C++ was finalized (work on C++ had started in 1980). It is
true that there were workable earlier versions of Ada published
but I don't think too many people committed to Ada earlier than that.

For a capsule history of C++ see http://www.cplusplus.com/info/history.html

Re: C++ virtual function mechanism in Ada ?

[Dmitry A. Kazakov]

On 26 Jul 2001 03:44:49 -0700, dewar@gnat.com (Robert Dewar) wrote:

>Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote in message news:<8TC4uKLBjMDq@eisner.encompasserve.org>...
>
>> What about those of us who chose Ada before there was a C++ ?
>
>Hmmm! There can't be too many people in that category, if any. The
>Ada language was standardized in 1983, the same year that the initial
>version of C++ was finalized (work on C++ had started in 1980). It is
>true that there were workable earlier versions of Ada published
>but I don't think too many people committed to Ada earlier than that.

It depends. I remember in my high school years [middle 80s], Ada 83
was already well known. It was not taught [FORTRAN and PL1 were
lectured] but it was recomended for self study and sometimes hotly
discussed. In contrary to this, C was completely unknown [happy life
(:-))]. I learn about a language called C first in 86, got a grip on
an extremely bad C compiler next year and forgot it till the beginning
of 90s. When I wrote my thesis using DEC Ada I did not even know that
C++ existed. I wish that time back! (:-()

Regards,
Dmitry Kazakov

Re: C++ virtual function mechanism in Ada ?

[Larry Kilgallen]

In article <5ee5b646.0107260244.3cd9e5b3@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:
> Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote in message news:<8TC4uKLBjMDq@eisner.encompasserve.org>...
> 
>> What about those of us who chose Ada before there was a C++ ?
> 
> Hmmm! There can't be too many people in that category, if any. The
> Ada language was standardized in 1983, the same year that the initial
> version of C++ was finalized (work on C++ had started in 1980).

But the common excuse for no C++ interface in Ada95 is that there
was no C++ standard.  Of course when I talk about the existance of
a language, I mean with a compiler available for an operating system
on which I want to use it.

Re: C++ virtual function mechanism in Ada ?

[Ted Dennison]

In article <3b600dd2.859745@news.cis.dfn.de>, Dmitry A. Kazakov says...
>It depends. I remember in my high school years [middle 80s], Ada 83
>was already well known. It was not taught [FORTRAN and PL1 were
.
>discussed. In contrary to this, C was completely unknown [happy life

Here in the US, I had friends using C around 83 or so (when I was in high
school). I think I'd first heard about it about a year before that.

Admittedly, C++ was completely below my radar until about 1994. At the time, I
seem to remember everyone talking like it was some brand new thing that was
still being worked on. It certianly wasn't standardized yet, and Ada was already
nearly done with the second version of its standard. Don't get me wrong: It is
good to have the *facts* laid out, where someone had them wrong. But I think
those of us who took all that talk at face value can be forgiven for the
mistake.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: C++ virtual function mechanism in Ada ?

[Warren W. Gay VE3WWG]

Robert Dewar wrote:
> Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote in message news:<eO4BFW3WWD3M@eisner.encompasserve.org>...
> 
> > I think that is a very bad assumption in an Ada newsgroup.
> 
> That seems an entirely unreasonable reaction. Many well informed Ada
> programmers will be aware of how major programming languages
> handle things, and there are plenty of CLA readers who of course
> know how C++ works. I definitely do NOT want to see elementary
> tutorials on C++ appearing here! If you don't know C++ you should
> probably just skip a thread with a subject like the above!

Furthermore, some of us who support Ada, must use C/C++ as part of
their "day job" :<

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: C++ virtual function mechanism in Ada ?

[Robert Dewar]

dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) wrote in message news:<3b600dd2.859745@news.cis.dfn.de>...

> It depends. I remember in my high school years [middle 80s], Ada 83
> was already well known. It was not taught [FORTRAN and PL1 were
> lectured] but it was recomended for self study and sometimes hotly
> discussed. In contrary to this, C was completely unknown

Well any high school can teach anything and that does not prove much
(some high schools in the states teach creationism :-)

But in fact C was of course well known in that period, and any
programming language course not mentioning C that was taught in
the middle 80's was really decrepit. C is for example definitely
a whole generation after Fortran, and to teach Fortran and PL1 
without mentioning C at that time in a PL course is more than
a bit odd!

My first exposure to C was on a PDP-11 in the early 70's. Very
nice compiler and a very nice system (a single 128K PDP-11 could
happily support dozens of users in time sharing mode :-)

Re: C++ virtual function mechanism in Ada ?

[Dmitry Kazakov]

On 27 Jul 2001 19:10:11 -0700, dewar@gnat.com (Robert Dewar) wrote:

>dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) wrote in message news:<3b600dd2.859745@news.cis.dfn.de>...
>
>> It depends. I remember in my high school years [middle 80s], Ada 83
>> was already well known. It was not taught [FORTRAN and PL1 were
>> lectured] but it was recomended for self study and sometimes hotly
>> discussed. In contrary to this, C was completely unknown
>
>Well any high school can teach anything and that does not prove much
>(some high schools in the states teach creationism :-)

In my case it was Marxism (:-))

>But in fact C was of course well known in that period, and any
>programming language course not mentioning C that was taught in
>the middle 80's was really decrepit. C is for example definitely
>a whole generation after Fortran, and to teach Fortran and PL1 
>without mentioning C at that time in a PL course is more than
>a bit odd!

I think there was a reason behind. Our major was applied mathematics.
C was hardly suitable for that (no true arrays, no overflow checks
etc). {}-brackets alone were a big problem that time. I saw an Algol
compiler that required all keywords be put in ''-quotes, like 'BEGIN'.
Presumably, because the machine had only capitals (:-))

>My first exposure to C was on a PDP-11 in the early 70's. Very
>nice compiler and a very nice system (a single 128K PDP-11 could
>happily support dozens of users in time sharing mode :-)

Lucky were you. My C compiler took about 5-10 min for hello-world (5-6
passes or so) on a PDP-11, so I switched back to MACRO-11.

Regards,
Dmitry Kazakov