"michael" <serrano@ozemail.com.au> writes:

|>  > > > It is true only inside constructors *and* destructors. In all
|>  > > > other cases, the overriding method of the object's dynamic
|>  > > > type is called.

|>  > > It is true during construction and destruction.  You can't
|>  > > defeat the behaviour by having the ctor forward to a helper.

|>  > In all cases, the overriding method of the object's dynamic type
|>  > is called.  There are no special rules for constructors or
|>  > destructors.  (Of course, in the constructor or destructor for X,
|>  > the dynamic type of the object is X.)

|>  Yes, a fine unification.

|>  (but there _is_ a special rule:
|>  12.7/3&4 _define_ the dynamic type of the object during
|>  contruction/destruction in this special way.    Without this rule, I
|>  might think the dynamic type was the type used in the new expresion
|>  or declaration of the object.)

I wouldn't call it a "special rule".  Without the rule, we wouldn't know
what the dynamic type was during construction.  A language must define
it.

Java defines it differently.  I've had to track down a couple of
NullPointerException because of it, and add some special code to handle
the case where a function is called on an unconstructed object.
Admittedly, I get a NullPointerException, rather than undefined
behavior, and since Java always 0 initializes an object before calling
constructors, it is possible to test.  But having used both rules, I can
only say that C++ is a lot safer in this regard.  (The safest rule would
probably be that you cannot call a virtual function, period, until the
object is fully constructed.  However, I don't see any way the compiler
could enforce this, and the C++ rule is definitly preferrable to yet
another case of undefined behavior.)

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"michael" <serrano@ozemail.com.au> writes:

> > It is true only inside constructors *and* destructors. In all other
> >   cases, the overriding method of the object's dynamic type is
> >   called.
>
> It is true during construction and destruction.
> You can't defeat the behaviour by having the ctor forward to a helper.
oops. Of course, thank you.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"michael" <serrano@ozemail.com.au> writes:

|>  > It is true only inside constructors *and* destructors. In all
|>  > other cases, the overriding method of the object's dynamic type is
|>  > called.

|>  It is true during construction and destruction.  You can't defeat
|>  the behaviour by having the ctor forward to a helper.

In all cases, the overriding method of the object's dynamic type is
called.  There are no special rules for constructors or destructors.
(Of course, in the constructor or destructor for X, the dynamic type of
the object is X.)

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> > > It is true only inside constructors *and* destructors. In all
> > > other cases, the overriding method of the object's dynamic type is
> > > called.

> > It is true during construction and destruction.  You can't defeat
> > the behaviour by having the ctor forward to a helper.

> In all cases, the overriding method of the object's dynamic type is
> called.  There are no special rules for constructors or destructors.
> (Of course, in the constructor or destructor for X, the dynamic type of
> the object is X.)

Yes, a fine unification.

(but there _is_ a special rule:
12.7/3&4 _define_ the dynamic type of the object during
contruction/destruction in this special way.    Without this rule, I
might think the dynamic type was the type used in the new expresion
or declaration of the object.)



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Compiler: VisualC++ 5.0

I have a base class that defines a functions as virtual. In the
constructor I call this function and it initializes certain members. Now
I derived another class and there I defined the virtual function as
well,  to override the original one.

Now I call the constructor from the derived class and it in turn calls
the virtual function, but the problem is that the called function is not
the one that overrides it. Instead it calls the function of the base
class.

Maybe I missunderstand something here, but I thought that when I decalre
a function as virtual always the overriding function is called unless I
specify <class>::<function> explicitly.

Is this a missbehaving of the compiler or is this correct?

How can I achive that a overiding function is called? The base class
shouldn't and doesn't know about classes that overrides it but what good
is a virtual function when it doesn't get called?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gerhard W. Gruber" wrote:
>
> Compiler: VisualC++ 5.0
>
> I have a base class that defines a functions as virtual. In the
> constructor I call this function and it initializes certain members. Now
> I derived another class and there I defined the virtual function as
> well,  to override the original one.
>
> Now I call the constructor from the derived class and it in turn calls
> the virtual function, but the problem is that the called function is not
> the one that overrides it. Instead it calls the function of the base
> class.

Which is exactly as it's supposed to be. When you call the base class
constructor, the object starts becoming a base class object, but has not
yet become a derived class object. Virtual function dispatch is based
upon the current actual type of an object.

> Maybe I missunderstand something here, but I thought that when I decalre
> a function as virtual always the overriding function is called unless I
> specify <class>::<function> explicitly.

The overriding function is called whenever used in an object of the
derived type. An object doesn't start to be of the derived type until
after it's finished construction of the base class sub-object.

> Is this a missbehaving of the compiler or is this correct?
>
> How can I achive that a overiding function is called? The base class
> shouldn't and doesn't know about classes that overrides it but what good
> is a virtual function when it doesn't get called?

