Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #13417

Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour.

Show all headers | View raw

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
> On 16/01/2012 18:02, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:tfydnWenHpz4z4nSnZ2dnUVZ8hidnZ2d@giganews.com...
>>> On 16/01/2012 16:14, Paul<pchrist wrote:
>>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>>> news:dZmdnf_yLtEuronSnZ2dnUVZ8nydnZ2d@giganews.com...
>>>>> On 16/01/2012 14:14, Paul<pchrist wrote:
>>>>>> "Leigh Johnston"<leigh@i42.co.uk>    wrote in message
>>>>>> news:KuednRghMrM8gInSnZ2dnUVZ8uadnZ2d@giganews.com...
>>>>>>> On 16/01/2012 12:04, Paul<pchrist wrote:
>>>>>>> [snip]
>>>>>>>> http://www.artima.com/cppsource/nevercall.html
>>>>>>>
>>>>>>> That is just one opinion; another opinion is that calling virtual
>>>>>>> functions from ctors and dtors is OK as long as you are aware that 
>>>>>>> the
>>>>>>> object is an instance of the base type when still in base ctor or
>>>>>>> dtor.
>>>>>>>
>>>>>>
>>>>>> Remember the abstract class cannot exist as an object so there is no
>>>>>> object
>>>>>> on which to invoke a member function. A non-static member function
>>>>>> needs
>>>>>> to
>>>>>> be invoked on an object.
>>>>>
>>>>> Of course there is an object; a partially constructed object to be
>>>>> precise.  When in a base class ctor the object is currently an 
>>>>> instance
>>>>> of
>>>>> the base class type and whether or not the class is abstract has no
>>>>> bearing on this fact.
>>>>>
>>>> You are viewing the partially constructed object as an instance of the
>>>> abstract base object.
>>>
>>> That is what the effective type of the partially constructed object is
>>> whilst it is in the base class ctor; a class invariant can be said to
>>> start in the body of a ctor and this is true for base classes as well as
>>> derived classes irrespective of the presence of virtual functions (pure 
>>> or
>>> not).
>>>
>>>> But this goes against the concept of not being able to instanciate an
>>>> abstract class type.
>>>
>>> No it doesn't.
>>>
>> A pure virtual function is intended as an interface that will (must) be
>> implemented in a non abstract derived class.
>> If you want to call Base::foo during construction you could do the
>> following:
>>
>> <code ref="how it is">
>> class Base{
>> public:
>>   Base(){std::cout<<"Base constructor...\n"; }
>>   virtual void foo()=0;
>> };
>> void Base::foo(){std::cout<<"Base foo...\n";}
>>
>> class Derived : public Base{
>> public:
>>   Derived(){ std::cout<<"Derived constructor...\n"; Base::foo(); }
>>   void foo(){std::cout<<"Derived foo...\n";}
>> };
>>
>> int main(){
>>   Derived d;
>>   Base* bp =&d;
>>   bp->foo();
>> }
>> </code>
>
> You can also make a non-virtual call of Base::foo() from Base::Base() 
> according to the standard.
>
>>
>> The PVF must be implemented by the derived class and not by the base 
>> class.
>
> Wrong.  Pure virtual functions can have definitions.

I didn't say they cannot have a defintion . What I said is that they must be 
implemented in the non-abstract derived class.
In the case where a default definiton is given in an abstract class, that 
definition must be invoked by an implementation in the non-abstract derived 
class.

>
>> If para 6 of 10.4 did not exist this would not be the case. This case you
>> propose is:
>>
>> <code ref="how you think it should be">
>> class Base{
>> public:
>>   Base(){std::cout<<"Base constructor...\n"; foo();}/*UB*/
>>   virtual void foo()=0;
>> };
>> void Base::foo(){std::cout<<"Base foo...\n";}
>>
>> class Derived : public Base{
>> public:
>>   Derived(){ std::cout<<"Derived constructor...\n";}
>>   void foo(){std::cout<<"Derived foo...\n";}
>> };
>>
>> int main(){
>>   Derived d;
>>   Base* bp =&d;
>>   bp->foo();
>> }
>> </code>
>>
>>
>> If this were allowed then we no longer have a situation where the derived
>> class has full control over the implementation of the PVF. Here we have 
>> one
>> version of foo invoked during object construction of which the derived 
>> class
>> has no control over its implementation.
>> Basically the PVF is no longer just an Interface if you allow this
>> behaviour.
>
> A pure virtual function with a definition is not "just an Interface"; a 
> pure virtual function with a definition is simply a virtual function that 
> must be overridden.

