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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7a180be12347b9d3 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,7a180be12347b9d3 X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 2002-02-08 01:14:39 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) Newsgroups: comp.lang.ada,comp.object Subject: Re: Merits of re-dispatching [LONG] Date: Fri, 08 Feb 2002 09:16:32 GMT Message-ID: <3c6392e8.2400843@News.CIS.DFN.DE> References: <3c62524f.93369796@News.CIS.DFN.DE> <1013094178.985786@master.nyc.kbcfp.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) X-Trace: fu-berlin.de 1013159677 45057908 212.79.194.111 (16 [77047]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:19757 comp.object:33648 Date: 2002-02-08T09:16:32+00:00 List-Id: On Thu, 7 Feb 2002 20:29:42 -0500, "Matthew Heaney" wrote: >"Hyman Rosen" wrote in message >news:1013094178.985786@master.nyc.kbcfp.com... >> Again, this is false for C++. In a C++ constructor or destructor, the >> type of the object is the type of the class of which the constructor or >> destructor is a member. So in the C++ equivalent of Finalize(A), the >> call to Foo(A'Class) would call Foo(A), not Foo(AA), because in >> the destructor of A, the object is an A, not an AA, even when we >> are destructing the A component of an AA. This is good, since, as >> you point out, the AA part is no longer there! > >Yes, that's true, but it's easy to think that the virtual member function >call will dispatch, because that's how it works for every other virtual >member function: > >class B >{ >public: > virtual ~B(); > virtual void f(); > virtual void g(); >}; > >void B::f() >{ > g(); //dispatches >} > >B::~B() >{ > g(); //does not dispatch >} > >You have to learn that the call to g() doesn't dispatch in the dtor. This >behavior is certainly not immediately obvious, especially for those new to >the language. > >You seemed to have missed the point about this error-prone feature of C++: a >naive programmer is going to depend on dispatching to occur. He has to >learn --the hard way-- that the dtor is special. Yes, but there are two things here. First C++ does not make any difference between class wide and specific objects. The same type B is a class wide in B::f () and specific in B::~B (). So the difference in how B::f and B::~B are dealing with calls to g(). This is IMO bad. Second. The behaviour of B::~B is safe. One should never expect dispatching in a specific subroutine like destructor. My point is that the language should prohibit dispatching from specific subroutines. Therefore in my opinion the behaviour of B::f is unsafe. It is declared as virtual (dispatching) which means that inside B::f the type is already *known*. Thus there is no need in [re-]dispatching. A call to g() can be statically resolved. The reason why C++ dispatches in B::f (), is that otherwise it would impossible to have class wide subroutines [see the point 1]. In contrary to this Ada 95 does have class wide routines, so my question, why [explicit] re-dispatching is supported in Ada 95? Regards, Dmitry Kazakov