From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9cccf6ef6149fdaa X-Google-Attributes: gid103376,public From: Richard D Riehle Subject: Re: Ada Date: 2000/01/04 Message-ID: <84rphr$ql5$1@nntp8.atl.mindspring.net>#1/1 X-Deja-AN: 568016495 References: <38620350.48F8FC08@gecm.com> <83tohh$q2s$1@nnrp1.deja.com> <83u8l0$5i5$1@nnrp1.deja.com> <84rd2f$snm$1@nntp3.atl.mindspring.net> Organization: MindSpring Enterprises X-Server-Date: 4 Jan 2000 03:31:07 GMT Newsgroups: comp.lang.ada Date: 2000-01-04T03:31:07+00:00 List-Id: In article , Hyman Rosen wrote: >C++ provides excellent implementation of generics, >and good implementation of overloading, except that >one cannot overload on return type as in Ada. > >Is there something specific you believe you can not >do in C++ with regard to these abilities? There are some differences in Ada and C++. The issue is not "can not do" but rather how it is done and whether the Ada way is any improvement. Also, it is never a matter of whether something can or cannot be done in a particular language. Rather, the issue is whether a given language is more expressive of a desired capability. In many ways, Ada is more expressive. In other ways, C++ is more expressive. Ada generics (templates)are always compiled before they are "included" by the client. This is a function of the Ada library model. The instantiation is permitted only after the successful compilation of the generic unit. This puts type checking a little closer to the origination of the generic. If I read the C++ literature correctly, C++ templates are expected to be "full expansion" units. Ada permits a template to be instantiated in other forms to conserve memory. Some compilers support this. Ada has more formats for generic formal parameters. This has its advantages and may sometimes have disadvantages. The designer needs to learn more idioms of the language. Once having learned those idioms, more options for template design are available. Ada permits but does not require as much overloading of operators as one needs in a C++. This is useful when one is creating templates for simple scalar and numeric types. It does simplify the templates for those types. Actually, in this case, the Ada model is somewhat an improvement over C++. Of course, a C++ advocate may answer that the word "class" may be used for a built-in type, but this still falls short of the Ada model for range constraints and other rules of scalar types. Ada is more complicated when creating templates in which an entire package is a generic formal parameter. C++ is very straightfoward in this regard. The consequence is that this powerful feature of Ada is often ignored by component designers. In time, as Ada practitioners become more comfortable with its capabilities, we should see more use of it. Meanwhile, C++ seems much easier when one needs one of more classes as generic formal parameters. On the other hand, a generic formal package parameter provides the equivalent of a namespace parameter, something I suspect cannot be expressed easily in C++. It also enables one to design reusable signatures for simplifying the parameter lists of application frameworks components. Moreover, these signatures are subjected to all the checks of the compiler before they may ever be used. Implementation of Ada generics can take advantage of child library units, including private child library units to create, as private child package specifications, a whole subsystem of reusable package bodies. This is not widely used, in practice, but has substantial power once it is understood by Ada component designers. There are lots of other issues where Ada is more expressive of the component design problem. I am sure others who frequent this forum will note some of the more obvious ones I have overlooked. Richard Riehle