6:26 p.m.
https://bugs.meego.com/show_bug.cgi?id=19464
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #14 from pohly <patrick.ohly(a)intel.com> 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 <patrick.ohly(a)intel.com>
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: patrick.ohly(a)intel.com
Assigned To: patrick.ohly(a)intel.com
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.