C++ Gurus

Shade Of Mine

volkard schrieb:

Shade Of Mine schrieb:

Aber ein ResultType würde natürlich kein bisschen schaden.

doch.
rutsch bitte nicht ins suboptimale ab.

Ich würde es nicht schreiben, weil es bei einem Stil redundant ist (das R sagt ja schon, dass es ein Typ ist) aber ein ResultType würde ich lieber lesen als ein R

mantiz schrieb:

Man kann natürlich auch ein
#define ganzzahltyp int
#define fliesskomma float
etc.

Blödsinn. int ist ein synonym für ganzzahltyp, soetwas macht keinen Sinn.

Ich weiß nicht genau, aber ich glaube ich habe im Scott Meyers gelesen, dass man sich an folgendes halten sollte

So viel wie nötig, so wenig wie möglich.

Und? Inwiefern spricht das für ein
M<K, V<X> >?
Wenn man ein
Map<Key, Value<Whatever> >
haben kann?

for (int i = 0; i < max; ++i) { ... }
weiß auch jeder was gemeint ist, und das ist imo wesentlich übersichtlicher.

Deshalb haben wir ja gesagt: bei i ist es OK, aber bei K X R T C etc. ist nix klar...

mantiz

Deswegen hab' ich ja gesagt, dass es wohl immer ein wenig subjektiv ist. Wenn ich weiß, dass K für Key und V für Value steht, dann geht das auch nur mit Buchstaben. Ich persönlich würde in diesem Fall auch Key und Value bevorzugen, X würde ich aber beibehalten.

Das mit den defines war ja jetzt nur ein Beispiel, ich habe auch schon mit Leuten gesprochen, die die geschweiften Klammern als ein Beispiel für die Unlesbarkeit von z.B. C++ halten, wobei ich mich dann aber frage, wieso man ein BEGIN...END-Konstrukt für lesbarer hält. Alles andere ist und bleibt eine Stilfrage, die wohl immer subjektiv bleibt, aber nichts mit der Sprache zu tun hat.

Jeder schreibt seinen Code, glaube ich, erstmal so, dass man ihn selbst am Besten lesen kann, danach erst macht man sich Gedanken, ob dieser wohl auch für andere gut lesbar ist. Zumindest ist es bei mir so. Was habe ich von Code, den andere evtl. gut lesen können, ich mich beim lesen aber immer über unnötigerweise ausformulierte Bezeichnungen ärgern muss?

Wenn ich, wie in einem Beispiel weiter oben, weiß, dass pmf für Pointer (to) Member Function steht, dann geht es glaube ich nicht lesbarer.

Shade Of Mine

mantiz schrieb:

Deswegen hab' ich ja gesagt, dass es wohl immer ein wenig subjektiv ist. Wenn ich weiß, dass K für Key und V für Value steht, dann geht das auch nur mit Buchstaben. Ich persönlich würde in diesem Fall auch Key und Value bevorzugen, X würde ich aber beibehalten.

Wofür steht X?
eXtendend? eXtension? eXtra? etwas anderes? Welche Rolle spielt es? Ist K nun wirklich Key oder doch eher ein Fachbegriff aus der Domain?

Das mit den defines war ja jetzt nur ein Beispiel, ich habe auch schon mit Leuten gesprochen, die die geschweiften Klammern als ein Beispiel für die Unlesbarkeit von z.B. C++ halten, wobei ich mich dann aber frage, wieso man ein BEGIN...END-Konstrukt für lesbarer hält. Alles andere ist und bleibt eine Stilfrage, die wohl immer subjektiv bleibt, aber nichts mit der Sprache zu tun hat.

Gut, aber wir sind da wohl ein anderes Level...

Jeder schreibt seinen Code, glaube ich, erstmal so, dass man ihn selbst am Besten lesen kann,

Genau das ist aber falsch. Wenn wir jetzt mal von Teams ausgehen, denn wer schreibt schon Code nur für sich alleine (doch nur als Hobby und dann ist es ja wirklich egal, weil man jederzeit alles wegwerfen und nochmal beginnen kann).

