C++ Gurus

[Shade Of Mine]

mantiz schrieb:

Dafür bin ja dann nicht ich zuständig, sondern der Entwickler der Funktion MoveWindow. Wobei hier im Header soweit ich weiß sogar steht: bRepaint, was die IDE ja dann auch anzeigen sollte, also ist alles klar.

Ist mir klar, aber es ist wieder so ein schöner Punkt wo man etwas mehr lesbarkeit hätte einbauen können. Du kannst daran nichts ändern, das ist klar.

wobei das hier aber eher unnötig ist ein tmp-Objekt zu erzeugen, denke ich. Zum Speichern kann man die Werte ja dann ruhig in ein struct packen.

Du hast 0 overhead, sparst dir aber arbeit wenn du die Werte auch speichern statt nur weiterreichen willst. Ist ausserdem praktischer nur ein objekt rumzureichen - denn die 4 werte gehören ja sowieso zusammen und haben getrennt keinen Sinn.

Wenn nur iteratoren Sinn machen, wieso sollte man das dann nicht erzwingen?
Von mir aus auch in der Art, wenn das möglich ist:

template<typename T1, typename T2>
T1::iterator copy(T2::iterator Start, T2::iterator End, T1::iterator Target);

Nein, um Stroustrup frei zu zitieren "iterator ist, was sich wie ein iterator verhält" - ein char* kann ein iterator auf einen array of char sein.

Wieder Frieden?

NEEEIIINNNN!!!!! Ihc werte dihc n00b pwnen!!!111eins

:p

[c++ guru]

[cpp]void moveResized(const Rectangle**&** rect)[/cpp]

die cpp tags sind kaputt

[finix]

Shade Of Mine schrieb:

Es gibt kein aussen und innen.

Doch, es gibt den Templatecode an sich und den Clientcode. Du hast im Clientcode nirgendwo die "kryptischen" Bezeichner welche du monierst.
Und innerhalb des Templatecodes ist, allein vom Kontext her, offensichtlich was wofür steht.
In deinen folgenden Beispielen hast du Recht, da gilt es sinnvolle Bezeichner zu finden, aber das habe ich (und wohl auch sonst niemand) bestritten.
Wie PAD gesagt hat, soviel wie nötig, aber auch nicht mehr.

Wie sieht's denn hiermit aus:

template <typename T>
class Array
{ /* ... */ };

template <typename T>
void swap( T& t1, T& t2 )
{ /* ... */ };

Was wären denn hier z.B. sinnvolle Bezeichner? Wenn T so ungewöhnlich wäre könnte man vielleicht für Type plädieren, aber sonst?

Shade Of Mine schrieb:

Nur weil eine Methode private ist, nennen wir sie doch nicht p1 wenn ein stripInvalidSymbols() viel passender wäre, oder?

Wie nennen wir denn unsere Member Variablen?
m1, m2?
Nein, wir nennen sie value, size, speed, fuel,...

Du vergleichst noch immer Äpfel mit Birnen. Siehe oben (& vorige Posts).
Sah dein erstes Beispiel wirklich so aus:

template <typename T>
class V
{
  T v;
};

// oder doch eher wie folgt, mit sinnvollen Bezeichnern?

template <typename V>
class Value
{
  V value;
};

Shade Of Mine schrieb:

Natürlich ist der Template-Type ein Platzhalter für 'etwas'. Aber dieses 'etwas' hat ja bestimmte Beschränkungen oder einen bestimmten Nutzen/Verwendungszweck.

Siehe oben. Wenn es sinnvolle Bezeichner gibt spricht alles dafür sie auch zu verwenden.

Shade Of Mine schrieb:

Das mit dem ValueType ist wie volkard schon gesagt hat, suboptimal.

Ich finde es eigentlich ganz nett ein Uppercase-T anzuhängen. Nicht optimal aber auch nicht schlimmer als ohne.

Shade Of Mine schrieb:

Nehmen wir nochmal das schöne copy Beispiel (dass ihr so gerne ignoriert):

Beim copy Beispiel macht es durchaus Sinn, ja.

Shade Of Mine schrieb:

Bei Schleifen: i, j, k, l sind (wie ich schon so oft gesagt habe) standardisierte Namen in einem engen eingeschränkten Kontext. Ein i muss immer zu einer Zählschleife gehören. Ein T muss aber nur ein Typ sein. Das ist doch etwas vage... Zumal A und C auch Typen sind, aber welche Rolle spielen sie? Keine Ahnung.

Wieso ist die i, j Konvention 'Ok'? Wäre ein aussagekräftiger Name nicht viel sinnvoller? (Ich z.B. würde bei einer Tabelle/Matrix o.ä. immer row & col den Vorzug geben, und solche Beispiele lassen sich nicht für die meisten, aber doch recht viele Schleifen finden.)
Wenn A und C Typen sind welche eine besondere Rolle spielen, siehe oben, sinnvolle Bezeichner verwenden und gut ist. Was aber wenn es wirklich mehr oder weniger irgendein Typ sein kann? Ist die Assoziation "T ^= Typ[e]" echt so dramatisch?

Shade Of Mine schrieb:

Man lehrt dass sogar den Anfängern: jeder Bezeichner soll so aussagekräftig wie möglich sein. Lieber ein Wort zuviel als zu wenig. Das ist gut so, weil man den Code dadurch leichter lesen kann.

So aussagekräftig wie möglich? Ja, wenn man damit nicht mehr als nötig/sinnvoll meint.
Lieber ein Wort zuviel als zu wenig? DasWürdeIchNiemandemMitAufDenWegGeben, denn EwigLangeBezeichnerMachen DenCodeAuchNichtWirklich lesbarer.
Redundante, irrelevante oder Änderung unterworfene "Informationen" in den Bezeichner zu quetschen würde ich nicht direkt als geschickt bezeichnen.

Shade Of Mine schrieb:

Nochmal meine Frage:
was kostet es, den Bezeichner einen ordentlichen Namen zu geben? Wir machen es doch überall anders auch so, oder? Warum hier nicht?

Weil es zum Teil einfach unnötig/redundant ist.

Shade Of Mine schrieb:

'Weil es unnötig ist' ist eine doofe Begründung.

Mag sein dass sie doof ist, und eine 50 seitige Abhandlung wäre angemessener, aber in den Fällen wo es unnötig ist soll mir 'Weil es unnötig ist' reichen.

Shade Of Mine schrieb:

Denn es ist auch unnötig lokalen Variablen vernünftige Namen zu geben, ein char b[100] reicht doch statt einem char buffer[100] oder ein S s; statt einem string str; Wozu überhaupt lange Namen verwenden?
S ist string, also typedef std::string S; V ist vector (dass es auch Value oder Variadic oder Variant etc. heissen kann ignorieren wir natürlich)

Dann sehen unsere Codes so aus:

V<C> v;
v.p('a');
v.p('b');
v.p('c');
S s(v.b(), v.e());
c<<s;

geil!

Schon wieder, Äpfel und Birnen.

[mantiz]

@Shade Of Mine: Dein Kung-Fu nicht gut. Keine Chance gegen meine Tiger-Affen-Drachen-Technik.

[Michael E.]

finix schrieb:

Shade Of Mine schrieb:

Es gibt kein aussen und innen.

Doch, es gibt den Templatecode an sich und den Clientcode. Du hast im Clientcode nirgendwo die "kryptischen" Bezeichner welche du monierst.

Wieso die Unterscheidung? Ich will überall guten Code haben.

Und innerhalb des Templatecodes ist, allein vom Kontext her, offensichtlich was wofür steht.

Bei einem Einzeiler vielleicht. Aber nicht bei einer komplexeren Funktion (was nicht bedeutet, dass sie lang ist, kann auch was komplex Mathematisches sein) oder bei einer Klasse. Da bin ich heilfroh, so viele Informationen wie möglich auf den ersten Blick zu bekommen.

In deinen folgenden Beispielen hast du Recht, da gilt es sinnvolle Bezeichner zu finden, aber das habe ich (und wohl auch sonst niemand) bestritten.

Wieso dann nicht überall? Im Clientcode machst du auch keinen Unterschied zwischen wichtigen Variablen und Hilfsvariablen. Eigentlich müssten deine Hilfsvariablen dann auch ganz kryptische Namen haben, weil ja in den fünf Zeilen, in denen sie gebraucht werden, direkt klar sein sollte, wofür sie gut sind.

