Globale Variablen



  • Hi

    Ich lese mir gerade LLVM's Coding Standards durch und bin auf den Punkt gestossen:
    https://llvm.org/docs/CodingStandards.html#do-not-use-static-constructors

    In gewissen meiner Projekte habe ich im Header große Tabellen à la extern const std::unordered_map<...> o.Ä., die ich dann im Source-File konstruiere (der Konstruktoraufruf ist ebenfalls groß). Falls ich diese Tabellen nicht exposen möcht als Teil der API, aber dennoch intern brauche zur Implementation gewisser Funktionen, dann tu ich die im Source-File in einen anonymen Namespace.

    Zur Frage: Sind diese zwei geschilderten Szenarien nun problematisch gemäss dem Link? Wenn ja, was ist die Alternative? Wenn ich eine Funktion mache, die die Tabelle als static Variable enthält, dann habe ich (soweit ich das sehe) den Binary-Overhead zwar nicht mehr, dafür habe ich einen Runtime-Overhead jedes mal, wenn die Funktion aufgerufen wird (da wird ja auch ein Flag und ein Jump injiziert).

    MfG Underachiever



  • Underachiever schrieb:

    Zur Frage: Sind diese zwei geschilderten Szenarien nun problematisch gemäss dem Link?

    Ja, sicher.

    Underachiever schrieb:

    Wenn ja, was ist die Alternative?

    Das was du selbst gleich schreibst 🙂

    Underachiever schrieb:

    Wenn ich eine Funktion mache, die die Tabelle als static Variable enthält, dann habe ich (soweit ich das sehe) den Binary-Overhead zwar nicht mehr, dafür habe ich einen Runtime-Overhead jedes mal, wenn die Funktion aufgerufen wird (da wird ja auch ein Flag und ein Jump injiziert).

    Also... der Overhead ist normalerweise nicht sehr schlimm.
    Klar, wenn du das in einer super schnellen Funktion brauchst, die in einer super-engen Schleife aufgerufen wird, dann kann es schon blöd sein. Dann schreibst du es halt so um dass diese Funktion das statische Dings als Parameter mitgegeben bekommt. Dann kannst du es ausserhalb der Schleife 1x holen statt bei jedem Durchlauf. Normalerweise geht das schön.


Log in to reply