[haiku-commits] Re: r39369 - in haiku/branches/developer/bonefish/weak-symbols: headers/os/locale headers/private/locale src/apps/aboutsystem src/apps/deskbar src/apps/readonlybootprompt ...
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 09 Nov 2010 11:39:48 +0100
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
Other related posts:
