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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#13469

On 18/01/2012 10:38, Paul <pchrist wrote:
> "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..

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]

#13470

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:opqdnTXA5ZgKLovSnZ2dnUVZ8mGdnZ2d@giganews.com...
> On 18/01/2012 10:38, Paul <pchrist wrote:
>> "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..
>
> 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.
>
And you are a faggot

*shrugg*




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

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

#13449

On Jan 17, 4:35 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:

> I think its a handy feature for supplying some default functionality.

But, as far as I can tell, the only benefit over a protected non-
virtual is that you use the same name when calling, so you can write:

class Base
{
  public: virtual void f() = 0;
};
void Base::f()
{
   //whatever
}
class Derived : public Base
{
   public: virtual void f() {
      Base::f();
      // Derived-specific stuff goes here.
   }
}

/// Alternatively, without this language feature
class Base
{
  protected: void f_helper() {
   //whatever
  }
  public: virtual void f() = 0;
};
class Derived : public Base
{
   public: virtual void f() {
      f_helper();
      // Derived-specific stuff goes here.
   }
}

Is it handy? Well arguably, yes, but its not *very* handy, especially
as I can define f_helper() inline, but can't do so for Base::f().

Is there anything else I can do with it?   Well I suppose Base::f()
enables me to do something clever template things with by calling
T::f() in template code.

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

#13450

On 17/01/2012 16:59, gwowen wrote:
> On Jan 17, 4:35 pm, "Paul"<pchrist<nospam>o...@yahoo.co.uk>  wrote:
>
>> I think its a handy feature for supplying some default functionality.
>
> But, as far as I can tell, the only benefit over a protected non-
> virtual is that you use the same name when calling, so you can write:
>
> class Base
> {
>    public: virtual void f() = 0;
> };
> void Base::f()
> {
>     //whatever
> }
> class Derived : public Base
> {
>     public: virtual void f() {
>        Base::f();
>        // Derived-specific stuff goes here.
>     }
> }
>
> /// Alternatively, without this language feature
> class Base
> {
>    protected: void f_helper() {
>     //whatever
>    }
>    public: virtual void f() = 0;
> };
> class Derived : public Base
> {
>     public: virtual void f() {
>        f_helper();
>        // Derived-specific stuff goes here.
>     }
> }
>
> Is it handy? Well arguably, yes, but its not *very* handy, especially
> as I can define f_helper() inline, but can't do so for Base::f().

You can define it inline just define it outside of the class in the 
header file and use the inline keyword.

/Leigh

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

#13452

gwowen wrote:
> On Jan 17, 4:35 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:
> Is [PVF] handy? Well arguably, yes, but ...

The issue isn't that it is or might be useful. It is valid for a class 
method to invoke a virtual function. It is also valid for the ctor to call 
class methods, which might or might not indirectly invoke a virtual method. 
The compiler can't enforce that the ctor cannot indirectly invoke a virtual, 
pure or otherwise.

Arguably, then, the PVF with implementation is not really useful, but simply 
serves as an escape for defining a benign default action during 
construction. The alternative is to always hit the UB behavior on invoking a 
PVF. On both g++ and MSVC, the result is abrupt termination.

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

#13454

MikeWhy wrote:
> gwowen wrote:
>> On Jan 17, 4:35 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:
>> Is [PVF] handy? Well arguably, yes, but ...
>
> The issue isn't that it is or might be useful. It is valid for a class
> method to invoke a virtual function. It is also valid for the ctor to
> call class methods, which might or might not indirectly invoke a
> virtual method. The compiler can't enforce that the ctor cannot
> indirectly invoke a virtual, pure or otherwise.
>
> Arguably, then, the PVF with implementation is not really useful, but
> simply serves as an escape for defining a benign default action during
> construction. The alternative is to always hit the UB behavior on
> invoking a PVF. On both g++ and MSVC, the result is abrupt
> termination.

(FWIW, I think the better action is to fix the object model when you 
encounter a PVF termination, rather than hide it (forever more) behind the a 
default PVF implementation.)

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

