clamage@Eng.Sun.COM (Steve Clamage) writes:

>vandevod@cs.rpi.edu (David Vandevoorde) writes:
>>
>>SC> I think you would have to add this feature, or else disallow
>>SC> virtual calls from constructors and destructors.
>>
>>Right now, I think it makes sense disallowing them.
>
>The problem is actually a little more subtle. You also have to disallow
>passing the value of "this" out of a constructor or destructor, or
>make the results of doing so undefined. A constructor (destructor) for T
>might call an ordinary global function which takes a pointer to T and
>calls a virtual function.

Even disallowing passing the value of `this' out of a ctor or dtor
would not be sufficient, because a ctor or dtor might call an ordinary
global function which gets a pointer which happens to be the same as
`this' by using the address of a global or static variable:

 struct Foo {
  Foo();
  virtual void virtual_func();
 }

 Foo x;

 void bar() {
  x.virtual_func();
 }

 Foo::Foo() {
  bar();
 }

On the other hand, disallowing passing the value of `this' out of
a ctor or dtor is not necessary either - you could simply say that
any direct *or indirect* call to a virtual function from within
a ctor or dtor gives undefined behaviour.  Mind you, I don't
think this would make things easier for programmers, and I wouldn't
advocate it.

--
Fergus Henderson              WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au               PGP: finger fjh@128.250.37.3

---
[ 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. ]

In article <472ujv$ns0@engnews1.eng.sun.com> clamage@Eng.Sun.COM (Steve Clamage) writes:

   >Right now, I think it makes sense disallowing them.

   The problem is actually a little more subtle. You also have to disallow
   passing the value of "this" out of a constructor or destructor, or
   make the results of doing so undefined.

... which would invalidate the common idiom:

 class A {
  Destroy();
  Copy(const A&);
 public:
  ~A() { Destroy(); }
  A(const A& a) { Copy(a); }
  operator=(const A& a) { Destroy(); Copy(a); }
 }

... and hence is probably unacceptable.

Greg.
--
Gregory Bond <gnb@bby.com.au> Burdett Buckeridge & Young Ltd Melbourne Australia
``Efforts to maintain the "purity" of a language only succeed in establishing an
  elite class of people who know the shibboleths.  Ordinary folks know better,
  even if they don't know what "shibboleth" means.'' - Larry Wall

[ 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. ]

In article 95Oct29144834@avs.cs.rpi.edu, vandevod@cs.rpi.edu (David Vandevoorde) writes:
>
>What was the argumentation that lead to give defined semantics to
>calls to virtual functions in constructors?

The C++ object model is simple and consistent: When a constructor for
type T is invoked, it creates a T object out of raw storage. It doesn't
matter who invoked it or why. With single inheritance, which was all
that C++ supported when the object model was developed, there is no
reason to disallow calls to virtual functions under this model.

The one problem occurs for virtual base classes under multiple inheritance.
The offsets in the vtables for intermediate base classes are wrong during
construction. If multiple inheritance had been in C++ from the beginning,
I suspect a different object model would have been developed.

>SC> I think you would have to add this feature, or else disallow
>SC> virtual calls from constructors and destructors.
>
>Right now, I think it makes sense disallowing them.

The problem is actually a little more subtle. You also have to disallow
passing the value of "this" out of a constructor or destructor, or
make the results of doing so undefined. A constructor (destructor) for T
might call an ordinary global function which takes a pointer to T and
calls a virtual function.

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




---
[ 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. ]