From -2156304680587198718
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/12
Message-ID: <ocrvi06d0qv.fsf@ml.com>#1/1
X-Deja-AN: 271987747
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> <5ut97j$nkr@bgtnsc02.worldnet.att.net> <ocr4t7tgprf.fsf@ml.com> <01bcbe63$04fa8d20$6e3274cf@worldnet.worldnet.att.net>
X-Original-Date: 12 Sep 1997 11:12:56 -0400
X-Y-Zippy: Of course, you UNDERSTAND about the PLAIDS in the SPIN CYCLE --
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++ iQBVAwUBNBmpiUy4NqrwXLNJAQFubgH8DC8BM83aTzGFBzSqSmKxgfWEaLQm3Cml bbbULCkHsWoysrTee2UooXQ9plAza2tXSFwiiboiVRIhNHMDx5GD9w== =TZaw
Newsgroups: comp.std.c++
Originator: austern@isolde.mti.sgi.com


Cristian Georgescu writes:
> Colin Rafferty <craffert@ml.com> wrote:
>> Cristian Georgescu writes:

>> > Consider an Apple base class with a getColor() virtual
>> > function. Then I have a YellowApple class derived from Apple, and
>> > the getColor() overridden to return the color Yellow.
>> 
>> > The idea is that I do not want the classes that inherit from
>> > YellowApple to override the getColor().
>> 
>> You certainly do.  If I define LightYellowApple, I would want the
>> getColor() to return an instance of LightYellow (derived from Yellow).

> This was not my point. Color is an enumeration. 

I just wanted to cover all the possible bases.

> Yor next remark states better what I meant:

>> On the other hand, if the Color attribute is a choice out of a static
>> list, then there is no good reason for getColor() to be virtual in the
>> base class -- it should be just returning an attribute.

> I think that there is a good reason for getColor() to be virtual in the
> base class:

> class Apple {
> public:
>   enum Color {red, yellow, green};

>   Apple::Color getColor();
>   //...
> }

> class YellowApple {
> public:

>   Apple::Color getColor(){return Apple::Yellow;};
>   //..
> }

Since color is just an attribute, you don't need a virtual function.
All you need is a constructor with the color as an argument.

class Apple {
public:
  enum Color {red, yellow, green};

  Apple(..., Color color) : color_(color), ... { ... }

  Color getColor() const { return color_; }
  
  // ...
};

class YellowApple : public Apple {
public:
  YellowApple(...) : Apple(..., yellow) { ... }
  // ...
};


If all that you want the subclass to define is one out of a fixed range
of choices, you don't want virtual functions in the first place.  If the
range can be expanded, or you want the subclass to define behavior, then
the `final' keyword becomes just an impediment to a useful hierarchy.

> The idea is that you may have an Apple with an unknown color.
> You construct the Apple at night but you cannot see the color, therefore
> you set the color attribute later, when you see beter.

In the case where you must change the attibute after construction, you
would have a protected function, Apple::setColor.

-- 
#!/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 
]