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

Groups > comp.lang.c++ > #13376 > unrolled thread

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

Back to article view | Back to comp.lang.c++

Contents

  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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#13416

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.

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

/Leigh

[toc] | [prev] | [next] | [standalone]

#13417

"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 ---

[toc] | [prev] | [next] | [standalone]

#13418

On 16/01/2012 19:15, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
[snip]
>> 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:

What garbage.  My use of the term "overridden" is not incorrect and pure 
virtual functions can be inherited.

 From "C++ In A Nutshell":

"A derived class can override a pure virtual function and provide a body 
for it, override it and declare it pure again, or simply inherit the 
pure function."

/Leigh

[toc] | [prev] | [next] | [standalone]

#13419

On 16/01/2012 20:34, Leigh Johnston wrote:
> On 16/01/2012 19:15, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk> wrote in message
>> news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
> [snip]
>>> 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:
>
> What garbage. My use of the term "overridden" is not incorrect and pure
> virtual functions can be inherited.
>
>  From "C++ In A Nutshell":
>
> "A derived class can override a pure virtual function and provide a body
> for it, override it and declare it pure again, or simply inherit the
> pure function."

And yes overriding and providing a body is another way of saying 
"implementing" but it should be obvious to any decent C++ programmer 
that this is what I was referring to.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13420

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:iZudnd3HOcZeFInSnZ2dnUVZ8sudnZ2d@giganews.com...
> On 16/01/2012 19:15, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
> [snip]
>>> 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:
>
> What garbage.  My use of the term "overridden" is not incorrect and pure 
> virtual functions can be inherited.

You can't inherit the definition, if I am wrong show me some code that does 
this.

>
> From "C++ In A Nutshell":
>
> "A derived class can override a pure virtual function and provide a body 
> for it, override it and declare it pure again, or simply inherit the pure 
> function."
>
This is talking about inheriting the pure virtual function, as a PVF without 
a definition. This is not talking about inheriting and overridding the 
definition of a PVF , which is what you were talking about.



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

[toc] | [prev] | [next] | [standalone]

#13421

On 16/01/2012 20:49, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:iZudnd3HOcZeFInSnZ2dnUVZ8sudnZ2d@giganews.com...
>> On 16/01/2012 19:15, Paul<pchrist wrote:
>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>> news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
>> [snip]
>>>> 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:
>>
>> What garbage.  My use of the term "overridden" is not incorrect and pure
>> virtual functions can be inherited.
>
> You can't inherit the definition, if I am wrong show me some code that does
> this.

Wrong; see below.

>
>>
>>  From "C++ In A Nutshell":
>>
>> "A derived class can override a pure virtual function and provide a body
>> for it, override it and declare it pure again, or simply inherit the pure
>> function."
>>
> This is talking about inheriting the pure virtual function, as a PVF without
> a definition. This is not talking about inheriting and overridding the
> definition of a PVF , which is what you were talking about.

No it isn't; you don't know what you are talking about as usual. 
Whether or not a pure virtual function has a definition has no bearing 
on the fact that it must be implemented in some derived class or on how 
it is inherited.  Some code:

struct foo
{
   virtual void f() = 0;
};

void foo::f() {}

struct bar : foo
{
   // does bar inherit foo::f()?
};

struct baz : bar
{
   virtual void f() { bar::foo(); } // yes, bar does inherit foo::f().
};

/Leigh

[toc] | [prev] | [next] | [standalone]

#13422

