From: James R. <si...@wa...> - 2007-11-11 07:07:38
|
-------------------------------------------------- From: "poy" <po...@12...> Sent: Friday, November 09, 2007 6:11 PM To: "dcplusplus-devel" <dcp...@li...> Subject: [dcplusplus-devel] Fw: patch: let windows draw ListView arrows > forgot the patch once again. ^^ > >> here, new patch. >> - the function now uses SmartWin::LibraryLoader. >> - moved the MessageBox to MainWindow, and its string can be translated. >> - played with some includes... Unfortunately, this introduces a dependency on the ordering of C++ static initialisers in separate translation units - which is undefined by the C++ spec, as far as I can see. The static initialisers are all done before the 'main' starts executing, and this particular call chain is the problem: win32\WinUtil.cpp: const SmartWin::WidgetListView::Seed WinUtil::Seeds::listView; -> causes the static construction of -> smartwin\source\widgets\WidgetListView.cpp: WidgetListView::Seed::Seed -> calls common controls check, which ultimately uses the static lock at -> smartwin\source\LibraryLoader.cpp: Utilities::CriticalSection LibraryLoader::itsCs; Now, the problem is that the initialisation of LibraryLoader::itsCs is also a static initialiser. If the itsCs lock is not initialised before the Seed constructor, the application crashes on startup. Which is exactly what happens for me. :-( The simplest, but less than ideal, fix I've found is to move the common control check in the Seed constructor into WidgetListView::create. Better ideas welcome - especially ones which don't do the check on every list view creation! Note that the most likely reason this has affected me and not others is that I'm probably the only one building with MSVC. I am only to assume GCC is being lucky here, as I can't find any indication that it's actually a bug in either compiler, it's just undefined behaviour, which is a right pain. -- James Ross P.S. I hope I got all that right, I've spent most of the day periodically searching the little information on the web about C++ static initialisers, their orderings and compiler-specific behaviours and it's all starting to blur a bit. |