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

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

 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

[toc] | [next] | [standalone]

#13379

On Jan 15, 12:06 am, 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?

I completely agree with you. So not thoughts here ;-).

Goran.

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

#13380

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:c72dnSYot-_4l4_SnZ2dnUVZ8o-dnZ2d@giganews.com...
> 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?

The more-derived type has not yet been constructed. It therefore does not 
exist yet. Similarly during destruction, the more-derived types have already 
been destroyed. They no longer exist. It is unsafe be invoke a method in an 
object that does not exist.

This is not an ease of implementation issue. Virtual calls during 
construction/destruction are dispatched as though the vptr references the 
vtable for the current class, not that of the most derived type.

If it were possible to call an override defined in a more-derived type 
during construction, what assumptions can *any* virtual method make about 
data members, its own or in any of its bases?

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

#13385

On 15/01/2012 08:25, MikeWhy wrote:
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:c72dnSYot-_4l4_SnZ2dnUVZ8o-dnZ2d@giganews.com...
>> 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?
>
> The more-derived type has not yet been constructed. It therefore does
> not exist yet. Similarly during destruction, the more-derived types have
> already been destroyed. They no longer exist. It is unsafe be invoke a
> method in an object that does not exist.

Yes but I am talking about the case where the base class pure virtual 
function *does* exist; it is defined behaviour to invoke non-pure 
virtual functions from a ctor (most-derived type not yet constructed).

>
> This is not an ease of implementation issue. Virtual calls during
> construction/destruction are dispatched as though the vptr references
> the vtable for the current class, not that of the most derived type.

Correct and if the base pure virtual function does have a definition why 
not make calling it from the ctor defined behaviour just like calling a 
non-pure virtual function from the ctor is defined behaviour?

>
> If it were possible to call an override defined in a more-derived type
> during construction, what assumptions can *any* virtual method make
> about data members, its own or in any of its bases?

You misunderstand; I am not arguing for this.

/Leigh

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

#13389

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:w--dnSiP8NwAQI_SnZ2dnUVZ7vGdnZ2d@giganews.com...
> On 15/01/2012 08:25, MikeWhy wrote:
>> The more-derived type has not yet been constructed. It therefore does
>> not exist yet. Similarly during destruction, the more-derived types have
>> already been destroyed. They no longer exist. It is unsafe be invoke a
>> method in an object that does not exist.
>
> Yes but I am talking about the case where the base class pure virtual 
> function *does* exist; it is defined behaviour to invoke non-pure virtual 
> functions from a ctor (most-derived type not yet constructed).

Its purity is pure myth, then, despite notation to the contrary. However, 
the class is still abstract without an override higher in the hierarchy. In 
which case, my common defintion of "abstract" would be less comprehensive 
since it uses the term "pure virtual". I believe that this is purely, 
virtually, just a natural language issue. I do very much prefer a more 
rigorous language when unambiguous communication is important.

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

#13381

On 15.01.2012 00: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.

The implementation can only be called by explicit qualification.

Its only connection to the pure virtual function is that it has the same 
name and type (type = signature + result), and so, that it very 
naturally can serve as a default.

So, it is not really an implementation of the virtual function as such, 
it is just an implementation of the same kind of function, perhaps a bit 
confusingly with the same name as  the virtual function. ;-)


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

Pure also means that the function does not exist in this class.

That's easier to get to grips with when one realizes that the apparent 
implementation of the virtual function is not, but is just an 
implementation of the same kind of function, and with the same name.

For example, it's then more clear that it will never (guaranteed) be 
executed by a virtual call, no matter where that call comes from.


Cheers & hth.,

- Alf

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

#13386

On 15/01/2012 08:29, Alf P. Steinbach wrote:
> On 15.01.2012 00: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.
>
> The implementation can only be called by explicit qualification.

Yes because that is what the standard currently implies; I am arguing 
that the standard is possible wrong.

>
> Its only connection to the pure virtual function is that it has the same
> name and type (type = signature + result), and so, that it very
> naturally can serve as a default.
>
> So, it is not really an implementation of the virtual function as such,
> it is just an implementation of the same kind of function, perhaps a bit
> confusingly with the same name as the virtual function. ;-)
>
>
>> 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?
>
> Pure also means that the function does not exist in this class.

No it doesn't; pure virtual functions can have definitions.

