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

[Walli]

DDR-RAM schrieb:

Ich höre zum erstenmal, das and C++-Standard sein soll

Ist es aber (2.11.2). Ich finde es auch nicht wirklich lesbarer als &&, aber naja... Geschmackssache!

DDR-RAM schrieb:

VC++ 2003 hat damit nichts am Hut (ist der jetzt schon so alt?)

Ich weiß ja nicht welchen VC++ 2003 du hast, aber meiner kann das von Haus aus.

[ness]

Also ich werde auch weiterhin && || ^... benutzen. Ich HASSE diese Verbaloperatoren. Sizeif oder typeid sehen ja enigstens noch wie Funktionen aus, aber Logische verknüpfungen wie in exel (ham wir grad in info ):

=WENN(UND(bedingung_1,begingung_2);tudas;WENN(ODER(bedingung_3;bedingung_4);tujenes;tusolches))

(in c++ etwa:

int r;
if(bedingung_1&&bedingung_2)
    r=tudas();
else if(bedingung_3||bedingung_4)
    r=tujenes();
else
    r=tusolches();

)

[Konrad Rudolph]

groovemaster schrieb:

Konrad Rudolph schrieb:

groovemaster schrieb:

- zudem hat 'a and b' diesen VB Touch

Sieh's als Vorteil.

Nein danke, ich verzichte. :p

Gut. Dann ist die Diskussion ja schon erledigt. Es handelt es sich also nur um engstirnige Ideologie. volkard scheint recht zu haben.

Konrad Rudolph schrieb:

Ich muss volkard recht geben, es ist übersichtlicher.

Find ich nicht. Hast du dir das Beispiel von audacia mal angeschaut? Was ist da bitteschön übersichtlicher?

Wer schreibt denn so einen <del>Mist</del><ins>Code</ins>? Außerdem gibt es Syntax-Highlighting und das erfüllt einen Sinn. Mit einem geeigneten Highlighting ist solch ein Code in sprachlicher Variante sehr wohl übersichtlicher.

Dann überlad dir halt & und schreib

a & " und " & b

so wie in VB. Wo ist das Problem?

Dass es kein Standard ist. Diesen Code verstehen dann nur VBler intuitiv. Ein C++-Programmierer wird schwitzen.

operator void schrieb:

Man könnte auch if durch ?? und for durch -> ersetzen, nach ein paar Programmen würde man es ohne größere Probleme geistig übersetzen.

Was aber völlig OT ist, wir reden über mathematische Operatoren und nicht über Schlüsselwörter zur Flusssteuerung.

Ich weiß nicht, ob da jetzt so ein gewaltiger Unterschied ist. Klar, ich sehe was Du meinst und bin gewillt, Dir im ersten Moment recht zu geben aber vielleicht ist das ja nur eine Sache der Gewöhnung. In C++ gibt es schließlich auch '{...}' statt 'begin...end'.

volkard schrieb:

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.

Du magst also solchen Code?

a = b and c;
d = e & f;

Und nicht

a = b and c;
d = e bitand f;

Die Frage ging zwar nicht an mich, ich antworte trotzdem: Ja. Aber hier handelt es sich um einen Grenzfall. In C++, wo ich die Alternative habe, würde ich in solch einer Situation wohl durchaus '&&' schreiben ... nur eben in einer Bedingung einer Flusssteuerung nicht.

Mag sein, dass ich mir meine Arbeit zu einfach mache, indem man möglichst viel vereinheitlicht. Zu schade, dass sowas nicht mehr "in" ist.

Nein, nicht schade, gut so. Du vereinfachst nicht nur, Du übertreibst. Einheitlichkeit zum Selbstzweck bringt keinen Vorteil.

[DDR-RAM]

Walli schrieb:

DDR-RAM schrieb:

Ich höre zum erstenmal, das and C++-Standard sein soll

Ist es aber (2.11.2). Ich finde es auch nicht wirklich lesbarer als &&, aber naja... Geschmackssache!

