3. [and or xor] vs. [&& || ?]

[and or xor] vs. [&& || ?]

  • ?

    Da es sich bei and, or und xor um Keywords handelt halte ich die
    Konstruktionen:
    #define and &&
    ...
    für ausserordentlich schlecht.

    Wenn jemand nichts für die jetzigen Operatoren übrig hat dann ist nachfolgendes sicher die bessere Lösung:
    #define AND &&
    ...

    Für einen Menschen spielt der Unterschied zwischen AND und and
    glücklicherweise keine so grosse Rolle wie für einen Compiler bzw.
    Standardisierung. 😉

    0
  • G

    Die heuten Compiler brauchen keine #define and/AND &&
    Nur die alten comilier.

    0
  • V

    Redhead schrieb:

    Da es sich bei and, or und xor um Keywords handelt halte ich die
    Konstruktionen:
    #define and &&
    ...
    für ausserordentlich schlecht.

    genau desdawegen macht man #define and &&.
    und nicht #define AND &&.
    weil der alte compiler kaputt ist. das ist ein BUGFIX und hat nix mit freier entfaltung der personlichkeit unter sozioökonomischen aspekten der farblichen gestaltung alter compiler zu tun.
    es ist kein abweichen vom standard, wie die anderen keyword-wegdefines ala

    #define goto fOrbiDDeN

    es ist definen zum standard hin.

    0
  • W

    Redhead schrieb:

    Da es sich bei and, or und xor um Keywords handelt halte ich die
    Konstruktionen:
    #define and &&
    ...
    für ausserordentlich schlecht.

    Warum? Im schlimmsten Fall hat man das keyword nachträglich nochmal definiert.

    0
  • F

    Redhead schrieb:

    Da es sich bei and, or und xor um Keywords handelt halte ich die
    Konstruktionen:
    #define and &&
    ...
    für ausserordentlich schlecht.

    Wenn jemand nichts für die jetzigen Operatoren übrig hat dann ist nachfolgendes sicher die bessere Lösung:
    #define AND &&
    ...

    Für einen Menschen spielt der Unterschied zwischen AND und and
    glücklicherweise keine so grosse Rolle wie für einen Compiler bzw.
    Standardisierung. 😉

    config.hpp, anyone?
    btw, der Unterschied zwischen AND und UND ist auch nicht allzu groß...

    0
  • G

    config.hpp, anyone?
    btw, der Unterschied zwischen AND und UND ist auch nicht allzu groß...

    Mir dem Unterschied das UND eine Variable sein kann...
    Das gleiche wie meine Grossmutter und meine Mutter einen unterschied haben.

    0
  • A

    volkard2 schrieb:

    und and ist einfach besser als &&

    Warum? Bessere Lesbarkeit 🤡, persönliche Abneigung, Ironie?

    0
  • V

    audacia schrieb:

    volkard2 schrieb:

    und and ist einfach besser als &&

    Warum? Bessere Lesbarkeit 🤡, persönliche Abneigung, Ironie?

    code mit viel && und || ist zu schwer zu lesen, wie folgender ausschnitt beweist:

    bool datumIstGueltig(int tag,int monat,int jahr)
{
   return monat>0&&monat<13&&tag>0&&tag<32&&(tag<31¦¦(monat>7!=monat%2==1))
   &&(monat!=2¦¦(tag<30&&(((jahr%4==0&&jahr%100!=0)¦¦jahr%400==0)¦¦tag<29)));
}
    0
  • N

    ich bin auch dafür, dass aus '{' endlich 'begin' und aus '}' ein 'end' wird 😉

    0
  • A

    volkard schrieb:

    code mit viel && und || ist zu schwer zu lesen, wie folgender ausschnitt beweist:

    bool datumIstGueltig(int tag,int monat,int jahr)
{
   return monat>0&&monat<13&&tag>0&&tag<32&&(tag<31¦¦(monat>7!=monat%2==1))
   &&(monat!=2¦¦(tag<30&&(((jahr%4==0&&jahr%100!=0)¦¦jahr%400==0)¦¦tag<29)));
}

    Und welches von denen findest du leserlicher 🤡?

    bool datumIstGueltig(int tag,int monat,int jahr)
{
   return monat > 0 && monat < 13 && tag > 0 && tag < 32 && (tag < 31 || (monat > 7 != monat % 2 == 1))
   && (monat != 2 || (tag < 30 && (((jahr % 4 == 0 && jahr % 100 != 0) || jahr % 400 == 0) || tag < 29)));
}
bool datumIstGueltigMitAndUndOr(int tag,int monat,int jahr)
{
   return monat > 0 and monat < 13 and tag > 0 and tag < 32 and (tag < 31 or (monat > 7 != monat % 2 == 1))
   and (monat != 2 or (tag < 30 and (((jahr % 4 == 0 and jahr % 100 != 0) or jahr % 400 == 0) or tag < 29)));
}

    Oder meinst du, and, or etc. sind besser, weil sie den Programmierer zwingen, zwischen Operatoren und Operanden Leerzeichen zu machen?

    0
  • F

    Green_Ghost schrieb:

    config.hpp, anyone?
    btw, der Unterschied zwischen AND und UND ist auch nicht allzu groß...

    Mir dem Unterschied das UND eine Variable sein kann...

    Der war gut 😃 👍

    Green_Ghost schrieb:

    Das gleiche wie meine Grossmutter und meine Mutter einen unterschied haben.

    Ich bin mir zwar nicht sicher was du mit dieser Äußerung ausdrücken willst, aber mach dir mal Gedanken was ich mit meiner bezweckte.

    0
  • G

    Green_Ghost schrieb:

    Soll ich and,or,xor nicht mehr gebrauchen *zweifelanmir*

    Nunja, ist letztendlich persönliche Geschmackssache. Trotzdem sollte man sich darüber im Klaren sein, dass man mit and, or, xor, etc. keine Vorteile hat
    - längere Schreibweise (zB bitand gegenüber &)
    - 99,9% aller C++ Programmierer nutzen es nicht (dh, du musst dir letztendlich sowieso beide Schreibweisen aneignen, wenn du Fremdcode verstehen willst)
    - und wenn du's nutzt, dann musst du es auch generell durchziehen - ein 'a not_eq b' ist ja noch möglich, aber was machst du bei 'a == b'? Wieder mit #defines Unzulänglichkeiten beseitigen?
    - audacia's Beispiel hat gezeigt, dass man damit keine leserlichen Vorteile hat - ausschlaggebend dafür ist immer noch die Codegestaltung des Programmieres. Und wer solchen Code wie den von volkard schreibt, sollte sich einfach mal 'ne neue Tastatur kaufen, wo die Leertaste auch funktioniert. 🙂
    - zudem hat 'a and b' diesen VB Touch 😮 🙂

    0
  • O

    groovemaster schrieb:

    - zudem hat 'a and b' diesen VB Touch 😮 😃

    Eigentlich finde ich keins der Argumente sonderlich überzeugend, aber das hier ist wohl leider das, was für viele Leute den Ausschlag geben wird... man lernt ja schließlich nicht die komplexeste aller Mainstream-Programmiersprachen, um am Ende Code in englischen Worten zu verfassen 🙄

    0
  • K

    groovemaster schrieb:

    Nunja, ist letztendlich persönliche Geschmackssache. Trotzdem sollte man sich darüber im Klaren sein, dass man mit and, or, xor, etc. keine Vorteile hat
    - und wenn du's nutzt, dann musst du es auch generell durchziehen - ein 'a not_eq b' ist ja noch möglich, aber was machst du bei 'a == b'? Wieder mit #defines Unzulänglichkeiten beseitigen?

    Kann ich nicht nachvollziehen. Es gibt eben einige Operatoren ('+' ...) die einen fest etablierten Zeichencode haben und es gibt solche, die man ausschreibt. 'sizeof' und 'typeid' sind schließlich auch Operatoren.
    In anderen Sprachen ist es gang und gäbe, 'and', 'or' etc. zu schreiben. Ich muss volkard recht geben, es ist übersichtlicher. Hmm, mag Ansichtssache sein. Aber ich finde, man sollte die Menge an "ASCII-Art" im Code minimieren. In Ausdrücken ist es für mich persönlicher, Zeichen zu verwenden, weswegen ich auch '&' statt 'bitand' schreiben würde. Aber in "normalem" Code finde ich die textuelle Variante lesbarer. Klar, eine Bedingung ist letztendlich auch nur ein Ausdruck. Aber ich denke, jeder Programmierer fasst eine Verknüfung mehrerer Bedingungen intuitiv nicht wie eine mathematische Formel auf; 'and', 'or' sind hier also durchaus angebracht.

    groovemaster schrieb:

    - zudem hat 'a and b' diesen VB Touch

    Sieh's als Vorteil.

    0
  • F

    Zur englischen Sprache: Wer bitte schön 'übersetzt' denn && nicht sofort, zwangsläufig, ohne Mühe und unbewußt sofort mit der Bedeutung von "and"/"und"??

    operator void schrieb:

    Eigentlich finde ich keins der Argumente sonderlich überzeugend

    Auch die Verbreitung nicht?

    Konrad Rudolph schrieb:

    In anderen Sprachen ist es gang und gäbe, 'and', 'or' etc. zu schreiben.

    Und?

    Konrad Rudolph schrieb:

    In Ausdrücken ist es für mich persönlicher, Zeichen zu verwenden, weswegen ich auch '&' statt 'bitand' schreiben würde.

    Eh? "Persönlicher"? Hallo!? 🤡

    Konrad Rudolph schrieb:

    Aber in "normalem" Code finde ich die textuelle Variante lesbarer. Klar, eine Bedingung ist letztendlich auch nur ein Ausdruck.

    Was ist denn "normaler" Code? An der definition wär ich echt interessiert...
    Hast du auch #define plus + etc für "normalen" Code?

    Konrad Rudolph schrieb:

    Aber ich denke, jeder Programmierer fasst eine Verknüfung mehrerer Bedingungen intuitiv nicht wie eine mathematische Formel auf; 'and', 'or' sind hier also durchaus angebracht.

    Ja, stimmt. Mir fällt es auch immer wieder schwer Bool'sche Algebra in einen Zusammenhang mit der Mathematik zu stellen... 🙄

    0
  • K

    finix schrieb:

    Konrad Rudolph schrieb:

    In anderen Sprachen ist es gang und gäbe, 'and', 'or' etc. zu schreiben.

    Und?

    Nix und. Es gibt Leute, die das verwenden und normal finden. Ich sehe keinen Grund, wieso es in C++ weniger normal sein sollte.

    Konrad Rudolph schrieb:

    In Ausdrücken ist es für mich persönlicher, Zeichen zu verwenden, weswegen ich auch '&' statt 'bitand' schreiben würde.

    Eh? "Persönlicher"? Hallo!? 🤡

    Uh? Habe ich das geschrieben? *nachschau* tatsächlich. Äääh, ich meinte "lesbarer". Keine Ahnung, wie ich auf den Schwachsinn kam.

    Konrad Rudolph schrieb:

    Aber in "normalem" Code finde ich die textuelle Variante lesbarer. Klar, eine Bedingung ist letztendlich auch nur ein Ausdruck.

    Was ist denn "normaler" Code? An der definition wär ich echt interessiert...
    Hast du auch #define plus + etc für "normalen" Code?

    Wann kommt das denn mal im "normalen" Code vor? Der einzige nicht-mathematische Kontext vom '+', der mir jetzt einfällt, ist die String-Konkatenation. Und dort stört es mich auch irgendwie ziemlich. Man addiert schließlich keine Strings, man hängt sie aneinander ...

    Konrad Rudolph schrieb:

    Aber ich denke, jeder Programmierer fasst eine Verknüfung mehrerer Bedingungen intuitiv nicht wie eine mathematische Formel auf; 'and', 'or' sind hier also durchaus angebracht.

    Ja, stimmt. Mir fällt es auch immer wieder schwer Bool'sche Algebra in einen Zusammenhang mit der Mathematik zu stellen... 🙄

    Ich finde es intuitiver, eine verknüpfte Bedingung umgangssprachlich zu lesen. Klar, Boolesche Algebra ist hier anwendbar aber ich finde sie eigentlich fehl. Ich lese da lieber "Wenn Bedingung1 und Bedingung2 oder Bedingung3". Oder stellst Du im Kopf eine Logiktabelle auf, bildest die kanonische Form und vereinfachst die Terme, wenn Dir jemand sagt "Das Wetter ist schön und ich habe gute Laune, lass uns Fußballspielen gehen"?

    0
  • O

    finix schrieb:

    Zur englischen Sprache: Wer bitte schön 'übersetzt' denn && nicht sofort, zwangsläufig, ohne Mühe und unbewußt sofort mit der Bedeutung von "and"/"und"??

    Jeder, der nicht in einem Ableger der C-Familie programmiert?
    Man könnte auch if durch ?? und for durch -> ersetzen, nach ein paar Programmen würde man es ohne größere Probleme geistig übersetzen. Ich behaupte trotzdem, dass and und or ein klitzekleines Stück leichter verarbeitbar sind.

    finix schrieb:

    Auch die Verbreitung nicht?

    In dem selben Maß halt, wie alle Konventionen ein Argument sind. Wenn der Rest deines Teams && und || verwendet, fein, das wäre ein Argument. In einem eigenständigen Projekt sehe ich kein Problem darin, die "schönen" Keywords zu verwenden.

    finix schrieb:

    Hast du auch #define plus + etc für "normalen" Code?

    Es gibt einen gewissen Unterschied in der Verbreitung zwischen + und ||.

    0
  • F

    Konrad Rudolph schrieb:

    Was ist denn "normaler" Code? An der definition wär ich echt interessiert...
    Hast du auch #define plus + etc für "normalen" Code?

    Wann kommt das denn mal im "normalen" Code vor? Der einzige nicht-mathematische Kontext vom '+', der mir jetzt einfällt, ist die String-Konkatenation. Und dort stört es mich auch irgendwie ziemlich. Man addiert schließlich keine Strings, man hängt sie aneinander ...

    RTFM! 😉
    💡 ➡ mystring.append(foo) 👍

    Konrad Rudolph schrieb:

    Ich finde es intuitiver, eine verknüpfte Bedingung umgangssprachlich zu lesen. Klar, Boolesche Algebra ist hier anwendbar aber ich finde sie eigentlich fehl. Ich lese da lieber "Wenn Bedingung1 und Bedingung2 oder Bedingung3".

    Naja, wie gesagt, im C++-Kontext ist für mich && komplett equivalent zu 'and', auch vom Erfassen des Codes her. (Würde mich wundern wenn das für jemanden der schon einige Zeit programmiert anders wäre...)
    Außerdem lassen sich && and || und so viel leichter von Bezeichnern unterscheiden.

    Konrad Rudolph schrieb:

    Oder stellst Du im Kopf eine Logiktabelle auf, bildest die kanonische Form und vereinfachst die Terme, wenn Dir jemand sagt "Das Wetter ist schön und ich habe gute Laune, lass uns Fußballspielen gehen"?

    Umgangssprache und formale Sprache sind irgendwie schon zwei Paar Schuhe.
    Davon ab denke ich schon dass auch z.B. Tautologien o.ä. im "normalen Leben" auffallen, oder?

    0
  • V

    also fazitiere ich, daß and zwar schöner ist und aus ästhetischen gründen benutzt werden sollte, aber die betonschädel der c++-gemeinde sich nicht umstellen wollen, weil es zu basicisch ist.

    und natürlich soll man and in bedingungen nehmen aber nicht bitand in berechnungen. dieses eswige "wenn du a sagst, musst du auch b sagen", dieses "wenn du glockenbimmeln verbieten willst, musst du auch alle christen erschießen" (stets ohne herleitung, warum dieser zwang da sein sollte), ist ja langsam sowas von öde. das weltdümmste argument, und es ist bedauerlich, es hier so oft zu hören.

    0
  • D

    Ich höre zum erstenmal, das and C++-Standard sein soll, VC++ 2003 hat damit nichts am Hut (ist der jetzt schon so alt?). Und wenn ihr alle den Code net lesen könnt, dann teilt die Ausdrücke, der Compiler wirds schon wegoptimieren und macht kommentare!

    Naja, ich würd nen bisschen anderes Fazit ziehen, auf jedenfall werde ich garantiert kein and verwenden, weil es weder lesbarer noch irgendwas anderes ist.

    MfG
    DDR-RAM

    0
Anmelden zum Antworten