>
> That's easier to get to grips with when one realizes that the apparent
> implementation of the virtual function is not, but is just an
> implementation of the same kind of function, and with the same name.
>
> For example, it's then more clear that it will never (guaranteed) be
> executed by a virtual call, no matter where that call comes from.

If I understand you correctly then you could argue that the base class 
version of *any* overridden virtual function can never be executed by a 
virtual call (not just pure virtual functions); this is irrelevant; pure 
and not-pure should behave the same in my opinion (if both are defined).

/Leigh

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

#13387

On 15.01.2012 15:16, Leigh Johnston wrote:
>
> If I understand you correctly then you could argue that the base class
> version of *any* overridden virtual function can never be executed by a
> virtual call (not just pure virtual functions);

Oh no.

The (apparent) class T implementation of a function that is pure virtual 
in T, is a very special case.

It's a non-virtual beast.


> this is irrelevant; pure
> and not-pure should behave the same in my opinion (if both are defined).

No, the pure specifier says directly that there is no such function in 
this class. Even if you have defined an apparent implementation of it. 
Bjarne, according to a passage in the Design & Evolution of C++ book, 
chose the "= 0" to express the "no such here" in an initializer-like 
way, with the "0" as stand-in for the implementation part.

As far as I know that's the original reason that you can't write an 
(apparent) definition inline, but have to write it out of class.

However, while I have argued that that old purely syntactical 
restriction ideally could/should be removed, I no longer think so. For 
apparently very few C++ programmers have a clear view of this. And then 
allowing the inline definition could easily serve to support 
misconceptions about it, so, better that it stands out as Very Special.


Cheers & hth.,

- Alf

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

#13388

On 15/01/2012 14:25, Alf P. Steinbach wrote:
> On 15.01.2012 15:16, Leigh Johnston wrote:
>>
>> If I understand you correctly then you could argue that the base class
>> version of *any* overridden virtual function can never be executed by a
>> virtual call (not just pure virtual functions);
>
> Oh no.
>
> The (apparent) class T implementation of a function that is pure virtual
> in T, is a very special case.
>
> It's a non-virtual beast.
>
>
>> this is irrelevant; pure
>> and not-pure should behave the same in my opinion (if both are defined).
>
> No, the pure specifier says directly that there is no such function in
> this class. Even if you have defined an apparent implementation of it.
> Bjarne, according to a passage in the Design & Evolution of C++ book,
> chose the "= 0" to express the "no such here" in an initializer-like
> way, with the "0" as stand-in for the implementation part.

And yet pure dtors must have a definition; I disagree with your analysis 
here.

>
> As far as I know that's the original reason that you can't write an
> (apparent) definition inline, but have to write it out of class.
>
> However, while I have argued that that old purely syntactical
> restriction ideally could/should be removed, I no longer think so. For
> apparently very few C++ programmers have a clear view of this. And then
> allowing the inline definition could easily serve to support
> misconceptions about it, so, better that it stands out as Very Special.

"Very Special"?  Your proposed rationale is Very Shaky, the "apparent 
view" of a "few C++ programmers" or lack of said "view" in a lot of C++ 
programmers is irrelevant.

/Leigh

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

#13394

On Jan 14, 11:06 pm, Leigh Johnston <le...@i42.co.uk> wrote:

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

It is indeed, quite odd. To be honest, I'd be more interested in the
rationale / use-case that motivated the definition of a pure virtual
function.  What does it allow that cannot be just as simply done with
a non-pure virtual function, or an undefined pure virtual + a non-
virtual protected function?

I'm sure there's an answer, but I can't see what it is.

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

#13398

On 16.01.2012 10:57, gwowen wrote:
> On Jan 14, 11:06 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>
>> 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?
>
> It is indeed, quite odd. To be honest, I'd be more interested in the
> rationale / use-case that motivated the definition of a pure virtual
> function.  What does it allow that cannot be just as simply done with
> a non-pure virtual function, or an undefined pure virtual + a non-
> virtual protected function?

The latter case, undefined pure virtual + a non-virtual function, is 
what you effectively /have/ when you (apparently) define for class T a 
function that is pure virtual in T.

It is just a matter of language, of how we talk about it. Instead of 
misleadingly talking about a definition of a pure virtual function, 
perhaps we should better talk about an /associated/ definition, or 
something like that. It is not virtual, it cannot be called virtually, 
it just has the same name and signature as the pure virtual function.