On 16/01/2012 21:08, Leigh Johnston wrote:
> On 16/01/2012 20:49, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk> wrote in message
>> news:iZudnd3HOcZeFInSnZ2dnUVZ8sudnZ2d@giganews.com...
>>> On 16/01/2012 19:15, Paul<pchrist wrote:
>>>> "Leigh Johnston"<leigh@i42.co.uk> wrote in message
>>>> news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
>>> [snip]
>>>>> 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:
>>>
>>> What garbage. My use of the term "overridden" is not incorrect and pure
>>> virtual functions can be inherited.
>>
>> You can't inherit the definition, if I am wrong show me some code that
>> does
>> this.
>
> Wrong; see below.
>
>>
>>>
>>> From "C++ In A Nutshell":
>>>
>>> "A derived class can override a pure virtual function and provide a body
>>> for it, override it and declare it pure again, or simply inherit the
>>> pure
>>> function."
>>>
>> This is talking about inheriting the pure virtual function, as a PVF
>> without
>> a definition. This is not talking about inheriting and overridding the
>> definition of a PVF , which is what you were talking about.
>
> No it isn't; you don't know what you are talking about as usual. Whether
> or not a pure virtual function has a definition has no bearing on the
> fact that it must be implemented in some derived class or on how it is
> inherited. Some code:
>
> struct foo
> {
> virtual void f() = 0;
> };
>
> void foo::f() {}
>
> struct bar : foo
> {
> // does bar inherit foo::f()?
> };
>
> struct baz : bar
> {
> virtual void f() { bar::foo(); } // yes, bar does inherit foo::f().
> };

That should be:

struct baz : bar
{
   virtual void f() { bar::f(); } // yes, bar does inherit foo::f().
};

/Leigh

[toc] | [prev] | [next] | [standalone]

#13423

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:8YydncgNDvB9DInSnZ2dnUVZ8oGdnZ2d@giganews.com...
> On 16/01/2012 20:49, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:iZudnd3HOcZeFInSnZ2dnUVZ8sudnZ2d@giganews.com...
>>> On 16/01/2012 19:15, Paul<pchrist wrote:
>>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>>> news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
>>> [snip]
>>>>> 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:
>>>
>>> What garbage.  My use of the term "overridden" is not incorrect and pure
>>> virtual functions can be inherited.
>>
>> You can't inherit the definition, if I am wrong show me some code that 
>> does
>> this.
>
> Wrong; see below.
>
>>
>>>
>>>  From "C++ In A Nutshell":
>>>
>>> "A derived class can override a pure virtual function and provide a body
>>> for it, override it and declare it pure again, or simply inherit the 
>>> pure
>>> function."
>>>
>> This is talking about inheriting the pure virtual function, as a PVF 
>> without
>> a definition. This is not talking about inheriting and overridding the
>> definition of a PVF , which is what you were talking about.
>
> No it isn't; you don't know what you are talking about as usual. Whether 
> or not a pure virtual function has a definition has no bearing on the fact 
> that it must be implemented in some derived class or on how it is 
> inherited.  Some code:
>
> struct foo
> {
>   virtual void f() = 0;
> };
>
> void foo::f() {}
>
> struct bar : foo
> {
>   // does bar inherit foo::f()?
> };
>
> struct baz : bar
> {
>   virtual void f() { bar::foo(); } // yes, bar does inherit foo::f().
> };
>
Ok so you can inherit the definition, but still not in the way I 
represented( inherited to an instantiatable class). Which was a very 
important aspect of what I represented because after all this is the point 
where the PVF must be implemented.

So you are still incorrect to suggest that a PVF is just a virtual function 
that must be overridden, because it is certainly alot different than that.







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

[toc] | [prev] | [next] | [standalone]

#13424

