[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: "Clemens Zeidler" <clemens.zeidler@xxxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Wed, 10 Nov 2010 06:40:08 +1300

Am 09.11.2010, 23:39 Uhr, schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:

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

thanks for the explanation!

Other related posts: