Can QScopedPointer be used as a static member?
Is the behavior for QScopedPointer defined when used as a static member? (Documented it is not).
static QScopedPointer<AnotherClass> sm_OtherClass;
Once allocated, will QScopedPointer ensure sm_OtherClass will be deleted once the application terminates?
Initial tests reveal that it does work (Windows@Visual Studio 2010).
The deleter of QScopedPointers is called within atexit.
The question is: If this is cleanly implemented, why isn't it documented in the class description of QScopedPointer?
The more interesting question is: does it work on all platforms? and on all windows versions?
A scoped pointer is mean to be used in a scope. Typically a scope is not the process end :-)
Are you sure that deletion of the global object works in all cases on all pülatforms? windopws for example has clear restictions what you might use and what not before main is entered (or before and during DllMain).
Everything that is not explicitly allowed, might work in 99.9% of the cases, but might also crash or do something else (= undefined behavior).
A thread on stackoverflow suggested to use std::autoPtr. Since I consistently use Qt, I wondered whether I could use QScopedPointer instead.
I am asking myself exactly the same questions you are asking. I can see that it works on my current platform, for my current compiler. Nothing more.
Alternatively, what is a proper way to clean up static pointers? One thread suggests using atexit, which seems to e exactly what QScopedPointer is using. atexit is covered by the C++ standard
From the 2003 version:
bq. If a function is registered with atexit (see <cstdlib>, 18.3) then following the call to exit, any objects with static storage duration initialized prior to the registration of that function shall not be destroyed until the registered function is called from the termination process and has completed. For an object with static storage duration constructed after a function is registered with atexit, then following the call to exit, the registered function is not called until the execution of the object’s destructor has completed. If atexit is called during the construction of an object, the complete object to which it belongs shall be destroyed before the registered function is called.
Link to the stackoverflow discussion:
It should be safe to use QScopedPointer in such a manner. According to the C++ standard
bq. Destructors (12.4) for initialized objects of static storage duration (declared at block scope or at namespace scope) are called as a result of returning from main and as a result of calling exit
The destructor for QScopedPointer does what I want.
That might be safe if you only create an executable. If you are inside a dll, it is not (not on Windows).
Dlls on windows have some special behavior, which can be found in msdn (but I don't know exatcly where... :-( )
Good point. Don't we all love dlls?
Have a look at the following link for more information:
IIRC, global variables are created before DLLMain,and destroyed afterwards, but I'm not 100% sure...
[quote author="Asperamanca" date="1360247282"]Good point. Don't we all love dlls?[/quote]
Sure, that's my daily business, I nearly never create an executable...
By the way, s copy from MSDN:
bq. If your DLL is linked with the C run-time library (CRT), the entry point provided by the CRT calls the constructors and destructors for global and static C++ objects. Therefore, these restrictions for DllMain also apply to constructors and destructors and any code that is called from them.