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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7251fa99aab97e06 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-03-02 03:53:51 PST Newsgroups: comp.lang.ada Path: sparky!uunet!pipex!seunet!sunic!news.lth.se!dag From: dag@control.lth.se (Dag Bruck) Subject: Re: Ichibah flames, and flames out over, Ada 9X Message-ID: <1993Mar2.074347.3386@lth.se> Sender: news@lth.se Organization: Department of Automatic Control, Lund, Sweden References: <1993Feb24.211028.8076@evb.com> <1993Feb24.224827.27672@sei.cmu.edu> <1993Feb25.170827.2178@ennews.eas.asu.edu> <1993Mar1.155907.10766@inmet.camb.inmet.com> Date: Tue, 2 Mar 1993 07:43:47 GMT Date: 1993-03-02T07:43:47+00:00 List-Id: In stt@spock.camb.inmet.com (Tucker Taft) writes: > >Independent of this type=module vs. type-inside-module issue, >there are in fact some differences between the Ada (83 and 9X) >language design philosophy and the C++ philosophy. But even >in the fundamental philosophy, there has been more convergence >than divergence as time has passed. It is worth pointing out that in many cases, classes in C++ are used only as abstract datatypes, i.e., without using inheritance or virtual functions. This common use of classes is very close to Ada packages. >Interestingly, a number of tools have sprung up to >provide run-time checks for C++ programmers (e.g. CenterLine's >ObjectCenter, Pure Software's Purify). However, the run-time checks >provided by such tools currently impose a higher run-time >overhead than the corresponding (standardized) checks in Ada, >because they haven't been integrated in with the optimizer, and in >some cases, are performed by interpreting rather than by direct execution. I would like to comment as a user of Purify. Some of the overhead, probably a significant portion, comes from checks that are not normally done by a civilized compiler with run-time checks. Purify will also check all system libraries, e.g., your X11 library, which are normally compiled without debugging and checks turned off to improve speed. >The fact that these checks are provided by separate tools (much >as "lint" used to be used instead of having function prototypes) reflects >the C/C++ philosophy of keeping the language semantics simple, and leaving >checking to the environment. The advantage of this approach is offset >somewhat by the lack of portability in what checks any given environment >enforces, and in the (currently significant) difference in performance in the >presence of checks. I think this has nothing to do with language semantics. For example, it is clear that accessing a piece of storage that was explicitly deallocated is an error, in C++ as in any other language. Few, if any, language implementations check this, but Purify does. I think this is a typical example where tools go beyond the language implementation by adding checks that are not normally present, but still does not add any semantics to the language. There are of course other advantages to the tool approach. In the case of Purify, one advantage is that it can be used on code produced by several compilers (but not any compiler, of course), which in some sense increases portability. Perhaps someone can answer this question: what kind of debugging support (along the lines suggested above) will typical Ada implementations give for unchecked deallocation? -- Dag