🚀 go-pugleaf

In article <470gvp$i3h@engnews1.eng.sun.com> clamage@Eng.Sun.COM (Steve Clamage) writes:

> [discussion about calling virtual function in derived classes from base class
> constructor deleted]
>
> >fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
> >[...]
> >Yes.  In fact I think that would *often* be the effect you want.
>
> I disagree, and it would be a dangerous language rule, as I argue below.

There is a common pattern in which a base class implements an algorithm but
leaves some of the steps unspecified (in C++ typically as pure virtual
functions). These steps are later defined in subclasses. The current 
standard draft prevents this pattern to be used in constructors, which I
think is unfortunate.

The main problem with calling virtual functions in constructors is that the
complete object hasn't been fully initialized at the point of the call. 
However, isn't that a logical problem only if you really have access to 
the (sub-)object in that function? What if there was a type of member 
function with access only to static members and no implicit object pointer 
(just like an ordinary static member function), but which could be called 
through the virtual function table? Something like:

class B {
	int i;
public:
	static virtual int init() { return 1; } // not C++, but what if?
	B() : i(init()) {}
};

class D : public B {
public:
	static virtual int init() { return 2; }
};

B b; // B::B calls B::init which sets b.i to 1
D d; // B::B calls D::init which sets d.i to 2

Of course, the algorithms "return 1" and "return 2" here are so simple that 
you would write them directly in the colon list of B::B and D::D, but 
for more complicated code this would be convenient.

---
Harald Winroth
Computational Vision and Active Perception Laboratory,
Royal Institute of Technology, Stockholm.


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]