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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,436e4ce138981b82 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-09 07:14:59 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!nntp.abs.net!ash.uu.net!spool.news.uu.net!not-for-mail Date: Tue, 09 Mar 2004 10:14:45 -0500 From: Hyman Rosen User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: abstract sub programs overriding References: <5f59677c.0403021101.4ac263d0@posting.google.com> <5f59677c.0403060718.3d6aa909@posting.google.com> <1078776213.376775@master.nyc.kbcfp.com> <1078839257.157439@master.nyc.kbcfp.com> <5cmr40t76va200betf07b7bd6er05ltto9@4ax.com> In-Reply-To: <5cmr40t76va200betf07b7bd6er05ltto9@4ax.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Organization: KBC Financial Products Message-ID: <1078845298.702789@master.nyc.kbcfp.com> Cache-Post-Path: master.nyc.kbcfp.com!unknown@aphelion.nyc.kbcfp.com X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) NNTP-Posting-Host: 204.253.250.10 X-Trace: 1078845298 8527 204.253.250.10 Xref: archiver1.google.com comp.lang.ada:6190 Date: 2004-03-09T10:14:45-05:00 List-Id: Dmitry A. Kazakov wrote: > The problem is that to construct an object (A) /= to construct the > dispatching table of its methods (B). If a constructor is able to call member functions, some choice must be made as to where dispatching calls will go. > C++ choice is very close to: A implies B. Yes. > Obviously it is a bad choice from many points of view. It's obviously a good choice from my point of view. > One of them is safety, as the case shows. As I said, if calls to member functions are to be permitted, as they are in C++, Java, and Ada, it must be decided what happens in the case of dispatching. The C++ approach is the safest, because when a method is actually reached, it sees only properly initialized data for its type. If code does happen to attempt to dispatch to an abstract method, the result is formally undefined, but in practice implementations dispatch to a stub function which aborts the program, and thus the error is detected at the point where it happens. > True, but in practice it is difficult to view object construction / > destruction as monolitic or error free. In C++ construction is neither monolithic nor required to be error-free, in the sense that any constructor may throw an exception to abort the creation of an object. > I think that probably two stage construction is needed. > The first one for type specific construction, the second for class-wide > one (at least to have dispatching in constructors) Constructors can always pass arguments up the hierarchy in C++, so ultimate type information is available if needed. If you want to require the ultimate class to provide this data with no chance of forgetting, simply inherit from a virtual base class without a default constructor. struct RepositoryOfFinalTypeInformation { int magic_type_code; RepositoryOfFinalTypeInformation(int code) : magic_type_code(code) { } }; struct A : virtual RepositoryOfFinalTypeInformation { A() : RepositoryOfFinalTypeInformation(1) { if (magic_type_code == 1) /* ultimately A */; if (magic_type_code == 2) /* ultimately B */; if (magic_type_code == 3) /* ultimately C */; } }; struct B : A { B() : RepositoryOfFinalTypeInformation(2) { } }; struct C : B { }; /* error - will not compile */ struct C : B { C() : RepositoryOfFinalTypeInformation(3) { } /* Aah. That's better. */ };