From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: ***
X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID,
	RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 1108a1,b87849933931bc93
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,b87849933931bc93
X-Google-Attributes: gid103376,public
X-Google-Thread: 109fba,b87849933931bc93
X-Google-Attributes: gid109fba,public
X-Google-Thread: fac41,b87849933931bc93
X-Google-Attributes: gidfac41,public
X-Google-Thread: 114809,b87849933931bc93
X-Google-Attributes: gid114809,public
X-Google-Thread: f43e6,b87849933931bc93
X-Google-Attributes: gidf43e6,public
From: "Bob Jarvis" <nospam@thankyou.net>
Subject: Re: What is wrong with OO ?
Date: 1997/02/12
Message-ID: <01bc190e$02774a20$c318b993@jarvisb>#1/1
X-Deja-AN: 218296626
References: <5dopri$dei@news4.digex.net>
Organization: The Timken Company
Newsgroups: 
 comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng
Date: 1997-02-12T00:00:00+00:00
List-Id: <comp.lang.ada>


Ell <ell@access5.digex.net> wrote in article <5dopri$dei@news4.digex.net>...
> Nick Leaton (nickle@calfp.co.uk) wrote:
> : richard@highrise.nl wrote:
> : > 
> : > Virtual functions are also a kind of documentation. When declaring a
> : > function virtual, the programmer is more or less saying "go ahead,
> : > override this function if you like."
> : > 
>  
> : The decision to make a function virtual assumes a knowledge of what
> : users of your class are going to do. It akin to predicting the future.
> : One of the problems with C++ is this very point. Should you, as a
> : designer of a class restrict what someone else does with your class?
> 
> How does making inherited classes able to override a parent function
> "restrict"ing "what someone else does with" that class"?

It's true that in C++ you can override a non-virtual base class member function in
a derived class, and that this will work as intended as long as you are referring to the
derived class instance through a reference or pointer to the derived type.  However,
if you're referring to the derived class instance through a base class reference or 
pointer you will invoke the base class version of all non-virtual functions.  For example

	class A {
	     public:
		int a_func(void);
		};

	class B : public A
		{
	     public:
		int a_func(void);
		}

	...

	A::a_func(void) { printf("A::a_func\n"); }
	B::a_func(void) { printf("B::a_func\n"); }

	...

	B b_instance;
	A *a_pointer;

	a_pointer = &b_instance;

	b_instance.a_func();
	a_pointer->a_func();

In this case the output you should receive would be

	B::a_func
	A::a_func

This is a limitation on the possible use of classes derived from A.
a_func is not declared virtual in the base class and thus overrides of
a_func in derived classes will not resolve properly when derived class
instances are referred to through base class references or pointers.
In this case the designer of the original class should have made a_func
virtual but failed to do so, thus limiting how the class can be used later.
This might be intentional, but in the real-world cases I've seen it's usually
been the case that the eventual needs of re-users of the base class were
not considered by the original class designer.
-- 
Bob Jarvis
Mail addresses hacked to foil automailers!
Send replies to jarvisb@timken.com