On 16/01/2012 23:18, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:8YydncgNDvB9DInSnZ2dnUVZ8oGdnZ2d@giganews.com...
>> On 16/01/2012 20:49, Paul<pchrist wrote:
>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>> news:iZudnd3HOcZeFInSnZ2dnUVZ8sudnZ2d@giganews.com...
>>>> On 16/01/2012 19:15, Paul<pchrist wrote:
>>>>> "Leigh Johnston"<leigh@i42.co.uk>    wrote in message
>>>>> news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
>>>> [snip]
>>>>>> 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:
>>>>
>>>> What garbage.  My use of the term "overridden" is not incorrect and pure
>>>> virtual functions can be inherited.
>>>
>>> You can't inherit the definition, if I am wrong show me some code that
>>> does
>>> this.
>>
>> Wrong; see below.
>>
>>>
>>>>
>>>>    From "C++ In A Nutshell":
>>>>
>>>> "A derived class can override a pure virtual function and provide a body
>>>> for it, override it and declare it pure again, or simply inherit the
>>>> pure
>>>> function."
>>>>
>>> This is talking about inheriting the pure virtual function, as a PVF
>>> without
>>> a definition. This is not talking about inheriting and overridding the
>>> definition of a PVF , which is what you were talking about.
>>
>> No it isn't; you don't know what you are talking about as usual. Whether
>> or not a pure virtual function has a definition has no bearing on the fact
>> that it must be implemented in some derived class or on how it is
>> inherited.  Some code:
>>
>> struct foo
>> {
>>    virtual void f() = 0;
>> };
>>
>> void foo::f() {}
>>
>> struct bar : foo
>> {
>>    // does bar inherit foo::f()?
>> };
>>
>> struct baz : bar
>> {
>>    virtual void f() { bar::foo(); } // yes, bar does inherit foo::f().
>> };
>>
> Ok so you can inherit the definition, but still not in the way I
> represented( inherited to an instantiatable class). Which was a very
> important aspect of what I represented because after all this is the point
> where the PVF must be implemented.

What is "inherited to an instantiatable class" supposed to mean?  Nobody 
has suggested that an abstract class can be instantiated however a 
partially constructed object of type abstract base class can exist.

>
> So you are still incorrect to suggest that a PVF is just a virtual function
> that must be overridden, because it is certainly alot different than that.

I am not still incorrect.  A pure virtual function is a simply a virtual 
function that must be implemented in a derived class, nothing more and 
the standard should reflect this.  You have yet to answer the original 
question I posed which is to provide a rationale as to why the standard 
makes it UB to make a virtual call to a pure virtual function that has a 
definition.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13425

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:bqGdnd40oMTSKInSnZ2dnUVZ7tKdnZ2d@giganews.com...
> On 16/01/2012 23:18, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:8YydncgNDvB9DInSnZ2dnUVZ8oGdnZ2d@giganews.com...
>>> On 16/01/2012 20:49, Paul<pchrist wrote:
>>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>>> news:iZudnd3HOcZeFInSnZ2dnUVZ8sudnZ2d@giganews.com...
>>>>> On 16/01/2012 19:15, Paul<pchrist wrote:
>>>>>> "Leigh Johnston"<leigh@i42.co.uk>    wrote in message
>>>>>> news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
>>>>> [snip]
>>>>>>> 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:
>>>>>
>>>>> What garbage.  My use of the term "overridden" is not incorrect and 
>>>>> pure
>>>>> virtual functions can be inherited.
>>>>
>>>> You can't inherit the definition, if I am wrong show me some code that
>>>> does
>>>> this.
>>>
>>> Wrong; see below.
>>>
>>>>
>>>>>
>>>>>    From "C++ In A Nutshell":
>>>>>
>>>>> "A derived class can override a pure virtual function and provide a 
>>>>> body
>>>>> for it, override it and declare it pure again, or simply inherit the
>>>>> pure
>>>>> function."
>>>>>
>>>> This is talking about inheriting the pure virtual function, as a PVF
>>>> without
>>>> a definition. This is not talking about inheriting and overridding the
>>>> definition of a PVF , which is what you were talking about.
>>>
>>> No it isn't; you don't know what you are talking about as usual. Whether
>>> or not a pure virtual function has a definition has no bearing on the 
>>> fact
>>> that it must be implemented in some derived class or on how it is
>>> inherited.  Some code:
>>>
>>> struct foo
>>> {
>>>    virtual void f() = 0;
>>> };
>>>
>>> void foo::f() {}
>>>
>>> struct bar : foo
>>> {
>>>    // does bar inherit foo::f()?
>>> };
>>>
>>> struct baz : bar
>>> {
>>>    virtual void f() { bar::foo(); } // yes, bar does inherit foo::f().
>>> };
>>>
>> Ok so you can inherit the definition, but still not in the way I
>> represented( inherited to an instantiatable class). Which was a very
>> important aspect of what I represented because after all this is the 
>> point
>> where the PVF must be implemented.
>
> What is "inherited to an instantiatable class" supposed to mean?  Nobody 
> has suggested that an abstract class can be instantiated however a 
> partially constructed object of type abstract base class can exist.
>
>>
>> So you are still incorrect to suggest that a PVF is just a virtual 
>> function
>> that must be overridden, because it is certainly alot different than 
>> that.
>
> I am not still incorrect.  A pure virtual function is a simply a virtual 
> function that must be implemented in a derived class, nothing more and the 
> standard should reflect this.  You have yet to answer the original 
> question I posed which is to provide a rationale as to why the standard 
> makes it UB to make a virtual call to a pure virtual function that has a 
> definition.
>
I see you have now changed your wording to "must be *implemented* in a 
derived class".
I will take that as a silent admission of your incorrectness.