Was habe ich von Code, den andere evtl. gut lesen können, ich mich beim lesen aber immer über unnötigerweise ausformulierte Bezeichnungen ärgern muss?

Schau dir meinen Code an. wenn wir von mem_fun_adapter absehen, was kannst du daran schwer lesen?

Wenn ich, wie in einem Beispiel weiter oben, weiß, dass pmf für Pointer (to) Member Function steht, dann geht es glaube ich nicht lesbarer.

pmf? Ja _wenn_. Bei "Method method" ist es sofort klar. Meinetwegen nenne es MethodPointer. Aber du erkennst es ohne acronym was es bedeutet. Bei "method" weisst du es auch ohne direkten Kontext worum es geht, bei pmf nicht unbedingt. Ich assoziiere zB pmf mit
p -> ungarisch für Zeiger
m -> ungarisch für Member
f -> name der Variablen

Natürlich ist Stil subjektiv, aber ein
M<K, V<X> >
ist trotzdem eine Katastrophe...
Es gibt einfach keinen Grund einer Variable nur einen Buchstaben als Namen zu geben. i, j, k, l ausgenommen, denn diese sind wiederum standardisiert für Schleifen und dürfen nirgends anders verwendet werden.

Ich verstehe diese einbuchstaben Typen nicht. Denn es ist wirklich nur ein Template Phänomen. Niemand würde

struct V
{
  string name;
  int foo;
};

schreiben. Aber ein

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

ist 'OK'.

Verstehe ich nicht, denn eine logische Argumentation dafür gibt es nicht.

PAD

Halt ich durchaus für verständlich und lesbar, da sich der einzige Bezug innerhalb von 5 Zeilen befindet.

Genausowenig habe ich etwas allgemeine Laufvariablen für Schleifen jeglicher Art
in der Art der Mathematiker als i,j,k... zu bezeichnen.

Haben die Laufvariablen einen besonderen Sinn, so ziehe ich kurze sperechende Namen vor.

Genauso heißen temporäre Variablen für Zwischenergebnisse ohne weiteres temp, tmp,... oder Arbeitsstrings buffer. Sobald aber ein buffer "InputBuffer", der aus einem File gelesen wird, nach dem Entfernen von Beiwerks wie cr\lf, führenden und schließenden Whitespacees in z.B. Kommandos und Parameter zerlegt wird, so heißen
die entsprechenden Elemente dann auch command und param (respektive param[i])

ganz nach dem hier schon benannten Motto
So viel wie nötig, so wenig wie möglich.

Zu lange Namen, die auch nur Redundanzen ausdrücken verwirren genauso, wie kryptischer AbKüFi mancher PseudoProfis. Was oftmals wichtiger ist, ist eine vernünftige Dokumentation und auch diese kurz prägnant und richtig, und am besten im Sourcecode.

hauptsache es

fktiniert

finix

Shade Of Mine schrieb:

Ich verstehe diese einbuchstaben Typen nicht. Denn es ist wirklich nur ein Template Phänomen. Niemand würde
struct V
{
  string name;
  int foo;
};
schreiben. Aber ein
template<typename V>
struct Value
{
  V value;
};
ist 'OK'.

Verstehe ich nicht, denn eine logische Argumentation dafür gibt es nicht.

Ich verstehe dein Problem hierbei nicht wirlich. Wenn du aus dem V ein T für Type oder gleich direkt Type machst ist doch offensichtlich was da steht!? Und so direkt vergleichbar ist es mit deinem struct V nicht, von daher ist mir etwas unklar auf welcher Basis du logische Argumente forderst.

Michael E.

finix schrieb:

Ich verstehe dein Problem hierbei nicht wirlich. Wenn du aus dem V ein T für Type oder gleich direkt Type machst ist doch offensichtlich was da steht!?

So kann man bei allem argumentieren.

Und so direkt vergleichbar ist es mit deinem struct V nicht

Wieso denn nicht?

finix

Michael E. schrieb:

finix schrieb:

