const-Variablen in der header-Datei und die statische Initialisierung Fiasko

Nach der Lektüre eine Menge der Fragen bezüglich der Initialisierung von statischen Variablen bin ich noch nicht sicher, wie dies gilt für const Variablen auf namespace-Ebene.

Ich habe diese Art von den folgenden code in eine header Datei config.h erzeugt durch das build-Skript:

static const std::string path1 = "/xyz/abc";
static const std::string path2 = "/etc";

Je nach dem was ich gelesen habe, die static Stichwort ist nicht notwendig, sogar veraltet hier.

Meine Frage: Ist der obige code anfällig für die statische Initialisierung Fiasko?

Wenn ich das folgende in einem header Datei myclass.h:

class MyClass
{
public:
    MyClass(const std::string& str) : m_str(str) {}
    std::string Get() const { return m_str; }

private:
    std::string m_str;
}

const MyClass myclass1("test");

Wird diese pose auch keine Probleme mit statischer Initialisierung?

Wenn ich das richtig verstanden, aufgrund const Variablen auf, die interne Verlinkung sollte es kein problem sein, in beiden Fällen?

Edit: (aufgrund dribeas Antwort)

Vielleicht sollte ich erwähnen, dass ich mich für Anwendungsfälle wie:

In main.cpp:

#include <config.h>
#include <myclass.h>

std::string anotherString(path1 + myclass1.Get());

int main()
{
    ...
}

Andere Frage bezüglich dieser use-case: Wird die compiler-Optimierung entfernt path2 in diesem Fall?

InformationsquelleAutor Hanno S. | 2011-01-26

  1. 12

    Ihre erste definition Orte path1 in jeder compilation unit enthält config.h. Um dies zu vermeiden, nicht bei der Definition von Variablen in header-Dateien. In der Regel würden Sie deklarieren Sie die Variablen in der Kopfzeile als extern:

    extern const std::string path1;
extern const MyClass myclass1;

    definieren und diese in einer übersetzung Einheit, z.B. config.cpp:

    const std::string path1 = "/xyz/abc";
const MyClass myclass1("test");

    Manchmal müssen Sie eine Konstante variable, die kann nur von einem übersetzungs-Einheit. Dann können Sie erklären, dass Variablen auf file-scope als static.

    static const std::string path1 = "/xyz/abc";

    static ist nicht veraltet, nicht mehr. static und extern sind manchmal angedeutet, aber ich vergesse immer, wo und wie, damit ich in der Regel geben Sie diese explizit für alle namespace-level-Variablen.

    Es stimmt nicht, dass static kann nur verwendet werden, in der Umsetzung Dateien.
    natürlich, es ist kein Konzept für die Umsetzung-Datei in C++ an alle, ich werde versuchen, die Worte zu verändern
    Ich denke, die phrase, die Sie suchen, ist "translation unit" statt Umsetzung-Datei. Werte sollten deklariert werden, der im Header definiert und in höchstens einer übersetzungseinheit. In diesem Fall, da Sie sind const und implizite interne Verlinkung, die Sie nicht bekommen, eine mehrfach definierte symbol Fehler beim link-Zeit, aber Sie haben die gleiche definierte symbol in jeder übersetzungseinheit enthält dieser header. Da Sie über interne Verlinkung, Sie brechen nicht verlinken, aber der compiler kann nicht Beseitigung der Duplikate. Ich habe einmal Rasiert 8 MB aus einer ausführbaren Datei, durch entfernen der Definitionen von strings aus Kopf.

    InformationsquelleAutor Philipp

  2. 9

    Habe ich versucht, die notwendigen Informationen direkt aus der C++03 Standard-Dokument. Hier ist was ich gefunden habe:

    Über die const static Erklärungen:

    Gemäß Abschnitt 3.5.3 definierten Objekte auf namespace-Ebene und erklärt const haben interne Verlinkung standardmäßig. static auch deklariert einen namespace-level-Objekt, intern verknüpft, so gibt es keine Notwendigkeit zu erklären, ein Objekt static const.

    Ebenfalls nach Anhang D. 2

    Die Verwendung des static-Schlüsselwort ist
    veraltet bei der Deklaration der Objekte in
    namespace-Gültigkeitsbereich (siehe 3.3.5).

    Bezüglich der statischen Initialisierung Fiasko:

    Da die Variablen sind definiert in der header-Datei werden Sie immer definiert werden, bevor irgendeine andere statische Objekte, die Sie verwenden.

    Aus Abschnitt 3.6.2.1:

    Objekte mit statischer Speicherdauer
    definiert im namespace-Gültigkeitsbereich in der gleichen
    übersetzung Einheit und dynamisch
    initialisiert wird initialisiert
    die Reihenfolge, in der Ihre definition
    erscheint in der übersetzung Einheit.

    Antwort 1: Dies bedeutet vorbei der Variablen zu einem statischen Objekt constuctor sollte in Ordnung sein.

    Antwort 2: Jedoch ein problem auftreten könnte, wenn die Variablen verwiesen wird, die von einer nicht-inline-Konstruktor, der ein statisches Objekt:

    Weder in Abschnitt 3.6.2.1 noch 3.6.2.3 ist es angegeben, in welcher Reihenfolge die statischen Objekte in verschiedenen compilation units initialisiert wenn dynamische Initialisierung abgeschlossen ist, bevor die erste Anweisung des main.

    Folgendes:

    //consts.h
#include <string>

const std::string string1 = "ham";
const std::string string2 = "cheese";

//myclass.h
#include <string>

class MyClass
{
public:
    MyClass();
    MyClass(std::string str);
    std::string Get() { return memberString; }
private:
    std::string memberString;
}

//myclass.cpp
#include "consts.h"
#include "myclass.h"

MyClass::MyClass() : memberString(string1) {}

MyClass::MyClass(std::string str) : memberString(str) {}

//main.cpp
#include <iostream>
#include "consts.h"
#include "myclass.h"

MyClass myObject1;
MyClass myObject2(string2);

using namespace std;

int main()
{
    cout << myObject1.Get(); //might not print "ham"
    cout << myObject2.Get(); //will always print "cheese"
}

    Seit myclass.cpp hat seine eigene Kopie der const Variablen, könnten diese nicht initialisiert, wenn MyClass::MyClass() genannt wird.

    Also ja, const definierten Variablen in header-Dateien können in einer Weise verwendet werden, die anfällig für die statische Initialisierung Fiasko

    Soweit ich sehen kann, gilt dies nur für Variablen, die nicht erfordern, statische Initialisierung:

    Aus C++03-standard, Abschnitt 3.6.2.1:

    Objekte von POD-Typen (3.9) mit statischer
    Lagerung Dauer initialisiert mit
    Konstante Ausdrücke (5.19) gilt
    initialisiert ist, bevor alle dynamischen
    Initialisierung stattfindet.

    InformationsquelleAutor Hanno S.

  3. 8

    Was bezeichnet wird als die statische Initialisierung Fiasko ist ein problem, wenn ein namespace-level-Variablen ist abhängig vom Wert zugewiesen zu einem anderen namespace-Ebene-variable, die kann oder nicht initialisiert werden, bevor. In deinen beiden Beispielen gibt es keine solche Abhängigkeit, und es sollte kein problem sein.

    Diese, auf der anderen Seite, ist anfällig für diese Art von Fehler:

    //header.h
extern const std::string foo;

//constant.cpp
const std::string foo( "foo" );

//main.cpp
#include "header.h"
const std::string foobar( foo+"bar" );
int main() {
   std::cout << foobar << std::endl;
}

    Gibt es keine Garantie, dass foo wird initialisiert werden, bevor foobar, auch wenn beide konstant sind. Das bedeutet, dass das Verhalten des Programms ist undefiniert, und es könnte durchaus print "foobar", "bar" oder sterben.

    Ich aktualisierte mein use-case in der original-Frage. Dies ist genau das Szenario, das ich wissen wollen.
    Ich würde es nicht Wagen, zu äußern. Mein Erster Gedanke ist, dass es in Ordnung sein sollte (die Konstante ist lokal für die übersetzungseinheit definiert wird, bevor die zweite Konstante), würde ich aber wenn möglich vermeiden, dass konstruieren. Der einfachste Weg den ich kenne um sicher zu sein, wäre mit einer Funktion mit einer static-variable intern statt der globalen var: inline myclass& global_object() { myclass instance; return instance; } Die Sprache garantiert, dass instance wird vollständig initialisiert ist, beim ersten Aufruf der Funktion, so std::string other( global_object().Get() ); wird sicherlich funktionieren...
    Jedenfalls würde ich wirklich versuchen Sie zu vermeiden, Sie ganz zu beseitigen und die namespace-Ebene-Variablen mit Ihrer Initialisierung. Initialisierung der namespace-Ebene-Variablen ist nicht trivial, es geschieht in zwei Durchgängen, wo alle globals, die instanziiert werden aus Konstanten Ihre Werte zuerst, und dann in einem zweiten Durchlauf alles, was ist, ist abhängig von nicht-Konstanten initialisiert werden entsprechend der Reihenfolge der definition (innerhalb der gleichen übersetzungseinheit), in einer unbestimmten Reihenfolge, wenn mehr als eine übersetzungseinheit verbunden ist, die in ein Programm.
    Separate Zusammenstellung ist wahrscheinlich der Schuldige. In Python geben, die Sie haben zu zählen und die Dinge sind exakt ausgeführt, wie Sie interpretiert werden. Sie kann sich nur auf etwas, das bereits definiert wurde. In Java-erstellen Sie eine source-Datei für die generierten .Klasse, und wieder das stellt eine klare Hierarchie für die Objekt-Dateien. In C oder C++ Sie erstellen separate übersetzungseinheiten gegen Erklärungen, der linker nicht weiß, wie zu bestellen, diese. Nicht zu erwähnen, dass es eventuell nicht in Ordnung ist, können Sie (auch wenn Sie nicht sollte) haben zyklische Abhängigkeiten zwischen TUs
    das ist schwer zu sagen... wie? Module, glaube ich, wird dazu beitragen, in diese Richtung, aber Sie haben zu bauen, in einem völlig anderen Modus, hemmt zirkuläre Abhängigkeiten (z.B. Kopf-vs. implementation-Dateien) und haben einen Mechanismus, um zu verfolgen, welche hängt davon ab, was sonst. Module sind in dieser Linie, aber Sie nicht blockieren Sie das Problem, und Sie haben zu Leben, wie es für die Abwärtskompatibilität. C++ ist fast voll abwärtskompatibel, das ist eines der zentralen Kriterien in der standard committee. Jede wichtige änderung ist sorgfältig gewichtet: wie viele Menschen betroffen sein werden, und was die Lösung ist

    InformationsquelleAutor David Rodríguez - dribeas

  4. 2

    Statische Initialisierung Fiasko bezieht sich auf statische Variablen, die abhängen jeder andere. Lediglich die Definition einiger static const Variablen nicht eine Quelle von Problemen sein.

    InformationsquelleAutor Puppy

Schreibe einen Kommentar