Wait to call the virtual function until after the object has entered the
derived class's constructor.

Alternative:

class Base:
{
// Other stuff
protected:
 Base(void (*pre_ctor)(Base&b)){
  // other stuff
  pre_ctor(*this);
 }

};

class Derived: public Base
{
private:
 static pre_ctor(Base&b){
  // Can use any member of Base class, but only
  // static members of the Derived class.
 }

public:
 Derived(): Base(pre_ctor) {
  // Other stuff
 }

// Other stuff
};

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gerhard W. Gruber" <sparhawk@gmx.at> writes:

> Compiler: VisualC++ 5.0
>
> I have a base class that defines a functions as virtual. In the
> constructor I call this function and it initializes certain members. Now
> I derived another class and there I defined the virtual function as
> well,  to override the original one.
>
> Now I call the constructor from the derived class and it in turn calls
> the virtual function, but the problem is that the called function is not
> the one that overrides it. Instead it calls the function of the base
> class.
>
> Maybe I missunderstand something here, but I thought that when I decalre
> a function as virtual always the overriding function is called unless I
> specify <class>::<function> explicitly.
>
> Is this a missbehaving of the compiler or is this correct?

Your compiler is correct in this case; if a virtual function is called
  from inside a constructor, the method of that class - *not* the
  overriding method - is called.

>
> How can I achive that a overiding function is called? The base class
> shouldn't and doesn't know about classes that overrides it but what good
> is a virtual function when it doesn't get called?
>

For the full philosophy behind this decision, see D&E 13.2.4 (pg
  282-284)

Prior to the completion of the constructor, an object is
  uninitialized.

Most methods must assume the object has been initialized in order to
  do what they were designed to do. If you could call a typical
  overriding virtual method from a base class constructor, it would
  most likely fail horribly.

If overriding virtual methods could be called from base class
  constructors, all overriding virtual methods would have to be
  written as if the object were unitialized.

C++ chose to make ordinary virtual methods safe to write - at the cost
  of disallowing virtual initialization.

It seems to me that a virtual initialization method such as what you
  want implies a close coupling between the implementation of the base
  class's constructor and the derived class. How could the author of
  the overriding virtual initialization method know what to
  initialize without understanding the implementation of the base
  class's constructor? Such tight coupling is usually poor design, as
  it makes derived classes likely to break when the implementation of
  the base class is changed.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

in article 399A78E4.8345D7B@gmx.at, Gerhard W. Gruber at sparhawk@gmx.at
wrote on 8/16/00 9:03 AM:

> Compiler: VisualC++ 5.0
>
> I have a base class that defines a functions as virtual. In the
> constructor I call this function and it initializes certain members. Now
> I derived another class and there I defined the virtual function as
> well,  to override the original one.
>
> Now I call the constructor from the derived class and it in turn calls
> the virtual function, but the problem is that the called function is not
> the one that overrides it. Instead it calls the function of the base
> class.
>
> Maybe I missunderstand something here, but I thought that when I decalre
> a function as virtual always the overriding function is called unless I
> specify <class>::<function> explicitly.
>
> Is this a missbehaving of the compiler or is this correct?
>
> How can I achive that a overiding function is called? The base class
> shouldn't and doesn't know about classes that overrides it but what good
> is a virtual function when it doesn't get called?

The compiler will not allow you to call a non-static member function of an
object that has not been constructed. Disappointing, isn't it? However,
there are good reasons for this rule.

I've developed two techniques to accomplish what you are trying to do.

The first is to pass a function in a constructor's parameter list. Then the
base class can call a function provided by the derived class. The function
may not be a non-static member of the derived class, but it can be a static
member function that takes a base class reference as a parameter.

My other approach has been to define a "post init" function in a base class
which is called by public constructors of both the base and derived class.
This requires awkward protected constructors in base classes that don't call
the "post init" function and whose only purpose is to initialize the base
sub-object in the derived object's constructor.

You may have a hard time enforcing at compile time that the base class's
public constructor is not called by the derived class's constructor, but you
can place a runtime check to assert the "post init" function is not called
twice.

Good lick!

Anders.


--
Anders Pytte                                   Milkweed Software
PO Box 32                                  voice: (802) 586-2545
Craftsbury, VT 05826                  email: anders@milkweed.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gerhard W. Gruber" <sparhawk@gmx.at> wrote in message
news:399A78E4.8345D7B@gmx.at...
> Compiler: VisualC++ 5.0
>
> I have a base class that defines a functions as virtual. In the
> constructor I call this function and it initializes certain members. Now
> I derived another class and there I defined the virtual function as
> well,  to override the original one.
>
> Now I call the constructor from the derived class and it in turn calls
> the virtual function, but the problem is that the called function is not
> the one that overrides it. Instead it calls the function of the base
> class.

