 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Julian Hsiao Guest
|
Posted: Sat May 06, 2006 4:21 pm Post subject: Overriding overloaded member functions |
|
|
Hi,
Suppose I have a base class, defined thusly:
class Rect { /* ... */ } ;
class Point { /* ... */ };
class RegularPoly
{
public:
virtual ~RegularPoly() { }
virtual void define(Point center, int radius, int edges)
{
// ...
}
virtual void define(Point center, Point *vertexes)
{
int radius;
int edges;
// Compute the correct radius, edge based on the vertexes,
// error checking, etc.
define(center, radius, edges);
}
virtual void define(Rect bound, int edges)
{
Point center;
int radius;
// Compute the regular polygon inscribed by bound
define(center, radius, edges);
}
// More overloaded define() ...
};
Note that RegularPoly::define(Point, int, int) is the actual function that
does the defining, and all the other overloaded forms call it.
Now suppose I want a regular polygon whose edges are painted in different
colors, say it alternates between red and green:
class AltColorRegularPoly : public RegularPoly
{
public:
virtual ~AltColorRegularPoly() { }
using RegularPoly::define;
virtual void define(Point center, int radius, int edges)
{
// Make the edges alternate between red and green
RegularPoly::define(center, radius, edges);
}
};
This works out nicely, but only because I know which of the overloaded
functions is the "master" master function. In general I wouldn't know that
(unless it's documented), so I'd be forced to override all of them. The
burden would only get worse as the inheritance hierarchy deepens. Moreover,
such dependency could arise could arise with non-overloaded member functions
as well.
Other than relying on documentation, is there an idiomatic way of marking the
"master" function, so that others writing derived classes knows which to
override?
Thanks.
Julian Hsiao
My spam filter's lame...
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
benben Guest
|
Posted: Sat May 06, 2006 6:21 pm Post subject: Re: Overriding overloaded member functions |
|
|
Julian Hsiao wrote:
| Quote: | Hi,
Suppose I have a base class, defined thusly:
class Rect { /* ... */ } ;
class Point { /* ... */ };
class RegularPoly
{
public:
virtual ~RegularPoly() { }
virtual void define(Point center, int radius, int edges)
{
// ...
}
virtual void define(Point center, Point *vertexes)
{
int radius;
int edges;
// Compute the correct radius, edge based on the vertexes,
// error checking, etc.
define(center, radius, edges);
}
virtual void define(Rect bound, int edges)
{
Point center;
int radius;
// Compute the regular polygon inscribed by bound
define(center, radius, edges);
}
// More overloaded define() ...
};
Note that RegularPoly::define(Point, int, int) is the actual function that
does the defining, and all the other overloaded forms call it.
Now suppose I want a regular polygon whose edges are painted in different
colors, say it alternates between red and green:
class AltColorRegularPoly : public RegularPoly
{
public:
virtual ~AltColorRegularPoly() { }
using RegularPoly::define;
virtual void define(Point center, int radius, int edges)
{
// Make the edges alternate between red and green
RegularPoly::define(center, radius, edges);
}
};
This works out nicely, but only because I know which of the overloaded
functions is the "master" master function. In general I wouldn't know that
(unless it's documented), so I'd be forced to override all of them. The
burden would only get worse as the inheritance hierarchy deepens. Moreover,
such dependency could arise could arise with non-overloaded member functions
as well.
Other than relying on documentation, is there an idiomatic way of marking the
"master" function, so that others writing derived classes knows which to
override?
|
If other define() functions are nothing more complicated than a wrapper
for the "master" define() then the optimizer should be able to inline
the call (and therefore better context analysis can be done.)
On the other hand, if you really want to mark the "master" function
clearly why not just give it another name and keep it protected (and
non-virtual)?
| Quote: |
Thanks.
Julian Hsiao
My spam filter's lame...
|
Regards,
Ben
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Alberto Ganesh Barbati Guest
|
Posted: Sun May 07, 2006 1:21 pm Post subject: Re: Overriding overloaded member functions |
|
|
Julian Hsiao ha scritto:
| Quote: |
Other than relying on documentation, is there an idiomatic way of marking the
"master" function, so that others writing derived classes knows which to
override?
|
Just define as virtual ONLY the "master" function and keep the other
non-virtual. A general rule-of-thumb that is often useful is the
following "if it's not virtual, then it shouldn't be overridden". Of
course, the compiler won't forbid you to do it, but a few compilers and
most static syntax checkers can be set up to emit at least a warning.
HTH,
Ganesh
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
James Kanze Guest
|
Posted: Sun May 07, 2006 1:21 pm Post subject: Re: Overriding overloaded member functions |
|
|
Julian Hsiao wrote:
[Example deleted... I hope the rest is still
understandable.]
| Quote: | This works out nicely, but only because I know which of the
overloaded functions is the "master" master function. In
general I wouldn't know that (unless it's documented), so I'd
be forced to override all of them. The burden would only get
worse as the inheritance hierarchy deepens. Moreover, such
dependency could arise could arise with non-overloaded member
functions as well.
Other than relying on documentation, is there an idiomatic way
of marking the "master" function, so that others writing
derived classes knows which to override?
|
The usual solution is that only the actual "master" function
will be virtual. In fact, more usually, it will have a
different name, and very often will be private.
--
James Kanze kanze.james (AT) neuf (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|