Stilfrage: T& a oder T &a

[volkard]

Tomahawk schrieb:

Wie der Titel schon sagt, eine kleine Stilfrage. Bisher haben wir meist im Stil

T& a oder char buffer* geschrieben. Allerdings würde folgendes natürlich so nicht funktionieren:

const char m_token_begin, m_token_end, m_end;*

Stattdessen muss es heissen:

*const char *m_token_begin, *m_token_end, m_end;

Daher tendiere ich gerade es konsistent wie im zweiten 'Fall' umzusetzen. Also '&' oder '*' an das Objekt, bzw. die Variable zu binden und nicht an den Typ. Wie sind eure Meinungen dazu?

Ja, das war die Regel in C.
Da schrieb man
int a,b, c[5], *d;
als erste Zeile und dann gibgs los…

Ind C++ definiert man eine Variable eigentlich erst, wenn man sie sinnvoll initialisieren kann, und dann bekommt auch jede Variable ihre eigene Zeile. Daher können wir es uns leiten, Typen wie int* oder int& zu denken.

[Tomahawk]

Danke für die Meinungen.

Wahrscheinlich ist es lesbarer für jedes Objekt bzw. jede Variable eine eigene Zeile anzulegen, um genannter Problematik zu entgehen:

private:
  const char* m_token_begin;
  const char* m_token_end;
  const char* m_end;

[out]

nwp3 schrieb:

Wo ich gerade bei nutzloser Semantiknerverei bin: In C++ gibt es nur call by value. Call by reference gibts weder in C noch in C++ noch in Java.

void foo(int *i); //ein Pointer auf ein int wird per value übergeben
void foo(int &i); //eine Referenz auf ein int wird per value übergeben

Jetzt ist die ganze Welt verwirrt.

[asc]

nwp3 schrieb:

Wo ich gerade bei nutzloser Semantiknerverei bin: In C++ gibt es nur call by value. Call by reference gibts weder in C noch in C++ noch in Java.

Nenne es wie du willst, aber bitte verwirre andere nicht damit. Es wird nun einmal in 90+% aller Quellen anders genannt, und die andere Benennung ergibt durchaus Sinn um die Unterschiede zu beschreiben.

[Marthog]

Ich habe mir die Frage auch schon gestellt und es gibt bei allem irgendwelchen Probleme.
Letztendlich bin ich aber zu T& a übergegangen, weil das Referenzzeichen ja zum Typ gehört und nicht zum Namen.

Generell würde ich das aber als Geschmacksfrage beschreiben.

[five star programmer]

Ich bin mittlerweile dazu übergegangen, immer T&/T* zu verwenden, wenn nur eine Variable diesen Typ bekommt (also auch in Parametern, die sind meistens nicht auf einer einzelnen Zeile).

volkard schrieb:

Ind C++ definiert man eine Variable eigentlich erst, wenn man sie sinnvoll initialisieren kann

Es gibt die genannte Ausnahme, wenn man die Membervariablen einer Struktur deklariert:

private:
  const char *token_begin, *token_end, *end;

Dann mache ich den Stern zum Namen. Allerdings immer nur ein Typ pro Zeile, nie Pointer und Nicht-Pointer gemischt.

Btw: Ich ziehe "T const&" der Schreibweise "const T&" vor, weil T ist eine const-referenz und T const& ist besser zu lesen (wichtiges zuerst), schreiben und aussprechen.

[Shade Of Mine]

five star programmer schrieb:

Es gibt die genannte Ausnahme, wenn man die Membervariablen einer Struktur deklariert:

private:
  const char *token_begin, *token_end, *end;

Dann mache ich den Stern zum Namen. Allerdings immer nur ein Typ pro Zeile, nie Pointer und Nicht-Pointer gemischt.

Ich mache eine Variable pro Zeile - ist viel besser lesbar. und wenn man einen kommentar zu einer variablen packen will ists auch einfacher dann. oder die commits bei code änderungen an der klasse - ich muss keine zeile mit 10 variablen anpassen und dann funktionieren die blames wieder nicht gut genug. ne ne. 1 zeile pro variable ist besser.

Btw: Ich ziehe "T const&" der Schreibweise "const T&" vor, weil T ist eine const-referenz und T const& ist besser zu lesen (wichtiges zuerst), schreiben und aussprechen.

dem stimme ich hingegen voll zu.

[hustbaer]

Tomahawk schrieb:

private:
  const char* m_token_begin;
  const char* m_token_end;
  const char* m_end;

+1

Nur dass du das const auf der falschen Seite von char stehen hast

[TyRoXx]

Wenn man mal den Namen weglässt, sieht eine der beiden Varianten unnötig gequetscht aus:

void (int&, std::string*)

void (int &, std::string *)

Gerade als Template-Argument geht ein kleines & oder ein * unter, wenn kein Leerzeichen davor steht.
Bei g finde ich die linke Seite durch den langen Typ sehr unübersichtlich. Für das Sternchen am Ende des Typs muss ich zweimal hinsehen. Wenn es jedoch rechts vom Leerzeichen direkt am Namen steht, sehe ich es sofort.

void g(std::vector<int*>::iterator* it);

void g(std::vector<int *>::iterator *it);