This is correct behaviour. 12.7/3 deals with it explicitly.

> Maybe I missunderstand something here, but I thought that when I decalre
> a function as virtual always the overriding function is called unless I
> specify <class>::<function> explicitly.

This is true, *except* in constructors and destructors.

The rationale is that during the base class constructor, the derived class'
constructor hasn't run yet, so it is not of that type yet.

Java does this differently - it will always call the most derived one
always.

> How can I achive that a overiding function is called? The base class
> shouldn't and doesn't know about classes that overrides it but what good
> is a virtual function when it doesn't get called?

The easy workround is do the initialising that depends on it being a fully
constructed object in a seperate Initialise method, where virtual functions
will call their most derived versions. If you want to ensure that it gets
called, use a factory pattern to create it.

Usually though, the objects can be redesigned to not need this sort of
initialisation.

Ric










---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"llewelly."@@edevnull.dot.com wrote:

> Your compiler is correct in this case; if a virtual function is called
>   from inside a constructor, the method of that class - *not* the
>   overriding method - is called.

Is this only true for the constructor? From your statement it appears
so, but I'm not sure on this.

> It seems to me that a virtual initialization method such as what you
>   want implies a close coupling between the implementation of the base
>   class's constructor and the derived class. How could the author of
>   the overriding virtual initialization method know what to
>   initialize without understanding the implementation of the base
>   class's constructor? Such tight coupling is usually poor design, as
>   it makes derived classes likely to break when the implementation of
>   the base class is changed.

I don't really see why this should be poor design. When I call the base
class constcructor, I can assume that the class is properly initialized
(That's what the constructor is for, isnt't it?). So when the base class
constructor returns I can change part of the initialization in the
derived class that fits the derivation. Isn't that so?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gerhard W. Gruber" wrote:
>
> "llewelly."@@edevnull.dot.com wrote:
>
> > Your compiler is correct in this case; if a virtual function is called
> >   from inside a constructor, the method of that class - *not* the
> >   overriding method - is called.
>
> Is this only true for the constructor? From your statement it appears
> so, but I'm not sure on this.

No - it's also true for the destructor, for parallel reasons.

...
> I don't really see why this should be poor design. When I call the base
> class constcructor, I can assume that the class is properly initialized
> (That's what the constructor is for, isnt't it?). ...

Yes - a class should be properly initialized as soon as it's constructor
has returned. The base class sub-object of a derived object is properly
initialized by the time the body of the derived class constructor starts
executing.

> ... So when the base class
> constructor returns I can change part of the initialization in the
> derived class that fits the derivation. Isn't that so?

Yes. If you wait until it returns, there's no problem. Calls to virtual
functions in the derived class constructor will call the derived class
overrider. The problem only occurs with calls from inside the base class
constructor, which call the base class overrider instead.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gerhard W. Gruber" <sparhawk@gmx.at> writes:

> "llewelly."@@edevnull.dot.com wrote:
>
> > Your compiler is correct in this case; if a virtual function is called
> >   from inside a constructor, the method of that class - *not* the
> >   overriding method - is called.
>
> Is this only true for the constructor? From your statement it appears
> so, but I'm not sure on this.

It is true only inside constructors *and* destructors. In all other
  cases, the overriding method of the object's dynamic type is
  called.

>
> > It seems to me that a virtual initialization method such as what you
> >   want implies a close coupling between the implementation of the base
> >   class's constructor and the derived class. How could the author of
> >   the overriding virtual initialization method know what to
> >   initialize without understanding the implementation of the base
> >   class's constructor? Such tight coupling is usually poor design, as
> >   it makes derived classes likely to break when the implementation of
> >   the base class is changed.
>
> I don't really see why this should be poor design. When I call the base
> class constcructor, I can assume that the class is properly initialized
> (That's what the constructor is for, isnt't it?). So when the base class
> constructor returns I can change part of the initialization in the
> derived class that fits the derivation. Isn't that so?

I think we are talking about two different things. I had the
  impression that the virtual initialization function was to be called
  *before* the base class constructor had returned.

Reconfiguring the base class sub object after it has been correctly
  initialized seems less error prone.

[snip]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gerhard W. Gruber" wrote:
>
> "llewelly."@@edevnull.dot.com wrote:
>
> > Your compiler is correct in this case; if a virtual function is called
> >   from inside a constructor, the method of that class - *not* the
> >   overriding method - is called.
>
> Is this only true for the constructor? From your statement it appears
> so, but I'm not sure on this.

Constructor and destructor. More explanation below.