As for answering your original question , I have answered but you seen to 
fail to understand. I have explained that if it were allowed to invoke PVF 
definitions from a constructor in an abstract class it would give the PFV a 
behaviour that was not pure. In other words the function could invoke 
multiple definitions, or as I said earlier it would no longer represent an 
interfase-like concept.




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

[toc] | [prev] | [next] | [standalone]

#13426

On 16/01/2012 23:48, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:bqGdnd40oMTSKInSnZ2dnUVZ7tKdnZ2d@giganews.com...
>> On 16/01/2012 23:18, Paul<pchrist wrote:
>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>> news:8YydncgNDvB9DInSnZ2dnUVZ8oGdnZ2d@giganews.com...
>>>> On 16/01/2012 20:49, Paul<pchrist wrote:
>>>>> "Leigh Johnston"<leigh@i42.co.uk>    wrote in message
>>>>> news:iZudnd3HOcZeFInSnZ2dnUVZ8sudnZ2d@giganews.com...
>>>>>> On 16/01/2012 19:15, Paul<pchrist wrote:
>>>>>>> "Leigh Johnston"<leigh@i42.co.uk>     wrote in message
>>>>>>> news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
>>>>>> [snip]
>>>>>>>> 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:
>>>>>>
>>>>>> What garbage.  My use of the term "overridden" is not incorrect and
>>>>>> pure
>>>>>> virtual functions can be inherited.
>>>>>
>>>>> You can't inherit the definition, if I am wrong show me some code that
>>>>> does
>>>>> this.
>>>>
>>>> Wrong; see below.
>>>>
>>>>>
>>>>>>
>>>>>>      From "C++ In A Nutshell":
>>>>>>
>>>>>> "A derived class can override a pure virtual function and provide a
>>>>>> body
>>>>>> for it, override it and declare it pure again, or simply inherit the
>>>>>> pure
>>>>>> function."
>>>>>>
>>>>> This is talking about inheriting the pure virtual function, as a PVF
>>>>> without
>>>>> a definition. This is not talking about inheriting and overridding the
>>>>> definition of a PVF , which is what you were talking about.
>>>>
>>>> No it isn't; you don't know what you are talking about as usual. Whether
>>>> or not a pure virtual function has a definition has no bearing on the
>>>> fact
>>>> that it must be implemented in some derived class or on how it is
>>>> inherited.  Some code:
>>>>
>>>> struct foo
>>>> {
>>>>     virtual void f() = 0;
>>>> };
>>>>
>>>> void foo::f() {}
>>>>
>>>> struct bar : foo
>>>> {
>>>>     // does bar inherit foo::f()?
>>>> };
>>>>
>>>> struct baz : bar
>>>> {
>>>>     virtual void f() { bar::foo(); } // yes, bar does inherit foo::f().
>>>> };
>>>>
>>> Ok so you can inherit the definition, but still not in the way I
>>> represented( inherited to an instantiatable class). Which was a very
>>> important aspect of what I represented because after all this is the
>>> point
>>> where the PVF must be implemented.
>>
>> What is "inherited to an instantiatable class" supposed to mean?  Nobody
>> has suggested that an abstract class can be instantiated however a
>> partially constructed object of type abstract base class can exist.
>>
>>>
>>> So you are still incorrect to suggest that a PVF is just a virtual
>>> function
>>> that must be overridden, because it is certainly alot different than
>>> that.
>>
>> I am not still incorrect.  A pure virtual function is a simply a virtual
>> function that must be implemented in a derived class, nothing more and the
>> standard should reflect this.  You have yet to answer the original
>> question I posed which is to provide a rationale as to why the standard
>> makes it UB to make a virtual call to a pure virtual function that has a
>> definition.
>>
> I see you have now changed your wording to "must be *implemented* in a
> derived class".
> I will take that as a silent admission of your incorrectness.

