nachziehende spaces entfernen

[HumeSikkins]

Ist das mit "gruselts" neue Rechtschreibung oder einfach Unsinn?

Letzteres. Ich bin mittlerweile derart betriebsblind, dass ich nicht mal mehr raffe, dass "mich gruselt's" von mich "gruselt es" kommt und das Apostroph damit völlig zurecht dort steht.

[volkard]

Original erstellt von HumeSikkins:
Oder ist das mal wieder einer nach dem Motto:
a) STL ist scheiße, also ist auch dies hier scheiße (obwohl die zugegeben sehr häßliche string-Klasse strenggenommen nicht zur STL gehört)

Hab den ?: angemeckert, aber selber find_first_of oder sowas vorgeschlagen.

b) Ich verstehe den ternären Operator nicht, also müssen alle Menschen auf den Einsatz des selbigen verzichten und immer schön if-else benutzen.

Das hat nix mit verstehen zu tun. Bist du jetzt auch auf dem level, daß du gerne komplizierten code baust und jedem, der ihn anmeckert sagtst "tja, wer kein c++ kann, der soll meinen code nicht lesen".

"weils sonst zu einfach wäre".

Was wäre denn dein konkreter Vorschlag?
Na, auf jeden Fall if/else. Und mit ein wenig glück knn man dann, nachdem der code durch if/else leichter lesbar und veränderbar wurde, sogar noch ne signifikante vereinfachung finden. aber das haste ja schon.

[HumeSikkins]

Bist du jetzt auch auf dem level, daß du gerne komplizierten code baust und jedem, der ihn anmeckert sagtst "tja, wer kein c++ kann, der soll meinen code nicht lesen".

Mein Level hat sich nicht verändert. Und ich freue mich nach wie vor über jede ernsthafte Kritik. Besonders da ich noch nie mit meinem Code zufrieden war, aber selten weiß, wie ich es besser machen könnte.

Einen Satz wie "tja, wer kein c++ kann, der soll meinen code nicht lesen" würde ich nie sagen. Einen Satz wie "tja, wer den ternären Operator nicht versteht, der sollte schleunigst ein gutes Buch zur Hand nehmen und an seinem Verständnis arbeiten" aber dafür ganz bestimmt.

Und ich sehr wirklich nicht, warum ein

if (p == string::npos)
    return Elefant;
else
   return Huhn;

in irgendeiner Form besser zu lesen sein soll, als ein:

return p == string::npos ? Elefant : Huhn;

Ganz im Gegenteil.

Der ternäre Operator hat IMO einen Sinn.
Ist für mich wie mit dem i = i+1 vs. ++i (bzw. i++)

[ Dieser Beitrag wurde am 07.05.2003 um 18:33 Uhr von HumeSikkins editiert. ]

[volkard]

Original erstellt von HumeSikkins:
Einen Satz wie "tja, wer den ternären Operator nicht versteht, der sollte schleunigst ein gutes Buch zur Hand nehmen und an seinem Verständnis arbeiten" aber dafür ganz bestimmt.

Ich kann dich dahingehend beruhigen, daß ich den ?: durchaus kenne.

Und ich sehr wirklich nicht, warum ein

if (p == string::npos)
    return Elefant;
else
   return Huhn;

in irgendeiner Form besser zu lesen sein soll, als ein:

return p == string::npos ? Elefant : Huhn;

Ganz im Gegenteil.

Ich aber. Im einen Fall hat man Entscheidung und zwei Tätigkeiten in drei hübsch getrennten Zeilen und im anderen Fall hat man alles auf eine Zeile kompremiert, die in sich keine die lesbarkeit verbesserne unterteilunngen hat, und die man erst zerlegen kann, wenn man mit dem lesen schon bis zum ? gestoßen ist.

Der ternäre Operator hat IMO einen Sinn.
Ist für mich wie mit dem i = i+1 vs. ++i (bzw. i++)

Der ?: hat eher historischen Sinn. Es gab mal ne Zeit, da mußte man viel in Ausdrücken unterbringen, weils keine inline-Funktionen gab. Wir erinnern uns alle gerne an #define max(a,b) ((a)>(b)?(a):(b)).

