Lambda the Ultimate

inactiveTopic Comparing Ada and C
started 9/27/2000; 5:32:59 AM - last post 10/5/2000; 1:40:18 AM
Ehud Lamm - Comparing Ada and C  blueArrow
9/27/2000; 5:32:59 AM (reads: 1073, responses: 4)
Comparing Ada and C
Contests like the ICFP are one way to compare languages. They have some advantages. Another more "software engineering" approach can be found in this paper, comparing development in Ada and C. Some find the results surprising...
Posted to "" by Ehud Lamm on 9/27/00; 5:34:09 AM

Chris Rathman - Re: Comparing Ada and C  blueArrow
9/28/2000; 12:16:58 PM (reads: 1113, responses: 3)
I don't know if this is an appropriate place for a comment about Ada'95, but I've been meaning to lodge a complaint... :-)

The biggest problem I ran across in Ada'95 was the lack of transparency between Tagged (record) types and Access (pointers) types. In a non-inheritance situation, a tagged variable can be seamlessly exchanged to and from an access variable (using .all for the record).

However, when inheritance gets involved, things are not quite as simple. Specifically I am thinking of polymorphism. IIRC, a tagged variable can only hold an instance of the type that is declared - not an instance of a subclass (though I may be misremembering on this one).

More of a thorn, however, is that variables of Access type are ignorant of the inheritance hierarchy. An access var that points to a subclass can not be used polymorphically as a pointer to a superclass.

I'm probably not being clear on this, but I found inheritance and polymorphism to be less than optimal. There is a distinction between the inheritance system promoted by the tagged records, and the access(ors) to those records. To get variables to hold polymorphic values, you really need to have them be accessors. But to get the polymorphic dispatch to work properly, you have to go back to the base tagged type (.all).

The Ada'95 examples that I've run across don't seem to make that distinction, as they go from using pure tagged types in one example, to pure accessors in another. The idea that both tagged types and accessors are required doesn't seem to be obvious from the examples.

Ehud Lamm - Re: Comparing Ada and C  blueArrow
9/29/2000; 3:03:41 AM (reads: 1185, responses: 2)
Well, comp.lang.ada is a better place to discuss Ada. Some of the language designers and implementors are contributors. It'd be great to have them over here too, of course.

I am not sure I understand what you exact concern is. The Ada model is slightly different than others (e..g, C++) so perhaps that's what causes your concern. Any way, let me elaborate a bit on this, at least for the sake of those unfamiliar with Ada.

In Ada pointers are called access types, so when you see the word access know that we are dealing with a pointer type.

Suppose you have a hierarchy of types rooted in

Type Shape is abstract tagged null record

We can declare two kinds of pointer types

Type P1 is access Shape

Type P2 is access Shape'class

P1 can only point to Shape objects. P2 can point to the whole hierarchy rooted in Shape. When you want runtime dispatching, you use access to classwide types.

Ada also supports writing classwide routines (which in C++ would be routines that live outside the class). These are written once and can work on any type in the hierarchy. Natrualy, if you want different behaviours for different types - and factor out the common code using a classwide routine - you must use dispatchinhg operations from inside the single classwide routine.


I find this distinction helpful.

More on the Ada model can be found in Ada textbooks or on my Ada site. AdaPower has plenty of links.

My paper on Application Frameworks (see my site), conatains a brief comparison between the Ada and the C++ models.

Chris Rathman - Re: Comparing Ada and C  blueArrow
9/29/2000; 8:35:15 AM (reads: 1246, responses: 1)
I don't have my Ada compiler handy, so I'll have to do this from memory (sorry if any syntax errors creep in). Anyhow, let me see if I can explain myself better, starting off with your declarations of:

   Type Shape is abstract tagged null record
   Type P1 is access Shape
   Type P2 is access Shape'class

and adding some subclasses to this:

   Type Circle is new Shape with null record
   Type P3 is access Circle
   Type P4 is access Circle'class

Now, as you indicate P1 can only point to a shape (and P3 can only point to a circle). This means that from the standpoint of polymorphism, they aren't of much use. A variable of type P1 can only point to an exact instance of type Shape - a var of type P1 could not point to a subclass such as circle. Along similar lines, a function parameter of type P1 must be a pointer to an instance of type Shape - no provision for an instance of a subclass of Shape.

If we look at the record itself, Type Shape, things are only slightly better. Although polymorphism works on function parameters for any subclass, you still have the problem of variables. A variable of Type Shape can not hold an instance of a variable of Type Circle. The variable confines the specific instance of the class to be a match. This forces you into a situation that if you have a variable that must not distinquish the exact type of subclass, you can't store the value as a Type Record - it must be an accessor - specifically a Shape'class accessor.

Which leaves us with access Shape'class as the type of variable used to hold instances of subclasses when the specific instance of the subclass is irrelevant. Any variable which must be capable of polymorphically holding any subclass instance, must use a classwide accessor.

But that leaves us with a different problem: The types Shape'class and Circle'class can not be used interchangeably. This makes it difficult to use the classwide types as parameter types for the functions. If I declare the param type as Circle'class for the circle objects, I can not directly call that function using a variable of type Shape'class from a routine that wants to remain ignorant about the specific subclass instance. But I can't use a Shape'class type for the param since it won't allow access to Circle specific attributes.

Bottom line is this: Variables which need to be capable of holding different subclasses must be a classwide accessor (Shape'class). However, the parameters (and return values) in the functions within the defined classes will only work polymorphically if they operate on the tagged type (not the access pointer types).

My complaint is that Ada'95 does not retain a hierarchy for classwide accessors. In the immediate case, I can not use access Shape'class (P2) and access Circle'class (P4) interchangeably. In other words, the classwide accessors do not behave polymorphically wrt classwide accessors defined in the super or subclasses.

Ehud Lamm - Re: Comparing Ada and C  blueArrow
10/5/2000; 1:40:18 AM (reads: 1302, responses: 0)
Hi!

Sorry, but it will take me a day or two to find the time to really consider your message. As you can see, I don't even have the time to post anything. Help out, until I come back!

I cam across this discussion which may make you love Ada