#13463

"MikeWhy" <boat042-nospam@yahoo.com> writes:

> Arguably, then, the PVF with implementation is not really useful, but
> simply serves as an escape for defining a benign default action during
> construction. 

With the irony being, as Leigh initially pointed out, this is the one
thing you're not allowed to do...

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

#13484

"Gareth Owen" <gwowen@gmail.com> wrote in message 
news:87fwfdikio.fsf@gmail.com...
> "MikeWhy" <boat042-nospam@yahoo.com> writes:
>
>> Arguably, then, the PVF with implementation is not really useful, but
>> simply serves as an escape for defining a benign default action during
>> construction.
>
> With the irony being, as Leigh initially pointed out, this is the one
> thing you're not allowed to do...

I'm a bit vexed this moment. At one point, some earlier version of the 
following did manage to print "AbstractBase::PureVirtual()." Toggling the 
#if now produces no difference. PVF termination is hit, whether the PVF has 
an implementation or not.


#include <iostream>
//======================================================
//======================================================
class AbstractBase
{
public:
    AbstractBase() { foo(); }
    virtual ~AbstractBase() {}

    void foo() { PureVirtual(); }
private:
    virtual void PureVirtual() = 0;
};
//======================================================
// not so pure
//##########
#if 1
//##########
void AbstractBase::PureVirtual()
{   std::cout << "AbstractBase::PureVirtual().\n";
}
//##########
#endif
//##########
//======================================================
//======================================================
class Derived : public AbstractBase
{
public:
    Derived() { }
private:
    void PureVirtual()
    {   std::cout << "Derived::PureVirtual().\n";
    }
};

//======================================================
//======================================================
//======================================================

int main(int argc, char **argv)
{
    Derived a;
    a.foo();

    std::cout << "Hello, world!" << std::endl;

    return 0;
}

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

#13485

"MikeWhy" <boat042-nospam@yahoo.com> wrote in message 
news:jf75be$8sp$1@dont-email.me...
> "Gareth Owen" <gwowen@gmail.com> wrote in message 
> news:87fwfdikio.fsf@gmail.com...
>> "MikeWhy" <boat042-nospam@yahoo.com> writes:
>>
>>> Arguably, then, the PVF with implementation is not really useful, but
>>> simply serves as an escape for defining a benign default action during
>>> construction.
>>
>> With the irony being, as Leigh initially pointed out, this is the one
>> thing you're not allowed to do...
>
> I'm a bit vexed this moment. At one point, some earlier version of the 
> following did manage to print "AbstractBase::PureVirtual()." Toggling the 
> #if now produces no difference. PVF termination is hit, whether the PVF 
> has an implementation or not.

Hmmm. The earlier version probably called the PVF directly from the ctor, 
rather than indirectly through another method. That would apparently succeed 
with a statically scoped, non-virtual call.

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

#13443

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:S6udnZal0s2qFojSnZ2dnUVZ8uCdnZ2d@giganews.com...
> 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.
>
In this issue the submitter states that:
"The prohibition of virtual calls to pure virtual functions arises from the 
first meaning and unnecessarily penalizes those who only need the second."

re:
  1.. A pure virtual function need not be defined.
  2.. A pure virtual function must be overridden in any concrete derived 
class.

But the second meaning would not be possible if this resolution was allowed.
If you could invoke an function definition, defined in an abstract class, 
from a constructor for example... this function would not be overridden, or 
reimplemented in the concrete class.
So the basic rules of PVFs and abstract classes would go out the window.
You can't say that a function *must* be overridden, yet also allow it not to 
be overridden. :) It's either one or the other. 



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

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

#13444

