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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,342dcd67e9ca73ee X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: tagged record child: override constructor? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1126591134.797303.318920@z14g2000cwz.googlegroups.com> <1uri5gd2n7om0.1ujkzb26ayxdx.dlg@40tude.net> <1126625009.709876.226260@f14g2000cwb.googlegroups.com> <225337460.SlYKbeB8eD@linux1.krischik.com> <87vf14him5.fsf@ludovic-brenta.org> <1idpvzxcxfckw.mrs8nw3eu4ks$.dlg@40tude.net> Date: Wed, 14 Sep 2005 15:20:44 +0200 Message-ID: <13wyu4lwsmzmz.ktc3t2av54yv$.dlg@40tude.net> NNTP-Posting-Date: 14 Sep 2005 15:20:40 MEST NNTP-Posting-Host: d813c1a0.newsread2.arcor-online.net X-Trace: DXC=I1`?K8aQhL:GKQ1;SL\gZ1Q5U85hF6f;4jW\KbG]kaM8Q>n?D9BSA] On Wed, 14 Sep 2005 11:05:10 +0200, Maciej Sobczak wrote: > Dmitry A. Kazakov wrote: > >> There is no difference between T and >> T'Class (the source of countless problems.) > > Could you elaborate? 1. It is space inefficient. To have T and T'Class same requires keeping the type tag in all Ts, while it is only necessary in T'Class. 2. There is no chance to get a consistent type system where each specific type would have classes and primitive operations. If Boolean and Boolean'Class have to be same, then the size of Boolean cannot be 1 bit. (Presently Ada does not use this opportunity, but I hope it some day will) 3. It is inefficient, because it has to dispatch everywhere (except for constructors and destructors, which still have the overhead of unused dispatching.) Maybe this is the reason why so many people believe that OO isn't suitable for real-time. I believe that this is rather an ungrounded projection from C++ to Ada. 4. It is error-prone because of enforced re-dispatch (see below.) One should explicitly specify T::Foo() referring member functions within a member function. In practice nobody cares to do this, which often leads to nasty surprises. 5. When T and T'Class are same, objects have identity. This identity might be arbitrary. Nevertheless people will exploit it. This leads to bad fragile design. Another form of identity is the object's address. Which is quite similar case. Here again Ada prevents you from occasional using this sort of identity (you have to make the object aliased), while C++ encourages it (you can apply & to almost everything.) >> So all operations re-dispatch > > What does that mean? type Base is tagged ...; procedure Foo (X : Base); -- Primitive operation procedure Bar (X : Base); -- Another primitive operation procedure Foo (X : Base) is begin Bar (X); -- This does not dispatch! It calls Base.Bar end Foo; The implementation of Foo stay consistent no matter what a derived type would do with Bar. Note that this is nothing but a trivial contract model which C++ lacks in this case. Within Foo, X is declared of the type Base. So it would be infeasible to dispatch again. The type is known. If dispatch is really needed, then that should be specified in the contract. I.e. the type of X should be Base'Class. [Ada allows explicit conversions to Base'Class, a bad idea though. Better pattern is to make the objects explicitly having identity, using the Rosen's trick.] Re-dispatch usually indicates a design problem. >> except for constructors and destructors, which don't. > > They do, but there the dynamic and static type of the object is the > same, which actually saves a lot of problems. Yes, they do as if they wouldn't. To me it is that they don't. Of course this saves the problems just because there is no re-dispatch, which is in general a bad thing. Actually what C++ does in constructors and destructors is using Ada's (consistent) model. >> I.e. it is rather C++ >> where the call site determines whether a virtual function dispatches. > > It always does, independent on the call site. It is rather the dynamic > type of the object that changes during construction and destruction, > thus leading to the "virtual functions don't work" impression. Yes. It changes from T'Class to T and backwards depending on the location, utterly inefficient and very error-prone. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de