Incorrect about what?  *Your* view as to what well known terms mean? 
*Implementing* a pure virtual function in a derived class is also 
*overriding* a pure virtual function in a derived class; it is obvious 
to anyone with half a brain that that was what I referring to.  You are 
obviously starting to troll now as you are unable to answer my question.

>
> As for answering your original question , I have answered but you seen to
> fail to understand. I have explained that if it were allowed to invoke PVF
> definitions from a constructor in an abstract class it would give the PFV a
> behaviour that was not pure. In other words the function could invoke
> multiple definitions, or as I said earlier it would no longer represent an
> interfase-like concept.

That is not an adequate rationale; C++ is not Java; abstract base 
classes in C++ are not the same as Java interfaces; sub-objects of type 
abstract base class can have state and function implementations.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13437

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:z4OdncoNKKISJInSnZ2dnUVZ8lednZ2d@giganews.com...
> On 16/01/2012 23:48, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:bqGdnd40oMTSKInSnZ2dnUVZ7tKdnZ2d@giganews.com...
>>> On 16/01/2012 23:18, Paul<pchrist wrote:
>>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>>> news:8YydncgNDvB9DInSnZ2dnUVZ8oGdnZ2d@giganews.com...
>>>>> On 16/01/2012 20:49, Paul<pchrist wrote:
>>>>>> "Leigh Johnston"<leigh@i42.co.uk>    wrote in message
>>>>>> news:iZudnd3HOcZeFInSnZ2dnUVZ8sudnZ2d@giganews.com...
>>>>>>> On 16/01/2012 19:15, Paul<pchrist wrote:
>>>>>>>> "Leigh Johnston"<leigh@i42.co.uk>     wrote in message
>>>>>>>> news:Ze6dneM27chs94nSnZ2dnUVZ8sednZ2d@giganews.com...
>>>>>>> [snip]
>>>>>>>>> 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:
>>>>>>>
>>>>>>> What garbage.  My use of the term "overridden" is not incorrect and
>>>>>>> pure
>>>>>>> virtual functions can be inherited.
>>>>>>
>>>>>> You can't inherit the definition, if I am wrong show me some code 
>>>>>> that
>>>>>> does
>>>>>> this.
>>>>>
>>>>> Wrong; see below.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>      From "C++ In A Nutshell":
>>>>>>>
>>>>>>> "A derived class can override a pure virtual function and provide a
>>>>>>> body
>>>>>>> for it, override it and declare it pure again, or simply inherit the
>>>>>>> pure
>>>>>>> function."
>>>>>>>
>>>>>> This is talking about inheriting the pure virtual function, as a PVF
>>>>>> without
>>>>>> a definition. This is not talking about inheriting and overridding 
>>>>>> the
>>>>>> definition of a PVF , which is what you were talking about.
>>>>>
>>>>> No it isn't; you don't know what you are talking about as usual. 
>>>>> Whether
>>>>> or not a pure virtual function has a definition has no bearing on the
>>>>> fact
>>>>> that it must be implemented in some derived class or on how it is
>>>>> inherited.  Some code:
>>>>>
>>>>> struct foo
>>>>> {
>>>>>     virtual void f() = 0;
>>>>> };
>>>>>
>>>>> void foo::f() {}
>>>>>
>>>>> struct bar : foo
>>>>> {
>>>>>     // does bar inherit foo::f()?
>>>>> };
>>>>>
>>>>> struct baz : bar
>>>>> {
>>>>>     virtual void f() { bar::foo(); } // yes, bar does inherit 
>>>>> foo::f().
>>>>> };
>>>>>
>>>> Ok so you can inherit the definition, but still not in the way I
>>>> represented( inherited to an instantiatable class). Which was a very
>>>> important aspect of what I represented because after all this is the
>>>> point
>>>> where the PVF must be implemented.
>>>
>>> What is "inherited to an instantiatable class" supposed to mean?  Nobody
>>> has suggested that an abstract class can be instantiated however a
>>> partially constructed object of type abstract base class can exist.
>>>
>>>>
>>>> So you are still incorrect to suggest that a PVF is just a virtual
>>>> function
>>>> that must be overridden, because it is certainly alot different than
>>>> that.
>>>
>>> I am not still incorrect.  A pure virtual function is a simply a virtual
>>> function that must be implemented in a derived class, nothing more and 
>>> the
>>> standard should reflect this.  You have yet to answer the original
>>> question I posed which is to provide a rationale as to why the standard
>>> makes it UB to make a virtual call to a pure virtual function that has a
>>> definition.
>>>
>> I see you have now changed your wording to "must be *implemented* in a
>> derived class".
>> I will take that as a silent admission of your incorrectness.
>
> Incorrect about what?  *Your* view as to what well known terms mean? 
> *Implementing* a pure virtual function in a derived class is also 
> *overriding* a pure virtual function in a derived class; it is obvious to 
> anyone with half a brain that that was what I referring to.  You are 
> obviously starting to troll now as you are unable to answer my question.
>
Incorrect to say that a PVF is just a normal virtual function that must be 
overridden.

