"xxx or return;" vs. "if (!xxx) return;"

[pumuckl]

Hi!

In vielen Skriptsprachen liest man ja haeufig kurze Statements wie

$file = open("bla.txt") or die

was dann in etwa heisst, dass wenn der erste Ausdruck false liefert, das Programm terminiert wird. Ist sowas in C++ auch erlaubt? Machbar ist es, bsp

int i;
cin >> i or return 0;

Ich frage mich allerdings, ob der Compiler das eventuell wegoptimieren darf, da der temporaer erzeugte bool ja nicht benutzt wird, oder ob es andere Gruende gibt, die gegen so etwas sprechen.

[hey]

pumuckl schrieb:

Machbar ist es, bsp

int i;
cin >> i or return 0;

welchen compiler nutzt du denn bitte, dass DAS funktioniert? o.O

in c oder c++ ist wohl

int i;
!(cin >> i) ? return -1 : /* foo */;

angebrachter...

[Bashar]

Ist return neuerdings ein Ausdruck? Falls ja, warum sollte er das wegoptimieren dürfen?

[qqqq]

nur ein test..

or  and   xor not

[pumuckl]

okay, mit or return war ein griff ins Klo, allerdings funktioniert folgendes bei mir:

int main() {
  int i;
  std::cin >> i or std::cout << "pfui!" << std::endl;
  std::cout<< "ende" << std::endl;
}

[Bashar]

Ja, warum soll das nicht gehen. Üblicher ist es aber trotz aller Hübschheit von or, den || Operator zu verwenden.

[Konrad Rudolph]

Bashar schrieb:

Ja, warum soll das nicht gehen. Üblicher ist es aber trotz aller Hübschheit von or, den || Operator zu verwenden.

„Üblicher“ – bä. In allen anderen Sprachen, wo beide Alternativen erlaubt sind, setzen sich „and“ und „or“ immer mehr durch, nur in C++ ist das anders. Woran liegt das? Sind C++-Programmierer so verbohrt? Ich persönlich vermute ja, dass es eher daran liegt, dass der Compiler des sympathischen Weltmarktführers das nicht unterstützt.

Aber sei's drum: „Üblicher“ ist hier kein gutes Argument, tut mir leid. Ich verwende durchweg „and“ und „or“, weil's besser lesbar ist. Klar, das ist subjektiv aber allemal ein besseres Argument.

[pumuckl]

Konrad Rudolph schrieb:

Ich persönlich vermute ja, dass es eher daran liegt, dass der Compiler des sympathischen Weltmarktführers das nicht unterstützt.

Es gibt aktuelle Compiler die das nicht unterstuetzen? Ich mein, ich versteh es ja, wenn ein Compiler bei zwar standardkonformen, aber extrem komplizierten Templategeschichten das Handtuch schmeissen, aber die Unterstuetzung von or, and & co zu implementieren, die wenn ich nicht irre schon seit Jahren im Standard sind, sollte doch nicht so schwer sein oder?

[Konrad Rudolph]

pumuckl schrieb:

Konrad Rudolph schrieb:

Ich persönlich vermute ja, dass es eher daran liegt, dass der Compiler des sympathischen Weltmarktführers das nicht unterstützt.

Es gibt aktuelle Compiler die das nicht unterstuetzen?

MSVC.

Auf meinen Fehlerbericht kam von MS der folgende Kommentar:

Jonathan Caves schrieb:

#include of <iso646.h> (or ciso646) is how we support these keywords: and currently have no plans to change this. To be honest you are the first person to ever request something like this.

IMHO Unbefriedigend.

aber die Unterstuetzung von or, and & co zu implementieren, die wenn ich nicht irre schon seit Jahren im Standard sind, sollte doch nicht so schwer sein oder?

Es müsste reichen, die Lexeme der Symboltabelle hinzuzufügen und intern gleichwertig mit den konventionellen Symbolen zu behandeln.

[Badestrand]

Es wird unterstützt, nur muss man dafür eine extra Header-Datei einbinden und die Wörter sind nicht Schlüsselwort-farben, was sich aber (umständlich) durch einen Eintrag in einer Zusatz-Schlüsselwörter-Datei machen lässt.

[pumuckl]

Konrad Rudolph schrieb:

IMHO Unbefriedigend.

Was ist dem noch hinzuzufuegen? Nichts. Gut dass es noch andere Compiler gibt...

[Braunstein]

Bei den Borland-Compilern ist es auch nicht anders. Hier muss man iso646.h mit einbinden. Also Makros.

[HumeSikkins]

Konrad Rudolph schrieb:

Aber sei's drum: „Üblicher“ ist hier kein gutes Argument, tut mir leid. Ich verwende durchweg „and“ und „or“, weil's besser lesbar ist. Klar, das ist subjektiv aber allemal ein besseres Argument.

