const vs nicht konstanten des Behälters und dessen Inhalts

Question

mit einem Behälterklasse wie std::vector, gibt es zwei unterschiedliche Konzepte der Konstantheit: die des Behälters (d.h. seine Größe), und dass die Elemente. Es scheint, dass std::vector diese beiden verwirrt, so dass die folgenden einfachen Code wird nicht kompiliert:

struct A { 
    A(size_t n) : X(n) {} 
    int&x(int i) const { return X[i]; } // error: X[i] is non-const. 
private: 
    std::vector<int> X; 
}; 

Beachten Sie, dass, obwohl die Datenelemente (die drei Zeiger auf das & Ende der Daten beginnen und Ende der zugewiesenen Puffers) von std::vector sindnicht durch einen Aufruf an seinen operator[] geändert, ist dieses Mitglied const nicht - ist das nicht ein seltsames Design?

Beachten Sie auch, dass für Roh-Zeigern, diese beiden Konzepte von konstant-ness sind fein säuberlich getrennt, so dass die entsprechenden Roh-Zeiger Code

struct B { 
    B(size_t n) : X(new int[n]) {} 
    ~B() { delete[] X; } 
    void resize(size_t n);     // non-const 
    int&x(int i) const { return X[i]; } // fine 
private: 
    int*X; 
}; 

funktioniert gut.

Also, was ist der richtige/empfohlene Weg, um dies zu behandeln, wenn std::vector (ohne mutable) verwendet wird?

Ist ein const_cast<> wie in

int&A::x(int i) const { return const_cast<std::vector<int>&>(X)[i]; } 

als akzeptabel erachtet (X bekannt ist, nicht const, so dass kein UB hier)?

EDIT nur weitere Verwirrung zu vermeiden: ich die Elemente ändern will, das heißt den Inhalt des Behälters, aber nicht der Behälter selbst (die Größe und/oder Speicherplatz).

Answer 1

C++ unterstützt nur eine Ebene von const. Soweit der Compiler betrifft, so ist es bitweise const: die „Bits“ tatsächlich in der Objekt (dh in sizeof gezählt) kann nicht ohne Spielen geändert werden (const_cast, etc.), aber alles andere ist fair Spiel . In den frühen Tagen von C++ (Ende der 1980er, Anfang der 1990er Jahre) gab es eine Menge Diskussion über die Designvorteile von bitweisem const vs. logischem const (auch bekannt als Humpty-Dumpty const, weil, wie Andy Koenig einmal sagte , wenn der Programmierer const verwendet, bedeutet es genau, was der Programmierer will, dass es bedeutet). Der Konsens verschmolz schließlich zugunsten von logischem const.

Dies bedeutet, dass Autoren von Container-Klassen eine Wahl haben müssen. Sind die Elemente des Containerteils des Containers, oder nicht. Wenn sie Teil des Containers sind, können sie nicht geändert werden, wenn der Container const ist. Es gibt keine Möglichkeit, eine Auswahl anzubieten; der Autor des Containers muss einen oder den anderen wählen. Auch hier scheint es einen Konsens zu geben: Die Elemente sind Teil des Containers, und wenn der Container const ist, können sie nicht geändert werden. (Vielleicht ist die parallel mit C-Stil-Arrays spielte hier eine Rolle, wenn eine C-Stil-Array const ist, dann kann man nichts von seinen Elementen ändern.)

Wie Sie, ich habe mal begegnet, wenn ich verbieten wollte Änderung der Größe des Vektors (vielleicht Iteratoren zu schützen), aber nicht seiner Elemente. Es gibt keine wirklich zufriedenstellende Lösungen; das beste, was ich mir vorstellen kann, ist einen neuen Typ zu erstellen, der eine mutable std::vector enthält, und Weiterleitungsfunktionen, die der Bedeutung von const ich in diesem speziellen Fall entsprechen. Und wenn Sie drei Ebenen unterscheiden möchten (vollständig const, teilweise const und nicht-const), Sie Ableitung benötigen. Die Basisklasse exponiert nur die vollständig const und teilweise const Funktionen (z. B. eine const int operator[](size_t index) const; und int operator[]( size_t index);, aber nicht void push_back(int);); Die Funktionen, die das Einfügen und Entfernen eines Elements ermöglichen, sind nur in der abgeleiteten Klasse ausgesetzt. Clients, die keine Elemente einfügen oder entfernen sollen, erhalten nur einen nichtkonstanten Verweis an die Basisklasse.

Answer 2

Es ist nicht eine seltsame Design, es ist eine sehr bewusste Entscheidung, und die richtige IMHO.

struct C { 
    int& get(int i) const { return X[i]; } 
    int X[N]; 
}; 

aber mit dem sehr nützlichen Unterschied, dass die Anordnung der Größe verändert werden kann:

Ihr B Beispiel für ein std::vector keine gute Analogie ist, wäre eine bessere Analogie sein. Der obige Code ist ungültig aus dem gleichen Grunde wie das Original ist, das Array (oder vector) Elemente sind vom Konzept „Mitglieder“ (technisch Unterobjekte) des enthaltenden Typs, so dass Sie nicht in der Lage sein sollten, sie durch ein const Mitglied zu ändern Funktion.

Ich würde sagen, die const_cast ist nicht akzeptabel, und keiner verwendet mutable, es sei denn als letztes Mittel. Sie sollten fragen, warum Sie die Daten eines const-Objekts ändern möchten, und in Betracht ziehen, die Elementfunktion nicht-const zu machen.

Answer 3

Leider anders als Zeiger, können Sie so etwas wie

std::vector<int> i; 
std::vector<const int>& ref = i; 

nicht tun, deshalb, std::vector kann nicht zwischen den beiden Arten von const disambiguate wie sie angewendet werden könnte, und es hat konservativ.Ich persönlich würde, wählen Sie so etwas wie

const_cast<int&>(X[i]); 

bearbeiten tun: Wie ein anderer Kommentator genau darauf hingewiesen, Iteratoren tun Modell diese Dichotomie. Wenn Sie eine vector<int>::iterator an den Anfang gespeichert haben, können Sie sie in einer const-Methode de-referenzieren und eine nicht-const int& zurückgeben. Ich denke. Aber Sie müssen auf die Ungültigkeit achten.

Answer 4

Ich würde vorschlagen, std::vector::at() Methode anstelle einer const_cast.