Re: C++ STL Components and Ada

[James Rogers <jimmaureenrogers@worldnet.att.net>]

Jon Orris wrote:
> 
> "James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> news:3B5450EF.7D82CCF5@worldnet.att.net...
>> > C++ templates also have the disadvantage that their instantiations
> > cannot
> > be checked by the compiler. Instead, you must deal with runtime errors
> > when making simple mistakes such as filling a container with values
> > of Animal and then trying to read them out as values of Mineral.
> 
> Could you provide an example of what you mean here? I've seen this claim
> before, and have been unable to think of how this would occur. I've never
> had this sort of issue crop up when developing in C++.
> 

Sure.

All pointers to Objects in C++ are equivalent to class-wide access
values in Ada. A pointer to an object can point to objects of all
classes inheriting from the pointer's object base type.

When instantiating a template you must specify the class of the
objects to be contained by the generic container class. That
class parameter allows objects of the class and all its 
subclasses to be stored in the container class. So far, so good.

Now, what happens if you instantiate the C++ Vector class with
class Airplane, followed by appropriate additions of Airplane
objects to the container. However, you used the cut and paste
method of programming, so one of your functions extracts data
from the Vector and wants to assign it to a reference to the
String class.

Your compiler is completely satisfied with this situation.
The compiler does not check actual parameter types for template
instantiation. All that is done at run time. When you test the
program you find that you have some problems. If you are really
lucky someone has programmed some exceptions into your code and
the code dies cleanly and quickly. If you are unlucky, you must
try to figure out where the data is getting corrupted, and how
to fix it. This usually involves some non-trivial effort running
a debugger. Even worse, the offending code is in a branch not
normally encountered in your code. It doesn't get tested in house.
However, the customers do encounter that branch. Now you have a
relatively expensive problem. You must first recreate the reported
problem. Then you must analyze the cause, and finally fix
the problem. Release of the fix may have to wait until the next
scheduled software release for this product, meaning that your
code will have a possibly serious problem, in customer hands,
for an extended period of time.

Compare this with the Ada generic instantiation. The compiler
checks the actual parameters against the generic formal parameters.
It also can then check all the return values from functions, and
return types from procedure parameter lists. If there is an error
it will be detected BEFORE you can run your program. You do not
need to rely on testing to find the problems. You do not run the
risk that customers will encounter the problem. You do not
incur the costs of re-releasing the code to provide a fix for the
problem.

Jim Rogers
Colorado Springs, Colorado USA