Sehe ich anders. Was "Üblicher" und "besser lesbar" ist, hängt davon ab, wer den Code liest/bearbeitet. Wenn ich an einem Projekt mit 10 C++ Programmierern arbeite und 8 davon schreiben || statt or, dann ist || sowohl "üblicher", als auch "besser lesbar" und demzufolge die richtige Wahl. Schreibt die Mehrheit hingegen lieber or, dann ist or die bessere Wahl. Wer nur für sich selbst schreibt, kann natürlich einzig und allein seinen eigenen Geschmack als Maßstab verwenden, aber derjenige ist sowieso in eine glücklichen Situation

Ist für mich exakt das Selbe wie mit den verschiedenen Bracing-Styles.

[Konrad Rudolph]

HumeSikkins schrieb:

Sehe ich anders. Was "Üblicher" und "besser lesbar" ist, hängt davon ab, wer den Code liest/bearbeitet. Wenn ich an einem Projekt mit 10 C++ Programmierern arbeite …

Ja, das ist etwas anderes. Coderichtlinien in einem Projekt sollten natürlich schon konsistent durchgesetzt werden. Wobei man sich darüber streiten kann, ob sie dermaßen detailliert sein müssen.

[pumuckl]

Naja, eigentlich sollten z.B. die Bracing-styles und im Grunde auch solche Sachen doch alle gleich lesbar sein, schliesslich liest man sich doch auch durch diverse Literatur und schreibt nicht gleich ne Meckermail an den Autor oder Verlag "das entspricht nicht dem Coding-Style den ich gewohnt bin, bitte aendert das" - Hauptsache man bleibt in einer Sourcefile konsistent...

[hustbaer]

pumuckl schrieb:

okay, mit or return war ein griff ins Klo, allerdings funktioniert folgendes bei mir:

int main() {
  int i;
  std::cin >> i or std::cout << "pfui!" << std::endl;
  std::cout<< "ende" << std::endl;
}

Es müsste auch das gehen:

#if defined(_MSC_VER) && !defined(or)
#include <iso646.h>
#endif

inline bool die(char const* message = "WTF???")
{
    printf("\n\nfatal error: %s\n", message);
    terminate();
    return false;
}

int main()
{
    int i;
    (std::cin >> i) or die("invalid input");
}

[Bashar]

pumuckl schrieb:

Naja, eigentlich sollten z.B. die Bracing-styles und im Grunde auch solche Sachen doch alle gleich lesbar sein[...]Hauptsache man bleibt in einer Sourcefile konsistent...

Du meinst also, wenn man ein Sourcefile anfasst, das jemand anders geschrieben hat, soll man erstmal dessen Stil analysieren und den dann auch umsetzen?

[Konrad Rudolph]

Bashar schrieb:

pumuckl schrieb:

Naja, eigentlich sollten z.B. die Bracing-styles und im Grunde auch solche Sachen doch alle gleich lesbar sein[...]Hauptsache man bleibt in einer Sourcefile konsistent...

Du meinst also, wenn man ein Sourcefile anfasst, das jemand anders geschrieben hat, soll man erstmal dessen Stil analysieren und den dann auch umsetzen?

Ja. Das ist schließlich in OS-Projekten gang und gäbe, individuelle Style Guidelines für das Projekt zu publizieren.

[Bashar]

Konrad Rudolph schrieb:

Bashar schrieb:

pumuckl schrieb:

Naja, eigentlich sollten z.B. die Bracing-styles und im Grunde auch solche Sachen doch alle gleich lesbar sein[...]Hauptsache man bleibt in einer Sourcefile konsistent...

Du meinst also, wenn man ein Sourcefile anfasst, das jemand anders geschrieben hat, soll man erstmal dessen Stil analysieren und den dann auch umsetzen?

Ja. Das ist schließlich in OS-Projekten gang und gäbe, individuelle Style Guidelines für das Projekt zu publizieren.

Lesen. Denken. Posten.

[hustbaer]

Da braucht man doch kaum was zu analysieren, 95% sieht man doch eh auf den 1. Blick.

Ich muss mich jedesmal ziemlich zurückhalten wenn jmd. neu zu einem Team/Projekt kommt, und einfach in "seinem Stil" anfängt Code zu schreiben, ohne Rücksicht auf bestehenden Code. (zurückhalten deswegen weil's ja nicht jeder mit Humor nimmt wenn man ihm 10 Minuten lang in gehobener Lautstärke erklärt dass er ein dummer Vollkoffer ist )

Alternative, wenn man alleine ein altes Projekt übernimmt oder das ganze Team findet das der alte Stil furchtbar ist: das gesamte Projekt umformatieren. Dazu gibt es ganz gute Tools, mit denen man auch mehrere zigtausend Zeilen in ein paar Minuten umformatiert hat.

p.S.: was jedermann für sich alleine zuhause oder sonstwo macht wo es mich nicht betrifft ist mir natürlich egal, soll jeder machen wie er glaubt. Gröber ärgern tut es mich bloss wenn es in der Arbeit passiert, bei Sourcen an denen ich dann u.U. auch noch arbeiten muss, bzw. auch nur wenn ich die mal lesen/kontrollieren/... muss.