From -3429272976726190469
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,8c9f1307b83ac2db
X-Google-Attributes: gidf78e5,public
From: "Cristian Georgescu" <Cristian.Georgescu@worldnet.att.net>
Subject: Re: Q: virtual functions not overridable anymore?
Date: 1997/09/15
Message-ID: <01bcc079$7a443f00$713274cf@worldnet.worldnet.att.net>#1/1
X-Deja-AN: 272805154
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> <ocrvi06d0qv.fsf@ml.com>
X-Original-Date: 13 Sep 1997 19:18:25 GMT
Organization: Opal Technologies
X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBNB3d4Uy4NqrwXLNJAQGK/QIAkuZAsTe8gI97+XMlRw1JmUvdfnAunh5A NhAuSqGuJxfmz9w8SnyoHzMTopUipgFcyiFlRkQCgcdRtGhr7fvUVg== =os+L
Newsgroups: comp.std.c++
Originator: austern@isolde.mti.sgi.com


Colin Rafferty <craffert@ml.com> wrote in article
<ocrvi06d0qv.fsf@ml.com>...
> 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().
> 
> > I think that there is a good reason for getColor() to be virtual in the
> > base class.
> 
> Colin Rafferty <craffert@ml.com> wrote:
>
> 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.

I agree with you that:
----------------------

The above example may be not quite suitable however for the discussion
because
the underlying attribute can be set as a constant in the constructor, and
there is no reason why getColor should be virtual. 

But ...
-------

But what happens if you have an invariant of the class, or an Attribute
that is computed not mapped to a variable in the class.

class Rectangle {
	double length_;
	double width_;
public:
	Length(){return length_;}
	Width(){return width_;}

	Rectangle(double length, double width): length_(length), width_(width){};

	virual double Area(){return length_*width_;}
	virual double AspectRatio(){return length_/width_;}
}

class Square : public Rectangle {
public:

	Square(double size): Rectangle(size, size){};

	virtual double Area(){return sqr(size);}
	virtual double AspectRatio(){return 1.0;}
}

In this case we have:

1. Square::Area() that can be seen as an algorithmic improvement of the
Rectangle::Area() in order to take into account the specificity of the
Square

This Square::Area() may be a candidate to be final.

2. Square::AspectRatio() that is an invariant of the Square with respect to
the Rectangle::AspectRatio() which is not.

This Square::AspectRatio() should be definitely a candidate to be final.

Remark: 
=======
Declaring final Square::AspectRatio(): 

	final virtual double AspectRatio(){return 1.0;}

therefor removing the virtualness of the AspectRatio() from Square on,
would make that the classes that inherit from the Square have the
AspectRatio() function binding at compile time (with respect to class
Square) -- therefore some performance improvement! I think this may be a
good thing.

Besides, if all the functions from Square are finalized, then the classes
derived from Square would not even need a vptr table.

-- 
Cristian Georgescu
_________________________________________________
    Smith Industries
    Aerospace & Defense Systems
    7-9 Vreeland Road,
    Florham Park, NJ 07932, USA.
_________________________________________________
E-mail: Georgescu_Christian@si.com      
---
[ 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 
]