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

Discussion in 'C++' started by gwowen, Jan 17, 2012.

  1. gwowen

    gwowen Guest

    On Jan 17, 2:11 pm, Leigh Johnston <> 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.
     
    gwowen, Jan 17, 2012
    #1
    1. Advertising

  2. gwowen

    gwowen Guest

    On Jan 17, 2:52 pm, Leigh Johnston <> 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.
     
    gwowen, Jan 17, 2012
    #2
    1. Advertising

  3. gwowen

    gwowen Guest

    On Jan 17, 4:35 pm, "Paul" <pchrist<nospam>> 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.
     
    gwowen, Jan 17, 2012
    #3
  4. gwowen

    MikeWhy Guest

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

    gwowen wrote:
    > On Jan 17, 4:35 pm, "Paul" <pchrist<nospam>> 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.
     
    MikeWhy, Jan 17, 2012
    #4
  5. gwowen

    MikeWhy Guest

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

    MikeWhy wrote:
    > gwowen wrote:
    >> On Jan 17, 4:35 pm, "Paul" <pchrist<nospam>> 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.)
     
    MikeWhy, Jan 17, 2012
    #5
  6. gwowen

    MikeWhy Guest

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

    "Gareth Owen" <> wrote in message
    news:...
    > "MikeWhy" <> 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;
    }
     
    MikeWhy, Jan 18, 2012
    #6
  7. gwowen

    MikeWhy Guest

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

    "MikeWhy" <> wrote in message
    news:jf75be$8sp$...
    > "Gareth Owen" <> wrote in message
    > news:...
    >> "MikeWhy" <> 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.
     
    MikeWhy, Jan 18, 2012
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. IK
    Replies:
    2
    Views:
    639
    hemraj
    Jul 23, 2004
  2. tuvok
    Replies:
    27
    Views:
    865
    Howard
    Jun 16, 2005
  3. Replies:
    10
    Views:
    737
    Richard Herring
    Oct 18, 2005
  4. Replies:
    2
    Views:
    591
  5. Martin
    Replies:
    5
    Views:
    489
    Felix Palmen
    Aug 26, 2010
Loading...

Share This Page