C++ Gurus

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

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?

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.

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?

volkard

finix schrieb:

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

das ist unfug.
KeyType und ValueType sind typen.
"KeyType" und "ValueType" stehen für typen.
namen wie "KeyType" werden in der deutschen sprache ausgewertet zum objekt, das sie benamsen. willste den namen selbst benutzen, mußte schon quoten.

"finix" hat vorne ein 'f'.
finix hat aber vorne eine nase.

irgendwie fühlt sich das aber nicht gut an, wenn man nicht Type benutzt

selbst hume sikkins benutzt meistens nur einzelne buchstaben für template-parameter

template <class H, class E>
struct MemFunInvoker
{
	// restores the type of h and e then dispatches the event to the
	// appropriate member funtion.
	static void invoke(const Handler& h, const void* e)
	{
		event::CallTraits<H, E>::handle(*static_cast<H*>(const_cast<void*>(h.obj_)), 
			*static_cast<const E*>(e));
	}
	static void invokeConst(const Handler& h, const void* e)
	{

		event::CallTraits<H, E>::handleConst(*static_cast<const H*>(h.obj_), 
			*static_cast<const E*>(e));
	}
};

template <class Fun, class E>
struct FunInvoker
{
	static void invoke(const Handler& h, const void* e)
	{
		reinterpret_cast<Fun>(h.fun_)(*static_cast<const E*>(e));
	}
};

Shade Of Mine

wtf???? schrieb:

selbst hume sikkins benutzt meistens nur einzelne buchstaben für template-parameter

Und mir sagt H und E hier garnichts.

Aber ich sagte ja: diese kurzen Bezeichner sind so gaengig geworden und das ich genau das nicht verstehe. Ich habe sie ja selber lange genug verwendet

HumeSikkins

@wtf????
Ich habe den Thread nicht verfolgt, aber falls der Topic-Titel programm sein sollte, dann macht es herzlich wenig Sinn Code von mir als Pro- oder Contra-Argument zu verwenden.
Da ich die Voraussetzung nicht erfülle, ist jede Schlussfolgerung uninteressant.

Und mir sagt H und E hier garnichts.

Was sicher ein wenig daran liegt, dass der Code aus dem Kontext gerissen ist.
Betrachtet man den Code in dem Kontext in dem er steht, dann erfordert es keinen Doktortitel um zu erkennen, dass H für Handler und E für Event steht. Desweiteren sollte man vielleicht berücksichtigen, dass der Code ein Implementationsdetail aus einem detail-Namespace ist, also nicht für den allgemeinen Gebrauch gedacht ist.

Bei öffentlichen Klassen benenne ich normalerweise entweder die Template-Parameter sinnvoll oder aber erzeuge zumindest ein hübsches typedef innerhalb der Definition. Leiger bin ich diesbezüglich oft aber auch etwas nachlässig.
Schlimmer finde ich es allerdings, wenn die Semantik des Templateparmeters nicht beschrieben ist (welche Eigenschaften muss ein konkretes Argument erfüllen).

es geht nicht mehr um gurus

Shade Of Mine

HumeSikkins schrieb:

Was sicher ein wenig daran liegt, dass der Code aus dem Kontext gerissen ist.

Klar, nur sehe ich halt den dennoch keinen Vorteil in einem H wenn man es auch Handle nennen kann... Und genau das habe ich gesagt: "ich verstehe es nicht". Wobei ich es auch lange so gemacht habe, aber wie ich mal darueber nachgedacht habe, habe ich festgestellt, dass es nur Bequemlichkeit ist.