Wie PAD gesagt hat, soviel wie nötig, aber auch nicht mehr.

So langsam macht es keinen Sinn mehr, in jedem zweiten Posting diesen Satz mit eigener (aber nicht schriftlich niedergelegter) Interpretation zu sehen.

Wie sieht's denn hiermit aus:

template <typename T>
class Array
{ /* ... */ };

Data? Element?

Shade Of Mine schrieb:

Nur weil eine Methode private ist, nennen wir sie doch nicht p1 wenn ein stripInvalidSymbols() viel passender wäre, oder?

Wie nennen wir denn unsere Member Variablen?
m1, m2?
Nein, wir nennen sie value, size, speed, fuel,...

Du vergleichst noch immer Äpfel mit Birnen. Siehe oben (& vorige Posts).
Sah dein erstes Beispiel wirklich so aus:

template <typename T>
class V
{
  T v;
};

// oder doch eher wie folgt, mit sinnvollen Bezeichnern?

template <typename V>
class Value
{
  V value;
};

Und wie machst dus mit lokalen Variablen? BTW: Mit Membervariablen meinte Shade wohl die privaten. Die haben einen genauso großen Gültigkeitsbereich wie ein typename T bei einer Template-Klasse. Von daher ein Vergleich von Äpfeln mit Äpfeln.

Shade Of Mine schrieb:

Natürlich ist der Template-Type ein Platzhalter für 'etwas'. Aber dieses 'etwas' hat ja bestimmte Beschränkungen oder einen bestimmten Nutzen/Verwendungszweck.

Siehe oben. Wenn es sinnvolle Bezeichner gibt spricht alles dafür sie auch zu verwenden.

Wieso widersprichst du dir selbst?

Shade Of Mine schrieb:

Bei Schleifen: i, j, k, l sind (wie ich schon so oft gesagt habe) standardisierte Namen in einem engen eingeschränkten Kontext. Ein i muss immer zu einer Zählschleife gehören. Ein T muss aber nur ein Typ sein. Das ist doch etwas vage... Zumal A und C auch Typen sind, aber welche Rolle spielen sie? Keine Ahnung.

Wieso ist die i, j Konvention 'Ok'? Wäre ein aussagekräftiger Name nicht viel sinnvoller? (Ich z.B. würde bei einer Tabelle/Matrix o.ä. immer row & col den Vorzug geben, und solche Beispiele lassen sich nicht für die meisten, aber doch recht viele Schleifen finden.)

Bei mir eigentlich so gut wie nie. Du beschäftigst dich wohl mit anderen Themen wie ich. Aber wenn ein konkreter anderer Name hilfreich ist, sollte man auch von i abweichen, klar.

Wenn A und C Typen sind welche eine besondere Rolle spielen, siehe oben, sinnvolle Bezeichner verwenden und gut ist. Was aber wenn es wirklich mehr oder weniger irgendein Typ sein kann? Ist die Assoziation "T ^= Typ[e]" echt so dramatisch?

Bei vielen Templates ist es aber nicht so, dass alle Typen eingesetzt werden können, sodass es noch Sinn macht. Ansonsten neige ich auch zum T.

Shade Of Mine schrieb:

Man lehrt dass sogar den Anfängern: jeder Bezeichner soll so aussagekräftig wie möglich sein. Lieber ein Wort zuviel als zu wenig. Das ist gut so, weil man den Code dadurch leichter lesen kann.

So aussagekräftig wie möglich? Ja, wenn man damit nicht mehr als nötig/sinnvoll meint.
Lieber ein Wort zuviel als zu wenig? DasWürdeIchNiemandemMitAufDenWegGeben, denn EwigLangeBezeichnerMachen DenCodeAuchNichtWirklich lesbarer.
Redundante, irrelevante oder Änderung unterworfene "Informationen" in den Bezeichner zu quetschen würde ich nicht direkt als geschickt bezeichnen.

Schau dir mal Anfänger an. Sehr viele benutzen Abkürzungen, die keiner versteht. Von daher ist der Rat durchaus gut, weil man als Anfänger gar nicht auf die Idee kommt, ellenlange Variablennamen zu verwenden.

