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?

...Daher tendiere ich gerade es konsistent wie im zweiten 'Fall' umzusetzen.

Ich tendiere unter C++ inzwischen zum 3ten Fall: <Typ> <Zeichen> <Bezeichnung>

1. Deklariere ich ohnehin niemals mehrere Variablen in einer Zeile.
2. Spätestens wenn const hinzu kommt gibt es ohnehin wieder Abstände (Zumindest wenn man das const wie ich [Auch wieder nur in C++] immer konsequent hinter das schreibt, was konstant ist).

Beispiel:

int const * const wert;

In welche Richtung willst du nun das Zeichen packen?

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?

Aus genau diesem Grund mache ich das auch so.
char *s bedeutet nicht "s ist ein char pointer" sondern "der Wert von s (dereferenziert) ist ein char".

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

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.

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;

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.

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.

Generell würde ich das aber als Geschmacksfrage beschreiben.

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.

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.

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

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);

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.

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.

T const * const foo;

foo ist ein konstanter Zeiger auf ein konstantes T.

Deshalb schreibe ich es auch so.

const * const T foo;

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

Bei mir säh ein Pointer so aus:

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

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).

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.

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.

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

Mehrfachdeklarationen in einer Zeile (Funktionsparameter) sind quasi unvermeidbar. Wenn es logisch passt finde ich das sogar empfehlenswert, z.B. iter begin, end;

camper schrieb:

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

Mehrfachdeklarationen in einer Zeile (Funktionsparameter) sind quasi unvermeidbar. Wenn es logisch passt finde ich das sogar empfehlenswert, z.B. iter begin, end;

mehrfachdeklarationen in einer zeile bei funktionsargumenten und bei der definition von variablen haben nicht die selbe syntax...

int* a, * b;
void f(int* a, int* b) {}

camper schrieb:

denn der Lesefluss bleibt ja weiterhin rechts-nach-links, oben-nach-unten.

Editiere dies mal, denn du meinst ja "links-nach-rechts"