On 17/01/2012 15:50, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:S6udnZal0s2qFojSnZ2dnUVZ8uCdnZ2d@giganews.com...
>> 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.
>>
> In this issue the submitter states that:
> "The prohibition of virtual calls to pure virtual functions arises from the
> first meaning and unnecessarily penalizes those who only need the second."
>
> re:
>    1.. A pure virtual function need not be defined.
>    2.. A pure virtual function must be overridden in any concrete derived
> class.
>
> But the second meaning would not be possible if this resolution was allowed.
> If you could invoke an function definition, defined in an abstract class,
> from a constructor for example... this function would not be overridden, or
> reimplemented in the concrete class.
> So the basic rules of PVFs and abstract classes would go out the window.
> You can't say that a function *must* be overridden, yet also allow it not to
> be overridden. :) It's either one or the other.

You are being dense.  It must still be overridden and implemented in 
some derived class in order to instantiate the concrete most derived 
class even if the proposal was allowed; the proposal is only concerned 
about what it means to call a pure virtual function with a definition 
from the abstract base class ctor; the abstract base class sub-object is 
still an object.

/Leigh

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

#13445

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:IMOdnRZE2cxrB4jSnZ2dnUVZ8judnZ2d@giganews.com...
> On 17/01/2012 15:50, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:S6udnZal0s2qFojSnZ2dnUVZ8uCdnZ2d@giganews.com...
>>> 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.
>>>
>> In this issue the submitter states that:
>> "The prohibition of virtual calls to pure virtual functions arises from 
>> the
>> first meaning and unnecessarily penalizes those who only need the 
>> second."
>>
>> re:
>>    1.. A pure virtual function need not be defined.
>>    2.. A pure virtual function must be overridden in any concrete derived
>> class.
>>
>> But the second meaning would not be possible if this resolution was 
>> allowed.
>> If you could invoke an function definition, defined in an abstract class,
>> from a constructor for example... this function would not be overridden, 
>> or
>> reimplemented in the concrete class.
>> So the basic rules of PVFs and abstract classes would go out the window.
>> You can't say that a function *must* be overridden, yet also allow it not 
>> to
>> be overridden. :) It's either one or the other.
>
> You are being dense.  It must still be overridden and implemented in some 
> derived class in order to instantiate the concrete most derived class even 
> if the proposal was allowed; the proposal is only concerned about what it 
> means to call a pure virtual function with a definition from the abstract 
> base class ctor; the abstract base class sub-object is still an object.
>

The function is invoked before the concrete class has even been constructed 
so how can it be overridden in the concrete class?
How can you overide a function after it has been invoked? lol thats just 
impossible unless you introduce some kind of time machine.







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

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

#13446

In article <dZmdnf_yLtEuronSnZ2dnUVZ8nydnZ2d@giganews.com>,
Leigh Johnston  <leigh@i42.co.uk> wrote:
>The fundamental issue is what should a base class vtable entry for a 
>pure virtual function contain *if* the pure virtual function has a 
>definition?

so don't do that

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

#13477

jgk@panix.com (Joe keane) writes:
>In article <dZmdnf_yLtEuronSnZ2dnUVZ8nydnZ2d@giganews.com>,
>Leigh Johnston  <leigh@i42.co.uk> wrote:
>>The fundamental issue is what should a base class vtable entry for a 
>>pure virtual function contain *if* the pure virtual function has a 
>>definition?
>
>so don't do that

Finally, some rationality injected into the thread.

scott

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

#13408

On Jan 16, 2:14 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:

> Also..
> During destruction of a class with an abstract base... When the derived
> class has been destroyed and the destructor is invoked on the abstract part,
> where do the vtble pointers point?

In theory, to the Base class definition which, for reasons still
unclear to me, can exist.

> Does the vtble still refer to the member
> function, as defined in the derived class?

No.  The vtable will point to base class's definition. (When it hasn't
been defined, it's inevitably UB).

Actually, that might be the rationale - a micro-optimisation of
construction.  When a derived class is being destroyed, the vtable
presumably has to be repeatedly updated as the destruction procedes
from most-derived to least-derived base classes. For completely-
abstract interface-only base classes (i.e. ones where every virtual
function is pure), this step can be skipped.

That's a possible rationale, albeit a pretty flimsy one.

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

#13430

