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.

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

or  and   xor not

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

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.

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

IMHO Unbefriedigend.

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

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.

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.

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");
}

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?

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

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.

Lesen. Denken. Posten.

Erklären.

Oder, anders gesagt: „input underflow.“

Du: "Man sollte projektweit einheitliche Standards haben."
pumuckl: "Wozu, es reicht, wenn es innerhalb einer Quelldatei einheitlich ist."
Ich: "Man sollte also bei jedem File erstmal den individuellen Stil analysieren und nachbilden?"
Du: "Ja, deshalb hat man projekteinheitliche Style Guidelines". (Hä?)

Pumuckl bezog sich doch aber eher auf Hume als auf mich und widersprach mir damit nicht sondern stellte einen ähnlichen Standpunkt dar.

So zumindest habe ich das verstanden.