From 7666442229827028685
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,8c9f1307b83ac2db
X-Google-Attributes: gidf78e5,public
From: Valentin Bonnard <bonnardv@pratique.fr>
Subject: Re: Q: virtual functions not overridable anymore?
Date: 1997/10/07
Message-ID: <343A3A71.5FF4@pratique.fr>#1/1
X-Deja-AN: 278450405
References: <01bcb109$1e790180$433574cf@worldnet.worldnet.att.net> <3404A0AE.6F7E@Eng.Sun.COM> <5uimip$l56@bgtnsc03.worldnet.att.net> <340D93AA.643A@Eng.Sun.COM> <01bcb951$ea80a440$909c389d@mtayler> <ocr4t7zlk2o.fsf@ml.com> <34166C9E.1882@pratique.fr> <341E7C8E.EA4@pratique.fr> <3420858D.12DB@mWilden.com> <34293558.73F@pratique.fr> <342C48EF.75AF@mWilden.com>
X-Original-Date: Tue, 07 Oct 1997 15:34:41 +0200
Reply-To: bonnardv@pratique.fr
Organization: Internet Way
X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANDpCpeEDnX0m9pzZAQGKbQF/WiR4URoWEstEJiUCu0FJtMwfSjuzz3g8 RexbAhFRJ1/EKWOVwDY9qbswIqxmY9n9 =jotb
Newsgroups: comp.std.c++


Mark Wilden <Mark@mWilden.com> writes:

> Valentin Bonnard wrote:
> > 
> > virtual functions aren't a way to patch program to remove
> > bugs or to introduce debugging tests; they are a way to
> > write OO programs where the derived class define a function
> > the correct way.
> 
> Do you have any supporting references for that opinion? 

I have just found one:

Unofficial C++ Style Guide, by Dave Goldsmith and Jack Palevich
from develop, The Apple Technical Journal, Issue 2, April 1990.

Part 2: Using Language Features, Use virtual functions the right way:

| The wrong way to use virtual functions is via a "come-from" 
| mechanism like some macintosh trap patches. Don't override a 
| virtual function because "I know it's called from over here with 
| these parameters."  Needdless to say, this breaks havoc with 
| data abstractions that are one of the major benefits of 
| object-based programming.

BTW, if you don't know the possibillity to patch a trap (a trap 
is a system call) on the Macintosh, I have to tell you that it 
often leads to crashes (but it's possible to get it to work after 
lots of tests), and the result is almost never compatible with 
the next system release.

> In any event, if
> the derived class's purpose is to debug the parent class (perhaps
> because the parent source isn't available), then my example does indeed
> define the function the correct way.

In this example, yes. But what about this case:

class MemoryHandler
{
public:
    size_t   avail_mem () const; // implicilty virtual in C+=Wilden
    // Documented behaviour: returns the size of the free memory
    // Undocumented behaviour: I won't tell you

    ...
};

Then you derive:

size_t   MyMHandler::avail_mem () const
{
    cerr << "avail_mem called\n";
    return MemoryHandler::avail_mem ();
}

The use of cerr may change the available memory, but 
you call the base class version after, so it seems 
correct... until I tell you the undocmented behaviour, 
which is: can be called at interrupt time, and output 
to cerr certainly can't be done at interrupt time.

Note that this undocumented behaviour is only used 
by other MemoryHandler members and shouldn't be used 
by clients of MemoryHandler; it can appear or 
disappear from a release of this class to the next.

-- 

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]