From 2129323972180817926
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/12
Message-ID: <01bcbf4e$e9343b80$183274cf@worldnet.worldnet.att.net>#1/1
X-Deja-AN: 271981768
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> <5v1i5j$qrg$1@mail.pl.unisys.com> <ocr3endgp95.fsf@ml.com> <34173066.15FB@wizard.net> <ocrpvqfgaqw.fsf@ml.com>
X-Original-Date: 12 Sep 1997 07:41:01 GMT
Organization: Opal Technologies
X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBNBmo2Ey4NqrwXLNJAQEziAIAgLU1j8uqB5L6xZYl7gn2QzInKMn8SFWV o/wwRJ1MXsrQ8zf7o9kdRQ3RAPejG5nFc00pIqO3T7H64Dsf+F5www== =f877
Newsgroups: comp.std.c++
Originator: austern@isolde.mti.sgi.com


Colin Rafferty <craffert@ml.com> wrote in article
<ocrpvqfgaqw.fsf@ml.com>...
> James Kuyper writes:
> > The ThreeVector class implemented length() as returning a constant 3.
It
> > used a fixed double[3] array member to store the data. Thus, it was
> > quicker, smaller, but less flexible than an NVector.
> 
> > I cannot think any situation where it would be a good idea for a class
> > derived from ThreeVector to override length(). If there were a 'final'
> > keyword in C++, I would have used it there.
> 
> This is a little goofy, but it would work:
> 
>    template <class TT>
>    class FiveVector : public ThreeVector<TT> {
>          TT rest_[2];
>       public:
>          virtual size_t length() const { return ThreeVector<TT>::length()
+ 2; }
>          virtual TT& ref(size_t elt) {
>             return ((elt < 2) ? rest_[elt] : ThreeVector<TT>::ref(elt -
2));
>          }
>    };

To me this does not make sense: you say that a ThreeVector is a FiveVector?
(Basically a pentagon is a triangle?)

Or rather should we read: ThreeVector<TT> as: the class ThreeVector is a
poligon?

> Of course, the basic point is still that the allocation should be an
> attribute of your Vector class itself, rather than a behavior of a
> subclass.

I suppose length IS an attribute of the class Vector as well as of the
class ThreeVector. But it is private and there is also a function
getLength() that is virtual in Vector. 

The 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 getLength should be virtual. 

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 
]