Why do I have to keep repeating this?
 Its obviously the two things are not exactly the same, and if anyone is 
trolling its obviously you.

>>
>> As for answering your original question , I have answered but you seen to
>> fail to understand. I have explained that if it were allowed to invoke 
>> PVF
>> definitions from a constructor in an abstract class it would give the PFV 
>> a
>> behaviour that was not pure. In other words the function could invoke
>> multiple definitions, or as I said earlier it would no longer represent 
>> an
>> interfase-like concept.
>
> That is not an adequate rationale;
Why not?

> C++ is not Java; abstract base classes in C++ are not the same as Java 
> interfaces; sub-objects of type abstract base class can have state and 
> function implementations.
>

Java does not own the term "Interface". 



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

[toc] | [prev] | [next] | [standalone]

#13439

On 17/01/2012 12:24, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:z4OdncoNKKISJInSnZ2dnUVZ8lednZ2d@giganews.com...
>> On 16/01/2012 23:48, Paul<pchrist wrote:
>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>> news:bqGdnd40oMTSKInSnZ2dnUVZ7tKdnZ2d@giganews.com...
>>>> On 16/01/2012 23:18, Paul<pchrist wrote:
[snip]
>>>>> So you are still incorrect to suggest that a PVF is just a virtual
>>>>> function
>>>>> that must be overridden, because it is certainly alot different than
>>>>> that.
>>>>
>>>> I am not still incorrect.  A pure virtual function is a simply a virtual
>>>> function that must be implemented in a derived class, nothing more and
>>>> the
>>>> standard should reflect this.  You have yet to answer the original
>>>> question I posed which is to provide a rationale as to why the standard
>>>> makes it UB to make a virtual call to a pure virtual function that has a
>>>> definition.
>>>>
>>> I see you have now changed your wording to "must be *implemented* in a
>>> derived class".
>>> I will take that as a silent admission of your incorrectness.
>>
>> Incorrect about what?  *Your* view as to what well known terms mean?
>> *Implementing* a pure virtual function in a derived class is also
>> *overriding* a pure virtual function in a derived class; it is obvious to
>> anyone with half a brain that that was what I referring to.  You are
>> obviously starting to troll now as you are unable to answer my question.
>>
> Incorrect to say that a PVF is just a normal virtual function that must be
> overridden.
>
> Why do I have to keep repeating this?
>   Its obviously the two things are not exactly the same, and if anyone is
> trolling its obviously you.

