In article <1995Apr6.163134.8900@rcmcon.com> rmartin@rcmcon.com
(Robert Martin) writes:

|> There is a rule in C++.  A member function of a class will not be
|> called if the corresponding object is not in a constructed state.

Except from the constructor itself (either directly or indirectly).

|> This is a powerful guarantee.  It means that all variables in your
|> class will be in a "known state" whenever any member function is
|> called.

>>>>> On 11 Apr 1995 14:44:39 GMT, akv@srl03.cacs.usl.edu (Anil Vijendran) said:

loic>   I can't understand that. Why can't the MVT be initialised BEFORE the call to a
loic> constructor ??

Anil> That's not possible because the base class sub object has to be
Anil> constructed before the derived class part is and only when the derived
Anil> class part is constructed does it make sense calling a virtual
Anil> function that has been overridden in the derived class.

So that's the explanation? Sounds good to me...

Anil> My *guess* is the compiler would initialize the object's vptr with the base
Anil> class' vtable address when the base class constructor is executing and
Anil> the vptr would be reassigned the vtable address of the derived class
Anil> when control enters the body of the derived class constructor.

It seems that (at least) the bcc-3.1 did this (I had some classes
which worked OK), but gcc-2.6.3 doesn't initialize any table, so a
call to a virtual function in the constructor fails miserably...

Thank you for the explanation of this strange behaviour... :)




 Anil> --
 Anil> Anil

 Anil> ___________________________________________________________________________
 Anil> Anil K Vijendran                    USL Box 43007, Lafayette, LA 70504-3007
 Anil> akv@cacs.usl.edu                                         (318) 232-5502 [H]
--

                      -- Jens --
         http://wowbagger.pc-labor.uni-bremen.de/jens.html

>>>>> On 4 Apr 1995 11:45:45 GMT, tregan_l@xenon.epita.fr (loic
tregan) said:

    loic>   I can't understand that. Why can't the MVT be initialised BEFORE the call to a
    loic> constructor ??

That's not possible because the base class sub object has to be
constructed before the derived class part is and only when the derived
class part is constructed does it make sense calling a virtual
function that has been overridden in the derived class.

My *guess* is the compiler would initialize the object's vptr with the base
class' vtable address when the base class constructor is executing and
the vptr would be reassigned the vtable address of the derived class
when control enters the body of the derived class constructor.

Please correct me if I'm wrong.





--
Anil

___________________________________________________________________________
Anil K Vijendran                    USL Box 43007, Lafayette, LA 70504-3007
akv@cacs.usl.edu                                         (318) 232-5502 [H]

In article <D6rGHI.2zE@actrix.gen.nz>,
Reynaldo Crisostomo <reycri@atlantis.actrix.gen.nz> wrote:
>
>A few months ago somebody posted a proposal for a special member function
>for "post-constructor" processing. This special member function would be
>called implicitly - immediately after the chain of constructor calls to
>form the object. Here, virtual functions would truly be virtual because
>the full object has already been created.
>
>Does anybody know what happened to that proposal? Was it proposed
>formally? I think this is useful and I currently have a need for it in
>the class library I am working on.

 There are plenty of "useful" things we could have and
