Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   Re: Rationale for base class pure virtual function call fromctor/dtor being undefined behaviour. (http://www.velocityreviews.com/forums/t808126-re-rationale-for-base-class-pure-virtual-function-call-fromctor-dtor-being-undefined-behaviour.html)

gwowen 01-17-2012 02:43 PM

Re: Rationale for base class pure virtual function call fromctor/dtor being undefined behaviour.
 
On Jan 17, 2:11*pm, Leigh Johnston <le...@i42.co.uk> wrote:
> Read:
>
> http://www.open-std.org/jtc1/sc22/wg...ctive.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 01-17-2012 03:22 PM

Re: Rationale for base class pure virtual function call fromctor/dtor being undefined behaviour.
 
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.

gwowen 01-17-2012 04:59 PM

Re: Rationale for base class pure virtual function call fromctor/dtor being undefined behaviour.
 
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.

MikeWhy 01-17-2012 05:34 PM

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



MikeWhy 01-17-2012 06:14 PM

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



MikeWhy 01-18-2012 07:08 PM

Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour.
 
"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;
}



MikeWhy 01-18-2012 07:14 PM

Re: Rationale for base class pure virtual function call from ctor/dtor being undefined behaviour.
 
"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.



All times are GMT. The time now is 08:35 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.