allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0212201142.6a028793@posting.google.com>...
> > Allan W wrote:
> > > Are you suggesting that the function would not occupy a spot in
> > > Derived's virtual table?

I suspect that it would.

> hyrosen@mail.com (Hyman Rosen) wrote

> > It just means that when the function is called from a pointer or
> > reference to Derived, that call will be direct and will not involve
> > virtual dispatch. The function will still be dispatched to if it is
> > called through a Base pointer or reference.

> Okay, so Baseptr->foo() goes through the vtable, where it could call
> either Base::foo or Derived::foo, but Derptr->foo() goes directly to
> Derived::foo. This means that Derived (and all classes drived from
> Derived, if you will) still need a vtable entry for foo.

Right.  The important point is that the call through Baseptr resolves to
the function in Derived, regardless of what happens after.

> That means that "turning off virtual" is an optimization only, right?

No.  It is a means of enforcing the class invariants in Derived.

> But how is it different than calling Derptr->Derived::foo() with
> today's compilers?

> Would you want to allow MoreDerived to "turn virtual back on"?

In what sense?  If a class derives from Derived, then as far as it is
concerned, foo is a non-virtual function.  IMHO, it would be just as
legal to declare a virtual foo in MoreDerived as it would be if foo had
never been virtual.  It would also be as useful, since it would have the
same semantics -- Baseptr->foo() or Derivedptr->foo() still always
resolve to Derived::foo(); never to MoreDerived::foo().

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Allan W wrote:
> > Are you suggesting that the function would not
> > occupy a spot in Derived's virtual table?

hyrosen@mail.com (Hyman Rosen) wrote
> It just means that when the function is called
> from a pointer or reference to Derived, that
> call will be direct and will not involve virtual
> dispatch. The function will still be dispatched
> to if it is called through a Base pointer or
> reference.

Okay, so Baseptr->foo() goes through the vtable, where it could
call either Base::foo or Derived::foo, but Derptr->foo() goes
directly to Derived::foo. This means that Derived (and all classes
drived from Derived, if you will) still need a vtable entry for foo.

That means that "turning off virtual" is an optimization only,
right? But how is it different than calling Derptr->Derived::foo()
with today's compilers?

Would you want to allow MoreDerived to "turn virtual back on"?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
> That means that "turning off virtual" is an optimization only,
> right? But how is it different than calling Derptr->Derived::foo()
> with today's compilers?

It's not, except that you don't need to write it that way,
so you can change your mind without changing every call.
Also, a member pointer &Derived::foo would not do virtual
dispatch either.

> Would you want to allow MoreDerived to "turn virtual back on"?

I would. There are others who wouldn't.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote
> Hyman Rosen <hyrosen@mail.com> writes
> >The problem for Java is that it has no object types,
> >only pointers to objects, and no non-virtual functions.
> >Therefore, to gain some of the advantages of inline and
> >direct function calls, that language needs a way to
> >bypass the virtual mechanism. In C++, you can just make
> >methods non-virtual.
>
> Actually not entirely.
>
> In Java all functions start as virtual and you can switch that off when
> you so choose (imposing your will on those that wish to derive from your
> class)
>
> In C++ we start with functions being non-virtual, but once we switch on
> virtual we have no way to switch it off again. Once we have started we
> cannot stop.

This is an interesting angle that I don't think I've seen before.
Are you suggesting that a function which is virtual in Base could be
non-virtual in Derived? Are you suggesting that the function would not
occupy a spot in Derived's virtual table?

We would have to guarantee that code which had a Base* pointing to a
Derived would never try to call that virtual function, directly or
indirectly, or else the results would be undefined. That seems like
a difficult thing to guarantee, in the general case.

I also wonder how compilers would deal with this. Would they re-use the
virtual table entry for another virtual function? That could be a nightmare...

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
> Are you suggesting that the function would not
> occupy a spot in Derived's virtual table?

It just means that when the function is called
from a pointer or reference to Derived, that
call will be direct and will not involve virtual
dispatch. The function will still be dispatched
to if it is called through a Base pointer or
reference.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]