DDR-RAM schrieb:

VC++ 2003 hat damit nichts am Hut (ist der jetzt schon so alt?)

Ich weiß ja nicht welchen VC++ 2003 du hast, aber meiner kann das von Haus aus.

Also ich hab 7.1.3088

Hat wer mal nen Link, wo offiziell steht das nen Standard ist?
Ich kann nicht glauben.

MfG
DDR-RAM

edit:
ok hab nen link gefunden

[finix]

Konrad Rudolph schrieb:

Es handelt es sich also nur um engstirnige Ideologie.

Genau, welchen tatsächlichen Vorteil sollten and, xor und Konsorten denn haben?

Konrad Rudolph schrieb:

Mit einem geeigneten Highlighting ist solch ein Code in sprachlicher Variante sehr wohl übersichtlicher.

Ansichtssache.

[volkard2]

ness schrieb:

Also ich werde auch weiterhin && || ^... benutzen. Ich HASSE diese Verbaloperatoren. Sizeif oder typeid sehen ja enigstens noch wie Funktionen aus, aber Logische verknüpfungen wie in exel (ham wir grad in info ):

=WENN(UND(bedingung_1,begingung_2);tudas;WENN(ODER(bedingung_3;bedingung_4);tujenes;tusolches))

(in c++ etwa:

int r;
if(bedingung_1&&bedingung_2)
    r=tudas();
else if(bedingung_3||bedingung_4)
    r=tujenes();
else
    r=tusolches();

)

wir reden über

int r;
if(bedingung_1 and bedingung_2)
    r=tudas();
else if(bedingung_3 and bedingung_4)
    r=tujenes();
else
    r=tusolches();

[volkard2]

groovemaster schrieb:

a = b and c;
d = e & f;

Und nicht

a = b and c;
d = e bitand f;

oder

a = b && c;
d = e & f;

?

destawegen tat ich schreiben , daß ich and in bedingungen haben mag. damit meine ich den steuernden ausdruck in if, while, do, for und ?:.

wer unbedingt a = b && c schreiben mag, der soll das tun. man kann eh praktisch alles in c++ auf 5 oder mehr arten implemetieren. und die gemeinde benutzt die freiheit, um noch besseren code zu zaubern. wenn man and in bedingungen und && in berechnungen nähme, wäre mir schon sehr gehelft.

[borg]

if(fish_and_chips and and_potatoe)

if(fish_and_chips && and_potatoe)

wie kommt ihr alle auf die idee es sei lesbarer diese 'verbaloperatoren' zu benutzen?
ich finde da sollte man die leute eher dazu prügeln zwischen operatoren leerstellen zu machen.

[Konrad Rudolph]

borg schrieb:

if(fish_and_chips and and_potatoe)

if(fish_and_chips && and_potatoe)

wie kommt ihr alle auf die idee es sei lesbarer diese 'verbaloperatoren' zu benutzen?
ich finde da sollte man die leute eher dazu prügeln zwischen operatoren leerstellen zu machen.

Wer seine Variablen so doof benennt, dem ist nicht meht zu helfen. Was hat das mit der Diskussion zu tun?

[borg]

Konrad Rudolph schrieb:

Wer seine Variablen so doof benennt, dem ist nicht meht zu helfen.

mir fallen haufenweise undoofe wörter ein in denen or und and vorkommt.

if(new_order or original_order)

Konrad Rudolph schrieb:

Was hat das mit der Diskussion zu tun?

ich behaupte es wird nicht lesbarer wenn man die operatoren ausschreibt, darum gehts doch hier oder?

[k1ro]

Boaaah, immer diese komischen diskussionen die sich dann über zig seiten wälzen,
wer das eine benutzen will benutzt dies, wer das andere benutzen will benutzt das

für mich ist "&&" genauso lesbar wie "and",
warum?
Ganz einfach: Weil ich es so gewöhnt bin.
Wer lieber "and" schreibt statt "&&": Na && soll er doch!
Wers andersrum mag: Auch gut.

