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,e5eb8ca5dcea2827 X-Google-Attributes: gid103376,public From: Hyman Rosen Subject: Re: Ada OO Mechanism Date: 1999/05/26 Message-ID: #1/1 X-Deja-AN: 482446522 Sender: hymie@calumny.jyacc.com References: <7i05aq$rgl$1@news.orbitworld.net> <7i17gj$1u1k@news2.newsguy.com> <7iems7$1vm@news2.newsguy.com> <86iu9fhawg.fsf@ppp-101-91.villette.club-internet.fr> X-Complaints-To: abuse@panix.com X-Trace: news.panix.com 927750165 14367 209.49.126.226 (26 May 1999 20:22:45 GMT) Organization: PANIX Public Access Internet and UNIX, NYC NNTP-Posting-Date: 26 May 1999 20:22:45 GMT Newsgroups: comp.lang.ada Date: 1999-05-26T20:22:45+00:00 List-Id: Laurent Guerby writes: > I don't know if in C++ you can constrain a template type argument to > be of a specific class (type and class in the Ada sense). No, you can not. There are tricks that can accomplish the test, but they are tricks, not basic language features. The C++ approach to generics is "if it compiles, it works". Instead of restricting a parameter to be of a certain type, you just write the template as if the parameter has that type. It may be that a different type will support the operations equally well, in which case there is no reason to prevent the template from working. I understand that this is unpleasant for many people who want to be able to say and see exactly what's going on with the code. > The Ada OO model guarantees that no dispatch operation will run > non-existing code (even in case of wild generics), I don't know if > it's true of the C++ one. Yes, it's true. There will be either a compile-time or link-time error if non-exisiting code is referenced. In no case will the error be delayed to run-time. > * In Ada, with discriminants you can easily have objects of varying > size being stack allocated instead of heap allocated. In C++ as well. In C++, you use a template parameter - template struct Array { T a[N]; } Array ai; Array ad; Ada is somewhat ahead here, though, because (if I'm not mistaken) in Ada all the discrminated forms are the same type while in C++ they're not (i.e., in C++, Array and Array are completely unrelated). > * I don't know if self referencial types have a C++ equivalent (see > the Ada rationale for an example of such beast). struct SelfRef { SelfRef &Me; SelfRef() : Me(*this) { } }; > * You can "statically" create complex objects and elaboration issues > are correctly handled by the Ada definition, I don't think it's the > case in C++ (I think you don't know in what order the constructors > will be called for "static" data in C++, I might be wrong). For objects at file scope in a single compilation unit (a file), constructors are called in top-to-bottom order. For static objects within a function, constructors are called the first time the flow of control passes through the definition. Order of initialization across compilation units is unspecified. > * What happens if a constructor or a destructor (C++ terminology) > raises an exception is fully specified in Ada, in particular in case > of a destructor exception, for each object in the scope its destructor > is given a chance to run, when this is done a big general ooops > exception is raised. I don't know if it is the case in C++. This > applies too to function returning objects called as argument of > another subprogam. It's fully specified in C++ as well. When a constructor throws, any already constructed sub-components are destructed. As scopes are left in search of an exception handler, all constructed objects in those scopes are properly destructed. If during this process a destructor throws an exception unhandled within itself, a special termination handler is called. C++ cognoscenti have concluded that you should not throw exceptions from destructors because of this.