Such an associated definition is necessary for a pure virtual destructor 
(note that the definition is then not called virtually, it's never 
called virtually and cannot be called virtually), but one might argue 
that pure virtual destructors are of very limited utility.


> I'm sure there's an answer, but I can't see what it is.

For the mechanism, see above.

For the rationale, it standardizes how to implement the Smalltalk 
concept of "subclass responsibility".

Instead of each programmer inventing some way to do that  --  exception, 
default implementation, comment  --  the language provides a single way 
that all programmers can relate to and expect from others.


Cheers & hth.,

- Alf

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

#13402

On 16/01/2012 10:28, Alf P. Steinbach wrote:
> On 16.01.2012 10:57, gwowen wrote:
>> On Jan 14, 11:06 pm, Leigh Johnston<le...@i42.co.uk> wrote:
>>
>>> 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?
>>
>> It is indeed, quite odd. To be honest, I'd be more interested in the
>> rationale / use-case that motivated the definition of a pure virtual
>> function. What does it allow that cannot be just as simply done with
>> a non-pure virtual function, or an undefined pure virtual + a non-
>> virtual protected function?
>
> The latter case, undefined pure virtual + a non-virtual function, is
> what you effectively /have/ when you (apparently) define for class T a
> function that is pure virtual in T.
>
> It is just a matter of language, of how we talk about it. Instead of
> misleadingly talking about a definition of a pure virtual function,
> perhaps we should better talk about an /associated/ definition, or
> something like that. It is not virtual, it cannot be called virtually,
> it just has the same name and signature as the pure virtual function.

A pure virtual function cannot be called virtually due to the UB present 
in the standard; if you call the pure virtual function indirectly from 
another function called from the base ctor then dynamic dispatch should 
be allowed to kick in making it defined behaviour for that pure virtual 
function with a definition to be called.

Perhaps you are arguing that a pure virtual function should never have 
an entry in a vtable (which chimes with your gut feeling about "= 0")? 
I disagree that such a restriction is useful as it is better to make 
something defined behaviour in the standard rather than undefined behaviour.

/Leigh

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

#13403

On Jan 16, 10:28 am, "Alf P. Steinbach" <alf.p.steinbach
+use...@gmail.com> wrote:

> The latter case, undefined pure virtual + a non-virtual function, is
> what you effectively /have/ when you (apparently) define for class T a
> function that is pure virtual in T.

I appreciate that the notion of pure virtual allows a subclass
responsibility.

It just seems to me that allowing a programmer to define its "pure
virtuals" has no clear benefit (especially if you can't call them from
abstract base-class ctor/dtor). (To be honest, I'd never realised it
was *possible*).

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

#13404

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:c72dnSYot-_4l4_SnZ2dnUVZ8o-dnZ2d@giganews.com...
> 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?
>

http://www.artima.com/cppsource/nevercall.html 



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

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

#13405

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.

/Leigh

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

#13406

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

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? Does the vtble still refer to the member 
function, as defined in the derived class?


There is more reading here about this :
http://www.artima.com/cppsource/pure_virtual.html 



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

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

#13407

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.

>
> 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? Does the vtble still refer to the member
> function, as defined in the derived class?

When in a base class ctor or dtor the vtable pointer points to the base 
class vtable.

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?

[snip]

/Leigh

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

#13411

"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.
But this goes against the concept of not being able to instanciate an 
abstract class type.

>>
>> 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? Does the vtble still refer to the 
>> member
>> function, as defined in the derived class?
>
> When in a base class ctor or dtor the vtable pointer points to the base 
> class vtable.
>
> 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?
>
Also remember classic vtable implementation is not defined in the C++ 
standard. The implementation of virtual functions is left open, perhaps this 
rule accomodates some more obscure implementations. 



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

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

#13412

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.

>
>>>
>>> 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? Does the vtble still refer to the
>>> member
>>> function, as defined in the derived class?
>>
>> When in a base class ctor or dtor the vtable pointer points to the base
>> class vtable.
>>
>> 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?
>>
> Also remember classic vtable implementation is not defined in the C++
> standard. The implementation of virtual functions is left open, perhaps this
> rule accomodates some more obscure implementations.

Correct it isn't but that doesn't mean that common vtable 
implementations are irrelevant to this discussion.

/Leigh

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

#13415

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

The PVF must be implemented by the derived class and not by the base 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. 



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

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web