Aber es gilt ja bekanntlich wie immer:
Über Geschmack lässt sich streiten.

Also viel Spaß noch beim Auswälzen der Für und Wider.

[groovemaster]

Konrad Rudolph schrieb:

Es handelt es sich also nur um engstirnige Ideologie.

"engstirnige Ideologie"? Wie bist du denn drauf? Wie ich bereits erwähnte, ist es Geschmackssache. Wenn du die textuelle Variante bevorzugst, gut, dann machs halt. Nur seh ich keinen Vorteil darin, und bisher hat auch noch niemand wirklich gute Argumete dafür gebracht.

Konrad Rudolph schrieb:

volkard scheint recht zu haben.

Ganz recht, volkard hat immer Recht.

Konrad Rudolph schrieb:

Außerdem gibt es Syntax-Highlighting und das erfüllt einen Sinn. Mit einem geeigneten Highlighting ist solch ein Code in sprachlicher Variante sehr wohl übersichtlicher.

Ach ja? Kannst du mal genau erklären WAS dann übersichtlicher ist?

Konrad Rudolph schrieb:

Dann überlad dir halt & und schreib

a & " und " & b

so wie in VB. Wo ist das Problem?

Dass es kein Standard ist.

Bitte? Was ist daran kein Standard? Dass std::string das nicht anbietet? Was hindert dich aber daran, das in deine eigene String Klasse zu implementieren. Uns sag jetzt nicht, dass du so eine nicht hast. Es soll doch tatsächlich Leute bzw APIs geben, die eigene String Klassen benutzen.

Konrad Rudolph schrieb:

Diesen Code verstehen dann nur VBler intuitiv. Ein C++-Programmierer wird schwitzen.

Und wirfst C++ vor, dass

string1 + string2

nicht intuitiv genug ist? Versteh ich nicht. Es wird nunmal immer Eigenheiten einer Sprache geben, mit der sich ein Programmierer auseinander setzen muss.

Konrad Rudolph schrieb:

Ich weiß nicht, ob da jetzt so ein gewaltiger Unterschied ist.

Nun, den gibt es zweifellos. Oder hast du schon mal versucht, 'for' zu überladen?

Konrad Rudolph schrieb:

In C++ gibt es schließlich auch '{...}' statt 'begin...end'.

Ja, wobei das imo noch mal eine ganz andere Kategorie ist. Letztendlich sind sowas Bereichsbegrenzungen, und man hat sich dort womöglich an ( und ) orientiert. Bei Templates ist das mit < und > das gleiche. Wobei jeder dieses schöne

template <class T = foo<int>>

kennt, was ja so nicht möglich ist. IIRC soll es da im nächsten Standard Änderungen geben.

Konrad Rudolph schrieb:

In C++, wo ich die Alternative habe, würde ich in solch einer Situation wohl durchaus '&&' schreiben ... nur eben in einer Bedingung einer Flusssteuerung nicht.

Wow, das find ich ja mal interessant. Du magst also solche Sachen

if (a and b)
    c = d && e;
    //...

Schon lustig, auf was für seltsame Ideen Leute so kommen. Letztendlich führt das die ganze Angelegenheit aber vollkommen ad absurdum. Mich, als Programmierer, interessiert doch nicht, wo ich jetzt welche Ausdrücke habe. Mich interessiert nur, dass ich einen Operator habe, der mir ein bestimmtes Ergebnis aus x Operanden liefert. Wenn ich hier mal diese Schreibweise habe und dort mal jene, DAS ist für mich wenig intuitiv.

Konrad Rudolph schrieb:

Einheitlichkeit zum Selbstzweck

Irgendwie ein Widerspruch, findest du nicht auch?

[Green_Ghost]

finix schrieb:

Genau, welchen tatsächlichen Vorteil sollten and, xor und Konsorten denn haben?

