Why virtual constructor does not exist?

They do - for example:

class test_interface
{
    public:
        virtual ~test_interface() {}
};

class A : public test_interface
{
    public:
        virtual ~A() { std::cout << "Running A's destructor..." << std::endl; }
};

class B : public test_interface
{
    public:
        virtual ~B() { std::cout << "Running B's destructor..." << std::endl; }
};

int main()
{
    test_interface *pA = new A;
    test_interface *pB = new B;

    delete pA;  // Virtual call of the destructor A::~A
    delete pB;  // Virtual call of the destructor B::~B
}

If you remove the virtual from the base class destructor's declaration the output will stop (although exactly what happens is undefined, should have pointed that out).

Cheers,

Ash

PS in response to the comment below...

Well as Sauro's pointed out to create an object of a class you really need to know what type the object is going to be before you can create it. However... you don't always need to know the type of the object you're creating. For example you might want to be able to polymorphically copy objects without knowing what concrete type they are, e.g:

void A::cache_companion( companion_interface *ci )
{
    // Want a deep copy of the object pointed to by ci
    // but we don't know its concrete class!
}

So how can you get around that? Well the first thing is you define a polymorphic copy member of the interface:

class companion_interface
{
    public:
        virtual companion_interface *polymorphic_copy() const = 0;
};

You can then implement it:

class implemented_interface : public companion_interface
{
    public:
        virtual implemented_interface *polymorphic_copy() const
        {
            return new implemented_interface( *this );
        }
};

You can then complete the code from earlier:

void A::cache_companion( companion_interface *ci )
{
    cached_interface_ = ci->polymorphic_copy();
}

So C++ does support virtual constructors, just not directly and only in the cases where the type of the object being constructed can be decoupled from the thing doing the construction. This technique works because objects always know their own class even if they can't tell anyone else what it is in a meaningful way.

Assuming we are talking about virtual constructors, here is the explanation from the man himself:

Why don't we have virtual constructors?
[^]:

A virtual call is a mechanism to get work done given partial information. In particular, "virtual" allows us to call a function knowing only an interfaces and not the exact type of the object. To create an object you need complete information. In particular, you need to know the exact type of what you want to create. Consequently, a "call to a constructor" cannot be virtual.

I think you meant "why virtual constructors doesn't exist".
Answer: Because the vtable that helps provide the polymorphism isn't created/accessible till after the constructor is done constructing the object. For the same reason, you must never call virtual functions inside a constructor. Well, you may call but don't expect polymorphism.

The target of virtual methods is to allow polymorphism at runtime.
The trick is that you can use a pointer to a base class to access a derived class: if a method is virtual, then calling the method on an object always invokes the method as implemented by the most heavily derived class. If the method is not virtual, then the implementation corresponding to the compile-time type of the object pointer.

Said that, a virtual constructor simply doesn't have any sense: the constructor is called when you instantiate an object, and obviously you must know and explicitly write which class the object you are instantiating belong.

Get more information of Virtual Constructor at here: http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=184[^]

See What is a virtual constructor[^] from Marshall cline's FAQ site.