[PAD]

@Michael E.
i,j,k,... sind in den Naturwissenschaften ein anerkanntes Verfahren um Lauf/Schleifeindices zu bezeichnen. Warum soll man hier eine neue Konvention die vom de facto Standard abweicht definieren. Dies gilt allerdings nur für "bedeutungslose" Zählvariablen. Haben dies Zaählvariablen noch eine zusätzlichen Sinn sollte man ihnen eine sinnhaften Namen geben.

n
(∑x[i])/n
i=1

Gibt es hier einen Sinn dem Laufindex einen speziellen Namen zu geben ? Ich meine nein, und so sollte man es vom Prinzip her auch im Code machen

@Shade du hattest dich vorhin dafür Ausgesprochen bei der Definiton des Rechtecks, die ersten beiden Koordinaten top,left zu nennen. Ich halte es da eher mit deinem vorredner, der da sagte in einem anderen Bezugssystem könnte auch bottom left die Anfangskoordinate sein und er würde deshalb x und y bevorzugen. Aber das fällt eher unter Geschmackssache, Aber wenn du mit einer PC-graphik 0,0 links oben und mit einem Vektorterminal mit kartesischen Koordinaten 0,0 links unten arbeitest freust du dich über eine widerspruchsfrei Definition wenn du gleichlautende Routinen benutzt.

[finix]

Michael E. schrieb:

finix schrieb:

Shade Of Mine schrieb:

Es gibt kein aussen und innen.

Doch, es gibt den Templatecode an sich und den Clientcode. Du hast im Clientcode nirgendwo die "kryptischen" Bezeichner welche du monierst.

Wieso die Unterscheidung? Ich will überall guten Code haben.

Ja, du hast natürlich völlig Recht.
Jetzt wo du es sagst.
Ich bin auch immer komplett am verzweifeln wenn ich über den Implementationsdetails von z.B. boosts shared_ptr hänge.
Naja, vielleicht auch nicht.

Michael E. schrieb:

Und innerhalb des Templatecodes ist, allein vom Kontext her, offensichtlich was wofür steht.

Bei einem Einzeiler vielleicht. Aber nicht bei einer komplexeren Funktion (was nicht bedeutet, dass sie lang ist, kann auch was komplex Mathematisches sein) oder bei einer Klasse. Da bin ich heilfroh, so viele Informationen wie möglich auf den ersten Blick zu bekommen.

Ich schätze grob unten stehendes Array-Template würde, ordentlich implementiert, deutlich über einen Einzeiler hinaus gehen. Dennoch traue ich auch dir zu selbst bei der zweiten Bildschirmseite (!) noch nicht vergessen zu haben wöfür T steht.

Michael E. schrieb:

In deinen folgenden Beispielen hast du Recht, da gilt es sinnvolle Bezeichner zu finden, aber das habe ich (und wohl auch sonst niemand) bestritten.

Wieso dann nicht überall? Im Clientcode machst du auch keinen Unterschied zwischen wichtigen Variablen und Hilfsvariablen. Eigentlich müssten deine Hilfsvariablen dann auch ganz kryptische Namen haben, weil ja in den fünf Zeilen, in denen sie gebraucht werden, direkt klar sein sollte, wofür sie gut sind.

Irgendwie scheinst du immer zu versuchen alles zu verallgemeinern, Aussagen auf völlig andere Situationen zu transferieren, die so nie auch nur erwähnt wurden oder gar explizit ausgeschlossen wurden. Wie bitte schön kommst du von meiner Aussage auf eine Mutmaßung über einen ganz anderen Sachverhalt, die, wenn überhaupt, meiner Aussage komplett entgegen gesetzt ist?

Michael E. schrieb:

Wie PAD gesagt hat, soviel wie nötig, aber auch nicht mehr.

So langsam macht es keinen Sinn mehr, in jedem zweiten Posting diesen Satz mit eigener (aber nicht schriftlich niedergelegter) Interpretation zu sehen.

Häh?

Michael E. schrieb:

Wie sieht's denn hiermit aus:

template <typename T>
class Array
{ /* ... */ };

Data? Element?

