virtual destructor

[siddhu]

Like other virtual functions does the entry of virtual destructor exist
in VTABLE?

 

[mlimber]

Like other virtual functions does the entry of virtual destructor exist
in VTABLE?

In general, it's implementation dependent since there is no guarantee
that there is a vtable. Compilers can use other techniques to implement
virtual dispatching (though I don't know of any that do). See this FAQ:

http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.4

In any implementation that implements vtables, however, I'd guess yes,
it does.

Cheers! --M

 

[Victor Bazarov]

Like other virtual functions does the entry of virtual destructor exist
in VTABLE?

Yes, but only if the implementation actually has VTABLE. The Standard
does not require it, so it is not really a C++ language feature, it's
just an implementation detail.

V

 

[JustBoo]

In general, it's implementation dependent since there is no guarantee
that there is a vtable. Compilers can use other techniques to implement
virtual dispatching (though I don't know of any that do). See this FAQ:

I'm curious: Please name one *current* C++ compiler that does not use
vtables. Just asking.

"Kites rise highest against the wind - not with it."
- Winston Churchill

 

[guyarad]

He said: "(though I don't know of any that do)"

 

[JustBoo]

He said: "(though I don't know of any that do)"

Hmm... let's think about that for awhile shall we. Yeah... just what I
thought.

From the Boost homepage:
"We aim to establish "existing practice" and provide reference
implementations so that Boost libraries are suitable for eventual
standardization. Ten Boost libraries are already included in the C++
Standards Committee's Library Technical Report ( TR1) as a step
toward becoming part of a future C++ Standard. More Boost libraries
are proposed for the upcoming TR2."

So many Boost features are NOT actually IN the C++ Standard.
Is that correct?

From V. Bazarov below:
"The Standard does not require it, so it is not really a C++ l
anguage feature, it's just an implementation detail."

Therefore, discussing Boost features NOT in the Standard is
forbidden in this ng, CORRECT?

I look forward to the Language Lawyers and Net Cops (notice I didn't
say engineers) expelling the horrendous offenders that populate this
ng. Thank you for defending us against the horde.

"All cats die. Socrates is dead. Therefore Socrates is a cat."

 

[Victor Bazarov]

Hmm... let's think about that for awhile shall we. Yeah... just what I
thought.

OK, so you had your question answered before you asked it, right? What
are you going on for, then?

From the Boost homepage:
"We aim to establish "existing practice" and provide reference
implementations so that Boost libraries are suitable for eventual
standardization. Ten Boost libraries are already included in the C++
Standards Committee's Library Technical Report ( TR1) as a step
toward becoming part of a future C++ Standard. More Boost libraries
are proposed for the upcoming TR2."

So many Boost features are NOT actually IN the C++ Standard.
Is that correct?

Sure. That's why 'Boost' is called "a third-party library". And not all
of it is going to be part of future C++ library either.

From V. Bazarov below:
"The Standard does not require it, so it is not really a C++ l
anguage feature, it's just an implementation detail."

Therefore, discussing Boost features NOT in the Standard is
forbidden in this ng, CORRECT?

How do you arrive at that? Discuss implementation details as much as you
want, just remember that they are that, details, and are not guaranteed to
be in the next implementation you get to use. As soon as you decide to
rely on those features, you're bound to encounter more problems than if
you just use the Standard Library.

I look forward to the Language Lawyers and Net Cops (notice I didn't
say engineers) expelling the horrendous offenders that populate this
ng.

Really? This newsgroup is unmoderated. We do here as we please. Nobody
is expelled unless the ISP decides to pull the plug on the access to the
entire Internet. But those things are rare, and there are plenty of ISPs
out there who don't care.

> Thank you for defending us against the horde.

I am guessing sarcasm here, but I just can't figure out what exactly in
this thread or in the poster's message to which you replied, warranted or
provoked that.

V

 

[Dietmar Kuehl]

I'm curious: Please name one *current* C++ compiler that does not use
vtables. Just asking.

Actually, I think you would be hard pressed to find any *current* C++
compiler which implements virtual functions as calling a function from
some table like the original CFront compiler did: the CFront virtual
function table is the what I would consider a vtable. Modern C++
implementations typically use things called "thunks" which e.g. do
appropriate pointer adjustments before effectively calling into a
a function looked up by the thunk. The key difference here is that
you could simply call a function obtained from a vtable using the
'this' pointer in CFront's implementations. You cannot do anything
like this with the data looked up by a thunk because you would first
need to adjust the position the 'this' pointer points to.

That is, while you could in principle (if there were an accessible
member called '_Vtable' to access the virtual function table) use

(obj->_Vtable[idx])(obj)

to call a virtual function without arguments using a vtable, you
cannot do anything like this with thunks. Also note that there are
different approaches to thunks: these could be small functions which
are really generated or the necessary operations could be applied
inline.

 

[JustBoo]

Actually, I think you would be hard pressed to find any *current* C++
compiler which implements virtual functions as calling a function from
some table like the original CFront compiler did: the CFront virtual
function table is the what I would consider a vtable. Modern C++
implementations typically use things called "thunks" which e.g. do
appropriate pointer adjustments before effectively calling into a
a function looked up by the thunk. The key difference here is that
you could simply call a function obtained from a vtable using the
'this' pointer in CFront's implementations. You cannot do anything
like this with the data looked up by a thunk because you would first
need to adjust the position the 'this' pointer points to.

Wow, what goes around comes around. I remember thunking functions
in the good ol' bad ol' days of Win16 - that's Win16 - programming.
IIRC it involved FAR (sorta' 32bit) segment/offset addressing. You had
a pre and post operation for each function. Much as you describe
above.

That is, while you could in principle (if there were an accessible
member called '_Vtable' to access the virtual function table) use

(obj->_Vtable[idx])(obj)

to call a virtual function without arguments using a vtable, you
cannot do anything like this with thunks. Also note that there are
different approaches to thunks: these could be small functions which
are really generated or the necessary operations could be applied
inline.

I'm a bit surprised, I won't mention the specific compiler -
unfortunately the most popular one on earth - again if IIRC - allows
straight C programs to develop a direct pointer into a certain
subsystem vtable and access it without thunking. They call it "VTBL
Binding." Of course this compiler is not known for standard behavior.

You did say any current compiler. Does gcc not allow access to
it's vtables?

I have learned something, I like that.