My use of the term "override" is not incorrect just slightly ambiguous 
when not qualified.  When somebody says "you must override that pure 
virtual function" it is obvious what they actually mean and that is also 
what I meant.

Read:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#230

The above is an open issue that agrees with my position on this issue as 
well as being another example of using the term "override" in the same 
way that I am using the term "override", specifically:

"As time passes, a number of classes are derived from B and it is 
noticed that each needs to *override* f, so it is decided to make B::f 
pure to enforce this convention while still leaving the original 
definition of B::f to perform its needed initialization."

/Leigh	

[toc] | [prev] | [next] | [standalone]

#13440

On Jan 17, 2:11 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> Read:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#230
>
> The above is an open issue that agrees with my position on this issue..

True, but given that there have been two ratified versions since that
issue was first noted, it doesn't seem the committee are minded to
amend the issue.

A single motivating use-case where defined behaviour was
(a) useful and
(b) not trivially obtained by other means
would probably have helped.

[toc] | [prev] | [next] | [standalone]

#13441

On 17/01/2012 14:43, gwowen wrote:
> On Jan 17, 2:11 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>> Read:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#230
>>
>> The above is an open issue that agrees with my position on this issue..
>
> True, but given that there have been two ratified versions since that
> issue was first noted, it doesn't seem the committee are minded to
> amend the issue.
>
> A single motivating use-case where defined behaviour was
> (a) useful and
> (b) not trivially obtained by other means
> would probably have helped.

I agree; this is a rather esoteric corner of C++ we are dealing with.  I 
personally have never had the need in my code to call a pure virtual 
function from a ctor but I nevertheless thought it interesting to post 
about it in this forum.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13442

On Jan 17, 2:52 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> I agree; this is a rather esoteric corner of C++ we are dealing with.  I
> personally have never had the need in my code to call a pure virtual
> function from a ctor but I nevertheless thought it interesting to post
> about it in this forum.