Sicherlich nette Bezeichner für die entsprechende Variable - aber für den Typ?
Davon ab, welchen Bezeichner würdest du für das zweite Beispiel vorschlagen?

Michael E. schrieb:

Shade Of Mine schrieb:

Nur weil eine Methode private ist, nennen wir sie doch nicht p1 wenn ein stripInvalidSymbols() viel passender wäre, oder?

Wie nennen wir denn unsere Member Variablen?
m1, m2?
Nein, wir nennen sie value, size, speed, fuel,...

Du vergleichst noch immer Äpfel mit Birnen. Siehe oben (& vorige Posts).
Sah dein erstes Beispiel wirklich so aus:

template <typename T>
class V
{
  T v;
};

// oder doch eher wie folgt, mit sinnvollen Bezeichnern?

template <typename V>
class Value
{
  V value;
};

Und wie machst dus mit lokalen Variablen? BTW: Mit Membervariablen meinte Shade wohl die privaten. Die haben einen genauso großen Gültigkeitsbereich wie ein typename T bei einer Template-Klasse. Von daher ein Vergleich von Äpfeln mit Äpfeln.

Es ging vorrangig darum noch einmal zu zeigen wie sehr der ursprüngliche Vergleich hinkt. Darüber hinaus wird sich für eine Membervariable generell ein 'bezeichnender' Name finden lassen, was bei Templateparametern nicht zwangsläufig der Fall ist.

Michael E. schrieb:

Shade Of Mine schrieb:

Natürlich ist der Template-Type ein Platzhalter für 'etwas'. Aber dieses 'etwas' hat ja bestimmte Beschränkungen oder einen bestimmten Nutzen/Verwendungszweck.

Siehe oben. Wenn es sinnvolle Bezeichner gibt spricht alles dafür sie auch zu verwenden.

Wieso widersprichst du dir selbst?

Woraus konstruierst du die Empfindung/Unterstellung ich widerspäche mir selbst?

Michael E. schrieb:

Wieso ist die i, j Konvention 'Ok'? Wäre ein aussagekräftiger Name nicht viel sinnvoller? (Ich z.B. würde bei einer Tabelle/Matrix o.ä. immer row & col den Vorzug geben, und solche Beispiele lassen sich nicht für die meisten, aber doch recht viele Schleifen finden.)

Bei mir eigentlich so gut wie nie. Du beschäftigst dich wohl mit anderen Themen wie ich. Aber wenn ein konkreter anderer Name hilfreich ist, sollte man auch von i abweichen, klar.
[/quote]
Ich bin mir nicht sicher warum du mir derart, vor allem in dieser Art und Weise, widersprichst; im weiteren Sinne ist das eine ähnliche Situation wie Bezeichner für Templateparameter zu bestimmen, lediglich mit dem Unterschied zu Euch, wie es scheint, dass ich mich auch oftmals mit einem i oder j zufrieden geben kann.

Michael E. schrieb:

Wenn A und C Typen sind welche eine besondere Rolle spielen, siehe oben, sinnvolle Bezeichner verwenden und gut ist. Was aber wenn es wirklich mehr oder weniger irgendein Typ sein kann? Ist die Assoziation "T ^= Typ[e]" echt so dramatisch?

Bei vielen Templates ist es aber nicht so, dass alle Typen eingesetzt werden können, sodass es noch Sinn macht. Ansonsten neige ich auch zum T.

Wie denn, T? Nicht Type? Oder Anything? Wie wär's mit AnyType?

Michael E. schrieb:

Shade Of Mine schrieb:

Man lehrt dass sogar den Anfängern: jeder Bezeichner soll so aussagekräftig wie möglich sein. Lieber ein Wort zuviel als zu wenig. Das ist gut so, weil man den Code dadurch leichter lesen kann.

So aussagekräftig wie möglich? Ja, wenn man damit nicht mehr als nötig/sinnvoll meint.
Lieber ein Wort zuviel als zu wenig? DasWürdeIchNiemandemMitAufDenWegGeben, denn EwigLangeBezeichnerMachen DenCodeAuchNichtWirklich lesbarer.
Redundante, irrelevante oder Änderung unterworfene "Informationen" in den Bezeichner zu quetschen würde ich nicht direkt als geschickt bezeichnen.

