Accessing static data member through a method of destroyed object

[Ioannis Vranos]

Today I came across this code. As far as I know this is undefined behaviour, but I wanted
to see what others think:


class SomeClass
{
static bool isDisconnected;

public:
~SomeClass()
{
isDisconnected= true;
}

bool IsDisconnected() { return isDisconnected; }
};

bool SomeClass::isDisconnected= false;

 

[Ioannis Vranos]

I don't see any reason why this should be UB.

The code implies invoking the method on a already destroyed object. Isn't it UB?

 

[Rolf Magnus]

Today I came across this code. As far as I know this is undefined
behaviour, but I wanted to see what others think:


class SomeClass
{
static bool isDisconnected;

public:
~SomeClass()
{
isDisconnected= true;
}

bool IsDisconnected() { return isDisconnected; }
};

bool SomeClass::isDisconnected= false;

I don't see any reason why this should be UB.

 

[Kai-Uwe Bux]

Today I came across this code. As far as I know this is undefined
behaviour, but I wanted to see what others think:


class SomeClass
{
static bool isDisconnected;

public:
~SomeClass()
{
isDisconnected= true;
}

bool IsDisconnected() { return isDisconnected; }
};

bool SomeClass::isDisconnected= false;

Why do you think there is UB here. Could you direct me to a clause in the
standard.


Best

Kai-Uwe

 

[Kai-Uwe Bux]

The code implies invoking the method on a already destroyed object.

Where? All I can see is that the destructor accesses static data of the
class. Besides, I do not think that method calls within the destructor
would be UB either.


Best

Kai-Uwe Bux

 

[Ioannis Vranos]

Where? All I can see is that the destructor accesses static data of the
class. Besides, I do not think that method calls within the destructor
would be UB either.

To rephrase my question, and provide the bottom-line. Don't the following codes invoke
undefined behaviour?



1)

#include <iostream>

class SomeClass
{
static bool isDisconnected;

public:
~SomeClass()
{
isDisconnected= true;
}

bool IsDisconnected() { return isDisconnected; }
};

bool SomeClass::isDisconnected= false;


int main()
{
SomeClass *pSomeClass= new SomeClass;

delete pSomeClass;

if(pSomeClass->IsDisconnected())
std::cout<<"Object is disconnected.\n";
}




2)

#include <iostream>

class SomeClass
{
static bool isDisconnected;

public:
~SomeClass()
{
isDisconnected= true;
}

bool IsDisconnected() { return isDisconnected; }
};

bool SomeClass::isDisconnected= false;


int main()
{
SomeClass obj;

obj.~SomeClass();

if(obj.IsDisconnected())
std::cout<<"Object is disconnected.\n";
}

 

[Andre Kostur]

To rephrase my question, and provide the bottom-line. Don't the
following codes invoke undefined behaviour?



1)

#include <iostream>

class SomeClass
{
static bool isDisconnected;

public:
~SomeClass()
{
isDisconnected= true;
}

bool IsDisconnected() { return isDisconnected; }
};

bool SomeClass::isDisconnected= false;


int main()
{
SomeClass *pSomeClass= new SomeClass;

delete pSomeClass;

if(pSomeClass->IsDisconnected())
std::cout<<"Object is disconnected.\n";
}

This code isn't what you started with...... _this_ code invokes undefined
behaviour by dereferencing an invalid pointer.

2)

#include <iostream>

class SomeClass
{
static bool isDisconnected;

public:
~SomeClass()
{
isDisconnected= true;
}

bool IsDisconnected() { return isDisconnected; }
};

bool SomeClass::isDisconnected= false;


int main()
{
SomeClass obj;

obj.~SomeClass();

if(obj.IsDisconnected())
std::cout<<"Object is disconnected.\n";
}

I would expect that this is undefined behaviour as well... calling a
method on a destroyed object.

 

[Rolf Magnus]

To rephrase my question, and provide the bottom-line.

Good idea! ;-)

Don't the following codes invoke undefined behaviour?

1)

#include <iostream>

class SomeClass
{
static bool isDisconnected;

public:
~SomeClass()
{
isDisconnected= true;
}

bool IsDisconnected() { return isDisconnected; }
};

bool SomeClass::isDisconnected= false;


int main()
{
SomeClass *pSomeClass= new SomeClass;

delete pSomeClass;

if(pSomeClass->IsDisconnected())
std::cout<<"Object is disconnected.\n";
}

Well, yes. This is UB, for the reason you mentioned. OTOH, I don't really
see a reason why the member function is not static, since it doesn't access
any non-static members.

2)

#include <iostream>

class SomeClass
{
static bool isDisconnected;

public:
~SomeClass()
{
isDisconnected= true;
}

bool IsDisconnected() { return isDisconnected; }
};

bool SomeClass::isDisconnected= false;


int main()
{
SomeClass obj;

obj.~SomeClass();

if(obj.IsDisconnected())
std::cout<<"Object is disconnected.\n";
}

Same as above. But this time, it would even be UB without the function call,
since the (already destroyed) object gets destroyed again when it goes out
of scope.

 

[Howard]

Kai-Uwe Bux wrote:


int main()
{
SomeClass *pSomeClass= new SomeClass;

delete pSomeClass;

if(pSomeClass->IsDisconnected())

UB here, dereferencing pointer to object that's been deleted.

std::cout<<"Object is disconnected.\n";
}





int main()
{
SomeClass obj;

obj.~SomeClass();

if(obj.IsDisconnected())

I'd assume UB here, too, since you called the destructor.

std::cout<<"Object is disconnected.\n";
}

But you *could* do this:


int main()
{
SomeClass* ptr = new SomeClass;
ptr->blah(); // call some function in the class
delete ptr;
if (SomeClass::IsDisconnected())
std::cout<<"Object is disconnected.\n";
}

No UB there, since no object is referenced.

-Howard

 

[Ioannis Vranos]

But you *could* do this:


int main()
{
SomeClass* ptr = new SomeClass;
ptr->blah(); // call some function in the class
delete ptr;
if (SomeClass::IsDisconnected())
std::cout<<"Object is disconnected.\n";
}

No UB there, since no object is referenced.

Thank you all for your replies.


I know what I could do, this is code I have come across. "SomeClass" is actually
"Server" and is intended having only one instance of it running. I was puzzled by this
method to static member approach, it was so obvious it was wrong, that I wondered if I was
missing something.