Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Virtual pure function call without constructor

29 views
Skip to first unread message

Marcel Mueller

unread,
Aug 28, 2022, 12:59:09 PM8/28/22
to
Is there *any* scenario how this error can happen without any
constructor or destructor in the call stack?


Marcel

Richard Damon

unread,
Aug 28, 2022, 1:13:07 PM8/28/22
to
I can see it happening with threads (the constructor/destructor is in a
different Thread).

Not sure if there is any way to create or slice an object to result in
an "abstract" object.

Paavo Helde

unread,
Aug 28, 2022, 1:37:39 PM8/28/22
to
28.08.2022 19:58 Marcel Mueller kirjutas:
> Is there *any* scenario how this error can happen without any
> constructor or destructor in the call stack?

Sure, when you call via an invalid pointer where the object has been
already destroyed.

Juha Nieminen

unread,
Aug 29, 2022, 7:21:05 AM8/29/22
to
Marcel Mueller <news.5...@spamgourmet.org> wrote:
> Is there *any* scenario how this error can happen without any
> constructor or destructor in the call stack?

Is this question different from just asking "is it possible that a member
function is called for an object that has not been constructed?"

I assume that since you mention pure virtuality in particular, you are
thinking of some other scenario here.

Marcel Mueller

unread,
Aug 29, 2022, 9:45:04 AM8/29/22
to
Am 28.08.22 um 19:12 schrieb Richard Damon:
> On 8/28/22 12:58 PM, Marcel Mueller wrote:
>> Is there *any* scenario how this error can happen without any
>> constructor or destructor in the call stack?

> I can see it happening with threads (the constructor/destructor is in a
> different Thread).

That's UB. Anything can happen.

> Not sure if there is any way to create or slice an object to result in
> an "abstract" object.

The compiler should prevent that kind of slicing because no variable of
an abstract type can exist.


Marcel

Marcel Mueller

unread,
Aug 29, 2022, 9:56:24 AM8/29/22
to
Am 28.08.22 um 19:37 schrieb Paavo Helde:
Hmm.

It turned out that I accidentally called a constructor in
std::vector<>::emplace_back(...) rather than just passing constructor
arguments. Once I removed this unnecessary temporary object the error
(later in the application) was gone.

It was a small number crunching application that did neither use any
multi-threading nor new/delete (except for std::vector internally) and
all class variables are POD or one of the classes of POD's or a
reference to it.
The latter was likely the problem. The automatically generated move or
copy constructor probably somehow generated a dangling reference.


Marcel

Manfred

unread,
Aug 29, 2022, 8:29:16 PM8/29/22
to
If you have virtual functions, then it's not a POD.


Richard Damon

unread,
Aug 30, 2022, 7:50:03 AM8/30/22
to

On 8/29/22 9:44 AM, Marcel Mueller wrote:
> Am 28.08.22 um 19:12 schrieb Richard Damon:
>> On 8/28/22 12:58 PM, Marcel Mueller wrote:
>>> Is there *any* scenario how this error can happen without any
>>> constructor or destructor in the call stack?
>
>> I can see it happening with threads (the constructor/destructor is in
>> a different Thread).
>
> That's UB. Anything can happen.

Yep, and the error mentioned is one of them.

>
>> Not sure if there is any way to create or slice an object to result in
>> an "abstract" object.
>
> The compiler should prevent that kind of slicing because no variable of
> an abstract type can exist.
>
>
> Marcel

That's why I said "Not Sure". I wasn't going to say definitively that it
wasn't possible.

The comment about accessing the distructed object was one way to get
such a sliced object (but again, invoking Undefined Behavior).
0 new messages