On Jan 14, 6:06 pm, Leigh Johnston <le...@i42.co.uk> wrote:
>  From n3242, 10.4./6:
> "Member functions can be called from a constructor (or destructor) of an
> abstract class; the effect of making a
> virtual call (10.3) to a pure virtual function directly or indirectly
> for the object being created (or destroyed)
> from such a constructor (or destructor) is undefined."
>
> Does anyone know the rationale for why the above is UB?
>
> For the newbies reading this: it *is* possible in C++ for a pure virtual
> function to have a definition.
>
> I think it might be an omission from the standard: whilst calling a pure
> virtual function *without a* definition is UB I can see no reason why
> calling a pure virtual function *with a* definition from a ctor/dtor
> should be UB.
>
> I do not believe this is an ease-of-implementation issue as VC++ and g++
> allow it no problem (yes I know UB can "silently work"); clang seemingly
> follows the standard to the letter and doesn't.
>
> All pure means is that a virtual function should be overridden in a
> derived class; there should be no difference in dynamic dispatch for
> pure virtual functions and ordinary virtual functions.
>
> Thoughts?
>
> /Leigh

read

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

hth,
gil

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

#13453

On 14/01/2012 23:06, Leigh Johnston wrote:
>  From n3242, 10.4./6:
> "Member functions can be called from a constructor (or destructor) of an
> abstract class; the effect of making a
> virtual call (10.3) to a pure virtual function directly or indirectly
> for the object being created (or destroyed)
> from such a constructor (or destructor) is undefined."
>
> Does anyone know the rationale for why the above is UB?
>
> For the newbies reading this: it *is* possible in C++ for a pure virtual
> function to have a definition.
>
> I think it might be an omission from the standard: whilst calling a pure
> virtual function *without a* definition is UB I can see no reason why
> calling a pure virtual function *with a* definition from a ctor/dtor
> should be UB.
>
> I do not believe this is an ease-of-implementation issue as VC++ and g++
> allow it no problem (yes I know UB can "silently work"); clang seemingly
> follows the standard to the letter and doesn't.

I was in error about VC++ and g++ as they do both terminate on virtual 
call to pure virtual from ctor like clang however unlike clang they do 
allow an *unqualified* call to the pure virtual from the ctor (clang 
doesn't); clang perhaps doesn't use the "don't use dynamic dispatch if 
we know the type" optimization.

I still assert that defined behaviour is better than undefined behaviour. :)

/Leigh

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

#13478

Leigh Johnston <leigh@i42.co.uk> writes:
>On 14/01/2012 23:06, Leigh Johnston wrote:
>>  From n3242, 10.4./6:
>> "Member functions can be called from a constructor (or destructor) of an
>> abstract class; the effect of making a
>> virtual call (10.3) to a pure virtual function directly or indirectly
>> for the object being created (or destroyed)
>> from such a constructor (or destructor) is undefined."
>>
>> Does anyone know the rationale for why the above is UB?
>>
>> For the newbies reading this: it *is* possible in C++ for a pure virtual
>> function to have a definition.
>>
>> I think it might be an omission from the standard: whilst calling a pure
>> virtual function *without a* definition is UB I can see no reason why
>> calling a pure virtual function *with a* definition from a ctor/dtor
>> should be UB.
>>
>> I do not believe this is an ease-of-implementation issue as VC++ and g++
>> allow it no problem (yes I know UB can "silently work"); clang seemingly
>> follows the standard to the letter and doesn't.
>
>I was in error about VC++ and g++ as they do both terminate on virtual 
>call to pure virtual from ctor like clang however unlike clang they do 
>allow an *unqualified* call to the pure virtual from the ctor (clang 
>doesn't); clang perhaps doesn't use the "don't use dynamic dispatch if 
>we know the type" optimization.
>
>I still assert that defined behaviour is better than undefined behaviour. :)

So make it illegal to associate a definition with a PVF.   Problem solved.

scott

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

#13483

