AND - Operator



  • Hi,
    Danke für deine Antwort.
    Nein ich verwechsele AND und OR nicht, zumindest nicht, wie es in anderen Sprachen gebracht wird :).

    Das mit der Do-Schleife ist eh komisch, ich kenne halt Do-Until.

    Egal, wenns AND und OR ja gar nicht gibt kann das ja auch nicht gehehn, nur es gibt ein Syntax-Highlighting dafür.

    Wie hab ich mir das Vorzustellen mit der Do-Schleife, so in etwa?:

    Mache
    //irgendwas
    Solange wie count kleinergleich 1 ist und count größergleich 3 ist.

    Also ich will, dass er wenn man etwas außerhalb von 1-3 eingibt, dass dann wieder die Eingabe kommt.

    Kannst du oder irgendjemand verraten wie ich das dann schreiben muss?

    Vielen Dank
    arnonym



  • Doch, du verwechselst "and" und "or".
    Und es gibt KEINE Sprache in der "and" und "or" anders gebraucht werden.

    Lies dir das mal durch.
    http://de.wikipedia.org/wiki/Logischer_Operator



  • arnonym schrieb:

    Wie hab ich mir das Vorzustellen mit der Do-Schleife, so in etwa?:

    Mache
    //irgendwas
    Solange wie count kleinergleich 1 ist und count größergleich 3 ist.

    Ich glaube dieses hier funktioniert besser:

    Mache
        // irgendwas
    Solange folgendes gilt: count kleinergleich 1 oder count größergleich 3
    

    Hier passt ein "und" nicht mehr, da count ja nicht gleichzeitig <2 und >2 sein kann.



  • übrings gibt es die operatoren wirklich mit namen
    and
    or
    xor
    ...



  • Hi,
    ich habs jetzt 🙂

    do{
        cout<<"Geben sie ein wieviele Muenzen sie wegnehmen moechten (1-3): ";
        cin >> count;
    }while((count<1||count>3));
    

    Dank Badestrands Erklärung hab ich jetzt kapiert, wie das mit der Do-Schleife funktioneirt.

    Und nein, ich verwechsele OR und AND nicht ich habe nur nicht gewusst, wie das umzusetzen war mit der Do-Schleife.

    Und scheinbar ist es ja auch egal, ob man or oder || benutzt.
    Aber normalerweise benutzt man || oder wie?

    Danke für die Hilfe 🙂
    arnonym



  • Ja. || bzw. && ist eben der dafür zugehörige Operator, der in C++ auch garantiert funktioniert. and und or gehen eigentlich nicht ohne Weiteres (es sind keine Schlüsselwörter der Sprache, auch wenn sie hier im Forum hervorgehoben werden).

    Übrigens:

    }while((count<1||count>3));
    

    würde ich eher so schreiben, ist aber natürlich Geschmackssache. Nur finde ich es übersichtlicher:

    while (count < 1 || count > 3);
    

    Pass ausserdem auf, dass du count nicht verwendest, wenn du den Namensraum std mittels using namespace bekannt gemacht hast und irgendwo die STL-Algorithmen eingebunden werden, sonst kommt es zu Namenskonflikten ( std::count() ist eine Funktion der Standardbibliothek).



  • Nochmals DANKE für die netten Tipps.

    😉

    arnonym



  • Nexus schrieb:

    Ja. || bzw. && ist eben der dafür zugehörige Operator, der in C++ auch garantiert funktioniert. and und or gehen eigentlich nicht ohne Weiteres (es sind keine Schlüsselwörter der Sprache, auch wenn sie hier im Forum hervorgehoben werden).

    Es sind DOCH Schlüsselwörter der Sprache, Standard Paragraph 2.5 - Alternative tokens - aber ich würde trotzdem lieber && und || verwenden, weil es üblicher ist. Außerdem wird and und or vom Microsoft Compiler nicht untersützt so weit ich weiß.

    Felix



  • Phoemuex schrieb:

    ...

    Man kann auch das hier schreiben:

    struct foo
    ??<
    	foo ()??<??>
    	??-foo()??<??>
    	int var??(2??);
    ??>;
    

    Gültiges C++. 😉



  • drakon schrieb:

    Phoemuex schrieb:

    ...

    Man kann auch das hier schreiben:

    ...
    

    Gültiges C++. 😉

    Der Unterschied ist, dass ??< &Co. Trigraphsequenzen sind die vom Präprozessor ersetzt werden, ihr Zweck ist, fremdländische Tastaturlayouts zu unterstützen wo die vorgesehenen Klammern nicht oder nur schlecht zu erreichen sind. and, or etc. sind dagegen alternative Token die nicht vom Präprozessor berührt werden und lediglich vom Lexer in das selbe Token übersetzt werden wie das zugehörige primary token. Zwar gibts auch da einige die so aussehen als ob sie für fremde Tastaturen gedacht sind ( z.B. "<?" als alternative zu "{" ), aber grundsätzlich sind sie als gleichberechtigte Alternative zu sehen im Gegensatz zum behelfsmäßigen Ersatz den die Trigraphsequenzen bieten.
    Gerade die Alternativen für die Bit- und logischen Operatoren sind in den AUgen vieler durchaus flüssiger zu lesen und intuitiver zu verstehen, wenn man sich denn schon dran gewöhnt hat, z.B. von anderen Sprachen her. Der wohl einzige Grund warum man sie in C++ so selten sieht ist das M$ wiedermal sein eigenes Süppchen kocht und einen nicht standardkonformen Compiler hat der die Dinger nicht unterstützt.



  • pumuckl schrieb:

    Der wohl einzige Grund warum man sie in C++ so selten sieht ist das M$ wiedermal sein eigenes Süppchen kocht und einen nicht standardkonformen Compiler hat der die Dinger nicht unterstützt.

    Soviel Einfluss hat MS nun auch wieder nicht. Eher dürfte es andersrum sein, MS unterstützt das nicht, weil es niemand haben will. Von ein, zwei Leuten hier im Forum abgesehen, wie es scheint 😉



  • sdfsdf schrieb:

    Doch, du verwechselst "and" und "or".
    Und es gibt KEINE Sprache in der "and" und "or" anders gebraucht werden.

    so wie er die do schleife kennt, also do -> until, dann wäre das richtig...

    das wäre ja folgendes

    mache
    //folgendes
    bis (count > 1) UND (count < 3)

    dann wäre ein und statt oder angebracht



  • arnonym schrieb:

    Hi,
    ich habs jetzt 🙂

    do{
        cout<<"Geben sie ein wieviele Muenzen sie wegnehmen moechten (1-3): ";
        cin >> count;
    }while((count<1||count>3));
    

    ich würd sagen du brauchst da && und nicht ||



  • Bashar schrieb:

    pumuckl schrieb:

    Der wohl einzige Grund warum man sie in C++ so selten sieht ist das M$ wiedermal sein eigenes Süppchen kocht und einen nicht standardkonformen Compiler hat der die Dinger nicht unterstützt.

    Soviel Einfluss hat MS nun auch wieder nicht. Eher dürfte es andersrum sein, MS unterstützt das nicht, weil es niemand haben will. Von ein, zwei Leuten hier im Forum abgesehen, wie es scheint 😉

    Würd ich auch so sehen. and und or werden auch in den wenigsten Büchern erläutert und sind kaum gebräuchlich. Und was das Umstellen von anderen Sprachen betrifft: Versuche, Dinge aus anderen Sprachen in C++ zu übernehmen, führen nicht selten zu Problemen (allgemein gesehen). Übrigens, pumuckl, zeig mir bitte mal einen 100% standardkonformen Compiler. 😉

    Skym0sh0 schrieb:

    so wie er die do schleife kennt, also do -> until, dann wäre das richtig...

    das wäre ja folgendes

    mache
    //folgendes
    bis (count > 1) UND (count < 3)

    dann wäre ein und statt oder angebracht

    Ja, nur hat er zusätzlich noch die falschen Vergleichsoperatoren verwendet ( count < 1 bzw. count > 3 ). 😉

    Gustl schrieb:

    ich würd sagen du brauchst da && und nicht ||

    Wie wärs mit Thread lesen? Bereits der erste Antwortpost weist darauf hin, dass das nicht sinnvoll ist. Man erkennt ausserdem durch eine Sekunde überlegen, dass die Bedingung count < 1 && count > 3 immer false ergibt...

    Aber ja, Hauptsache, man hat noch etwas dazu gesagt... 🙄



  • ***ironiedetektor justiert***



  • Nexus schrieb:

    Übrigens, pumuckl, zeig mir bitte mal einen 100% standardkonformen Compiler. 😉

    Ich bin ziemlich sicher dass es den nicht gibt. Mit dem Stichwort export kann man bis auf ein oder zwei alle Compiler ausschließen, und vermutlich haben die dann woanders kleine Problemchen, template-Geschichten sind ja prädestiniert dafür. Aber darum gings mir nicht, denn die meistenStandard-Inkompatibilitäten kommen bei vergleichsweise komplizierten Konstrukten vor, eben templates & Co.
    MS jedoch weigert sich aus nicht nachvollziehbaren Gründen einfach dem Lexer noch die paar zusätzlichen Token beizubringen die im Standard explizit erwähnt werden, das wäre nichts besonders kompliziertes. Dass so wenige die Dinger benutzen und sie auch in Büchern nur am Rande erwähnt werden (wenn überhaupt) liegt vermutlich hauptsächlich daran, dass man nunmal portablen Code fabrizieren will und der MS-Compiler zumindest in der Windows-Domäne serh weit verbreitet ist.



  • So schlimm ist das nun wirklich nicht, dass and und or von Microsoft nicht unterstützt werden (auch wenns dir ums Prinzip geht). Wie gesagt, wird sowieso meistens && und || verwendet, und sonst wird niemand daran gehindert, eigene Makros zu definieren.


  • Administrator

    Die Operatoren and/or/usw. werden von Microsoft auch unterstüzt. Allerdings nur als Makros und müssen zusätzlich inkludiert werden:
    http://msdn.microsoft.com/en-us/library/bw6140c5(VS.80).aspx

    Es gibt auch irgendwo in einem der Foren oder Bugmeldesystemen einen Thread über eben jenes Feature, wo sich Microsoft dazu äussert, dass noch kaum irgendjemand sich dazu geäussert hätte, dass diese Schlüsselwörter vermisst würden. Man sehe keine Nachfrage diese zu implementieren.

    Grüssli


  • Mod

    Standardkonformität ist kein Wert an sich sondern nur Mittel zum Zweck. Man kann und darf vieles an Microsofts Politik kritisieren, aber zumindest hier ist die Reaktion völlig logisch und sinnvoll. Es besteht die - geringe - Gefahr, dass durch diese zusätzlichen Schlüsselwörter existierender Code plötzlich nicht mehr funktioniert, umgekehrt wird durch die Einführung dieser Schlüsselwörter nichts gewonnen. Die einzigen standardkonformen Programme, bei denen es eine Rolle spielen könnte, sind solche, die diese Schlüsselwörter benutzen wollen, ohne den Header ciso646 bzw. iso646.h einzubinden (in einem standardkonformen Programm, dass den Header inklusiert, kann man den Unterschied zwischen Schlüsselwort und Makro überhaupt nicht feststellen...). Dieses Problem hat eine offensichtliche und einfache Lösung, die nicht einmal erst irgendwie durch umständliches Konfigurieren entsteht, da man diese Header immer bedingungslos inkludieren kann. Den Gralshüter der Standardkonformität zu spielen führt nicht weiter. Zumindest sollte man erst einmal die Frage stellen, wieso diese Wörter überhaupt Schlüsselwörter sein müssen - ich kann hier keinen plausiblen Grund erkennen. Immerhin kommt C auch mit den Makrodefinitionen gut zurecht.

    Die Situation unterscheidet sich wesentlich etwa von der Frage der Unterstützung von export - und dass export nicht unterstützt wird, kann man durchaus auch als gut ansehen, gemessen daran, wie unausgereift dessen Definition ist.


Anmelden zum Antworten