C++ FAQ Celebrating Twenty-One Years of the C++ FAQ!!!
(Click here for a personal note from Marshall Cline.)
Section 23:
[23.6] Okay, but is there a way to simulate that behavior as if dynamic binding worked on the this object within my base class's constructor?

Yes: the Dynamic Binding During Initialization idiom (AKA Calling Virtuals During Initialization).

To clarify, we're talking about this situation:

class Base {
public:
  Base();
  ...
  virtual void foo(int n) const; // often pure virtual
  virtual double bar() const;    // often pure virtual
  // if you don't want outsiders calling these, make them protected
};

Base::Base()
{
  ... foo(42) ... bar() ...
  // these will not use dynamic binding
  // goal: simulate dynamic binding in those calls
}

class Derived : public Base {
public:
  ...
  virtual void foo(int n) const;
  virtual double bar() const;
};
This FAQ shows some ways to simulate dynamic binding as if the calls made in Base's constructor dynamically bound to the this object's derived class. The ways we'll show have tradeoffs, so choose the one that best fits your needs, or make up another.

The first approach is a two-phase initialization. In Phase I, someone calls the actual constructor; in Phase II, someone calls an "init" method on the object. Dynamic binding on the this object works fine during Phase II, and Phase II is conceptually part of construction, so we simply move some code from the original Base::Base() into Base::init().

class Base {
public:
  void init();  // may or may not be virtual
  ...
  virtual void foo(int n) const; // often pure virtual
  virtual double bar() const;    // often pure virtual
};

void Base::init()
{
  ... foo(42) ... bar() ...
  // most of this is copied from the original Base::Base()
}

class Derived : public Base {
public:
  ...
  virtual void foo(int n) const;
  virtual double bar() const;
};
The only remaining issues are determining where to call Phase I and where to call Phase II. There are many variations on where these calls can live; we will consider two.

The first variation is simplest initially, though the code that actually wants to create objects requires a tiny bit of programmer self-discipline, which in practice means you're doomed. Seriously, if there are only one or two places that actually create objects of this hierarchy, the programmer self-discipline is quite localized and shouldn't cause problems.

In this variation, the code that is creating the object explicitly executes both phases. When executing Phase I, the code creating the object either knows the object's exact class (e.g., new Derived() or perhaps a local Derived object), or doesn't know the object's exact class (e.g., the virtual constructor idiom or some other factory). The "doesn't know" case is strongly preferred when you want to make it easy to plug-in new derived classes.

Note: Phase I often, but not always, allocates the object from the heap. When it does, you should store the pointer in some sort of managed pointer, such as a std::auto_ptr, a reference counted pointer, or some other object whose destructor deletes the allocation. This is the best way to prevent memory leaks when Phase II might throw exceptions. The following example assumes Phase I allocates the object from the heap.

#include <memory>

void joe_user()
{
  std::auto_ptr<Base> p(/*...somehow create a Derived object via new...*/);
  p->init();
  ...
}
The second variation is to combine the first two lines of the joe_user function into some create function. That's almost always the right thing to do when there are lots of joe_user-like functions. For example, if you're using some kind of factory, such as a registry and the virtual constructor idiom, you could move those two lines into a static method called Base::create():
#include <memory>

class Base {
public:
  ...
  typedef std::auto_ptr<Base> Ptr;  // typedefs simplify the code
  static Ptr create();
  ...
};

Base::Ptr Base::create()
{
  Ptr p(/*...use a factory to create a Derived object via new...*/);
  p->init();
  return p;
}
This simplifies all the joe_user-like functions (a little), but more importantly, it reduces the chance that any of them will create a Derived object without also calling init() on it.
void joe_user()
{
  Base::Ptr p = Base::create();
  ...
}
If you're sufficiently clever and motivated, you can even eliminate the chance that someone could create a Derived object without also calling init() on it. An important step in achieving that goal is to make Derived's constructors, including its copy constructor, protected or private..

The next approach does not rely on a two-phase initialization, instead using a second hierarchy whose only job is to house methods foo() and bar(). This approach doesn't always work, and in particular it doesn't work in cases when foo() and bar() need to access the instance data declared in Derived, but it is conceptually quite simple and clean and is commonly used.

Let's call the base class of this second hierarchy Helper, and its derived classes Helper1, Helper2, etc. The first step is to move foo() and bar() into this second hierarchy:

class Helper {
public:
  virtual void foo(int n) const = 0;
  virtual double bar() const = 0;
};

class Helper1 : public Helper {
public:
  virtual void foo(int n) const;
  virtual double bar() const;
};

class Helper2 : public Helper {
public:
  virtual void foo(int n) const;
  virtual double bar() const;
};
Next, remove init() from Base (since we're no longer using the two-phase approach), remove foo() and bar() from Base and Derived (foo() and bar() are now in the Helper hierarchy), and change the signature of Base's constructor so it takes a Helper by reference:
class Base {
public:
  Base(Helper const& h);
  ...   // remove init() since not using two-phase this time
  ...   // remove foo() and bar() since they're in Helper
};

class Derived : public Base {
public:
  ...   // remove foo() and bar() since they're in Helper
};
We then define Base::Base(Helper const&) so it calls h.foo(42) and h.bar() in exactly those places that init() used to call this->foo(42) and this->bar():
Base::Base(Helper const& h)
{
  ... h.foo(42) ... h.bar() ...
  // almost identical to the original Base::Base()
  // but with h. in calls to h.foo() and h.bar()
}
Finally we change Derived's constructor to pass a (perhaps temporary) object of an appropriate Helper derived class to Base's constructor (using the init list syntax). For example, Derived would pass an instance of Helper2 if it happened to contain the behaviors that Derived wanted for methods foo() and bar():
Derived::Derived()
  : Base(Helper2())   // the magic happens here
{
  ...
}
Note that Derived can pass values into the Helper derived class's constructor, but it must not pass any data members that actually live inside the this object. While we're at it, let's explicitly say that Helper::foo() and Helper::bar() must not access data members of the this object, particularly data members declared in Derived. (Think about when those data members are initialized and you'll see why.)

Of course the choice of which Helper derived class could be made out in the joe_user-like function, in which case it would be passed into the Derived ctor and then up to the Base ctor:

Derived::Derived(Helper const& h)
  : Base(h)
{
  ...
}
If the Helper objects don't need to hold any data, that is, if each is merely a collection of its methods, then you can simply pass static member functions instead. This might be simpler since it entirely eliminates the Helper hierarchy.
class Base {
public:
  typedef void (*FooFn)(int);  // typedefs simplify
  typedef double (*BarFn)();   //    the rest of the code
  Base(FooFn foo, BarFn bar);
  ...
};

Base::Base(FooFn foo, BarFn bar)
{
  ... foo(42) ... bar() ...
  // almost identical to the original Base::Base()
  // except calls are made via function pointers.
}
The Derived class is also easy to implement:
class Derived : public Base {
public:
  Derived();
  static void foo(int n); // the static is important!
  static double bar();    // the static is important!
  ...
};

Derived::Derived()
  : Base(foo, bar)  // pass the function-ptrs into Base's ctor
{
  ...
}
As before, the functionality for foo() and/or bar() can be passed in from the joe_user-like functions. In that case, Derived's ctor just accepts them and passes them up into Base's ctor:
Derived::Derived(FooFn foo, BarFn bar)
  : Base(foo, bar)
{
  ...
}
A final approach is to use templates to "pass" the functionality into the derived classes. This is similar to the case where the joe_user-like functions choose the initializer-function or the Helper derived class, but instead of using function pointers or dynamic binding, it wires the code into the classes via templates.