Ich verstehe dein Problem hierbei nicht wirlich. Wenn du aus dem V ein T für Type oder gleich direkt Type machst ist doch offensichtlich was da steht!?

So kann man bei allem argumentieren.

Wäre mir neu.

Michael E. schrieb:

Und so direkt vergleichbar ist es mit deinem struct V nicht

Wieso denn nicht?

Weil es eine völlig andere Situation ist?

mantiz

Stimmt, irgendwie kommt dies häufig bei Templates vor, zumindest soweit ich das bis jetzt sagen kann, soweit reicht meine Erfahrung da noch nicht. Aber wenn ich eine kleine Funktion oder Klasse habe, dann ist da das "T" eigentlich genauso logisch, wie das "i" in einer Schleife. Wenn ich eine große Template-Klasse habe und/oder mit verschiedenen Templatetypen, dann ist es sicherlich übersichtlicher und auch sehr sinnvoll diese entsprechend zu benennen, aber wenn ich nur einen Typen in einem 3-Zeiler habe, dann erfüllt ein "T" denselben Effekt, wie ein "Type" oder was auch immer, jeder weiß, was gemeint ist, wenn ich ein Template mit einem Rückgabe-Typen und zwei Parametertypen beispielsweise habe, dann würde ich "TReturn", "TParam1", "TParam2" evtl. für sinnvoll halten. Bei einer gewissen Mächtigkeit, bei einem 3-Zeiler finde ich "R", "P1", "P2" oder ähnliches ähnlich verständlich und übersichtlich.

Wo ist denn das Problem dabei, auch template-Parametern einen guten Namen zu geben? Es hat sich doch schon allgemein die Erkenntnis durchgesetzt, dass sprechende Namen für Instanzen schön sind. Und das sprechende Namen für Typen schön sind. Wenn ich meine Klasse für eine Geldeinheit "Euro" nenne und nicht "E" ist das schöner. Kann man einsehen, oder?
Jetzt ist der Token "Euro", bzw. "E" doch wirklich nur ein Typname. Völlig egal, was es ist. Ungarische-Notations-Freaks können natürlich T_Euro oder C_Euro schreiben, das ist mir egal. Aber welchen logischen Grund gibt es jetzt, weniger gute Namen für typedefs und Template-Parameter zu nehmen, als für Klassen?

Also, warum soll es jetzt böse sein, eine Map<KeyType, ValueType> zu haben? Wenn ich Map< schreibe, zeigt mir die IDE schön an, was reinkommt. Natürlich kann ich auch noch K und V interpretieren, ohne in die Hilfe sehen zu müssen. Spätestens beim dritten Parameter wird es aber eklig. Hier wird teilweise so getan, als wäre es ein Weltuntergang, einen vernünftigen Namen zu verwenden. *kopfschüttel*
Jetzt ist es ja noch nicht mal so, dass ich ständig KeyType und ValueType ausschreiben muss. Wenn ich die Map benutze, setze ich dafür einen konkreten Typ ein und schreibe höchstens diesen aus. Wenn ich die Map programmiere, benenn ich den Parameter halt nach der fertigstellung um, falls es mich wirklich stören sollte, ständig KeyType auszuschreiben. Das sind zwei Mausklicks in einer gescheiten IDE.

Michael E.

finix schrieb:

Michael E. schrieb:

finix schrieb:

Ich verstehe dein Problem hierbei nicht wirlich. Wenn du aus dem V ein T für Type oder gleich direkt Type machst ist doch offensichtlich was da steht!?

So kann man bei allem argumentieren.

Wäre mir neu.

Was verstehst du denn daran nicht / willst du nicht daran verstehen?

Michael E. schrieb:

Und so direkt vergleichbar ist es mit deinem struct V nicht

Wieso denn nicht?

Weil es eine völlig andere Situation ist?

Nö, es wird ein Typname gesucht.

finix

Michael E. schrieb:

finix schrieb:

Michael E. schrieb:

finix schrieb:

Ich verstehe dein Problem hierbei nicht wirlich. Wenn du aus dem V ein T für Type oder gleich direkt Type machst ist doch offensichtlich was da steht!?

