From 7041623186276034299
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,8c9f1307b83ac2db
X-Google-Attributes: gidf78e5,public
From: Colin Rafferty <craffert@ml.com>
Subject: Re: Q: virtual functions not overridable anymore?
Date: 1997/09/18
Message-ID: <ocr90wua5kx.fsf@ml.com>#1/1
X-Deja-AN: 273669626
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>
X-Original-Date: 18 Sep 1997 13:34:54 -0400
X-Y-Zippy: Now that I have my ``APPLE,'' I comprehend COST ACCOUNTING!!
X-Face: D>:hrrB{l6#\wU;)0R:OHSTA@ayd.Oq?s@Rrc;[+z0m+<-U"$G-J6L)F2QY`qK~uPu!s1(6{\#uy!Ag/D)?'L[}xErXvxoPn8T_hKi{M]/(`BF{e}X7;hby`p\.E$rJ}Aff#BT,rdDIw\y
Organization: Merrill Lynch
X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBNCHd0Ey4NqrwXLNJAQHaVAH+NvISZFwF3C70QjbQ5rdTUwpv6cug6b9s +WnunjD1jocatCsjLtk9P5k/rJUPFI6ttKtuXPlQXqN8Kw8zcvNYvQ== =rLWJ
Newsgroups: comp.std.c++
Originator: austern@isolde.mti.sgi.com


Valentin Bonnard writes:
> Valentin Bonnard <bonnardv@pratique.fr> writes:
>> Colin Rafferty <craffert@ml.com> writes:
>> > Michael B Taylor writes:

>> > > Maybe I missing something about this whole thread, but it seems to me
>> > > that the desire to declare a virtual method "final" in some derived
>> > > class is the same as the desire to declare a method in a class
>> > > non-virtual.

>> > Steve Clamage gave a lucid example of why this is a bad idea.  I have
>> > yet to see an example of why this is useful.  I cannot imagine a
>> > real-life use for `final', other than due to a poorly designed base
>> > class.

>> Others might find additionnal examples.

> Here is one.

> Let's say you have the following GUI classes:

> class Window {
>     virtual void draw () = 0;
> };

> class Dialog {
>     void draw ()
>     {
>         for_each (items.begin (), items.end (),
>                   ptr_mem_fun (DialogItem::draw));
>     }
>     list<DialogItem> items;
> };

> class DialogItem {
>     virtual void draw () = 0;
> };

> You might want to declare Dialog::draw () final as at this point, 
> behaviour should be changed by deriving from DialogItem, not Dialog.

If I want to decorate Dialog, I would have to subclass from it, and draw 
myself.  Of course, I have to keep the old behavior as well.  But I want 
to extend it.

class ModalDialog {
    void draw ()
    {
        // do something modal...
        Dialog::draw();
        // do something else modal...
    }
};

> In particular, any member of Dialog can assume that Dialog::draw 
> as the same effect as Dialog::draw (), the same undocumented 
> semantics...

Which means that any subclass of Dialog is responsible for doing the
appropriate thing.  Usually, this means calling the base class's
implementation.

-- 
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]