Q: What is Virtual Destructor?
A: Using virtual destructors, you can destroy objects without knowing their type - the correct
destructor for the object is invoked using the virtual function mechanism. Note that destructors
can also be declared as pure virtual functions for abstract classes. if someone will derive from
your class, and if someone will say "new Derived", where "Derived" is derived from your class,
and if someone will say delete p, where the actual object's type is "Derived" but the pointer p's
type is your class.
Q: Can a copy constructor accept an object of the same class as parameter, instead of reference
of the object?
A: No. It is specified in the definition of the copy constructor itself. It should generate an error if
a programmer specifies a copy constructor with a first argument that is an object and not a
reference.
Q: What's the order that local objects are destructed?
A: In reverse order of construction: First constructed, last destructed.
In the following example, b's destructor will be executed first, then a's destructor:
void userCode()
{
Fred a;
Fred b;
...
}
Q: What's the order that objects in an array are destructed?
A: In reverse order of construction: First constructed, last destructed.
In the following example, the order for destructors will be a[9], a[8], ..., a[1], a[0]:
void userCode()
{
Fred a[10];
...
}
Q: Can I overload the destructor for my class?
A: No.
You can have only one destructor for a class Fred. It's always called Fred::~Fred(). It never takes
any parameters, and it never returns anything.
You can't pass parameters to the destructor anyway, since you never explicitly call a destructor
(well, almost never).
Q: Should I explicitly call a destructor on a local variable?
A: No!
The destructor will get called again at the close } of the block in which the local was created.
This is a guarantee of the language; it happens automagically; there's no way to stop it from
happening. But you can get really bad results from calling a destructor on the same object a
second time! Bang! You're dead!
Q: What if I want a local to "die" before the close } of the scope in which it was created? Can I
call a destructor on a local if I really want to?
A: No! [For context, please read the previous FAQ].
Suppose the (desirable) side effect of destructing a local File object is to close the File. Now
suppose you have an object f of a class File and you want File f to be closed before the end of the
scope (i.e., the }) of the scope of object f:
void someCode()
{
File f;
...insert code that should execute when f is still open...
We want the side-effect of f's destructor here!
...insert code that should execute after f is closed...
}
There is a simple solution to this problem. But in the mean time, remember: Do not explicitly
call the destructor!
Q: OK, OK already; I won't explicitly call the destructor of a local; but how do I handle the
above situation?
A: Simply wrap the extent of the lifetime of the local in an artificial block {...}:
void someCode()
{
{
File f;
...insert code that should execute when f is still open...
} f's destructor will automagically be called here!
...insert code here that should execute after f is closed...}
Posts
0 comments:
Post a Comment