[Daniel E.]

Original erstellt von volkard:
Im einen Fall hat man Entscheidung und zwei Tätigkeiten in drei hübsch getrennten Zeilen und im anderen Fall hat man alles auf eine Zeile kompremiert, die in sich keine die lesbarkeit verbesserne unterteilunngen hat, und die man erst zerlegen kann, wenn man mit dem lesen schon bis zum ? gestoßen ist.

Andersrum. Bei einem 'if' wird auf das (optionale) 'else' (gefolgt von einem weiteren optionalen 'if' ...) überhaupt kein Bezug genommen. Der ?:-Operator ist genau für den Spezialfall da, dass der zweite und der dritte Operand 'irgendetwas' gemeinsam haben und von einer gemeinsamen Bedingung abhängen.

[HumeSikkins]

Ich kann dich dahingehend beruhigen, daß ich den ?: durchaus kenne.

Glaub mir, dass würde ich *niemals* bezweifeln.

Der ?: hat eher historischen Sinn.

Das hingegen sehe ich anders. Die Möglichkeiten Bedingungen in Ausdrücken einzubauen braucht man gerade in C++ nach wie vor sehr häufig (const-, reference-Initialisierung, Bedingungen in der Initialisierungsliste usw.)
Und für Situationen wie "gib einem X einen von genau zwei möglichen Werten abhängig vom Wahrheitswert der Bedingung B" ist der :? meiner Meinung nach einfach das ausdrucksstärkste Sprachelement.

Im einen Fall hat man Entscheidung und zwei Tätigkeiten in drei hübsch getrennten Zeilen und im anderen Fall hat man alles auf eine Zeile kompremiert, die in sich keine die lesbarkeit verbesserne unterteilunngen hat, und die man erst zerlegen kann, wenn man mit dem lesen schon bis zum ? gestoßen ist.

Das gilt IMO nicht. Erstens kann ich auch den ?:-Code auf mehrere Zeilen verteilen und zweiten muss ich beim if bis zur schließenden Klammer lesen.

if (p == string::npos) return Elefant; else return Huhn;

return p == string::npos ? 
       Elefant 
       : Huhn;

Sehe da keinen Unterschied.
Einmal suche ich nach einem ? und einem Doppelpunkt und einmal nach einem if (+ schließende Klammer) und einem else.

[Lars]

Ich find das ist eine Diskussion gar nicht wert

[DrGreenthumb]

Original erstellt von HumeSikkins:
**Es reicht ein if, ein else ist unnötig.

void trimright(std::string& t)
{
  size_t p = t.find_last_not_of(" \t");
  if (p < t.length())
      t.erase(++p);
}

**

Da passiert bei " " allerdings nichts, was ich als unpraktisch empfunden habe.

Meine Funktion schaut nun so aus:

void trimright(std::string& t)
{
  size_t p = t.find_last_not_of(" \t");
  t.erase( p==string::npos ? 0 : p+1 );
}

Finde ich besser zu lesen als ein if/else.

[volkard]

Original erstellt von HumeSikkins:
**Das gilt IMO nicht. Erstens kann ich auch den ?:-Code auf mehrere Zeilen verteilen und zweiten muss ich beim if bis zur schließenden Klammer lesen.
**

normale

return x == string::npos;

bin ich ja gewohnt und deswegen beim darauffolgenden '?' immer erschreckt.

am if und der einrückung sehe ich gleich, daß es ein if mit else ist und ich seh auch gleich, daß da nur zwei returns sind. von syntax-highlighting gehe ich natürlich aus. damit ist die struktur schonmal klar.

bei

return x == bla (aus den augenwinkeln noch viele sachen gesehen)

weiß ich noch gar nix biß zum bewußten lesen des '?'. könnte ja auch return x == bla * 5 / 12; heißen. erst nach dem '?' wird mir die struktur klar.
da erfasse ich aber ein syntaxgehighlightetes if/else mit zwei returns drin besser.

[Lars]

Klammern können die struktur auch sehr deutlich machen - sinnvoll gesetzt.