So kann man bei allem argumentieren.

Wäre mir neu.

Was verstehst du denn daran nicht / willst du nicht daran verstehen?

Ok, die Langversion, extra für dich: Es wäre mir neu dass man diese Argumentation, in sinnvoller Weise, bei "allem" anwenden könnte.
Was meinst du, nebenbei, mit "allem"?
Oder monierst du lediglich dass ich das Problem am konkreten Beispiel nicht entdecken kann?

Michael E. schrieb:

Und so direkt vergleichbar ist es mit deinem struct V nicht

Wieso denn nicht?

Weil es eine völlig andere Situation ist?

Nö, es wird ein Typname gesucht.[/quote]
Es lebe die kontextfreie Simplifikation!! Hurra!

// Anwendungscode:
void bar()
{
  Value<int> v1;
  v1.value = 42;

  V v2;
  v2.name = "whatever";
  v2.foo = v1.value;
}

Siehst du den Unterschied?

Michael E.

Ok, die Langversion, extra für dich: Es wäre mir neu dass man diese Argumentation, in sinnvoller Weise, bei "allem" anwenden könnte.
Was meinst du, nebenbei, mit "allem"?

"Alles" im Sinne von "jeder Name". Guck dir zum Beispiel dieses Beispiel an:

template<typename EPdTunewlN, typename ZPdTunewlN>
EPdTunewwlN EszVdFmewlN(EPdTunewlN EPdFmeaNadTP, ZPdTunewlN ZPdFmeaNadTP)
{
	return static_cast<EPdTunewwlN>(EPdFmeaNadTP.ExbMffdmkNme(ZPdFmeaNadTP.EaaybMffdmkNme()));
}

Legende:

Erster Parameter des Templates und ein wunderschöner langer Name
Zweiter Parameter des Templates und ein wunderschöner langer Name
Eine sinnfreie, zur Veranschaulichung dienende Funktion mit einem wunderschönen langen Namen
Erster Parameter der Funktion mit einem anderen Namen als die Template-Parameter
Zweiter Parameter der Funktion mit einem anderen Namen als die Template-Parameter
Eine x-beliebige Member-Funktion, für die mir kein Name mehr einfällt
Eine andere, also y-beliebige Member-Funktion, für die mir kein Name mehr einfällt

Jetzt kann ich auch argumentieren, wenn, ja wenn ich jetzt statt den Abkürzungen sinnvolle Namen benutze, "ist doch offensichtlich was da steht!?" (Zitat von dir).

Es lebe die kontextfreie Simplifikation!! Hurra!

Du führst die Simplifikation ein, indem du nur auf den Anwendungscode schaust.

finix

Michael E. schrieb:

Ok, die Langversion, extra für dich: Es wäre mir neu dass man diese Argumentation, in sinnvoller Weise, bei "allem" anwenden könnte.
Was meinst du, nebenbei, mit "allem"?

"Alles" im Sinne von "jeder Name". [...]

Ich gehe einfach mal davon aus dass dein Beispiel ein Scherz sein sollte.

Michael E. schrieb:

... sinnvolle Namen ...

Was wäre denn in Shades Beispiel ein sinnvoller Bezeichner?

Michael E. schrieb:

Es lebe die kontextfreie Simplifikation!! Hurra!

Du führst die Simplifikation ein, indem du nur auf den Anwendungscode schaust.

Hm. Bedeutet diese Entgegnung nun dass dir der Unterschied nicht ins Auge gestochen ist oder dass du nicht auf ihn einzugehen vermagst?

Michael E.

finix schrieb:

Michael E. schrieb:

Ok, die Langversion, extra für dich: Es wäre mir neu dass man diese Argumentation, in sinnvoller Weise, bei "allem" anwenden könnte.
Was meinst du, nebenbei, mit "allem"?

"Alles" im Sinne von "jeder Name". [...]

Ich gehe einfach mal davon aus dass dein Beispiel ein Scherz sein sollte.

Nein, das war ernst gemeint, frei nach

finix schrieb:

Wenn du aus dem V ein T für Type oder gleich direkt Type machst ist doch offensichtlich was da steht!?

Michael E. schrieb:

... sinnvolle Namen ...

Was wäre denn in Shades Beispiel ein sinnvoller Bezeichner?

Um diese Frage beantworten zu können, braucht man einen Kontext.

Michael E. schrieb:

Es lebe die kontextfreie Simplifikation!! Hurra!

Du führst die Simplifikation ein, indem du nur auf den Anwendungscode schaust.

Hm. Bedeutet diese Entgegnung nun dass dir der Unterschied nicht ins Auge gestochen ist oder dass du nicht auf ihn einzugehen vermagst?

Weder noch.

Gute Nacht.

Shade Of Mine

finix schrieb:

Ich verstehe dein Problem hierbei nicht wirlich. Wenn du aus dem V ein T für Type oder gleich direkt Type machst ist doch offensichtlich was da steht!?

Darum geht es mir ja. Warum soll ich V schreiben, wenn ich Value oder meinetwegen ValueT oder ValueType schreiben kann?

Warum soll ich T schreiben, wenn ich Type schreiben kann?

Warum soll ich K schreiben, wenn ich Key schreiben kann?

Warum soll ich SP schreiben, wenn ich SmartPointer schreiben kann?

Warum soll ich A schreiben, wenn ich Allocator schreiben kann?

Warum soll ich C schreiben, wenn ich Class oder Container schreiben kann?

PS: zu meinem Beispiel:
mir geht das darum zu zeigen, dass niemand eine Klasse T, C, V oder sonstwas nennen würde. Weil wir alle gelernt haben: diese Bezeichner sind nicht aussagekräftig. Andererseits ist es gängig T, C, V, A, K, M etc. bei Templates zu verwenden, obwohl hier genauso ordentliche Namen hingehören würden. Denn diese kurzen Bezeichner machen die Templates nur schwerer zu lesen.

ein

template<typename I1, typename I2>
I2 copy(I1 start, I1 end, I2 start2);

ist 'ok'
aber ein

template<typename OutIter, typename InIter>
InIter copy(OutIter start, OutIter end, InIter target);

wäre _viel_ besser.

Niemand würde ernsthaft eine Klasse I1 nennen oder eine Variable i1 - aber sobald wir bei Templates sind gehört das zum guten Ton?

'Warum' frage ich. Alles was ich als antwort bekomme ist "kann man doch eh lesen" - aber was ist so schlecht an lesbaren Bezeichnern? Warum nur bei Templates? Was hindert einem daran die paar Zeichen mehr zu schreiben?

PAD

Da hier ja 2 Elemente beteiligt sind und die gewählten "langen" Namen ja auch wirklich erklärend wirken und somit zur Dokumentation und Erklärung dienen ist diese Form definitiv vorzuziehen

und das deckt sich mit dem hier schon mehrfach erwähnten Motto
So viel wie nötig, so wenig wie möglich.

mantiz

Ich kann Dein Problem an der ganzen Sache nicht wirklich verstehen. Aber wir werden uns hier glaube ich eh ständig im Kreis drehen, ohne uns wirklich einigen zu können, glaube ich.

Bei Klassen und Funktionen wählt man recht aussagekräftige Bezeichner, soweit ich weiß auch in erster Linie in der Schnittstelle, alles, was klassenintern ist, ist wieder so eine andere Geschichte.

Das "T" in den Templates ist ja nur ein Platzhalter für "irgendwas", wenn ich eine Templatefunktion habe, dann habe z.B.

template<typename R, typename T, typename X>R TuWas(T Key, X Value) { ... }

Den Typen bestimme ich, wenn ich das Template aufrufe, und die IDE zeigt mir die Namen der Parameter an, also weiß ich doch trotzdem, welcher Parameter an welcher Stelle wofür steht. Wenn ich

template<typename ReturnType, typename KeyType, typename ValueType>ReturnType TuWas(KeyType Key, ValueType Value) { ... }

