Klassenpräfixe
-
@Thanatos
Mit der Form der zitierten Aussage von Shade gewinnt man sicher keinen Oscar, da sind wir uns einig. Und auch der Inhalt ist zwar extrem reduziert, bleibt auf der anderen Seite aber letztlich noch korrekt.
Das Ganze zeigt imo ein generelles Problem in Foren: Entweder du diskutierst bestimmte Themen jedes Mal von vorne neu oder du schreibst bei der siebenhundertsten Wiederholung auch mal einen kurzen provokativen Satz der ein Wort wie 'Käse' oder 'Mies' enthält (am Besten mit einem zusätzlichen Link auf eine alte Diskussion). Immer mit der Hoffnung, dass neue Leser sich danach selbst ein wenig schlau machen bzw. an bestimmten Punkten einfach nachfragen.
-
Spricht eigentlich auch was gegen ein "m_" vor Membervariablen von Klassen?
-
Man nimmt ein _ als Suffix.
beispiel_;
-
C++ Guru schrieb:
Man nimmt ein _ als Suffix.
beispiel_;
Und warum nicht "m_" als präfix?
Das klingt so schön nach member
-
godlikebot schrieb:
Spricht eigentlich auch was gegen ein "m_" vor Membervariablen von Klassen?
Naja, beim Programmieren ist das im Regelfall unangenehmer als ein _ am Ende, von wegen Code Completion und so...
-
Andererseits finde ich "bla_->" und "bla_." immer recht hässlich.
Was man hier als Markierung nimmt (oder ob man überhaupt eine nimmt), ist wohl Geschmackssache. Zumindest kann ich mich nicht an eine überwältigende Argumentation für eine Variante erinnern. Ich war mit allem eigentlich gleich zufrieden
-
Ich hab mir mMembervariable angewöhnt, das ist übersichtlich und kann man schön schnell tippen.
-
operator void schrieb:
Was man hier als Markierung nimmt (oder ob man überhaupt eine nimmt), ist wohl Geschmackssache.
Wobei das "was" imo deutlich mehr Geschmacksache ist als das "ob". Das "ob" sollte man imo zumindest deutlich intensiver diskutieren.
Was man am Ende dann für eine Markierung nimmt spielt eine untergeordnete Rolle.
-
Ne, man macht sa so:
class MyClass { struct M { Foo foo; } m; void foo (Foo value) { m.foo = value; } ... };
-
godlikebot schrieb:
Spricht eigentlich auch was gegen ein "m_" vor Membervariablen von Klassen?
Spricht eigentlich was dafür?? Das sind doch die selben fadenscheinigen Gründe wie für CAuto.
-
Wenn man seine Funktionen lieber size() als getSize() nennt, spricht schon mal eine ganze Menge dafür - allerdings wird mich die Verben-Fraktion dafür gleich toasten.
Ansonsten muss man entscheiden, ob man lieber this-> nimmt, wenn man eine Kollision mit einem Parameter hat, oder konsequent ein Präfix/Postfix tippt.
-
operator void schrieb:
Ansonsten muss man entscheiden, ob man lieber this-> nimmt, wenn man eine Kollision mit einem Parameter hat, oder konsequent ein Präfix/Postfix tippt.
membervariablen werden bei mir immer am anfang klein geschrieben, parameter immer groß(inklusive template parameter),damit erspar ich mir jegliches unschönes this->
-
Kollision mit Parameter gibt es bei mir eigentlich so gut wie nie. Ich verwende meistens die Initialisierliste und das macht er dann wunderbar.
ClassName(int size) : size(size) {}
Und bei setter-Methoden heißen die Parameter dann meistens irgendwie newSize oder so.
-
otze schrieb:
membervariablen werden bei mir immer am anfang klein geschrieben, parameter immer groß(inklusive template parameter),damit erspar ich mir jegliches unschönes this->
Damit hast du für Parameter und Typen aber die selbe Konvention, für Parameter und Variablen (dje ja im Prinzip das Gleiche sind) nicht mehr. Das verwirrt zumindest dann, wenn man GroßeKlassen undKleinenRest gewöhnt ist. Und man hat wieder das lustige Problem:
void flipMap(Map& Map); // Juhu!
Da kann man dann entweder den Parameter bei Bedarf doch präfixen oder anfangen, sich Synonyme auszudenken. Und gerade Letzteres macht einfach keinen Spaß, auch wenn es auf den ersten Blick lesbar und natürlich aussieht.
-
void flipMap(Map& Map);
damit hab ich keine probleme
-
du magst ja anscheinend auch ekelhaften code.
-
so meinte ich das nicht, sondern nur compiletechnisch
btw:registrier dich,dann kann ich dich ernstnehmen
-
void flipMap(Map& Map);
Da drückt der Compiler noch ein Auge zu bei:
template<class Map> void flipMap(Map& Map){ }
Hat er aber so seine Probleme.
-
otze schrieb:
void flipMap(Map& Map);
damit hab ich keine probleme
Wie umgehst du es?
-
atm umgehe ich es über typedefs,da ich im moment viel mit containern arbeite,und da eh nen typedef auf value_type brauch(und dann hat sich das problem mit Map& Map, selbst wenn der templateparameter immernoch Map ist,ich hab mit der typedef definiert, dass ich intern und extern nur value_type verwende,und damit ist der Code eindeutig)
an anderer Stelle hat sich für mich bisher noch nie das Problem gestellt,da ich eh andere Namen vergeben musste
@irgendwer bei mir compilierts ohne probleme^^