Some C++ Questions Part 2

What is the order of destruction of local objects and how objects in a array gets destructed

Local objects are destructed   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;
...
}

if we have a array of objects,  destruction occurs in reverse order of construction: 

In the following example, the order for destructors will be a[9], a[8], ..., a[1], a[0]:

void userCode()
{
Fred a[10];
...
}

Can we overload the destructor

No.
We can have only one destructor for a class. It's always called Classname ::~Classname().

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.

Can one constructor of a class call another constructor of the same class to initialize the this
object?

No.
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

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!!
...
}
We can do this rather : 


class Foo {
public:
Foo(char x, int y=0); // this line does our work
...
};

Some C++ Questions Part 1

Is it possible to have Virtual Constructor? 

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.

Can we have Virtual Destructor?

Yes there is a Virtual Destructor. A destructor can be virtual as it is possible, at runtime depending on the type of object caller is calling to, proper destructor shall be called.
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.
Parent p = new Derived();
This is used in situations like: Say, If someone derives from "Parent" class, and will say : "new Derived" 
where "Derived" is derived from "Parent" class, and will  delete "p" object , where the actual object's type is "Derived" but the pointer is of "Parent" type.

Difference between a copy constructor and an overloaded assignment operator?

A copy constructor initializes 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:

 Foo Obj1(10);

 Foo Obj2(Obj1); // calling foo copy constructor

 Foo Obj2 = Obj1;// calling foo copy constructor

A copy constructor constructs a new object by using the content of the argument object. 

Copy constructors are called in following cases:

(a) when a function returns an object of the 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.

An overloaded assignment operator assigns the contents of an existing object to another existing object of the same class.

How to handle constructor and destructor that fails

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. 

With destructors, we can write a message to a log file. But should 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, consider "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, 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.