PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Frage zur const correctness



totycro
16-07-2007, 12:17
Die Frage ist eher allgemein:

Ich habe eine Klasse, die im Prinzip ein Interface zur Kommunikation mit einem anderen Programm darstellt.
Da gibt es natürlich get-Methoden, die eigentlich nur Daten abfragen, also const sein sollten. Diese Methoden müssen aber auch überprüfen, ob die Verbindung mit dem Programm funktioniert, und sollte das nicht der Fall sein, neu verbinden.
Das Verbindungshandle ist ein Member der Klasse, und weil es beim Verbinden verändert wird, kann die Methode verbinden() nicht const sein. Folglich darf die get-Methode nicht const sein, weil sie sonst die nicht-const Methode verbinden() nicht aufrufen dürfte.

Ich habe das jetzt so gelöst, dass verbinden() auch const ist. Damit das kompiliert, habe ich das Verbindungshandle einfach als mutable deklariert.

Gibt es da nicht eine bessere Möglichkeit?

panzi
17-07-2007, 02:40
Ich weiß nicht ob die Lösung "besser" ist, aber ich glaube so ähnlich wird das in std::string::c_str gemacht:
Die Methode const machen und das handle innen (das ja dadurch als member eines const Objectes auch const ist) einfach in der verwendung casten. Also das const wegcasten. z.B. mit const_cast:


class A {
private:
int x;

public:
void y() const {
int *ptr = const_cast<int*>(&x);
*ptr = ...;
}
};

Ist zwar messy aber es sollte gehn.


PS: Warum macht std::string::c_str u.U sowas? Weil der String in C++ u.U. als Char-Array + Size implementiert ist ohne der abschließenden \0. Aber ein C-String braucht ein NIL am Ende, also fügt diese eigentlich konstante Methode noch ein \0 am Ende ein und gibt das (als const char*) zurück. Aber das liegt daran wie das in der jeweiligen Implementierung der STL gemacht ist.

totycro
17-07-2007, 11:11
Danke für deine Antwort.

Wenn das auch in der STL so gemacht wird, dann gibt es wohl keine bessere Lösung, also werd ich mich daran halten.

panzi
18-07-2007, 13:21
Danke für deine Antwort.

Wenn das auch in der STL so gemacht wird, dann gibt es wohl keine bessere Lösung, also werd ich mich daran halten.
Naja, in manchen STL implementierungen. In anderen hat auch der c++ string ein NIL am Ende und somit ist das nicht notwendig.