Schau dir mal Anfänger an. Sehr viele benutzen Abkürzungen, die keiner versteht. Von daher ist der Rat durchaus gut, weil man als Anfänger gar nicht auf die Idee kommt, ellenlange Variablennamen zu verwenden.

Entweder hast du meine Ausführung nicht verstanden (ein relativ kleiner Kritikpunkt, der jedoch gut in den Rahmen dieser Diskussion passt und vielleicht der von dir weiter oben erwähnten "Schriftlichen Niederlegung" nahe kommt) oder scheinst jene Überkompensation zu befürworten.

[Michael E.]

PAD schrieb:

@Michael E.
i,j,k,... sind in den Naturwissenschaften ein anerkanntes Verfahren um Lauf/Schleifeindices zu bezeichnen. Warum soll man hier eine neue Konvention die vom de facto Standard abweicht definieren. Dies gilt allerdings nur für "bedeutungslose" Zählvariablen. Haben dies Zaählvariablen noch eine zusätzlichen Sinn sollte man ihnen eine sinnhaften Namen geben.

Mein ich ja und habs IMHO auch so ausgedrückt.

finix schrieb:

Ja, du hast natürlich völlig Recht.
Jetzt wo du es sagst.
Ich bin auch immer komplett am verzweifeln wenn ich über den Implementationsdetails von z.B. boosts shared_ptr hänge.
Naja, vielleicht auch nicht.

Wenn du ihn selbst verändern willst, dann ja (BTW: keine Ahnung, wie schlimm der Code von shared_ptr ist). Du brauchst nicht so zu tun, als würdest du grad nur noch ne Hauptfunktion schreiben und den Rest von Libraries inkludieren, du hast nämlich auch Implementierungen, die du mit "innen" umschreibst. Von daher ist dein Beispiel daneben.

Ich schätze grob unten stehendes Array-Template würde, ordentlich implementiert, deutlich über einen Einzeiler hinaus gehen. Dennoch traue ich auch dir zu selbst bei der zweiten Bildschirmseite (!) noch nicht vergessen zu haben wöfür T steht.

Danke. Ich traue auch dir zu, dass du das mit Typnamen T bis Z hinkriegst. Die Frage ist nur, ob es anders nicht effizienter und einfacher wäre.

Irgendwie scheinst du immer zu versuchen alles zu verallgemeinern, Aussagen auf völlig andere Situationen zu transferieren, die so nie auch nur erwähnt wurden

Ich mache das, um dir deine Inkonstistenz an analogen Beispielen zu zeigen.

oder gar explizit ausgeschlossen wurden.

Wo?

Wie bitte schön kommst du von meiner Aussage auf eine Mutmaßung über einen ganz anderen Sachverhalt, die, wenn überhaupt, meiner Aussage komplett entgegen gesetzt ist?

Ich erkenne eindeutig eine Analogie. Wo siehst du den Gegensatz?

Michael E. schrieb:

So langsam macht es keinen Sinn mehr, in jedem zweiten Posting diesen Satz mit eigener (aber nicht schriftlich niedergelegter) Interpretation zu sehen.

Häh?

Ich meine damit, dass der Satz schon von beiden Seiten gebracht wurde, bloß unterschiedlich ausgelegt wird. Leider macht es dann ohne explizite Auslegung keinen Sinn mehr, diesen Satz noch öfter zu zitieren.

Michael E. schrieb:

Wie sieht's denn hiermit aus:
C/C++ Code:
template <typename T>
class Array
{ /* ... */ };
C/C++ Code:
template <typename T>
class Array
{ /* ... */ };
C/C++ Code:
template <typename T>
class Array
{ /* ... */ };

Data? Element?

Sicherlich nette Bezeichner für die entsprechende Variable - aber für den Typ?

Man hat ja schon vorher gesehen, dass du ein Postfix-T oder -Type magst. Also meinetwegen ElementType.

Davon ab, welchen Bezeichner würdest du für das zweite Beispiel vorschlagen?

T.

Darüber hinaus wird sich für eine Membervariable generell ein 'bezeichnender' Name finden lassen, was bei Templateparametern nicht zwangsläufig der Fall ist.

