Re: Assign Reference to another Referance
cpisz <cpisz@austin.rr.com> kirjutas:
On Sep 26, 1:28?am, Paavo Helde <pa...@nospam.please.ee> wrote:
cpisz <cp...@austin.rr.com> kirjutas:
I'll give you a compilable example as
soon as I get VS fixed later today.
Good! Please do so!
class Singleton
{
public:
? ?static Singleton & Instance()
? ?{
? ? ? if( !m_instance )
? ? ? {
? ? ? ? ?m_instance = new Singleton();
? ? ? }
? ? ? return *m_instance;
? ?}
? ?static void DoStuff()
? ?{
? ? ? int x = 1 + 1;
? ?}
private:
? ?static Singleton * m_instance;
};
Singleton * Singleton::m_instance ?= 0;
class Foo
{
public:
? ?Foo(){}
? ?~Foo()
? ?{
? ? ? Singleton::Instance().DoStuff();
? ?}
};
int main()
{
? ?static Foo foo;
? ?return 0; ?// Undefined behavior after this line, when program
cleanup occurs!
}
Please use the code earlier in this post where foo is global.
I tried both ways, nothing spectacular happened.
[trivialities about UB snipped]
So, it appears the lifetime of the static pointer ends only when the
memory is unmapped from the process space by the OS (storage
released).
You are just repeating my own claim back to me.
Except I am not claiming in the specific word you used "unmapped from
process space", but rather simply that, no matter how you'd like to
label it, the OS will make the memory where the static pointer resides
invalid.
Well, that's good, isn't it - otherwise wo would soon run out of bits!
(as you mentioned elsethread).
However, according to 3.6.3/2 UB only appears is the if the flow of
control passes through the definition of the static. When OS is unmapping
the process memory, you bet it has stopped the process execution (in
user-space) already, so the control flow cannot pass through anything.
I now took a closer look of your code and saw that you are not even using
local static, but a global static instead. This is much easier, as no
control flow cannot pass through its definition, so you don't even need
to be afraid of 3.6.3/2.
I've stopped the execution of it in GCC, I really wish I had written
down the call stack to show you what the heck I am talking about. It
had a special name that was obviously "process cleanup".
If gdb is still showing some stack containing user-space function calls,
this means that the program is still running and no statics' memory has
been released yet.
You are essentially claiming that if the program has written a pointer
value somewhere in the static data segment, its value might become
mysteriously changed by a legal program during the program shutdown,
before its official lifetime ends (as described by 3.8/1). Or are you
claiming that OS starts to release process memory while the process is
still running? Which one?
Paavo