It's still a pure virtual function, but it provides a default definition. 
However that default definition must be invoked from a non abstract derived 
class thus preserving the interface concept of PVF's.

>  Just because a virtual function must be overridden does not mean that it 
> makes no sense for its own implementation to be called within the context 
> of the class's ctor or dtor; what makes sense depends on the overall 
> object oriented design of the system of which the virtual function plays a 
> part.
>
Now wait,  you have evolved to suggest that the PVF is now simply a normal 
virtual function that must be overridden but this is not the case.

A normal virtual function is inherited and thus can be overridden. With a 
PVF there is no inheritence so it cannot be overridden, i.e:

class Base{
public:
 virtual void foo();
};
void Base::foo(){std::cout<<"Base foo...\n";}

class Derived : public Base{
public:
 //virtual void foo(){std::cout<<"Derived foo..\n";}
};

int main(){
 Derived d;
 Base* bp = &d;
 bp->foo();
}

The above shows how the normal virtual function is inherited and if 
Derived::foo is uncommented it would override the Base::foo. But if you make 
Base:foo pure virtual, Derived won't inherit Base::foo at all. If Base::foo 
is pure virtual it must be *implemented*, not overridden, in Derived:

class Base{
public:
 virtual void foo()=0;
};
void Base::foo(){std::cout<<"Base foo...\n";}

class Derived : public Base{
public:
 //virtual void foo(){std::cout<<"Derived foo..\n";}
};

int main(){
 Derived d;
 Base* bp = &d;
 bp->foo();
}

The above shows that a pure virtual function cannot be inherited , therefore 
it cannot be overridden. If you uncomment Derived::foo you are not 
overridding Base::foo, you are implementing it.

Without para6 the concept of this interfase-like behaviour is gone. 



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-14 23:06 +0000
  Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Goran <goran.pusic@gmail.com> - 2012-01-14 22:21 -0800
  Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-15 02:25 -0600
    Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-15 14:07 +0000
      Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-15 13:13 -0600
  Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-15 09:29 +0100
    Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-15 14:16 +0000
      Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-15 15:25 +0100
        Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-15 14:30 +0000
  Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. gwowen <gwowen@gmail.com> - 2012-01-16 01:57 -0800
    Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-16 11:28 +0100
      Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 11:29 +0000
      Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. gwowen <gwowen@gmail.com> - 2012-01-16 03:21 -0800
  Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-16 12:04 +0000
    Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 12:52 +0000
      Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-16 14:14 +0000
        Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 14:26 +0000
          Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-16 16:14 +0000
            Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 16:37 +0000
              Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-16 18:02 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 18:22 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-16 19:15 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 20:34 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 20:41 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-16 20:49 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 21:08 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 21:11 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-16 23:18 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 23:39 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-16 23:48 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-16 23:57 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-17 12:24 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-17 14:11 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. gwowen <gwowen@gmail.com> - 2012-01-17 06:43 -0800
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-17 14:52 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. gwowen <gwowen@gmail.com> - 2012-01-17 07:22 -0800
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-17 16:35 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-17 16:40 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-17 17:30 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-18 10:38 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-18 11:57 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-18 12:49 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. gwowen <gwowen@gmail.com> - 2012-01-17 08:59 -0800
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-17 17:03 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-17 11:34 -0600
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-17 12:14 -0600
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Gareth Owen <gwowen@gmail.com> - 2012-01-18 06:37 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-18 13:08 -0600
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-18 13:14 -0600
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-17 15:50 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-17 15:59 +0000
                Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-17 16:09 +0000
          Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. jgk@panix.com (Joe keane) - 2012-01-17 16:13 +0000
            Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. scott@slp53.sl.home (Scott Lurndal) - 2012-01-18 18:11 +0000
        Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. gwowen <gwowen@gmail.com> - 2012-01-16 06:34 -0800
  Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Gil <vnicula@gmail.com> - 2012-01-16 20:55 -0800
  Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-17 17:58 +0000
    Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. scott@slp53.sl.home (Scott Lurndal) - 2012-01-18 18:12 +0000
      Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Leigh Johnston <leigh@i42.co.uk> - 2012-01-18 19:00 +0000
        Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-18 22:00 +0000
      Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour. Gareth Owen <gwowen@gmail.com> - 2012-01-19 06:22 +0000

csiph-web