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

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

[volkard]

Konrad Rudolph schrieb:

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.

war es nicht viel eher so, daß in VB es kein && gibt, sondern nur &? nd daß man den & (dort and genannt) auch in bedingungen verwendet? und daß es entsprechend auch nur ein | (or) gibt? und daß man destawegen bei false=0 definieren mußte, daß true=-1? das nenne ich mal echt low-level! und wehe dem armen würsten, das ganz arglos sachen wie if(a = not b) schreibt und nicht genau weiß, daß das da bitweise operatoren sind. funktionen, die was feststellen, geben üblicherweise (wenn nicht boolean) eine 0 für false und eine 1 für true. beachte, daß -1 korrekt wäre. die aus der winapi auch, oder? mit einfachem and und or bemerkt man keinen fehler. einmal not und der tag ist gelaufen. optimalerweise stellt man den fehler erst einen tag später fest, dann kann man auch mehrere tage suchen.

[groovemaster]

Konrad Rudolph schrieb:

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 will nicht behaupten, dass ich der grosse Profi in VB bin. Aber ich hab damit schon einige Sachen gemacht. Sicherlich kann man mit VB vieles machen, aber nichts, was man mit anderen Sprachen nicht auch kann. Und in Sachen Komplexität und Flexibilität kann VB nunmal mit C++ nicht Schritt halten. Es ist schon armselig, wenn man nicht mal Shift Operatoren zur Verfügung hat. Das ist mir übrigens eines Tages bei der Signalauswertung für ein Operator Panel auf die Füsse gefallen. Für sowas erst entsprechende Funktionen mit 2-er Multiplikation und Division bereitzustellen, ist einfach kontra-produktiv. Aber hier geht es nicht um C++ vs. VB, das wäre OT. Der Punkt ist einfach der, dass VB für einen guten C++ Programmierer ein Rückschritt ist. Und wer nette klicki-bunti GUI Anwendungen haben will, der greift dann doch eher zu Java oder einer entsprechenden Lib.

[Konrad Rudolph]

volkard schrieb:

Konrad Rudolph schrieb:

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.

war es nicht viel eher so, daß in VB es kein && gibt, sondern nur &? nd daß man den & (dort and genannt) auch in bedingungen verwendet? und daß es entsprechend auch nur ein | (or) gibt?

Das ist ein reines Performanzproblem, aber nicht low-level. Code lässt sich damit genauso schreiben, ohne dass man auf irgend etwas besonders achten muss.

und daß man destawegen bei false=0 definieren mußte, daß true=-1? das nenne ich mal echt low-level!

Wieso? Ich finde, es ist reine Ansichtssache, ob 'true' nun einen Wert von 1 hat oder ob alle Bits gesetzt sind (und damit der Wert -1 beträgt). Ich finde, beide Konventionen sind logisch.

und wehe dem armen würsten, das ganz arglos sachen wie if(a = not b) schreibt und nicht genau weiß, daß das da bitweise operatoren sind.

Wer eine ordentliche Typenkonvertierung einhält, hat damit kein Problem. Ich hatte damit jedenafalls noch nie ein Problem. Problematisch könnte höchstens sein, dass VB (Classic) einen nicht zu einer allzu strengen Typisierung zwingt, es gibt recht weiträumige automatische Konvertierungen, was ich persönlich furchtbar finde, was aber leider in "modernen" Sprachen recht weit verbreitet ist. Na, damit ist ja jetzt Schluss, VB.NET ist (mit Option Strict) strenger typisiert als jede andere imperative Sprache, die ich kenne. Und VB.NET hat auch diese schöne Unterscheidung zwischen Bit-'And' und konditionalem 'And'.

funktionen, die was feststellen, geben üblicherweise (wenn nicht boolean) eine 0 für false und eine 1 für true. beachte, daß -1 korrekt wäre. die aus der winapi auch, oder? mit einfachem and und or bemerkt man keinen fehler. einmal not und der tag ist gelaufen.

Wieso? 'Not 0 = -1'; 'Not 1 = 0'. Wenn Du den Rückgabewert einer Funktion, die 0 oder 1 zurückgibt, überprüfen willst, klappt das einwandfrei.

optimalerweise stellt man den fehler erst einen tag später fest, dann kann man auch mehrere tage suchen.

Gib bitte mal ein Codebeispiel, ich kann mir jetzt einfach keine Situation vorstellen, in der so etwas auftreten sollte und ich programmiere nun wirklich viel in VB. Das einzige Problem ergibt sich, wenn eine API als Wert nicht 1 für den Erfolg zurückgibt, sondern einen "beliebiger" Wert != 0. Hier sollte man nicht einfach negieren sondern vorher nach Boolean konvertieren. Das sollte aber im Sinne einer ordentlichen Typisierung sowieso Standard sein -- ich mache es zumindest immer so.

--
Wenn diese Diskussion jetzt noch weiter geht (von mir aus gerne), könnte man ja vielleicht das Thread teilen ...

[Konrad Rudolph]

groovemaster schrieb:

Der Punkt ist einfach der, dass VB für einen guten C++ Programmierer ein Rückschritt ist.

Diese Aussage disqualifiziert Dich einfach, da sie unbegründet und falsch ist.

[groovemaster]

volkard schrieb:

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

Sicherlich schreibe ich auch kontextabhängige Sachen. Nur hab ich in diesem Zusammenhang noch nie über die alternativen Formen von Operatoren nachgedacht (auch wenn sie mir durchaus bekannt waren). Und da ich jetzt sehe, dass es tatsächlich Leute gibt die sowas machen, kann ich immer noch keinen Gewinn diesbezüglich feststellen. Das muss aber jeder für sich selbst entscheiden.
Bei deinem Beispiel würde ich mir übrigens keine Gedanken machen, ob ich jetzt

while(fuu.size())

oder

while(fuu.size() != 0)

oder

while(fuu.size() not_eq 0)

schreibe, sofern es ein

while(!fuu.empty())

gibt. Das wäre für mich am verständlichsten.

[volkard]

Konrad Rudolph schrieb:

Wieso? 'Not 0 = -1'; 'Not 1 = 0'.

das wundert mich jetzt.
not 1 hätte ich glatt für -2 gehalten.