habe, dann halte ich das irgendwie für doppelt gemoppelt. Warum soll ich da unbedingt "ValueType" angeben, wenn es doch durch den Bezeichner klar ist, dass da der Typ des "Values" angegeben wird?

Zu der i1-Geschichte: Meine PHP-Sources sind voll von Schleifen, wo ich $i1, $i2, etc. verwende. $i1 für die äußerste Schleife, usw. So kann ich jederzeit jede Laufvariable zuweisen. Bei i, j, k, l würde mir dies schwerer fallen.

finix

Shade Of Mine schrieb:

Niemand würde ernsthaft eine Klasse I1 nennen oder eine Variable i1 - aber sobald wir bei Templates sind gehört das zum guten Ton?
'Warum' frage ich. Alles was ich als antwort bekomme ist "kann man doch eh lesen" - aber was ist so schlecht an lesbaren Bezeichnern? Warum nur bei Templates? Was hindert einem daran die paar Zeichen mehr zu schreiben?

Auch bei Templates nennst du ja nicht die Klasse T oder sonstwas sondern nur die Templateparameter.
'Von Außen' ist da nirgends etwas einbuchstabiges zu sehen, nur innerhalb des Templates; dort sollte dann auch leicht ersichtlich wofür es steht (falls es sich nicht ohnehin um eine Lib handelt wo lediglich die Doku ausschlaggebend ist/sein sollte.)

Das ganze zählt natürlich nur für - im weitesten Sinne - Container-of-T, super-generische Algos oder sonstige 'klare Fälle' ( ). Ansonsten zählt natürlich, wie schon zuvor angemerkt und auch nie anders in meinen Beispielcodes zu finden, sinnvolle Bezeichner zu finden und schlicht ein (Konvention) T oder Type anzuhängen, sofern die Natur des Bezeichners (z.B. "fooPolicy") ersichtlich ist.

Shade Of Mine

Es gibt kein aussen und innen.
Es ist alles der Code den man warten muss.

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

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

Vergleich mal meine 2 copys. Welches ist leichter lesbar?

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

template<typename Result, typename Key, typename Value> Result tuWas(Key key, Value value) { ... }

Denn damit ist sofort klar was tuWas nun liefert. Nämlich Result. Ein R? was wäre R? Hat das R innerhalb der Funktion eine bestimmte Rolle? Ist es nur Result oder etwas Reziprokes? Reversal? Refund? Repeat? Restrict?

Tut es weh die paar Buchstaben zu schreiben?

Nehmen wir eine beliebige Funktion (ohne Templates)
R f(A a)
cool, was macht die denn? Keine Ahnung.
jetzt mit Templates:

template<typename R, typename A>
R f(A a)

jetzt ist alles klar, stimmts?

Wie man erkennt, ändert sich die Bedeutung ob mit oder ohne Templates nicht. Ein Typ A sagt mir nix. ein Product, Factor, LoopCondition oder was auch immer hilft mir aber den Sinn sofot zu verstehen.

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

template<typename A, typename B>
A copy(B b1, B b2, A a);

das ist eure Methode: kurze Bezeichner, weil es ja eh klar ist was sie machen.

Ich behaupte aber

template<typename InIter, typename OutIter>
InIter copy(OutIter start, OutIter end, InIter target);

ist besser lesbar.

Natürlich kann A nahezu jeder Typ sein, aber lustigerweise macht es nur mit einem Iterator-Typ Sinn.

Oder nehmen wir

template<typename T, class A, class C>
class Stack
{};

Alles klar?
Nein?
Wie wäre es mit:

template<typename Type, class Allocator, class ContainerImpl>
class Stack
{};

jetzt _ist_ es klar.

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.
Bei i und j weiss ich es: ich habe 2 Schleifen: i ist die äußere j die innere. Ich würde zwar nie i1, i2, i3 dafür verwenden, aber das mag auch ok sein. Wichtig ist: ich sehe den Namen und weiss welche Rolle er spielt. Das ist bei T aber _unmöglich_.

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.
ein
template<typename A, typename B, typename C>
zu lesen ist dagegen schwer.

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 unnötig ist' ist eine doofe Begründung. 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!