Don't get me wrong - I'm not criticising you for doing so. I've
learned that you can define pure virtual functions (although you
probably shouldn't ;) ), so I've gained something from your bringing
it up.

[toc] | [prev] | [next] | [standalone]

#13447

"gwowen" <gwowen@gmail.com> wrote in message 
news:c80e1e14-f27a-4b7a-946f-c91d8ddf6832@e8g2000yqd.googlegroups.com...
On Jan 17, 2:52 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> I agree; this is a rather esoteric corner of C++ we are dealing with. I
> personally have never had the need in my code to call a pure virtual
> function from a ctor but I nevertheless thought it interesting to post
> about it in this forum.

--Don't get me wrong - I'm not criticising you for doing so. I've
--learned that you can define pure virtual functions (although you
--probably shouldn't ;) ), so I've gained something from your bringing
--it up.

I think its a handy feature for supplying some default functionality.
If it were automatic(invoked during construction of abstract class)  then it 
couldn't be overridden in a concrete class and perhaps this is why the 
standard specifiies it as UB. 



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

[toc] | [prev] | [next] | [standalone]

#13448

On 17/01/2012 16:35, Paul <pchrist wrote:
> "gwowen"<gwowen@gmail.com>  wrote in message
> news:c80e1e14-f27a-4b7a-946f-c91d8ddf6832@e8g2000yqd.googlegroups.com...
> On Jan 17, 2:52 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>> I agree; this is a rather esoteric corner of C++ we are dealing with. I
>> personally have never had the need in my code to call a pure virtual
>> function from a ctor but I nevertheless thought it interesting to post
>> about it in this forum.
>
> --Don't get me wrong - I'm not criticising you for doing so. I've
> --learned that you can define pure virtual functions (although you
> --probably shouldn't ;) ), so I've gained something from your bringing
> --it up.
>
> I think its a handy feature for supplying some default functionality.
> If it were automatic(invoked during construction of abstract class)  then it
> couldn't be overridden in a concrete class and perhaps this is why the
> standard specifiies it as UB.

You are wrong.  Why are you wrong?  Because a) you don't know how 
vtables work and b) you don't understand that the dynamic type of an 
object changes as it moves from base class ctor to derived class ctor.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13451

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:I_Cdne08KLk9OYjSnZ2dnUVZ8n6dnZ2d@giganews.com...
> On 17/01/2012 16:35, Paul <pchrist wrote:
>> "gwowen"<gwowen@gmail.com>  wrote in message
>> news:c80e1e14-f27a-4b7a-946f-c91d8ddf6832@e8g2000yqd.googlegroups.com...
>> On Jan 17, 2:52 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>>> I agree; this is a rather esoteric corner of C++ we are dealing with. I
>>> personally have never had the need in my code to call a pure virtual
>>> function from a ctor but I nevertheless thought it interesting to post
>>> about it in this forum.
>>
>> --Don't get me wrong - I'm not criticising you for doing so. I've
>> --learned that you can define pure virtual functions (although you
>> --probably shouldn't ;) ), so I've gained something from your bringing
>> --it up.
>>
>> I think its a handy feature for supplying some default functionality.
>> If it were automatic(invoked during construction of abstract class)  then 
>> it
>> couldn't be overridden in a concrete class and perhaps this is why the
>> standard specifiies it as UB.
>
> You are wrong.  Why are you wrong?  Because a) you don't know how vtables 
> work and b) you don't understand that the dynamic type of an object 
> changes as it moves from base class ctor to derived class ctor.
>
What exactly am I wrong about here? 



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

[toc] | [prev] | [next] | [standalone]

#13467

"Paul or@yahoo.co.uk>" <pchrist<nospam> wrote in message 
news:jf4b7m$28nh$1@adenine.netfront.net...
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message 
> news:I_Cdne08KLk9OYjSnZ2dnUVZ8n6dnZ2d@giganews.com...
>> On 17/01/2012 16:35, Paul <pchrist wrote:
>>> "gwowen"<gwowen@gmail.com>  wrote in message
>>> news:c80e1e14-f27a-4b7a-946f-c91d8ddf6832@e8g2000yqd.googlegroups.com...
>>> On Jan 17, 2:52 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>>>> I agree; this is a rather esoteric corner of C++ we are dealing with. I
>>>> personally have never had the need in my code to call a pure virtual
>>>> function from a ctor but I nevertheless thought it interesting to post
>>>> about it in this forum.
>>>
>>> --Don't get me wrong - I'm not criticising you for doing so. I've
>>> --learned that you can define pure virtual functions (although you
>>> --probably shouldn't ;) ), so I've gained something from your bringing
>>> --it up.
>>>
>>> I think its a handy feature for supplying some default functionality.
>>> If it were automatic(invoked during construction of abstract class) 
>>> then it
>>> couldn't be overridden in a concrete class and perhaps this is why the
>>> standard specifiies it as UB.
>>
>> You are wrong.  Why are you wrong?  Because a) you don't know how vtables 
>> work and b) you don't understand that the dynamic type of an object 
>> changes as it moves from base class ctor to derived class ctor.
>>
> What exactly am I wrong about here?
>
So Im not wrong then and you are actually the one who is wrong, as usual.. 



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

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web