Welche Vorteile haben '&&', '||' und '^'?
Das es kompatibel ist mit den Alten Compiler, zieht nicht! (#define)!

Der Punkt ist der geschmack. Ob ich jetzt:

if(..){ //<= meine variante
..
}else{
..
}

//oder

if(..)
{
..
}
else
{
...
}

Ist reine Formsache. Jeder Programmierer hat seinen code.
Ich wollte hier keinen Streit verursachen...

Am rande:
was macht:

a=b and c

genau? Doppelzuweisung?

MFG Ghost

[borg]

Green_Ghost schrieb:

Am rande:
was macht:

a=b and c

MFG Ghost

a nimmt 1 oder 0 an, je nachdem was bei dem ausdruck "a and b" rauskommt.

[groovemaster]

Green_Ghost schrieb:

Am rande:
was macht:

a=b and c

genau? Doppelzuweisung?

Nö. Wie kommst du auf Doppelzuweisung?

borg schrieb:

a nimmt 1 oder 0 an

Fast. Das wäre nur der Fall, wenn a ein nicht-boolscher integraler Wert ist. 'a and b' (oder auch 'a && b' ) liefert false oder true. Je nachdem, ob a bzw b false oder true sind, halt und-verknüpft.

[volkard2]

borg schrieb:

if(fish_and_chips and and_potatoe)

wie kommt ihr alle auf die idee es sei lesbarer diese 'verbaloperatoren' zu benutzen?

das schlüsselwort ist blau. die eigenen bezeichner sind schwarz. guck doch mal genau hin.

[Konrad Rudolph]

groovemaster schrieb:

Konrad Rudolph schrieb:

Es handelt es sich also nur um engstirnige Ideologie.

"engstirnige Ideologie"? Wie bist du denn drauf? Wie ich bereits erwähnte, ist es Geschmackssache. Wenn du die textuelle Variante bevorzugst, gut, dann machs halt. Nur seh ich keinen Vorteil darin, und bisher hat auch noch niemand wirklich gute Argumete dafür gebracht.

Nun ja, so wie ich das verstehe, wird 'and' hier schon deswegen kategorisch abgelehnt, weil es in VB benutzt wird. Nicht wirklich ein toller Grund. Vielleicht hätte ich aber noch einen Smiley anbringen sollen.

Konrad Rudolph schrieb:

volkard scheint recht zu haben.

Ganz recht, volkard hat immer Recht.

Ich bezog mich jetzt allein auf diese Diskussion.

Konrad Rudolph schrieb:

Außerdem gibt es Syntax-Highlighting und das erfüllt einen Sinn. Mit einem geeigneten Highlighting ist solch ein Code in sprachlicher Variante sehr wohl übersichtlicher.

Ach ja? Kannst du mal genau erklären WAS dann übersichtlicher ist?

Ich weiß ja nicht, ob *Du* Syntaxeinfärbung verwendest aber diese Technik hat sich ziemlich weit verbreitet und wird wohl von den meisten Leuten als für die Lesbarkeit förderlich angenommen. Wenn also Operatoren farblich von Bezeichnern unterschieden werden, dann gibt es bei 'foo and bar' rein optisch eine Unterscheidung. Das ist natürlich bei 'foo && bar' genauso.

Konrad Rudolph schrieb:

Dann überlad dir halt & und schreib

a & " und " & b

so wie in VB. Wo ist das Problem?

Dass es kein Standard ist.

Bitte? Was ist daran kein Standard? Dass std::string das nicht anbietet? Was hindert dich aber daran, das in deine eigene String Klasse zu implementieren.

Warte mal, hast Du nicht über mangelnde Einheitlichkeit geschimpft?

Was das Benutzen "eigener" Stringklassen betrifft: Das halte ich für extrem kontraproduktiv. Die Stringklasse mag nicht perfekt sein aber sie ist sehr solide und bietet durch ihre Eingliederung ins STL eine optimale Grundlage. Dass jede API ihre eigene Stringklasse mitbringt, ist im Zusammenspiel verschiedener APIs eher hinderlich.

Konrad Rudolph schrieb:

Diesen Code verstehen dann nur VBler intuitiv. Ein C++-Programmierer wird schwitzen.

Und wirfst C++ vor, dass

string1 + string2

nicht intuitiv genug ist? Versteh ich nicht. Es wird nunmal immer Eigenheiten einer Sprache geben, mit der sich ein Programmierer auseinander setzen muss.

Das akzeptiere ich. Ich finde es eben nur nicht optimal. Allerdings schreibe ich gerade (schon seit längerem) an einer Syntaxdefinition für eine eigene Sprache und in dieser Sprache ist '+' ebenfalls für String-Konkatenation überladen.

Schon lustig, auf was für seltsame Ideen Leute so kommen. Letztendlich führt das die ganze Angelegenheit aber vollkommen ad absurdum. Mich, als Programmierer, interessiert doch nicht, wo ich jetzt welche Ausdrücke habe. Mich interessiert nur, dass ich einen Operator habe, der mir ein bestimmtes Ergebnis aus x Operanden liefert. Wenn ich hier mal diese Schreibweise habe und dort mal jene, DAS ist für mich wenig intuitiv.

Ich kann Deine Einstellung durchaus verstehen und muss zugeben, dass ich mir bei meiner Einstellung nicht unbedingt sicher bin (insbesondere dabei, ob man mal 'and' und mal '&&' verwenden sollte, je nach Kontext). Ich weiß allerdings, dass ich die textuelle Schreibweise für Bedingungen eindeutig bevorzuge.

[groovemaster]

Konrad Rudolph schrieb:

Nun ja, so wie ich das verstehe, wird 'and' hier schon deswegen kategorisch abgelehnt, weil es in VB benutzt wird.

Nicht kategorisch, eher zusätzlich. Es ist nunmal kein Geheimnis, dass VB vom Standpunkt eines erfahrenen C++ Programmierers aus nicht gerade die Erfüllung einer Sprache ist. Naja, welche Sprache ist das schon? Nur hat VB eben so einige Defizite, gerade was den Spagat zwischen high- und low-level Bereich betrifft. Mag mittlerweile mit VB.NET vielleicht anders sein.

Konrad Rudolph schrieb:

Konrad Rudolph schrieb:

volkard scheint recht zu haben.

Ganz recht, volkard hat immer Recht.

Ich bezog mich jetzt allein auf diese Diskussion.

Ich auch. Und meine Aussage war keinesfalls, wie der eine oder andere jetzt denken mag, ironisch gemeint.

Konrad Rudolph schrieb:

Ich weiß ja nicht, ob *Du* Syntaxeinfärbung verwendest

Sicher mach ich das. Wozu auf die netten Annehmlichkeiten verzichten?

Konrad Rudolph schrieb:

Wenn also Operatoren farblich von Bezeichnern unterschieden werden, dann gibt es bei 'foo and bar' rein optisch eine Unterscheidung. Das ist natürlich bei 'foo && bar' genauso.

Eben, deshalb versteh ich auch nicht was an 'foo and bar' nun übersichtlicher sein soll. Dass es reiner Text ist? Ohne irgendwelche Sonderzeichen? Das ist doch Blödsinn und vollkommen geschmacksfrei.

Konrad Rudolph schrieb:

Warte mal, hast Du nicht über mangelnde Einheitlichkeit geschimpft?

Ja schon. Nur reden wir immer noch über Operatoren oder irgendwelche Klassenimplementationen? Operatoren gehören nunmal zum rudimentären Sprachumfang, was man von std::string nicht behaupten kann.
Dass teilweise so viele verschiedene String-Klassen benutzt werden, ist auch nicht unbedingt nach meinem Geschmack. Mag aber auch daran liegen, dass std::string bei weitem nicht perfekt ist, und somit die Anforderungen diverser Benutzer nicht erfüllt.

Ich weiß allerdings, dass ich die textuelle Schreibweise für Bedingungen eindeutig bevorzuge.

OK, das kann (und muss) man akzeptieren. Ich würde dann aber versuchen, zumindest die Operatoren, die man textuell schreibt, immer zu verwenden. Völlig unabhängig vom Kontext. Ansonsten hast du zwei unterschiedliche Schreibweisen für ein und dieselbe Sache. Mehr als nur unnötige Redundanz.

[Konrad Rudolph]

groovemaster schrieb:

Konrad Rudolph schrieb:

Nun ja, so wie ich das verstehe, wird 'and' hier schon deswegen kategorisch abgelehnt, weil es in VB benutzt wird.

Nicht kategorisch, eher zusätzlich. Es ist nunmal kein Geheimnis, dass VB vom Standpunkt eines erfahrenen C++ Programmierers aus nicht gerade die Erfüllung einer Sprache ist. Naja, welche Sprache ist das schon? Nur hat VB eben so einige Defizite, gerade was den Spagat zwischen high- und low-level Bereich betrifft. Mag mittlerweile mit VB.NET vielleicht anders sein.

Genau das meinte ich. Was Du da sagst, ist Müll. Sorry, so ist es. Ich weiß nicht, wieviel Erfahrung Du in VB hast, ich weiß nur, dass die meisten Leute, die so lautstark dagegen sind, keine Ahnung von VB haben. Ich kenne hingegen eine Menge Leute, die VB und C++ erfolgreich parallel einsetzen und mit beiden Sprachen klar kommen -- zu dieser Gruppe zähle ich mich. Beide Sprachen haben ihre Mängel und ihre Stärken.

Was den von Dir angesprochenen Spagat betrifft, weiß ich ehrlich gesagt nicht, was Du meinst. in C++ ist dieser Spagat vorhanden, keine Frage. Er ist auch notwendig. Aber in VB? Das einzige, was es hier an "low-level" gibt, dient zur Interoperabilität, hauptsächlich mit der WinAPI, die nun mal eine Low-level-Schnittstelle verwendet.

[volkard]

groovemaster schrieb:

OK, das kann (und muss) man akzeptieren. Ich würde dann aber versuchen, zumindest die Operatoren, die man textuell schreibt, immer zu verwenden. Völlig unabhängig vom Kontext. Ansonsten hast du zwei unterschiedliche Schreibweisen für ein und dieselbe Sache. Mehr als nur unnötige Redundanz.

das werden auch die meisten tun.

ich habe großen komfortgewinn dadurch, daß ich bei manchen sachen echt kontextabhängig schreibe.

also wenn der int als ordinal zahl gemeint ist wie in

for(int i=0;i!=0;--i)

dann schreibe ich !=0

ist es aber eine kardinalzahl mit der zusätzlichen bedeutung 0 heißt nixda, weg, leer, ungültig, falsch, kaputt etc, dann auch

while(fuu.size())

oder beim umgang mit %2. weil das ergebnis von %2 immer nur eine zahl ist und da 0 nicht nixda, weg, leer, ungültig, falsch, kaputt etc bedeutet, kann ich nur

if(x%2!=0)

schreiben.
niemals

if(x%2)

bei zeigern hat 0 die bedeutung von nixda, weg, leer, ungültig, falsch, kaputt etc. also schreibe ich

for(Node* pos=anchor;pos;pos=pos->next)

auch verwende ich machmal in anderen kontexten andere sprachen. also deutsch im anwendungscode und englisch im bibliothekscode.

insofern ist es für mich eine ganz natürliche sache, in bedingungen eher an and zu denken und in berechnungen eher an &&. nebenbei bemerkt, denke ich, daß and oder && in berechnungen sauselten vorkommen. außer direkt im return-statement. muß mal überlegen, aber schätze, da sollte ich dann auch and nehmen.

bool operator and(Bar b){
   return Base::operator&&(b);
}
bool operator&&=(Bar b)//wie heißt der text-name?