Deshalb hab ich ja auch geschrieben, dass man einen guten Namen suchen soll und wenn man keinen findet, kommt meinetwegen T.

Michael E. schrieb:

Siehe oben. Wenn es sinnvolle Bezeichner gibt spricht alles dafür sie auch zu verwenden.

Wieso widersprichst du dir selbst?

Woraus konstruierst du die Empfindung/Unterstellung ich widerspäche mir selbst?

Daraus, dass du ein T/U/V sinnvolleren Namen vorziehst.

Michael E. schrieb:

Wieso ist die i, j Konvention 'Ok'? Wäre ein aussagekräftiger Name nicht viel sinnvoller? (Ich z.B. würde bei einer Tabelle/Matrix o.ä. immer row & col den Vorzug geben, und solche Beispiele lassen sich nicht für die meisten, aber doch recht viele Schleifen finden.)

Bei mir eigentlich so gut wie nie. Du beschäftigst dich wohl mit anderen Themen wie ich. Aber wenn ein konkreter anderer Name hilfreich ist, sollte man auch von i abweichen, klar.

Ich bin mir nicht sicher warum du mir derart, vor allem in dieser Art und Weise, widersprichst; im weiteren Sinne ist das eine ähnliche Situation wie Bezeichner für Templateparameter zu bestimmen, lediglich mit dem Unterschied zu Euch, wie es scheint, dass ich mich auch oftmals mit einem i oder j zufrieden geben kann.

Ich arbeite auch mit i/j/k. Guck mal, was PAD geschrieben hat:

PAD schrieb:

i,j,k,... sind in den Naturwissenschaften ein anerkanntes Verfahren um Lauf/Schleifeindices zu bezeichnen. Warum soll man hier eine neue Konvention die vom de facto Standard abweicht definieren.

Mit i/j/k weiß jeder sofort, was damit gemeint ist, und, was noch viel wichtiger ist, wie es sich verhält. Bei Typnamen ist das Verhalten nicht klar, deshalb versucht man es durch passende Namen näher zu erläutern.

Wie denn, T? Nicht Type? Oder Anything? Wie wär's mit AnyType?

Weil Type/Anything/AnyType weder genauer spezifizieren, was ich gerne als Übergabe hätte, noch der Leserlichkeit dienen.

Entweder hast du meine Ausführung nicht verstanden (ein relativ kleiner Kritikpunkt, der jedoch gut in den Rahmen dieser Diskussion passt und vielleicht der von dir weiter oben erwähnten "Schriftlichen Niederlegung" nahe kommt) oder scheinst jene Überkompensation zu befürworten.

OK, nochmal: Anfänger neigen dazu, kurze und unverständliche Variablennamen zu benutzen. Durch dieses "Lieber ein Wort zuviel als zu wenig" bringt man sie überhaupt erst mal auf verständliche Namen. Die Variablennamen werden also sozusagen auf Fortgeschrittenen-Niveau angepasst. Dass Variablennamen durch diesen Lehrsatz zu lang werden, sieht man eher selten.

[net 0]

ihr seid komplett durchgeknallt

[Herb Sutter aka finix]

net schrieb:

ihr seid komplett durchgeknallt

Nein, wir sind Gurus.

[FireFlow]

Hier gehts irgendwie nur darum dass jeder Recht haben will...

[finix]

Michael E. schrieb:

[..ne Menge Zeug..]

Mein Browser ist grad abgeschmiert und hat meine Antwort mitgerissen.
Ist wahrscheinlich auch besser so.
Ich hab ohnehin keine Lust mehr auf deine rethorischen Spielchen und [edit: so weiter] einzugehen.

Wenn ich dich nicht komplett mißverstanden habe sehen wir diese Bezeichnerfrage bei Templates ohnehin relativ ähnlich. Lies es nach oder lass es.

[Michael E.]

OK.

[Shade Of Mine]

Ich finde es lediglich komisch dass wenn ich sage "ein anfaenger sollte lieber ein wort zuviel als zu wenig schreiben" ein IchBinJaSoEinVerdammtLangerBezeichner rauskommt. Unter _einem_ Wort verstehe ich etwas, dass in etwa _einem_ Wort entspricht.