[theliquidwave]

Gutes Argument, TyRoXx. Stimme dir zu. War mir vorher noch gar nicht so bewusst, das mit dem Auffallen.

[*rant*]

T *foo

Begründung für mich:

T* foo, bar;
static_assert(std::is_same<decltype(foo), decltype(bar)>::value, "Nope");

*, &, && (und bei C++/CLI ^ und gehören zum Namen, nicht zum Typen.

[camper]

TyRoXx schrieb:

Wenn man mal den Namen weglässt, sieht eine der beiden Varianten unnötig gequetscht aus:

void (int&, std::string*)

void (int &, std::string *)

Gerade als Template-Argument geht ein kleines & oder ein * unter, wenn kein Leerzeichen davor steht.
Bei g finde ich die linke Seite durch den langen Typ sehr unübersichtlich. Für das Sternchen am Ende des Typs muss ich zweimal hinsehen. Wenn es jedoch rechts vom Leerzeichen direkt am Namen steht, sehe ich es sofort.

void g(std::vector<int*>::iterator* it);

void g(std::vector<int *>::iterator *it);

verstehe das Argument nicht

void g(std::vector<int *>::iterator *it)
//                   ^ das ist das Templateargument, ein Name folgt nicht

void g(std::vector<int *>::iterator *it)
//                                   ^  das ist ein Name, aber der Teil davor kein Templateargument

/rant/ schrieb:

T *foo

Begründung für mich:

T* foo, bar;
static_assert(std::is_same<decltype(foo), decltype(bar)>::value, "Nope");

*, &, && (und bei C++/CLI ^ und gehören zum Namen, nicht zum Typen.

petitio principii

...Und natürlich gehört const vor den Typ (wo möglich), denn das ist die natürliche Reihenfolge in der Sprache (English), aus der diese Wörter stammen.

[Nathan]

Mit const stimm ich camper zu. Blöd nur, dass das bei Pointern ungedrejt ist.
Bei mir säh ein Pointer so aus:
const * const T foo;
Heißt das was man liest: konstanter Pointer auf konstantes T.
Was T& angeht, hab ich mich noch nicht entschieden, verwend es mal so, mal so.

[Caligulaminus]

Typdeklarationen liest man von rechts nach links (und von innen nach außen).

T const * const foo;

foo ist ein konstanter Zeiger auf ein konstantes T.

Deshalb schreibe ich es auch so.

[dot]

Nathan schrieb:

const * const T foo;

Das ist kein gültiges C++...

[Caligulaminus]

Nathan schrieb:

Bei mir säh ein Pointer so aus:

Die Aussage war doch klar:
Wenn es nach Nathan ginge, wär's gültig.

[Nathan]

Danke, dot, aber ich glaub ich weiß wie man Pointer deklariert.
Man schreibt dazu ein & hinter den Typen.

[not smart]

mein stil:

T const& d;
T& d;
const T d;

für mich gehören referenzen usw einfach zum typen (mehrere definitionen in einer zeile sind sowieso das unleserlichste was ich mir vorstellen kann, mach ich nie).

[camper]

Caligulaminus schrieb:

Typdeklarationen liest man von rechts nach links (und von innen nach außen).

T const * const foo;

foo ist ein konstanter Zeiger auf ein konstantes T.

Deshalb schreibe ich es auch so.

Das zäumt das Pferd von hinten auf. rechts-nach-links ist lediglich, wie die Deklaration interpretiert wird (auch nur als Faustregel, weil es uns so schwer fällt echt rekursiv zu denken). Gelesen wird nat. trotzdem von links nach rechts (schließlich muss Anfang und Ende erfasst werden), denn der Lesefluss bleibt ja weiterhin rechts-nach-links, oben-nach-unten. Ich kann nicht nachvollziehen, dass diese Umkehrung als natürlich oder einfach empfunden wird. Gewöhnen kann man sich selbstverständlich daran.
Eine Variablendefinition benötigt einen 1. Typ, 2. einen Bezeichner, und 3. einen Initialisierer. Deklaratoren an den Namen anzuflanschen, vermischt 1. und 2. und direkte Initialisierung mittels () oder {} hebt auch noch die Trennung zu 3. auf - was zu zusätzlicher mentaler Arbeit führt, weil diese Teil nicht mehr klar optisch getrennt sind. Von der Tatsache, dass uns die Syntax Fälle aufzwingt, in denen diese Vermischung nicht (einfach) vermieden werden kann, führt allerdings keine Schlussregel, die bestimmt, dass dann auch in allen anderen Fällen so vorgegangen werden sollte.

Mehrfachdefinitionen in einer Zeile sind $\sqrt{\forall evil}$

Antwort an TE: mach, was du willst (ausser Bekehrungsversuchen), nur einheitlich.

[Caligulaminus]

camper schrieb:

Ich kann nicht nachvollziehen, dass diese Umkehrung als natürlich oder einfach empfunden wird.

C++ ist nicht natürlich, ist technisch. Technik ist künstlich - Kunst.
Ich lese Typdeklarationen von rechts nach links. Das mußte ich mir angewöhnen. Daß ich es akzeptiert und verinnerlicht habe, hat mein Programmierer-Dasein spürbar vereinfacht.