Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   Re: Confused about non-virtual functions (http://www.velocityreviews.com/forums/t267638-re-confused-about-non-virtual-functions.html)

Victor Bazarov 06-24-2003 01:04 AM

Re: Confused about non-virtual functions
 
"Robert William Vesterman" <bob@vesterman.com> wrote...
> I'm confused about the purpose of non-virtual functions. As I
> understand it, if you have a class E that extends a class B and
> overrides a non-virtual function f(),


OK, here is your first mistake. If the function is non-virtual,
nothing can _override_ it. Any member of the derived class with
the same name _hides_ it.

> then the f() that actually gets
> called for an E object depends upon whether that E object is known as
> an E or as a B at the time of the call.


No. Any non-virtual function call is resolved at compile time.
If object of type E is passed where a reference, say, to B is
expected, no object E exists inside, only the B part of E is
passed in:

void foo(B& rb)
{
// Here there is no 'E'. There is only 'B'
rb.f();
}

void bar()
{
E e;
foo(e); // 'e' is converted to 'B&'.
}

> I don't understand what's useful about this ambiguity in what the f()
> of an E is. Could someone please give me an example of why it would
> be useful?


Non-static functions are bound (resolved) at compile time. It
speeds up the process (no need to look it up using sime kind of
virtual function mechanism), and absence of virtual functions
usually means smaller objects. Leaner, meaner.

Having a member function that has the same (or similar) type
in two classes can be a requirement from the design point of
view. Let's take a very simple example: to be able to sort
a collection of objects of type T using standard means, the T
needs to have operator < defined (if no special comparison
function is provided). To use two different classes (whether
related or not) in some generic algorithm that requires the use
of some function 'f()', the two classes have to both implement
that function. You may have only one version of it, in the
base class of the two, and let the derived one use it, or you
may need to redefine it just because it has to use some data
members in that class. The function doesn't have to be virtual
because due to the intention it will never be called through
polymorphic means.

> I don't mean "useful as opposed to virtual functions". I mean "useful
> as opposed to not allowing non-virtual functions to be overridden in
> the first place".


Non-virtual functions cannot be overridden. Please print that
statement out on a sheet of paper and hang above your monitor.

> That is, imagine a language C++--, which is identical to C++ except
> that non-virtual functions cannot be overridden.


Why imagine anything? In C++ non-virtual functions cannot be
overridden.

> What's an example of
> a case where C++ is more useful, or nicer, or cleaner, or safer, or
> more whatever, than C++--?


Learn the language. It's useful, nice, clean, safe, as it is.

Victor



Robert William Vesterman 06-24-2003 01:38 AM

Re: Confused about non-virtual functions
 
Great, great, great. Thank you for the semantics lesson. Please
allow me to rephrase my question:

Please give me an example of why it is useful that C++ allows the
following:

class Base
{
void func ( void );
};

class Derived : public Base
{
void func ( void );
};

Thank you.

Bob Vesterman.

Victor Bazarov 06-24-2003 01:44 AM

Re: Confused about non-virtual functions
 
"Robert William Vesterman" <bob@vesterman.com> wrote...
> Great, great, great. Thank you for the semantics lesson. Please
> allow me to rephrase my question:
>
> Please give me an example of why it is useful that C++ allows the
> following:
>
> class Base
> {
> void func ( void );
> };
>
> class Derived : public Base
> {
> void func ( void );
> };


template<class T> void callClassSpecificFunc(T& t)
{
t.func();
}

int main()
{
Base b;
Derived d;
callClassSpecificFunc(b);
callClassSpecificFunc(d);
}


Now, you give me an example how it would be beneficial to disallow
that.

Victor



Cy Edmunds 06-24-2003 01:50 AM

Re: Confused about non-virtual functions
 
"Robert William Vesterman" <bob@vesterman.com> wrote in message
news:jpaffv49jba3p7mcpaehueqrgbtqtl9vbd@4ax.com...
> Great, great, great. Thank you for the semantics lesson. Please
> allow me to rephrase my question:
>
> Please give me an example of why it is useful that C++ allows the
> following:
>
> class Base
> {
> void func ( void );
> };
>
> class Derived : public Base
> {
> void func ( void );
> };
>
> Thank you.
>
> Bob Vesterman.


Well, that's an interesting point. It isn't something I would do with code I
wrote myself. But if Base was part of a library I was using it might turn
out to be a useful workaround.

I think the real reason for non-virtual functions is to avoid the overhead
of a virtual function call.



Victor Bazarov 06-24-2003 02:00 AM

Re: Confused about non-virtual functions
 
"Cy Edmunds" <cedmunds@spamless.rochester.rr.com> wrote...
> "Robert William Vesterman" <bob@vesterman.com> wrote in message
> news:jpaffv49jba3p7mcpaehueqrgbtqtl9vbd@4ax.com...
> > Great, great, great. Thank you for the semantics lesson. Please
> > allow me to rephrase my question:
> >
> > Please give me an example of why it is useful that C++ allows the
> > following:
> >
> > class Base
> > {
> > void func ( void );
> > };
> >
> > class Derived : public Base
> > {
> > void func ( void );
> > };
> >
> > Thank you.
> >
> > Bob Vesterman.

>
> Well, that's an interesting point. It isn't something I would do with code

I
> wrote myself. But if Base was part of a library I was using it might turn
> out to be a useful workaround.
>
> I think the real reason for non-virtual functions is to avoid the overhead
> of a virtual function call.


The reason for non-virtual functions is just because they exist. The
reason for _virtual_ functions is to implement polymorphism. People
tried to do away with non-virtual functions. What good did it do?
Nothing. Slow code and weird problems with calling virtual functions
for objects that haven't even begun constructing... Can you guess the
name of the language?

Victor



Robert William Vesterman 06-24-2003 02:06 AM

Re: Confused about non-virtual functions
 
On Tue, 24 Jun 2003 01:44:44 GMT, "Victor Bazarov"
<v.Abazarov@attAbi.com> wrote:

>"Robert William Vesterman" <bob@vesterman.com> wrote...
>> Great, great, great. Thank you for the semantics lesson. Please
>> allow me to rephrase my question:
>>
>> Please give me an example of why it is useful that C++ allows the
>> following:
>>
>> class Base
>> {
>> void func ( void );
>> };
>>
>> class Derived : public Base
>> {
>> void func ( void );
>> };

>
>template<class T> void callClassSpecificFunc(T& t)
>{
> t.func();
>}
>
>int main()
>{
> Base b;
> Derived d;
> callClassSpecificFunc(b);
> callClassSpecificFunc(d);
>}


I'm sorry, I'm not seeing what you mean. How does the fact that
func() is not virtual figure into the use, or lack thereof, of the
above construct?

Thanks,

Bob Vesterman.

Victor Bazarov 06-24-2003 03:41 AM

Re: Confused about non-virtual functions
 
"Robert William Vesterman" <bob@vesterman.com> wrote...
> On Tue, 24 Jun 2003 01:44:44 GMT, "Victor Bazarov"
> <v.Abazarov@attAbi.com> wrote:
>
> >"Robert William Vesterman" <bob@vesterman.com> wrote...
> >> Great, great, great. Thank you for the semantics lesson. Please
> >> allow me to rephrase my question:
> >>
> >> Please give me an example of why it is useful that C++ allows the
> >> following:
> >>
> >> class Base
> >> {
> >> void func ( void );
> >> };
> >>
> >> class Derived : public Base
> >> {
> >> void func ( void );
> >> };

> >
> >template<class T> void callClassSpecificFunc(T& t)
> >{
> > t.func();
> >}
> >
> >int main()
> >{
> > Base b;
> > Derived d;
> > callClassSpecificFunc(b);
> > callClassSpecificFunc(d);
> >}

>
> I'm sorry, I'm not seeing what you mean. How does the fact that
> func() is not virtual figure into the use, or lack thereof, of the
> above construct?


It doesn't. That's the beauty of it. And, BTW, what the hell does
virtuality have to do with it? Didn't you say in your other posting
that you didn't want to compare them to virtual functions?

In the given example the fact that 'Derived' is derived from 'Base'
has no relevance. Two classes each has a function named 'func' with
a certain signature. Why should the language prohibit that? Please
abstract from "virtual" and get a simple fact: inheritance shouldn't
have any bearing on whether the language allows or prohibits to have
the same type function in two classes.

struct B { void f(); }; // OK?
struct D { void f(); }; // unrelated. Still OK?
struct DB : B { void f(); }; // related. Why not OK?

For the users of those classes there is no need to know whether DB
and B are related or not. Whenever 'f' is called, it will be the
right 'f'.

Victor



David White 06-24-2003 05:52 AM

Re: Confused about non-virtual functions
 
Victor Bazarov <v.Abazarov@attAbi.com> wrote in message
news:ELPJa.5710$XG4.4416@rwcrnsc53...
> In the given example the fact that 'Derived' is derived from 'Base'
> has no relevance. Two classes each has a function named 'func' with
> a certain signature. Why should the language prohibit that?


Perhaps because it's asking for trouble. I don't know about prohibit, but at
least warn.

Derived d;
Base *pb = &d;
Derived *pd = &d;
pb->f();
pd->f();

I don't think anyone would expect the two calls above to call different
functions.

David




Karl Heinz Buchegger 06-24-2003 08:38 AM

Re: Confused about non-virtual functions
 


David White wrote:
>
> Victor Bazarov <v.Abazarov@attAbi.com> wrote in message
> news:ELPJa.5710$XG4.4416@rwcrnsc53...
> > In the given example the fact that 'Derived' is derived from 'Base'
> > has no relevance. Two classes each has a function named 'func' with
> > a certain signature. Why should the language prohibit that?

>
> Perhaps because it's asking for trouble. I don't know about prohibit, but at
> least warn.
>
> Derived d;
> Base *pb = &d;
> Derived *pd = &d;
> pb->f();
> pd->f();
>
> I don't think anyone would expect the two calls above to call different
> functions.


Please. Speak only for yourself. If my current situation asks for
calling different functions, then this is exactly what I expect
and this is exactly why I don't make that function virtual.


--
Karl Heinz Buchegger
kbuchegg@gascad.at

Karl Heinz Buchegger 06-24-2003 08:39 AM

Re: Confused about non-virtual functions
 


Victor Bazarov wrote:
>
>
> The reason for non-virtual functions is just because they exist. The
> reason for _virtual_ functions is to implement polymorphism. People
> tried to do away with non-virtual functions. What good did it do?
> Nothing. Slow code and weird problems with calling virtual functions
> for objects that haven't even begun constructing... Can you guess the
> name of the language?
>


Hmm. I guess I first need a cup of coffee :-)


--
Karl Heinz Buchegger
kbuchegg@gascad.at


All times are GMT. The time now is 02:06 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.