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: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: Nick Leaton Subject: Re: What is wrong with OO ? Date: 1997/02/21 Message-ID: <330D930A.2850@calfp.co.uk>#1/1 X-Deja-AN: 220398009 X-NNTP-Posting-Host: calfp.demon.co.uk References: <32D11FD3.41C6@wi.leidenuniv.nl> <01bbd23a$5b667cc0$LocalHost@christophe-leph> <01bc0269$3fd55b20$ca61e426@DCorbit.solutionsiq.com> <32FF1199.615E@calfp.co.uk> <3303A993.759E@pratique.fr> To: Valentin Bonnard Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m) Date: 1997-02-21T00:00:00+00:00 List-Id: Valentin Bonnard wrote: > > Nick Leaton wrote: > > > > richard@highrise.nl wrote: > > > > > > Virtual functions are also a kind of documentation. When declaring a > > > function virtual, the programmer is more or less saying "go ahead, > > > override this function if you like." > > > > The decision to make a function virtual assumes a knowledge of what > > users of your class are going to do. It akin to predicting the future. > > No. If it make sense to override, make it virtual; if it doesn't, > don't make it virtual. If you can forsee the future! > > One of the problems with C++ is this very point. Should you, as a > > designer of a class restrict what someone else does with your class? > > Yes; even the fact that you have private members restrict what > can be done with your class; does it mean that you should > only use public data members (ie expose all your implementation > details) ? We are only talking about classes that inherit, not classes that use. Why shouldn't a class that inherits another get access to implementation details? > > If you provide the class to someone else without source code, and they > > find a bug. One solution to fixing the bug is to produce a new class > > that inherits the original, and redefines the offending routine. However > > your decision about declaring or not declaring the routine virtual in > > the first place affects what can be done. > > You don't inherit from a class to fix it in C++ (nor to reuse it); > you specialize it. You don't patch a class like you apply a diff > file to a system to patch it ! OK, Microsoft release a duff library with a duff class. You have no source. Will Microsoft give you the source? No. You have to inherit and overide. It is ugly, it is not ideal, but you have no choice. > [For Mac programmers: overriding != SetTrapAddress] > > One must never forget that inheritance is not the only way to > use a class; composition is often the only sensible way. > > If there is a bug in one member function in a class, then if > you don't have the source code it's difficult to be sure > that the cause of this bug (or a similar bug) is not in > another function. > > Even if you are sure that you only need to correct one > function, public [normal] inherintance is not the way to go. > > You might use private inheritance and redefine the buggy > function: > > class BuggyClass { > public: > void BuggyFunction (); // need not to be virtual > void OtherFunction (); > }; > > class CorrectedClass : private BuggyClass { > public: > void BuggyFunction (); > using OtherFunction; > }; > > void CorrectedClass::BuggyFunction () > { > // corrected function > } It won't work. A user that has a pointer to a BuggyClass, which is an instance of CorrectedClass. The user calls ptr->BuggyFunction() The buggy code will be run, not the CorrectedClass::BuggyFunction. However if BuggyFunction is declared as virtual, it will work. > With private inheritance it's not possible (except for > CorrectedClass members) to convert a CorrectedClass to > a BuggyClass; it means that only CorrectedClass know that > CorrectedClass IS-A BuggyClass. > > You can also use composition by reimplementing all the > functions of BuggyClass; all these implementation just > call the corresponding function in BuggyClass; only > BuggyFunction is really rewritten. This won't work. The corrected class will not inherit BuggyClass, and so cannot be reffered to using a pointer to its base class. > And anyway I feel that's a very special case. You > should ask the BuggyClass writer to correct its class. Agreed. But you have to be realistic. Lets say Microsoft release some buggy code. Nothing suprising there. How long are you prepared to wait for them to fix the code? > Valentin Bonnard > mailto:bonnardv@pratique.fr > http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais) -- Nick