On 2010-11-09 at 05:06:07 [+0100], Clemens Zeidler <clemens.zeidler@xxxxxxxxxxxxxx> wrote: > Am 09.11.2010, 15:14 Uhr, schrieb <ingo_weinhold@xxxxxx>: > > > Log: > > * Got rid of global variables in the locale kit (be_locale[_roster], > > gMutableLocaleRoster, gRosterData). Introduced static getters instead. > > Probably breaks all optional packages using the locale kit. > > * Unbroke the cycles in the sRosterData (formerly gRosterData) > > initialization: > > - The fDefaultLocale member is now initialized with some actual default > > BLanguage() and BFormattingConventions() (both "en_US"). It was > > formerly > > initializing itself with itself. > > - The fDefaultTimeZone is now a pointer and lazily initialized. This > > breaks > > a longer cycle via ICU, tzset() and LibbeLocaleBackend. > > What do you mean with cycle? In the first case basically what Adrien wrote. In the second case the constructor of member of a global object via, various indirections used the object. Possibly only a part of the object that was already initialized at that time (I didn't check that exactly), but still rather ugly and preventing lazy creation of that object. > and how weak symbols helps here? Not at all. I just stumbled over the problem while following a crash happening when building without -Bsymbolic. > / whats the > problem with global variables? A global variable sucks from a software design point of view, as one cannot control access to it and cannot construct the object lazily. That can be OK in a small application, but really has no place in a public library. CU, Ingo