By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,420 Members | 1,130 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,420 IT Pros & Developers. It's quick & easy.

Pure virtual methods, constructors and destructors

P: n/a
I've recently noticed that it's not allowed to call a pure (non-implemented)
virtual method inside a constructor or a destructor, doesn't matter if this
method is declared in the considered class itself or in one of its base
classes. Such an attempt results in a linker undefined symbol error. Why? Is
it right, or is it a bad issue of my compiler/linker (I'm working with
Microsoft Visual C++ 7.1.3088)? Thank you in advance for your help.
Jul 23 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Ruben Campos wrote:
I've recently noticed that it's not allowed to call a pure (non-implemented)
virtual method inside a constructor or a destructor, doesn't matter if this
method is declared in the considered class itself or in one of its base
classes. Such an attempt results in a linker undefined symbol error. Why? Is
it right, or is it a bad issue of my compiler/linker (I'm working with
Microsoft Visual C++ 7.1.3088)? Thank you in advance for your help.


Calling a virtual function in a c-tor or d-tor results in static linking
to that class' member (or the base if this doesn't have it), and not in
a polymorphic call. That's why calling a pure virtual function from the
c-tor or d-tor causes undefined behaviour.

You can provide a definition of the pure virtual function just for that
purpose:

struct ABC {
virtual ~ABC() = 0; // makes this class abstract
};

ABC::~ABC() {} // do nothing, but at least it is defined

struct D : ABC { }; // no problem destroying it -- the ABC's dtor is
// defined, although it is pure

V
Jul 23 '05 #2

P: n/a


Ruben Campos wrote:
I've recently noticed that it's not allowed to call a pure (non-implemented)
virtual method inside a constructor or a destructor, doesn't matter if this
method is declared in the considered class itself or in one of its base
classes. Such an attempt results in a linker undefined symbol error. Why? Is
it right, or is it a bad issue of my compiler/linker (I'm working with
Microsoft Visual C++ 7.1.3088)? Thank you in advance for your help.


What do you expect the complier to call instead of the non-implemented
function?

BTW a pure virtual function just says that derived classes have to
define the method. It doesn't mean that the pure virtual can't also be
defined, and in may cases they are.

class A {
public:
virtual ~A() {};
};
Jul 23 '05 #3

P: n/a
Hang Dog wrote:
[...]
BTW a pure virtual function just says that derived classes have to
define the method. It doesn't mean that the pure virtual can't also be
defined, and in may cases they are.

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


There are two things wrong about this example. First, the topic is *pure*
virtual functions, and there are none in that example. Second, it has
a superfluous semicolon after the body of the d-tor. Yes, I do consider
it wrong although it's allowed by the syntax. It's a bad habit and
reduces readability.

Also, even if you did declare ~A() pure, you can't define it in the class:

class A {
public:
virtual ~A() = 0 {} // wrong as well
};

It would be a syntax error. The definition has to be put at the namespace
level.

V
Jul 23 '05 #4

P: n/a
Ruben Campos wrote:
I've recently noticed that it's not allowed to call a pure (non-implemented)
virtual method inside a constructor or a destructor,


Doesn't matter if it's implemented or not either. Making a virtual call
to a pure virtual fucntion during construction/destruction is undefined
behavior. That's the way the standard reads....it's not required to
catch it.
Jul 23 '05 #5

P: n/a
Victor Bazarov wrote:
Calling a virtual function in a c-tor or d-tor results in static linking
to that class' member (or the base if this doesn't have it), and not in
a polymorphic call


Incorrect. The call may still be polymorphic, but the type of the object
is that of the constructor that is currently running.

Consider the following:

class Base {
public:
virtual void vfunc();
void nvfunc() {
vfunc();
};
};

class Derived : public Base {
public:
void vfunc();
Derived() {
nvfunc();
}
};

class MoreDerived : public Derived {
void vfunc();
};

MoreDerived foo;

While the object is being created and the Derived function is being
invoked, the dynmaic type is set to Derived. Derived's constructor
calls Based::nvfunc which calls Derived::vfunc (not base::vfunc
or MoreDerived::vfunc).

If Base::vfunc was declared pure virtual, the behavior here is undefined.
Jul 23 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.