On 18/01/2012 18:12, Scott Lurndal wrote:
> Leigh Johnston<leigh@i42.co.uk>  writes:
>> On 14/01/2012 23:06, Leigh Johnston wrote:
>>>    From n3242, 10.4./6:
>>> "Member functions can be called from a constructor (or destructor) of an
>>> abstract class; the effect of making a
>>> virtual call (10.3) to a pure virtual function directly or indirectly
>>> for the object being created (or destroyed)
>>> from such a constructor (or destructor) is undefined."
>>>
>>> Does anyone know the rationale for why the above is UB?
>>>
>>> For the newbies reading this: it *is* possible in C++ for a pure virtual
>>> function to have a definition.
>>>
>>> I think it might be an omission from the standard: whilst calling a pure
>>> virtual function *without a* definition is UB I can see no reason why
>>> calling a pure virtual function *with a* definition from a ctor/dtor
>>> should be UB.
>>>
>>> I do not believe this is an ease-of-implementation issue as VC++ and g++
>>> allow it no problem (yes I know UB can "silently work"); clang seemingly
>>> follows the standard to the letter and doesn't.
>>
>> I was in error about VC++ and g++ as they do both terminate on virtual
>> call to pure virtual from ctor like clang however unlike clang they do
>> allow an *unqualified* call to the pure virtual from the ctor (clang
>> doesn't); clang perhaps doesn't use the "don't use dynamic dispatch if
>> we know the type" optimization.
>>
>> I still assert that defined behaviour is better than undefined behaviour. :)
>
> So make it illegal to associate a definition with a PVF.   Problem solved.

Why would you want to do that?  There is nothing wrong with a pure 
virtual function having a definition which is why C++ allows it and pure 
virtual destructors *must* to have a definition.

/Leigh

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

#13486

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:pq2dneA7k5V4i4rSnZ2dnUVZ8qqdnZ2d@giganews.com...
> On 18/01/2012 18:12, Scott Lurndal wrote:
>> Leigh Johnston<leigh@i42.co.uk>  writes:
>>> On 14/01/2012 23:06, Leigh Johnston wrote:
>>>>    From n3242, 10.4./6:
>>>> "Member functions can be called from a constructor (or destructor) of 
>>>> an
>>>> abstract class; the effect of making a
>>>> virtual call (10.3) to a pure virtual function directly or indirectly
>>>> for the object being created (or destroyed)
>>>> from such a constructor (or destructor) is undefined."
>>>>
>>>> Does anyone know the rationale for why the above is UB?
>>>>
>>>> For the newbies reading this: it *is* possible in C++ for a pure 
>>>> virtual
>>>> function to have a definition.
>>>>
>>>> I think it might be an omission from the standard: whilst calling a 
>>>> pure
>>>> virtual function *without a* definition is UB I can see no reason why
>>>> calling a pure virtual function *with a* definition from a ctor/dtor
>>>> should be UB.
>>>>
>>>> I do not believe this is an ease-of-implementation issue as VC++ and 
>>>> g++
>>>> allow it no problem (yes I know UB can "silently work"); clang 
>>>> seemingly
>>>> follows the standard to the letter and doesn't.
>>>
>>> I was in error about VC++ and g++ as they do both terminate on virtual
>>> call to pure virtual from ctor like clang however unlike clang they do
>>> allow an *unqualified* call to the pure virtual from the ctor (clang
>>> doesn't); clang perhaps doesn't use the "don't use dynamic dispatch if
>>> we know the type" optimization.
>>>
>>> I still assert that defined behaviour is better than undefined 
>>> behaviour. :)
>>
>> So make it illegal to associate a definition with a PVF.   Problem 
>> solved.
>
> Why would you want to do that?  There is nothing wrong with a pure virtual 
> function having a definition which is why C++ allows it and pure virtual 
> destructors *must* to have a definition.
>
Are you totally thick?

A pure virtual function cannot be pure if a constructor is allowed to invoke 
a paritial implementation.
I have already explained this to you but , as always, you resort to name 
calling and such and are incapable of an intellectual discussion. 



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

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

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

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

csiph-web