https://bugs.meego.com/show_bug.cgi?id=19464
pohly <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #14 from pohly <[email protected]> 2011-07-11 10:26:14 UTC --- (In reply to comment #13) > This seems to be about initialization of static instances. It's generally > considered that there is absolutely no way to know when static instances will > be initialized, and no way to control it. Stroustrup makes two statements that can be relied upon: 10.4.8 Local Static Store "The constructor for a local static object is called the first time the thread of control passes through the object's definition." 10.4.9 Nonlocal Store "Constructors for nonlocal objects in a translation unit are executed in the order their definitions occur." > It's best to just avoid static instances. Singletons are less awkward. > Singletons themselves depend on the first of these statements. I agree that nonlocal storage is awkward. But in the case of SyncEvolution it is convenient in a few places. Therefore I fixed the problem like this: commit e0883e4c9230afeb40b497bb877853c0ae1bdb68 Author: Patrick Ohly <[email protected]> Date: Mon Jul 11 11:37:09 2011 +0200 SyncConfig: fixed compiler problem with C++ initialization order (BMC #19464) g++ 4.6 and ld 2.21.52.20110707 (Debian Unstable) led to a different order of global instance construction: 1. WebDAV constructor calls SyncConfig::getRegistry() 2. getRegistry() adds the (uninitialized!) property instances and modifies them 3. SyncConfig.cpp instances are initializes, which resets some of the values modified by getRegistry() The result was that, for example, the "defaultPeer" property was treated like an unshared property and written into the wrong config file. The assumption that variables in a compilation unit are initialized before methods in that unit can be called is not based on anything in the C++ standard. Therefore this commit rewrites the code so that properties are not added/updated inside the getRegistry() methods. Instead this is done in separate classes which (and that is guaranteed by the C++ standard) are constructed after the properties defined earlier in the compilation unit. -------- Product: SyncEvolution Component: SyncEvolution MeeGo Release: unspecified Severity: major Priority: Medium Keywords: Status: RESOLVED Who: [email protected] Assigned To: [email protected] Target Build: --- Flags: Changed: Status Resolution -------- https://bugs.meego.com/show_bug.cgi?id=19464 -- Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