>
> > It seems to me that a virtual initialization method such as what you
> >   want implies a close coupling between the implementation of the base
> >   class's constructor and the derived class. How could the author of
> >   the overriding virtual initialization method know what to
> >   initialize without understanding the implementation of the base
> >   class's constructor? Such tight coupling is usually poor design, as
> >   it makes derived classes likely to break when the implementation of
> >   the base class is changed.
>
> I don't really see why this should be poor design. When I call the base
> class constcructor, I can assume that the class is properly initialized
> (That's what the constructor is for, isnt't it?). So when the base class
> constructor returns I can change part of the initialization in the
> derived class that fits the derivation. Isn't that so?

Initialization occurs at most once, by definition. You cannot initialize
a base-class member; only a base class constructor can initialize it.
You can assign a new value to a base-class member in a derived-class
constructor, but it will have already been initialized.

Going back to the original question: There are at least two reasonable
models for initialization and destruction of hierarchical objects.

1. The object always has its (most-derived) declared type. Virtual
function calls at all stages of construction or destruction yield
the function associated with the most-derived type. This is the
Java model.

2. The type of an object is the type associated with the constructor
or destructor currently running. Virtual function calls yield the
function associated with the current type.  This is the C++ model.

The C++ model has the advantage of safety. Presumably, you
have overridden a virtual function in a derived class in order to
operate on derived-class data. (That is not necessarily the case,
but it is certainly the most common situation.) If a base-class
constructor by default calls a derived-class function, it will
try to operate on data that has not yet been initialized, and
might not even have memory allocated for it yet.  Similarly,
if a base-class destructor by default calls a derived-class
function, it will try to operate on data that no longer exists.

Example:

class Base {
public:
 Base() { foo(); }
 ~Base() { foo(); }
 virtual void foo(); // does something for class Base
};
class Derived : public Base {
 ofstream& file;
public:
 Derived(const char* n) : file(*new ofstream(n)) { }
 ~Derived() { delete &file; }
 virtual void foo() { file << "running... "; }
};
Derived d; // what happens?

With the C++ model, you can't go wrong by accident. In the example,
the base-class version of foo gets called from the Base constructor,
and it deals with only base-class issues.

With the Java model, you have to be careful about inappropriate
running of derived-class virtual functions in all of your designs.
In the example, constructing a Derived object results in the
Base constructor trying to access a stream that hasn't been
created yet; the destructor tries to access a stream that has
already been destroyed. In both cases, no memory exists for
the "file" member to refer to.

In the (IMHO unusual) case where you truly want to run a derived-
class virtual function from a base-class constructor or destructor,
you have to design around the C++ object model.  But as llewelly
points out, you have also coupled the base and derived classes in
what is probably an undesirable way. You can probably find a better
way to factor the design, and eliminate the coupling.

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Anders Pytte wrote:

> The compiler will not allow you to call a non-static member function of an
> object that has not been constructed. Disappointing, isn't it? However,
> there are good reasons for this rule.
>
> I've developed two techniques to accomplish what you are trying to do.
>
> The first is to pass a function in a constructor's parameter list. Then the
> base class can call a function provided by the derived class. The function
> may not be a non-static member of the derived class, but it can be a static
> member function that takes a base class reference as a parameter.

I already tried this, but this brought me an "internal compiler error
please contact...". :) Also I consider this approach as somewhat ugly.
But it is better than nothing. :)

> My other approach has been to define a "post init" function in a base class
> which is called by public constructors of both the base and derived class.
> This requires awkward protected constructors in base classes that don't call
> the "post init" function and whose only purpose is to initialize the base
> sub-object in the derived object's constructor.

I'm not sure if I understand this right, but I think that I implemented
it that way. This resulted in multiple calls to the init function.
That's not really nice, but I can live with it, if there is no other way
around. Another idea I had was to use to a bit of assembly code to
enforce the initialization, but that's even worse. :)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Yes - a class should be properly initialized as soon as it's constructor
> has returned.

Right.

> The base class sub-object of a derived object is properly
> initialized by the time the body of the derived class constructor starts
> executing.

Actually, the base-class sub-object is properly intialized when its
constructor exits normally.  In particular, it is already fully-
constructed when the derived-class constructor begins initializing
its members, before the body of the constructor is entered.

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <399B8FA6.540D5B7F@gmx.at>,
  "Gerhard W. Gruber" <sparhawk@gmx.at> wrote:
> "llewelly."@@edevnull.dot.com wrote:
>
> > Your compiler is correct in this case; if a virtual function is
> > called
> >   from inside a constructor, the method of that class - *not* the
> >   overriding method - is called.
>
> Is this only true for the constructor? From your statement it appears
> so, but I'm not sure on this.
No, the same holds true for the destructor.

--
Jim
This message was posted using plain text only.  Any hyperlinks you may
see were added other parties without my permission.
I do not endorse any products or services that may be hyperlinked to
this message.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> It is true only inside constructors *and* destructors. In all other
>   cases, the overriding method of the object's dynamic type is
>   called.

It is true during construction and destruction.
You can't defeat the behaviour by having the ctor forward to a helper.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]