What is the use of "PURE vitual distructors"?
And why we can not have vitual constructors?
And why we can not have vitual constructors?
-
-
Re: virtual constructors and distructors...
Shraddha <shraddhajoshi8 4@gmail.comwrot e in news:1182812988 .480330.318240
@j4g2000prf.goo glegroups.com:
Forces a child class to declare their own destructor. Note that evenWhat is the use of "PURE vitual distructors"?
though it's a pure virtual destructor, you still need to supply a body.
See the FAQ:And why we can not have vitual constructors?
-
Re: virtual constructors and distructors...
On 2007-06-26 01:09, Shraddha wrote:If you have a class that you never want to be used as it is, instead youWhat is the use of "PURE vitual distructors"?
want the user to always derive from it you can declare the destructor
pure virtual (but provide an implementation) . This forces the user to
derive if they want to use the class.
--
Erik Wikström
Comment
-
Re: virtual constructors and distructors...
On 26 Jun, 00:09, Shraddha <shraddhajosh.. .@gmail.comwrot e:what is the use of virtual function anyway?What is the use of "PURE vitual distructors"?
And why we can not have vitual constructors?
the difference between pure virtual function and
pure virtual destructor is that you have to write
a body for PV destructor while you don't have to for
PV function. also PV function must be implemented
in the Derived (if you want to instantiate Derived) but
you don't have to implement ~Derive, compiler
generated one will suffice
struct Base
{
virtual ~Base()=0{}
virtual void foo(){}
};
struct Derived : public Base
{
~Derived(){}
void foo(){}
};
int main()
{
Base * p = new Derived;
p->foo();
delete p;
}
p->foo() will call Derived::foo, if Base::foo wasn't
virtual it would call Base::foo
delete p will call Derived destructor, if Base
destructor wasn't virtual it would call Base destructor
since ~Derived will call ~Base you have to provide
a body for ~Base even if it is pure virtual
regards
DS
Comment
-
Re: virtual constructors and distructors...
On 26 Jun, 11:55, dasjotre <dasjo...@googl email.comwrote:
also, declaring any member pure virtual makes
type non instantiable.
Base b; // ERR!struct Base
{
virtual ~Base()=0{}
virtual void foo(){}
};
regards
>
DS
Comment
-
Re: virtual constructors and distructors...
On Jun 26, 7:55 am, dasjotre <dasjo...@googl email.comwrote:this is a syntax errorstruct Base
{
virtual ~Base()=0{}
it should be
struct Base
{
virtual ~Base()=0;
};
....
Base::~Base() {}
Comment
-
Re: virtual constructors and distructors...
On Jun 27, 12:46 pm, Diego Martins <jose.di...@gma il.comwrote:Good point. Also why destructor can be non virtual? Is there any useOn Jun 26, 7:55 am, dasjotre <dasjo...@googl email.comwrote:
>>struct Base
{
virtual ~Base()=0{}
this is a syntax error
>
it should be
>
struct Base
{
virtual ~Base()=0;};
>
...
>
Base::~Base() {}
for that? I have never seen a real world scenario where destructors
shoudl not be virtual.
On the other hand, constructors can't be virtual as was already
pointed out. Except for one compiler called Borland C++ Builder. That
compiler allowed to declare virtual constructors, although the meaning
was different of what you could expect.
Normally C++ constructors can't make virtual function calls, because
the the VMT (virtual method table) is not fully built yet, leading to
subtle and unexpected bugs. In C++ Builder, you could declare your
constructors to be virtual, meaning that before executing the
constructor, the VMT would be fully built and therefore the virtual
methods would be called as appropiate.
Cheers,
Guillermo.
Comment
-
Re: virtual constructors and distructors...
On Jun 28, 6:13 am, Guillermo Schwarz <guillermo.schw ...@gmail.com>
wrote:On Jun 27, 12:46 pm, Diego Martins <jose.di...@gma il.comwrote:On Jun 26, 7:55 am, dasjotre <dasjo...@googl email.comwrote:struct Base
{
virtual ~Base()=0{}this is a syntax errorit should bestruct Base
{
virtual ~Base()=0;};...Base::~Base() {}Really? What about structures which are shared with C? PuttingGood point. Also why destructor can be non virtual? Is there any use
for that? I have never seen a real world scenario where destructors
shoudl not be virtual.
a vptr into the structure isn't going to please the C compiler
any. For that matter, making the destructor virtual for
something like complex<floatco uld double the size of the
object. An important consideration for people working with
large arrays of the thing. In general, for classes with value
semantics, there's no reason for the destructor to be virtual,
and every reason for it not to be.
Once a class has virtual functions, of course, the question
changes. The vptr is already there, so making the destructor
virtual doesn't change anything in this respect. And the
presence of virtual functions means that there is a very high
probability that inheritance will be involved somewhere, and
that a virtual destructor will be needed. On the other hand,
making the virtuality of the destructor depend on whether other
virtual functions are present or not isn't very orthogonal, to
say the least, and is another complication. And IMHO, C++
already has enough special cases, and doesn't really need
another one.
On the other hand, constructors can't be virtual as was already
pointed out. Except for one compiler called Borland C++ Builder. That
compiler allowed to declare virtual constructors, although the meaning
was different of what you could expect.Normally, the can, and in some cases, do.Normally C++ constructors can't make virtual function calls,
Sorry, but the vtbl is always complete, according to the dynamicbecause the the VMT (virtual method table) is not fully built
yet,
type of the object.
Avoiding subtle and unexpected bugs is precisely the reason whyleading to
subtle and unexpected bugs.
the dynamic type evolves. Calling a function on a type whose
constructor hasn't yet started running is a sure recepe for
disaster. Look at all the NullPointerExce ption it causes in
Java.
You mean, the call would dispatch to a function whose thisIn C++ Builder, you could declare your
constructors to be virtual, meaning that before executing the
constructor, the VMT would be fully built and therefore the virtual
methods would be called as appropiate.
pointer pointed to raw memory? Thank God C++ doesn't support an
idiocy like that.
--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Comment
-
Re: virtual constructors and distructors...
On Jun 28, 7:55 am, James Kanze <james.ka...@gm ail.comwrote:FYI, g++ has a pretty useful compiler warning when a class without aOn Jun 28, 6:13 am, Guillermo Schwarz <guillermo.schw ...@gmail.com>
wrote:
>>On Jun 27, 12:46 pm, Diego Martins <jose.di...@gma il.comwrote:Good point. Also why destructor can be non virtual? Is there any useOn Jun 26, 7:55 am, dasjotre <dasjo...@googl email.comwrote:
struct Base
{
virtual ~Base()=0{}
this is a syntax error
it should be
struct Base
{
virtual ~Base()=0;};
...
Base::~Base() {}
for that? I have never seen a real world scenario where destructors
shoudl not be virtual.
Really? What about structures which are shared with C? Putting
a vptr into the structure isn't going to please the C compiler
any. For that matter, making the destructor virtual for
something like complex<floatco uld double the size of the
object. An important consideration for people working with
large arrays of the thing. In general, for classes with value
semantics, there's no reason for the destructor to be virtual,
and every reason for it not to be.
>
Once a class has virtual functions, of course, the question
changes. The vptr is already there, so making the destructor
virtual doesn't change anything in this respect. And the
presence of virtual functions means that there is a very high
probability that inheritance will be involved somewhere, and
that a virtual destructor will be needed. On the other hand,
making the virtuality of the destructor depend on whether other
virtual functions are present or not isn't very orthogonal, to
say the least, and is another complication. And IMHO, C++
already has enough special cases, and doesn't really need
another one.
virtual destructor have other virtual functions
:)
Diego
Comment
Comment