some have to be left out. In this case, there is a saving of
an explicit call. More generally, you might want to
schedule calls before, after or in the middle of the body
of the constructor -- and the most general solution to that
is to require you to write code .. which is the solution we
already have.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <1995Apr6.163134.8900@rcmcon.com>,
Robert Martin <rmartin@rcmcon.com> wrote:
> tregan_l@xenon.epita.fr (loic tregan) writes:
>
> >  I can't understand that. Why can't the MVT be initialised BEFORE the call to a
> >constructor ??
>
> >   Wouldn't it be really useful ? Even if you don't think so, why is there a
> >particular case in the use of virtual functions ?
>
> >  in Delphi ( new Borland's OOLanguage ), it works well, and I work well with
> >that !
>
> First of all, virtual function calls ARE allowed in constructor and
> destructor implementations.  However, the deployment of the virtual
> function will not go below the class currently being constructed or
> destructed.
>
> There is a rule in C++.  A member function of a class will not be
> called if the corresponding object is not in a constructed state.
> This is a powerful guarantee.  It means that all variables in your
> class will be in a "known state" whenever any member function is
> called.
>
> This rule would be violated if virtual functions could be deployed
> lower than the current constructor or destructor.
>
> --
> Robert Martin       | Design Consulting   | Training courses offered:
> Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
> 2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
> Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

A few months ago somebody posted a proposal for a special member function
for "post-constructor" processing. This special member function would be
called implicitly - immediately after the chain of constructor calls to
form the object. Here, virtual functions would truly be virtual because
the full object has already been created.

Does anybody know what happened to that proposal? Was it proposed
formally? I think this is useful and I currently have a need for it in
the class library I am working on.

Rey Crisostomo
Wellington, New Zealand
"There is no substitute for intelligence, experience and good taste
in programming."  --Bjarne Stroustrup.

In article <3lrbh9$anb@boson.epita.fr>, tregan_l@xenon.epita.fr (loic tregan) writes:
|>   I can't understand that. Why can't the MVT be initialised BEFORE the call to a
|> constructor ??

Sure it *could* be but it'd be tricky.  Hmm, I'm a class ctor, I "know" to fill-in my VFT this way and then run some user code from the {}.  Now, am I a "standalone" object of this type, or am I a subpart of some other type derived from me?  Well, if I'm a subpart then something in the subpart's ctor may have initialized part of the VFT with some overloaded members.  Well, heck, lets just make it the responsibility of the "most derived" class to fill in the whole VFT.  After all, the compiler can see the w
hole derivation path and determine this.  OK, that means we need two entry points for a base class ctor, one for derived-part ctor, another "full" one that fills in the VFT for standalone objects.

|>    Wouldn't it be really useful ? Even if you don't think so, why is there a
|> particular case in the use of virtual functions ?

IMHO this wouldn't be "really useful."  In some cases it may be useful, in others it would be a disaster.  Suppose the base class ctor pushes some method that gets virtually resolved down to a derived class.  However, the derived class's ctor hasn't really run yet (just set up the VFT).  The derived class function expects to be run in a fully constructed derived object and works with some instance data.  Crash and burn time.

If you call virtual functions in a ctor and if the language allowed these to resolve to actual-type methods then it'd place extra restrictions on method overriding.  "Oh, no, you can't override that function, the base class ctor uses it."  Or, "if you override that, it has to be safe and sane even before the derived ctor runs."  Or, "you'd better not push that method in the base ctor, someone may want to override it."

|>   in Delphi ( new Borland's OOLanguage ), it works well, and I work well with
|> that !

Good, use what works for you.  I'm not trying to convert you, just point out why I wouldn't want/use this feechur.

--
Phil Staite
pstaite@vnet.ibm.com

tregan_l@xenon.epita.fr (loic tregan) writes:

>  I can't understand that. Why can't the MVT be initialised BEFORE the call to a
>constructor ??

>   Wouldn't it be really useful ? Even if you don't think so, why is there a
>particular case in the use of virtual functions ?

>  in Delphi ( new Borland's OOLanguage ), it works well, and I work well with
>that !

First of all, virtual function calls ARE allowed in constructor and
destructor implementations.  However, the deployment of the virtual
function will not go below the class currently being constructed or
destructed.

There is a rule in C++.  A member function of a class will not be
called if the corresponding object is not in a constructed state.
This is a powerful guarantee.  It means that all variables in your
class will be in a "known state" whenever any member function is
called.

This rule would be violated if virtual functions could be deployed
lower than the current constructor or destructor.









--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

  I can't understand that. Why can't the MVT be initialised BEFORE the call to a
constructor ??

   Wouldn't it be really useful ? Even if you don't think so, why is there a
particular case in the use of virtual functions ?

  in Delphi ( new Borland's OOLanguage ), it works well, and I work well with
that !



--
Loic.Tregan@epita.fr thanks you to read him.
                ( yes, he told mee that the other day )
warnings : no C, no C++, no 386, no UNIX, no DOS, no Delphi, no Paradox
PLEASE   : send me your answer by mail ( no time to read newsgroups !)