Ich sage, man solle Value schreiben wenn man Value meint und nicht V (denn V kann fuer Vector, Verkorkst, Verdummung, etc. stehen). Ich habe nie gesagt man solle Romane schreiben...

Und ob man jetzt in speziellen Situationen T verwenden soll ist auch eine ganz andere Frage... Ausnahmen wird es immer geben. Und mir geht es hier auch nicht um wegwerf code oder einzeiler, sondern ordentliche Anwendungen - da kann man nicht immer alles herleiten (bzw. koennen schon, aber man will es nicht, weil man dann vor lauter Namen herleiten den Code nicht mehr lesen kann...)

Und da mir bei dem copy Beispiel recht gegeben wurde, sehe ich das als bestaetigung dass wir an einander vorbeigeredet haben.

[Jester]

Optimizer schrieb:

Map<KeyType, ValueType> zu haben?

KeyType und ValueType sind Typen, nicht wahr. Warum ist es hier jetzt auf einmal toll das in den Namen reinzuschreiben, aber bei Variablen heißt es UN und ist scheiße?

[aussenstehender]

Wenn ich dich nicht komplett mißverstanden habe sehen wir diese Bezeichnerfrage bei Templates ohnehin relativ ähnlich.

*löl*

[finix]

Shade Of Mine schrieb:

Ich finde es lediglich komisch dass wenn ich sage "ein anfaenger sollte lieber ein wort zuviel als zu wenig schreiben" ein IchBinJaSoEinVerdammtLangerBezeichner rauskommt. Unter _einem_ Wort verstehe ich etwas, dass in etwa _einem_ Wort entspricht.

Entweder meinst du "1" Wort im übertragenen Sinne oder ganz exakt. Wenn du's im übertragenen Sinne meinst solltest du es auch dementsprechend klar machen (vor allem jenen gegenüber denen du diesen Tipp gibst). Meinst du es wortwörtlich dann ist ein Wort zuviel ein Wort zuviel.

Shade Of Mine schrieb:

Ich sage, man solle Value schreiben wenn man Value meint und nicht V (denn V kann fuer Vector, Verkorkst, Verdummung, etc. stehen). Ich habe nie gesagt man solle Romane schreiben...

Natürlich, wurde nie bestritten, zumindest nicht von mir, aber wenn du einen Value-of-T[ype]-Template hast, was spricht gegen typename T? Einen Algorithmus dessen Argumente keine inherenten Einschränkungen/Anforderungen aufweisen? Einen Container-of-T?
Bestenfalls bringst du redundante Informationen im Code unter.

Shade Of Mine schrieb:

Und da mir bei dem copy Beispiel recht gegeben wurde, sehe ich das als bestaetigung dass wir an einander vorbeigeredet haben.

Scheint fast so.

aussenstehender schrieb:

Wenn ich dich nicht komplett mißverstanden habe sehen wir diese Bezeichnerfrage bei Templates ohnehin relativ ähnlich.

*löl*

Was ist daran so albern?

[finix]

Jester schrieb:

Optimizer schrieb:

Map<KeyType, ValueType> zu haben?

KeyType und ValueType sind Typen, nicht wahr. Warum ist es hier jetzt auf einmal toll das in den Namen reinzuschreiben, aber bei Variablen heißt es UN und ist scheiße?

KeyType und ValueType und sind keine Typen, sie stehen für Typen.

[Gast]

Jester schrieb:

Optimizer schrieb:

Map<KeyType, ValueType> zu haben?

KeyType und ValueType sind Typen, nicht wahr. Warum ist es hier jetzt auf einmal toll das in den Namen reinzuschreiben, aber bei Variablen heißt es UN und ist scheiße?

Gut, stimmt schon, gegen Key und Value würd ich jetzt auch nichts sagen. Es sollte sich auch mehr auf den Unterschied zu K und V beziehen.

[otze]

finix schrieb:

Jester schrieb:

...

KeyType und ValueType und sind keine Typen, sie stehen für Typen.

Macht es einen Unterschied? Nein. Trägt dein Kommentar dazu bei, die Diskussion weiterzuführen? Nein. Wieso zum Geier machst du es dann?