Member const vs. non-const

15/04/2016 - 17:49 von Stefan Reuther | Report spam
Hallo,

wenn ich eine Klasse mit public-Member habe
class foo {
public:
std::string s;
};
ist der automatisch const, wenn ich ein 'const foo&' habe.

Nun soll der Member über eine Funktion bereitgestellt werden, aus Stil-
("keine public-Member") oder anderen Gründen (z.B. bei der
Bereitstellung noch irgendwas machen), und die gleiche Semantik haben:
const, wenn das enthaltende Objekt const ist. Dazu muss ich die
entsprechenden Funktionen aber immer zweimal schreiben.
class foo {
public:
std::string& getS() { return s; }
const std::string& getS() const { return s; }
private:
std::string s;
};

Wenn man mehrere solcher Member hat artet das langsam in Arbeit aus, und
von 'volatile' hab ich noch gar nicht angefangen.

Gibt es einen Trick, den ich übersehe?


Stefan
 

Lesen sie die antworten

#1 ram
16/04/2016 - 02:03 | Warnen spam
Stefan Reuther writes:
Gibt es einen Trick, den ich übersehe?



Du meinst den Pràprozessor, also statt

std::string& getS() { return s; }
const std::string& getS() const { return s; }

zu schreiben:

DECLARE_GETTER(std::string& getS(),{ return s; })

? Wahrscheinlich ist das dann auch »schlechter Stil«!
Und es muß auch noch etwas komplizierter werden, sobald
die Pràprozessorargumente selber Kommas enthalten können:

#define PREAMBLE std::string& getS()
#define BODY { return s; }
DECLARE_GETTER
#undef BODY
#undef PREAMBLE

Allerdings gelange ich immer mehr zu der Überzeugung, daß
alle öffentlichen Funktionen ohne Doxygen-Dokumentation
auch schlechter Stil sind. Ohne Dokumentation hat man
meiner Meinung nach nàmlich gar keine Kapselung, weil die
Funktionen keine Semantik haben. Dann sind eigentlich sogar
öffentliche Felder besser, weil die wenigstens eine Semantik
haben (von der Programmiersprache her).

Insofern wàre dies eine Verbesserungsmöglichkeit.

(Leider genüge ich aber meinen eigenen Maßstàben auch nicht
und schreibe derzeit noch viele Funktionen ohne Doxymentation.)

Ähnliche fragen