AND - Operator

[Nexus]

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

[arnonym]

Nochmals DANKE für die netten Tipps.

arnonym

[Phoemuex]

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

[drakon]

Phoemuex schrieb:

...

Man kann auch das hier schreiben:

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

Gültiges C++.

[pumuckl]

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.

[Bashar]

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

[Skym0sh0]

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

[Gustl]

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

[Nexus]

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

[Bashar]

***ironiedetektor justiert***

[pumuckl]

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.

[Nexus]

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.

[Dravere]

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

[camper]

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.