PREVIOUS NEXT
CONSTRUCTOR/DESTRUCTOR
Q: Is it possible to have Virtual Constructor? If yes, how? If not, Why not possible?
A: There is nothing like Virtual Constructor. The Constructor can’t be virtual as the constructor
is a code which is responsible for creating an instance of a class and it can’t be delegated to
any other object by virtual keyword means.
Q: What is constructor or ctor?
A: Constructor creates an object and initializes it. It also creates vtable for virtual functions. It is
different from other methods in a class.
Q: What about Virtual Destructor?
A: Yes there is a Virtual Destructor. A destructor can be virtual as it is possible as at runtime
depending on the type of object caller is calling to, proper destructor will be called.
Q: What is the difference between a copy constructor and an overloaded assignment operator?
A: A copy constructor constructs a new object by using the content of the argument object. An
overloaded assignment operator assigns the contents of an existing object to another existing
object of the same class.
Q: Can a constructor throws an exception? How to handle the error when the constructor fails?
A:The constructor never throws an error.
Q: What is default constructor?
A: Constructor with no arguments or all the arguments has default values.
Q: What is copy constructor?
A: Constructor which initializes the it's object member variables ( by
shallow copying) with another object of the same class. If you don't implement one in your class
then compiler implements one for you. for example:
(a) Boo Obj1(10); // calling Boo constructor
(b) Boo Obj2(Obj1); // calling boo copy constructor
(c) Boo Obj2 = Obj1;// calling boo copy constructor
Q: When are copy constructors called?
A: Copy constructors are called in following cases:
(a) when a function returns an object of that
class by value
(b) when the object of that class is passed by
value as an argument to a function
(c) when you construct an object based on another
object of the same class
(d) When compiler generates a temporary object
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 is conversion constructor?
A: constructor with a single argument makes that constructor as conversion ctor and it can be
used for type conversion.
for example:
class Boo
{
public:
Boo( int i );
};
Boo BooObject = 10 ; // assigning int 10 Boo object
Q:What is conversion operator??
A:class can have a public method for specific data type conversions.
for example:
class Boo
{
double value;
public:
Boo(int i )
operator double()
{
return value;
}
};
Boo BooObject;
double i = BooObject; // assigning object to variable i of type double.
now conversion operator gets called to assign the value.
Q: How can I handle a constructor that fails?
A: throw an exception. Constructors don't have a return type, so it's not possible to use return
codes. The best way to signal constructor failure is therefore to throw an exception.
Q: How can I handle a destructor that fails?
A: Write a message to a log-_le. But do not throw an exception. The C++ rule is that you must
never throw an exception from a destructor that is being called during the "stack unwinding"
process of another exception. For example, if someone says throw Foo(), the stack will be
unwound so all the stack frames between the throw Foo() and the } catch (Foo e) { will get
popped. This is called stack unwinding. During stack unwinding, all the local objects in all
those stack frames are destructed. If one of those destructors throws an exception (say it throws a
Bar object), the C++ runtime system is in a no-win situation: should it ignore the Bar and end up
in the } catch (Foo e) { where it was originally headed? Should it ignore the Foo and look for a }
catch (Bare) { handler? There is no good answer:either choice
loses information. So the C++ language guarantees that it will call terminate() at this point, and
terminate() kills the process. Bang you're dead.
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...}
Q: What if I can't wrap the local in an artificial block?A: Most of the time, you can limit the lifetime of a local by wrapping the local in an artificial
block ({...}). But if for some reason you can't do that, add a member function that has a similar
effect as the destructor. But do not call the destructor itself!
For example, in the case of class File, you might add a close() method. Typically the destructor
will simply call this close() method. Note that the close() method will need to mark the File
object so a subsequent call won't re-close an already-closed File. E.g., it might set the
fileHandle_ data member to some nonsensical value such as -1, and it might check at the
beginning to see if the fileHandle_ is already equal to -1:
class File {
public:
void close();
~File();
...
private:
int fileHandle_; // fileHandle_ >= 0 if/only-if it's open
};
File::~File()
{
close();
}
void File::close()
{
if (fileHandle_ >= 0) {
...insert code to call the OS to close the file...
fileHandle_ = -1;
}
}
Note that the other File methods may also need to check if the fileHandle_ is -1 (i.e., check if the
File is closed).
Note also that any constructors that don't actually open a file should set fileHandle_ to -1.
Q: But can I explicitly call a destructor if I've allocated my object with new?
A: Probably not.
Unless you used placement new, you should simply delete the object rather than explicitly
calling the destructor. For example, suppose you allocated the object via a typical new
expression:
Fred* p = new Fred();
Then the destructor Fred::~Fred() will automagically get called when you delete it via:
delete p; // Automagically calls p->~Fred()
You should not explicitly call the destructor, since doing so won't release the memory that was
allocated for the Fred object itself. Remember: delete p does two things: it calls the destructor
and it deallocates the memory.
Q: What is "placement new" and why would I use it?
A: There are many uses of placement new. The simplest use is to place an object at a particular
location in memory. This is done by supplying the place as a pointer parameter to the new part of
a new expression:
#include // Must #include this to use "placement new"
#include "Fred.h" // Declaration of class Fred
void someCode()
{
char memory[sizeof(Fred)]; // Line #1
void* place = memory; // Line #2
Fred* f = new(place) Fred(); // Line #3 (see "DANGER" below)
// The pointers f and place will be equal
...
}
Line #1 creates an array of sizeof(Fred) bytes of memory, which is big enough to hold a Fred
object. Line #2 creates a pointer place that points to the first byte of this memory (experienced C
programmers will note that this step was unnecessary; it's there only to make the code more
obvious). Line #3 essentially just calls the constructor Fred::Fred(). The this pointer in the Fred
constructor will be equal to place. The returned pointer f will therefore be equal to place.
ADVICE: Don't use this "placement new" syntax unless you have to. Use it only when you really
care that an object is placed at a particular location in memory. For example, when your
hardware has a memory-mapped I/O timer device, and you want to place a Clock object at that
memory location.
DANGER: You are taking sole responsibility that the pointer you pass to the "placement new"
operator points to a region of memory that is big enough and is properly aligned for the object
type that you're creating. Neither the compiler nor the run-time system make any attempt to
check whether you did this right. If your Fred class needs to be aligned on a 4 byte boundary but
you supplied a location that isn't properly aligned, you can have a serious disaster on your hands
(if you don't know what "alignment" means, please don't use the placement new syntax). You
have been warned.
You are also solely responsible for destructing the placed object. This is done by explicitly
calling the destructor:
void someCode()
{
char memory[sizeof(Fred)];
void* p = memory;
Fred* f = new(p) Fred();
...
f->~Fred(); // Explicitly call the destructor for the placed object
}
This is about the only time you ever explicitly call a destructor.
Note: there is a much cleaner but more sophisticated way of handling the destruction / deletion
situation.
Q: When I write a destructor, do I need to explicitly call the destructors for my member objects?
A: No. You never need to explicitly call a destructor (except with placement new).
A class's destructor (whether or not you explicitly define one) automagically invokes the
destructors for member objects. They are destroyed in the reverse order they appear within the
declaration for the class.
class Member {
public:
~Member();
...
};
class Fred {
public:
~Fred();
...
private:
Member x_;
Member y_;
Member z_;
};
Fred::~Fred()
{
// Compiler automagically calls z_.~Member()
// Compiler automagically calls y_.~Member()
// Compiler automagically calls x_.~Member()
}
Q: When I write a derived class's destructor, do I need to explicitly call the destructor for my
base class?A: No. You never need to explicitly call a destructor (except with placement new).
A derived class's destructor (whether or not you explicitly define one) automagically invokes the
destructors for base class subobjects. Base classes are destructed after member objects. In the
event of multiple inheritance, direct base classes are destructed in the reverse order of their
appearance in the inheritance list.
class Member {
public:
~Member();
...
};
class Base {
public:
virtual ~Base(); // A virtual destructor
...
};
class Derived : public Base {
public:
~Derived();
...
private:
Member x_;
};
Derived::~Derived()
{
// Compiler automagically calls x_.~Member()
// Compiler automagically calls Base::~Base()
}
Note: Order dependencies with virtual inheritance are trickier. If you are relying on order
dependencies in a virtual inheritance hierarchy, you'll need a lot more information than is in this
FAQ.
Q: Is there any difference between List x; and List x();?A: A big difference!
Suppose that List is the name of some class. Then function f() declares a local List object called
x:
void f()
{
List x; // Local object named x (of class List)
...
}
But function g() declares a function called x() that returns a List:
void g()
{
List x(); // Function named x (that returns a List)
...
}
Q: Can one constructor of a class call another constructor of the same class to initialize the this
object?A: Nope.
Let's work an example. Suppose you want your constructor Foo::Foo(char) to call another
constructor of the same class, say Foo::Foo(char,int), in order that Foo::Foo(char,int) would help
initialize the this object. Unfortunately there's no way to do this in C++.
Some people do it anyway. Unfortunately it doesn't do what they want. For example, the line
Foo(x, 0); does not call Foo::Foo(char,int) on the this object. Instead it calls Foo::Foo(char,int) to
initialize a temporary, local object (not this), then it immediately destructs that temporary when
control flows over the ;.
class Foo {
public:
Foo(char x);
Foo(char x, int y);
...
};
Foo::Foo(char x)
{
...
Foo(x, 0); // this line does NOT help initialize the this object!!
...
}
You can sometimes combine two constructors via a default parameter:
class Foo {
public:
Foo(char x, int y=0); // this line combines the two constructors
...
};
If that doesn't work, e.g., if there isn't an appropriate default parameter that combines the two
constructors, sometimes you can share their common code in a private init() member function:
class Foo {
public:
Foo(char x);
Foo(char x, int y);
...
private:
void init(char x, int y);
};
Foo::Foo(char x)
{
init(x, int(x) + 7);
...
}
Foo::Foo(char x, int y)
{
init(x, y);
...
}
void Foo::init(char x, int y)
{
...
}
BTW do NOT try to achieve this via placement new. Some people think they can say new(this)
Foo(x, int(x)+7) within the body of Foo::Foo(char). However that is bad, bad, bad. Please don't
write me and tell me that it seems to work on your particular version of your particular compiler;
it's bad. Constructors do a bunch of little magical things behind the scenes, but that bad
technique steps on those partially constructed bits. Just say no.
Q: Is the default constructor for Fred always Fred::Fred()?A: No. A "default constructor" is a constructor that can be called with no arguments. One
example of this is a constructor that takes no parameters:
class Fred {
public:
Fred(); // Default constructor: can be called with no args
...
};
Another example of a "default constructor" is one that can take arguments, provided they are
given default values:
class Fred {
public:
Fred(int i=3, int j=5); // Default constructor: can be called with no args
...
};
Q: Which constructor gets called when I create an array of Fred objects?A: Fred's default constructor (except as discussed below).
class Fred {
public:
Fred();
...
};
int main()
{
Fred a[10]; calls the default constructor 10 times
Fred* p = new Fred[10]; calls the default constructor 10 times
...
}
If your class doesn't have a default constructor, you'll get a compile-time error when you attempt
to create an array using the above simple syntax:
class Fred {
public:
Fred(int i, int j); assume there is no default constructor
...
};
int main()
{
Fred a[10]; ERROR: Fred doesn't have a default constructor
Fred* p = new Fred[10]; ERROR: Fred doesn't have a default constructor
...
}
However, even if your class already has a default constructor, you should try to use std::vector
rather than an array (arrays are evil). std::vector lets you decide to use any constructor, not just
the default constructor:
#include
int main()
{
std::vector a(10, Fred(5,7)); the 10 Fred objects in std::vector a will be initialized with Fred(5,7)
...
}
Even though you ought to use a std::vector rather than an array, there are times when an array
might be the right thing to do, and for those, you might need the "explicit initialization of arrays"
syntax. Here's how:
class Fred {
public:
Fred(int i, int j); assume there is no default constructor
...
};
int main()
{
Fred a[10] = {
Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), // The 10 Fred objects are
Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7) // initialized using Fred(5,7)
};
...
}
Of course you don't have to do Fred(5,7) for every entry you can put in any numbers you want,
even parameters or other variables.
Finally, you can use placement-new to manually initialize the elements of the array. Warning: it's
ugly: the raw array can't be of type Fred, so you'll need a bunch of pointer-casts to do things like
compute array index operations. Warning: it's compiler- and hardware-dependent: you'll need to
make sure the storage is aligned with an alignment that is at least as strict as is required for
objects of class Fred. Warning: it's tedious to make it exception-safe: you'll need to manually
destruct the elements, including in the case when an exception is thrown part-way through the
loop that calls the constructors. But if you really want to do it anyway, read up on placementnew. (BTW placement-new is the magic that is used inside of std::vector. The complexity of
getting everything right is yet another reason to use std::vector.)
By the way, did I ever mention that arrays are evil? Or did I mention that you ought to use a
std::vector unless there is a compelling reason to use an array?
Q: Should my constructors use "initialization lists" or "assignment"?A: Initialization lists. In fact, constructors should initialize as a rule all member objects in the
initialization list. One exception is discussed further down.
Consider the following constructor that initializes member object x_ using an initialization list:
Fred::Fred() : x_(whatever) { }. The most common benefit of doing this is improved
performance. For example, if the expression whatever is the same type as member variable x_,
the result of the whatever expression is constructed directly inside x_ the compiler does not
make a separate copy of the object. Even if the types are not the same, the compiler is usually
able to do a better job with initialization lists than with assignments.
The other (inefficient) way to build constructors is via assignment, such as: Fred::Fred() { x_ =
whatever; }. In this case the expression whatever causes a separate, temporary object to be
created, and this temporary object is passed into the x_ object's assignment operator. Then that
temporary object is destructed at the ;. That's inefficient.
As if that wasn't bad enough, there's another source of inefficiency when using assignment in a
constructor: the member object will get fully constructed by its default constructor, and this
might, for example, allocate some default amount of memory or open some default file. All this
work could be for naught if the whatever expression and/or assignment operator causes the
object to close that file and/or release that memory (e.g., if the default constructor didn't allocate
a large enough pool of memory or if it opened the wrong file).
Conclusion: All other things being equal, your code will run faster if you use initialization lists
rather than assignment.
Note: There is no performance difference if the type of x_ is some built-in/intrinsic type, such as
int or char* or float. But even in these cases, my personal preference is to set those data members
in the initialization list rather than via assignment for consistency. Another symmetry argument
in favor of using initialization lists even for built-in/intrinsic types: non-static const and nonstatic reference data members can't be assigned a value in the constructor, so for symmetry it
makes sense to initialize everything in the initialization list.
Now for the exceptions. Every rule has exceptions (hmmm; does "every rule has exceptions"
have exceptions? reminds me of Gdel's Incompleteness Theorems), and there are a couple of
exceptions to the "use initialization lists" rule. Bottom line is to use common sense: if it's
cheaper, better, faster, etc. to not use them, then by all means, don't use them. This might happen
when your class has two constructors that need to initialize the this object's data members in
different orders. Or it might happen when two data members are self-referential. Or when a datamember needs a reference to the this object, and you want to avoid a compiler warning about
using the this keyword prior to the { that begins the constructor's body (when your particular
compiler happens to issue that particular warning). Or when you need to do an if/throw test on a
variable (parameter, global, etc.) prior to using that variable to initialize one of your this
members. This list is not exhaustive; please don't write me asking me to add another "Or
when...". The point is simply this: use common sense.
Q: Should you use the this pointer in the constructor?
A: Some people feel you should not use the this pointer in a constructor because the object is not
fully formed yet. However you can use this in the constructor (in the {body} and even in the
initialization list) if you are careful.
Here is something that always works: the {body} of a constructor (or a function called from the
constructor) can reliably access the data members declared in a base class and/or the data
members declared in the constructor's own class. This is because all those data members are
guaranteed to have been fully constructed by the time the constructor's {body} starts executing.
Here is something that never works: the {body} of a constructor (or a function called from the
constructor) cannot get down to a derived class by calling a virtual member function that is
overridden in the derived class. If your goal was to get to the overridden function in the derived
class, you won't get what you want. Note that you won't get to the override in the derived class
independent of how you call the virtual member function: explicitly using the this pointer (e.g.,
this->method()), implicitly using the this pointer (e.g., method()), or even calling some other
function that calls the virtual member function on your this object. The bottom line is this: even
if the caller is constructing an object of a derived class, during the constructor of the base class,
your object is not yet of that derived class. You have been warned.
Here is something that sometimes works: if you pass any of the data members in this object to
another data member's initializer, you must make sure that the other data member has already
been initialized. The good news is that you can determine whether the other data member has (or
has not) been initialized using some straightforward language rules that are independent of the
particular compiler you're using. The bad news it that you have to know those language rules
(e.g., base class sub-objects are initialized first (look up the order if you have multiple and/or
virtual inheritance!), then data members defined in the class are initialized in the order in which
they appear in the class declaration). If you don't know these rules, then don't pass any data
member from the this object (regardless of whether or not you explicitly use the this keyword) to
any other data member's initializer! And if you do know the rules, please be careful.
Q: What is the "Named Constructor Idiom"?
A: A technique that provides more intuitive and/or safer construction operations for users of your
class.
The problem is that constructors always have the same name as the class. Therefore the only way
to differentiate between the various constructors of a class is by the parameter list. But if there
are lots of constructors, the differences between them become somewhat subtle and error prone.
With the Named Constructor Idiom, you declare all the class's constructors in the private or
protected sections, and you provide public static methods that return an object. These static
methods are the so-called "Named Constructors." In general there is one such static method for
each different way to construct an object.
For example, suppose we are building a Point class that represents a position on the X-Y plane.
Turns out there are two common ways to specify a 2-space coordinate: rectangular coordinates
(X+Y), polar coordinates (Radius+Angle). (Don't worry if you can't remember these; the point
isn't the particulars of coordinate systems; the point is that there are several ways to create a
Point object.) Unfortunately the parameters for these two coordinate systems are the same: two
floats. This would create an ambiguity error in the overloaded constructors:
class Point {
public:
Point(float x, float y); // Rectangular coordinates
Point(float r, float a); // Polar coordinates (radius and angle)
// ERROR: Overload is Ambiguous: Point::Point(float,float)
};
int main()
{
Point p = Point(5.7, 1.2); // Ambiguous: Which coordinate system?
...
}
One way to solve this ambiguity is to use the Named Constructor Idiom:
#include // To get sin() and cos()
class Point {
public:
static Point rectangular(float x, float y); // Rectangular coord's
static Point polar(float radius, float angle); // Polar coordinates
// These static methods are the so-called "named constructors"
...
private:
Point(float x, float y); // Rectangular coordinates
float x_, y_;
};
inline Point::Point(float x, float y)
: x_(x), y_(y) { }
inline Point Point::rectangular(float x, float y)
{ return Point(x, y); }
inline Point Point::polar(float radius, float angle)
{ return Point(radius*cos(angle), radius*sin(angle)); }
Now the users of Point have a clear and unambiguous syntax for creating Points in either
coordinate system:
int main()
{
Point p1 = Point::rectangular(5.7, 1.2); // Obviously rectangular
Point p2 = Point::polar(5.7, 1.2); // Obviously polar
...
}
Make sure your constructors are in the protected section if you expect Point to have derived
classes.
The Named Constructor Idiom can also be used to make sure your objects are always created via
new.
Note that the Named Constructor Idiom, at least as implemented above, is just as fast as directly
calling a constructor modern compilers will not make any extra copies of your object.
PREVIOUS NEXT
CONSTRUCTOR/DESTRUCTOR
Q: Is it possible to have Virtual Constructor? If yes, how? If not, Why not possible?
A: There is nothing like Virtual Constructor. The Constructor can’t be virtual as the constructor
is a code which is responsible for creating an instance of a class and it can’t be delegated to
any other object by virtual keyword means.
Q: What is constructor or ctor?
A: Constructor creates an object and initializes it. It also creates vtable for virtual functions. It is
different from other methods in a class.
Q: What about Virtual Destructor?
A: Yes there is a Virtual Destructor. A destructor can be virtual as it is possible as at runtime
depending on the type of object caller is calling to, proper destructor will be called.
Q: What is the difference between a copy constructor and an overloaded assignment operator?
A: A copy constructor constructs a new object by using the content of the argument object. An
overloaded assignment operator assigns the contents of an existing object to another existing
object of the same class.
Q: Can a constructor throws an exception? How to handle the error when the constructor fails?
A:The constructor never throws an error.
Q: What is default constructor?
A: Constructor with no arguments or all the arguments has default values.
Q: What is copy constructor?
A: Constructor which initializes the it's object member variables ( by
shallow copying) with another object of the same class. If you don't implement one in your class
then compiler implements one for you. for example:
(a) Boo Obj1(10); // calling Boo constructor
(b) Boo Obj2(Obj1); // calling boo copy constructor
(c) Boo Obj2 = Obj1;// calling boo copy constructor
Q: When are copy constructors called?
A: Copy constructors are called in following cases:
(a) when a function returns an object of that
class by value
(b) when the object of that class is passed by
value as an argument to a function
(c) when you construct an object based on another
object of the same class
(d) When compiler generates a temporary object
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 is conversion constructor?
A: constructor with a single argument makes that constructor as conversion ctor and it can be
used for type conversion.
for example:
class Boo
{
public:
Boo( int i );
};
Boo BooObject = 10 ; // assigning int 10 Boo object
Q:What is conversion operator??
A:class can have a public method for specific data type conversions.
for example:
class Boo
{
double value;
public:
Boo(int i )
operator double()
{
return value;
}
};
Boo BooObject;
double i = BooObject; // assigning object to variable i of type double.
now conversion operator gets called to assign the value.
Q: How can I handle a constructor that fails?
A: throw an exception. Constructors don't have a return type, so it's not possible to use return
codes. The best way to signal constructor failure is therefore to throw an exception.
Q: How can I handle a destructor that fails?
A: Write a message to a log-_le. But do not throw an exception. The C++ rule is that you must
never throw an exception from a destructor that is being called during the "stack unwinding"
process of another exception. For example, if someone says throw Foo(), the stack will be
unwound so all the stack frames between the throw Foo() and the } catch (Foo e) { will get
popped. This is called stack unwinding. During stack unwinding, all the local objects in all
those stack frames are destructed. If one of those destructors throws an exception (say it throws a
Bar object), the C++ runtime system is in a no-win situation: should it ignore the Bar and end up
in the } catch (Foo e) { where it was originally headed? Should it ignore the Foo and look for a }
catch (Bare) { handler? There is no good answer:either choice
loses information. So the C++ language guarantees that it will call terminate() at this point, and
terminate() kills the process. Bang you're dead.
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...}
Q: What if I can't wrap the local in an artificial block?A: Most of the time, you can limit the lifetime of a local by wrapping the local in an artificial
block ({...}). But if for some reason you can't do that, add a member function that has a similar
effect as the destructor. But do not call the destructor itself!
For example, in the case of class File, you might add a close() method. Typically the destructor
will simply call this close() method. Note that the close() method will need to mark the File
object so a subsequent call won't re-close an already-closed File. E.g., it might set the
fileHandle_ data member to some nonsensical value such as -1, and it might check at the
beginning to see if the fileHandle_ is already equal to -1:
class File {
public:
void close();
~File();
...
private:
int fileHandle_; // fileHandle_ >= 0 if/only-if it's open
};
File::~File()
{
close();
}
void File::close()
{
if (fileHandle_ >= 0) {
...insert code to call the OS to close the file...
fileHandle_ = -1;
}
}
Note that the other File methods may also need to check if the fileHandle_ is -1 (i.e., check if the
File is closed).
Note also that any constructors that don't actually open a file should set fileHandle_ to -1.
Q: But can I explicitly call a destructor if I've allocated my object with new?
A: Probably not.
Unless you used placement new, you should simply delete the object rather than explicitly
calling the destructor. For example, suppose you allocated the object via a typical new
expression:
Fred* p = new Fred();
Then the destructor Fred::~Fred() will automagically get called when you delete it via:
delete p; // Automagically calls p->~Fred()
You should not explicitly call the destructor, since doing so won't release the memory that was
allocated for the Fred object itself. Remember: delete p does two things: it calls the destructor
and it deallocates the memory.
Q: What is "placement new" and why would I use it?
A: There are many uses of placement new. The simplest use is to place an object at a particular
location in memory. This is done by supplying the place as a pointer parameter to the new part of
a new expression:
#include // Must #include this to use "placement new"
#include "Fred.h" // Declaration of class Fred
void someCode()
{
char memory[sizeof(Fred)]; // Line #1
void* place = memory; // Line #2
Fred* f = new(place) Fred(); // Line #3 (see "DANGER" below)
// The pointers f and place will be equal
...
}
Line #1 creates an array of sizeof(Fred) bytes of memory, which is big enough to hold a Fred
object. Line #2 creates a pointer place that points to the first byte of this memory (experienced C
programmers will note that this step was unnecessary; it's there only to make the code more
obvious). Line #3 essentially just calls the constructor Fred::Fred(). The this pointer in the Fred
constructor will be equal to place. The returned pointer f will therefore be equal to place.
ADVICE: Don't use this "placement new" syntax unless you have to. Use it only when you really
care that an object is placed at a particular location in memory. For example, when your
hardware has a memory-mapped I/O timer device, and you want to place a Clock object at that
memory location.
DANGER: You are taking sole responsibility that the pointer you pass to the "placement new"
operator points to a region of memory that is big enough and is properly aligned for the object
type that you're creating. Neither the compiler nor the run-time system make any attempt to
check whether you did this right. If your Fred class needs to be aligned on a 4 byte boundary but
you supplied a location that isn't properly aligned, you can have a serious disaster on your hands
(if you don't know what "alignment" means, please don't use the placement new syntax). You
have been warned.
You are also solely responsible for destructing the placed object. This is done by explicitly
calling the destructor:
void someCode()
{
char memory[sizeof(Fred)];
void* p = memory;
Fred* f = new(p) Fred();
...
f->~Fred(); // Explicitly call the destructor for the placed object
}
This is about the only time you ever explicitly call a destructor.
Note: there is a much cleaner but more sophisticated way of handling the destruction / deletion
situation.
Q: When I write a destructor, do I need to explicitly call the destructors for my member objects?
A: No. You never need to explicitly call a destructor (except with placement new).
A class's destructor (whether or not you explicitly define one) automagically invokes the
destructors for member objects. They are destroyed in the reverse order they appear within the
declaration for the class.
class Member {
public:
~Member();
...
};
class Fred {
public:
~Fred();
...
private:
Member x_;
Member y_;
Member z_;
};
Fred::~Fred()
{
// Compiler automagically calls z_.~Member()
// Compiler automagically calls y_.~Member()
// Compiler automagically calls x_.~Member()
}
Q: When I write a derived class's destructor, do I need to explicitly call the destructor for my
base class?A: No. You never need to explicitly call a destructor (except with placement new).
A derived class's destructor (whether or not you explicitly define one) automagically invokes the
destructors for base class subobjects. Base classes are destructed after member objects. In the
event of multiple inheritance, direct base classes are destructed in the reverse order of their
appearance in the inheritance list.
class Member {
public:
~Member();
...
};
class Base {
public:
virtual ~Base(); // A virtual destructor
...
};
class Derived : public Base {
public:
~Derived();
...
private:
Member x_;
};
Derived::~Derived()
{
// Compiler automagically calls x_.~Member()
// Compiler automagically calls Base::~Base()
}
Note: Order dependencies with virtual inheritance are trickier. If you are relying on order
dependencies in a virtual inheritance hierarchy, you'll need a lot more information than is in this
FAQ.
Q: Is there any difference between List x; and List x();?A: A big difference!
Suppose that List is the name of some class. Then function f() declares a local List object called
x:
void f()
{
List x; // Local object named x (of class List)
...
}
But function g() declares a function called x() that returns a List:
void g()
{
List x(); // Function named x (that returns a List)
...
}
Q: Can one constructor of a class call another constructor of the same class to initialize the this
object?A: Nope.
Let's work an example. Suppose you want your constructor Foo::Foo(char) to call another
constructor of the same class, say Foo::Foo(char,int), in order that Foo::Foo(char,int) would help
initialize the this object. Unfortunately there's no way to do this in C++.
Some people do it anyway. Unfortunately it doesn't do what they want. For example, the line
Foo(x, 0); does not call Foo::Foo(char,int) on the this object. Instead it calls Foo::Foo(char,int) to
initialize a temporary, local object (not this), then it immediately destructs that temporary when
control flows over the ;.
class Foo {
public:
Foo(char x);
Foo(char x, int y);
...
};
Foo::Foo(char x)
{
...
Foo(x, 0); // this line does NOT help initialize the this object!!
...
}
You can sometimes combine two constructors via a default parameter:
class Foo {
public:
Foo(char x, int y=0); // this line combines the two constructors
...
};
If that doesn't work, e.g., if there isn't an appropriate default parameter that combines the two
constructors, sometimes you can share their common code in a private init() member function:
class Foo {
public:
Foo(char x);
Foo(char x, int y);
...
private:
void init(char x, int y);
};
Foo::Foo(char x)
{
init(x, int(x) + 7);
...
}
Foo::Foo(char x, int y)
{
init(x, y);
...
}
void Foo::init(char x, int y)
{
...
}
BTW do NOT try to achieve this via placement new. Some people think they can say new(this)
Foo(x, int(x)+7) within the body of Foo::Foo(char). However that is bad, bad, bad. Please don't
write me and tell me that it seems to work on your particular version of your particular compiler;
it's bad. Constructors do a bunch of little magical things behind the scenes, but that bad
technique steps on those partially constructed bits. Just say no.
Q: Is the default constructor for Fred always Fred::Fred()?A: No. A "default constructor" is a constructor that can be called with no arguments. One
example of this is a constructor that takes no parameters:
class Fred {
public:
Fred(); // Default constructor: can be called with no args
...
};
Another example of a "default constructor" is one that can take arguments, provided they are
given default values:
class Fred {
public:
Fred(int i=3, int j=5); // Default constructor: can be called with no args
...
};
Q: Which constructor gets called when I create an array of Fred objects?A: Fred's default constructor (except as discussed below).
class Fred {
public:
Fred();
...
};
int main()
{
Fred a[10]; calls the default constructor 10 times
Fred* p = new Fred[10]; calls the default constructor 10 times
...
}
If your class doesn't have a default constructor, you'll get a compile-time error when you attempt
to create an array using the above simple syntax:
class Fred {
public:
Fred(int i, int j); assume there is no default constructor
...
};
int main()
{
Fred a[10]; ERROR: Fred doesn't have a default constructor
Fred* p = new Fred[10]; ERROR: Fred doesn't have a default constructor
...
}
However, even if your class already has a default constructor, you should try to use std::vector
rather than an array (arrays are evil). std::vector lets you decide to use any constructor, not just
the default constructor:
#include
int main()
{
std::vector a(10, Fred(5,7)); the 10 Fred objects in std::vector a will be initialized with Fred(5,7)
...
}
Even though you ought to use a std::vector rather than an array, there are times when an array
might be the right thing to do, and for those, you might need the "explicit initialization of arrays"
syntax. Here's how:
class Fred {
public:
Fred(int i, int j); assume there is no default constructor
...
};
int main()
{
Fred a[10] = {
Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), // The 10 Fred objects are
Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7) // initialized using Fred(5,7)
};
...
}
Of course you don't have to do Fred(5,7) for every entry you can put in any numbers you want,
even parameters or other variables.
Finally, you can use placement-new to manually initialize the elements of the array. Warning: it's
ugly: the raw array can't be of type Fred, so you'll need a bunch of pointer-casts to do things like
compute array index operations. Warning: it's compiler- and hardware-dependent: you'll need to
make sure the storage is aligned with an alignment that is at least as strict as is required for
objects of class Fred. Warning: it's tedious to make it exception-safe: you'll need to manually
destruct the elements, including in the case when an exception is thrown part-way through the
loop that calls the constructors. But if you really want to do it anyway, read up on placementnew. (BTW placement-new is the magic that is used inside of std::vector. The complexity of
getting everything right is yet another reason to use std::vector.)
By the way, did I ever mention that arrays are evil? Or did I mention that you ought to use a
std::vector unless there is a compelling reason to use an array?
Q: Should my constructors use "initialization lists" or "assignment"?A: Initialization lists. In fact, constructors should initialize as a rule all member objects in the
initialization list. One exception is discussed further down.
Consider the following constructor that initializes member object x_ using an initialization list:
Fred::Fred() : x_(whatever) { }. The most common benefit of doing this is improved
performance. For example, if the expression whatever is the same type as member variable x_,
the result of the whatever expression is constructed directly inside x_ the compiler does not
make a separate copy of the object. Even if the types are not the same, the compiler is usually
able to do a better job with initialization lists than with assignments.
The other (inefficient) way to build constructors is via assignment, such as: Fred::Fred() { x_ =
whatever; }. In this case the expression whatever causes a separate, temporary object to be
created, and this temporary object is passed into the x_ object's assignment operator. Then that
temporary object is destructed at the ;. That's inefficient.
As if that wasn't bad enough, there's another source of inefficiency when using assignment in a
constructor: the member object will get fully constructed by its default constructor, and this
might, for example, allocate some default amount of memory or open some default file. All this
work could be for naught if the whatever expression and/or assignment operator causes the
object to close that file and/or release that memory (e.g., if the default constructor didn't allocate
a large enough pool of memory or if it opened the wrong file).
Conclusion: All other things being equal, your code will run faster if you use initialization lists
rather than assignment.
Note: There is no performance difference if the type of x_ is some built-in/intrinsic type, such as
int or char* or float. But even in these cases, my personal preference is to set those data members
in the initialization list rather than via assignment for consistency. Another symmetry argument
in favor of using initialization lists even for built-in/intrinsic types: non-static const and nonstatic reference data members can't be assigned a value in the constructor, so for symmetry it
makes sense to initialize everything in the initialization list.
Now for the exceptions. Every rule has exceptions (hmmm; does "every rule has exceptions"
have exceptions? reminds me of Gdel's Incompleteness Theorems), and there are a couple of
exceptions to the "use initialization lists" rule. Bottom line is to use common sense: if it's
cheaper, better, faster, etc. to not use them, then by all means, don't use them. This might happen
when your class has two constructors that need to initialize the this object's data members in
different orders. Or it might happen when two data members are self-referential. Or when a datamember needs a reference to the this object, and you want to avoid a compiler warning about
using the this keyword prior to the { that begins the constructor's body (when your particular
compiler happens to issue that particular warning). Or when you need to do an if/throw test on a
variable (parameter, global, etc.) prior to using that variable to initialize one of your this
members. This list is not exhaustive; please don't write me asking me to add another "Or
when...". The point is simply this: use common sense.
Q: Should you use the this pointer in the constructor?
A: Some people feel you should not use the this pointer in a constructor because the object is not
fully formed yet. However you can use this in the constructor (in the {body} and even in the
initialization list) if you are careful.
Here is something that always works: the {body} of a constructor (or a function called from the
constructor) can reliably access the data members declared in a base class and/or the data
members declared in the constructor's own class. This is because all those data members are
guaranteed to have been fully constructed by the time the constructor's {body} starts executing.
Here is something that never works: the {body} of a constructor (or a function called from the
constructor) cannot get down to a derived class by calling a virtual member function that is
overridden in the derived class. If your goal was to get to the overridden function in the derived
class, you won't get what you want. Note that you won't get to the override in the derived class
independent of how you call the virtual member function: explicitly using the this pointer (e.g.,
this->method()), implicitly using the this pointer (e.g., method()), or even calling some other
function that calls the virtual member function on your this object. The bottom line is this: even
if the caller is constructing an object of a derived class, during the constructor of the base class,
your object is not yet of that derived class. You have been warned.
Here is something that sometimes works: if you pass any of the data members in this object to
another data member's initializer, you must make sure that the other data member has already
been initialized. The good news is that you can determine whether the other data member has (or
has not) been initialized using some straightforward language rules that are independent of the
particular compiler you're using. The bad news it that you have to know those language rules
(e.g., base class sub-objects are initialized first (look up the order if you have multiple and/or
virtual inheritance!), then data members defined in the class are initialized in the order in which
they appear in the class declaration). If you don't know these rules, then don't pass any data
member from the this object (regardless of whether or not you explicitly use the this keyword) to
any other data member's initializer! And if you do know the rules, please be careful.
Q: What is the "Named Constructor Idiom"?
A: A technique that provides more intuitive and/or safer construction operations for users of your
class.
The problem is that constructors always have the same name as the class. Therefore the only way
to differentiate between the various constructors of a class is by the parameter list. But if there
are lots of constructors, the differences between them become somewhat subtle and error prone.
With the Named Constructor Idiom, you declare all the class's constructors in the private or
protected sections, and you provide public static methods that return an object. These static
methods are the so-called "Named Constructors." In general there is one such static method for
each different way to construct an object.
For example, suppose we are building a Point class that represents a position on the X-Y plane.
Turns out there are two common ways to specify a 2-space coordinate: rectangular coordinates
(X+Y), polar coordinates (Radius+Angle). (Don't worry if you can't remember these; the point
isn't the particulars of coordinate systems; the point is that there are several ways to create a
Point object.) Unfortunately the parameters for these two coordinate systems are the same: two
floats. This would create an ambiguity error in the overloaded constructors:
class Point {
public:
Point(float x, float y); // Rectangular coordinates
Point(float r, float a); // Polar coordinates (radius and angle)
// ERROR: Overload is Ambiguous: Point::Point(float,float)
};
int main()
{
Point p = Point(5.7, 1.2); // Ambiguous: Which coordinate system?
...
}
One way to solve this ambiguity is to use the Named Constructor Idiom:
#include // To get sin() and cos()
class Point {
public:
static Point rectangular(float x, float y); // Rectangular coord's
static Point polar(float radius, float angle); // Polar coordinates
// These static methods are the so-called "named constructors"
...
private:
Point(float x, float y); // Rectangular coordinates
float x_, y_;
};
inline Point::Point(float x, float y)
: x_(x), y_(y) { }
inline Point Point::rectangular(float x, float y)
{ return Point(x, y); }
inline Point Point::polar(float radius, float angle)
{ return Point(radius*cos(angle), radius*sin(angle)); }
Now the users of Point have a clear and unambiguous syntax for creating Points in either
coordinate system:
int main()
{
Point p1 = Point::rectangular(5.7, 1.2); // Obviously rectangular
Point p2 = Point::polar(5.7, 1.2); // Obviously polar
...
}
Make sure your constructors are in the protected section if you expect Point to have derived
classes.
The Named Constructor Idiom can also be used to make sure your objects are always created via
new.
Note that the Named Constructor Idiom, at least as implemented above, is just as fast as directly
calling a constructor modern compilers will not make any extra copies of your object.
PREVIOUS NEXT
No comments:
Post a Comment