EMB DCE 12 - Bedingungen mit einen Assign-Zeichnen

[Rollo62]

Ok, wenn wir schon beim theoretisieren sind.
Die Frage ist ja , warum gibt es ÜBERHAUPT zwei verschiedene Zeichen.

Bei einem Vergleich wäre das ja gar nicht nötig, weil das "if" ja schon alles dazu sagt:

Delphi-Quellcode:

a = 1234;  // Zuweisung

if ( a = 1234 ) then   // Vergleich
begin
end

Das Problem sind wohl die direkten Zuweisungen aus einem boolschen Operator:

Delphi-Quellcode:

a = 1234;

b = a = 1234;   // Zuweisung und Vergleich, b wäre dann True

Im 2ten Fall weiß der Compiler nicht genau, ob er b zuweisen soll, oder a.
Wenn der Compiler schlauer wäre, dann sollte er das meiner Meinung nach trotzdem hinbekommen,
denn das erste "=" müsste IMMER eine Zuweisung sein, oder nicht?

Gibt es eventuell andere Fälle, wo eine Unterscheidung Zuweisung und Vergleich nötig wäre?
Sehe ich auf die Schnelle nicht.
Eine Zuweisung innerhalb von komplexeren Vergleichen würde ich sowieso als Seiteneffekt, und Fehler ansehen.

! Also: Weg mit all dem überflüssigem Zeug und nehmen wir nur "=" für Alles

[dummzeuch]

... und dann ist da noch die C-Syntax:

Code:

a = 5;
if (a=6) {
  AIst6(); // wird aufgerufen
} else {
  AIstNicht6();
}

Es wird AIst6 aufgerufen, weil das Gleichheitszeichen in der If-Abfrage als Zuweisung interpretiert wird und eine Zuweisung auch noch den zugewiesenen Wert zurückliefert. Der ist in diesem Fall <> 0 also True.

In Delphi entspräche das

Delphi-Quellcode:

  a := 5;
  a := 6; // in C findet dies in der If-Abfrage statt
  if a = 6 then
    AIst6()
  else
    AIstNicht6();

Wenn also die ersten C Compiler nicht versucht hätten, Tipparbeit zu sparen, sprich,

Code:

(Wert1 = Wert2)

immer einen Boolschen Wert liefern würde statt Wert1 auf Wert2 zu setzen, brauchte man den ganzen Kladderadatsch nicht.

Aber es war halt wichtiger (oder cooler?), schreiben zu können:

Code:

a = b = c = 10;

statt

Code:

a = 10;
b = 10;
c = 10;

Und der Mist zog sich danach durch alle von C abgeleiteten Sprachen. Das führte dann dazu, dass man statt

Code:

  if (a == 5)

immer

Code:

  if (5 == a)

schreiben sollte. Was das Problem etwas entschärfte, denn falls man ein '=' vergisst, schlägt die Zuweisung auf die Konstante fehl.

Inzwischen warnen die Compiler vermutlich, wenn sie in If-Abfragen etc. (x=y) finden, aber da bin ich nicht mehr auf dem Laufenden. Ich bin vor mehr als 20 Jahren aus den C-ähnlichen Sprachen ausgestiegen.

[Rollo62]

Zitat von dummzeuch:

... und dann ist da noch die C-Syntax:

Code:

a = 5;
if (a=6) {   //<== Halte ich IMMER für einen Fehler
  AIst6(); // wird aufgerufen
} else {
  AIstNicht6();
}

Ja genau, aber ich halte das eben immer für falsch, korrigiert mich wenn es Fälle gibt, wo dies wirklich logisch Sinn macht.

Außer maximaler Verwirrung hat das doch keine Vorteile, außer vielleicht wirklich auf Assembler-Ebene,
wo dann z.B. ein zugewiesener Wert direkt weiterverarbeitet werden kann, der schon im Register ist, oder sowas.

Man muss dabei vielleicht Bedenken, dass diese Syntax wirklich aus Zeiten kamen,
als 1024 Byte noch ein Riesenspeicher war, und als noch um jedes Bit mit Säbeln und Morgenstern hart gekämpft wurde.

[paule32.jk]

Ihr kennt bestimmt die Anekdote mit den Russen und C ... ?

Einige Verschwörer denken ja bis heute, das C entwickelt wurde, um den technischen Fortschritt der Federation (mit Luna, Lika und Gagarin) zu bremsen. Und weil die Russen als erstes Bunt TiWi hatten, sollte das mit den in den USA gestarteten Gemini Projekte (also die bemante Mondbesteigung) ausgeglichen werden.

[Rollo62]

Nee, glaube ich nicht.
IT Nerds waren schn immer auf ihrem Paralleluniversum in ihrer Parallelwelt unterwegs,
da zählen Ländergrenzen oder Staatszugehörigkeiten einfach nichts.
Es ist wie eine große Familie, Sternenübergreifend.

[jaenicke]

Zitat von Rollo62:

Ja genau, aber ich halte das eben immer für falsch, korrigiert mich wenn es Fälle gibt, wo dies wirklich logisch Sinn macht.

Naja, also ich habe schon öfter Code wie diesen:

Delphi-Quellcode:

CallResult := CallAPI(...);
if CallResult = 0 then
  Result := ...
else
  raise ESevereError.Create('Fehlercode: ' + CallResult.ToString);

Ich finde es aber immer besser, wenn man einzelne Befehle auch separat schreibt, damit es übersichtlicher ist. Insofern würde ich das ohnehin nicht zusammenfassen wollen. Also so nach dem Motto:

Delphi-Quellcode:

if CallResult := CallAPI(...) then
  raise ESevereError.Create('Fehlercode: ' + CallResult.ToString)
else
  Result := ...

Theoretisch wäre das mit Pascal-Syntax durchaus umsetzbar, ohne dass es dort Mehrdeutigkeiten gäbe. Die automatische Umwandlung des Zahlenwerts in einen Boolean wäre noch zusätzlich nötig. Sonst müsste es so gemacht werden: if (CallResult := CallAPI(...)) > 0 then Wie gesagt, ich würde es nicht wollen.

[smallie]

Niklaus Wirth schrieb vor einigen Jahren:

Zitat:

Good Ideas, Through the Looking Glass
IEEE Cover Feature 2006

It has become fashionable to regard notation as a secondary issue depending purely on personal taste. This could partly be true; yet the choice of notation should not be considered arbitrary. It has consequences and reveals the language’s character.

Choosing the equal sign to denote assignment is one notoriously bad example that goes back to Fortran in 1957 and has been copied blindly by armies of language designers since. This bad idea overthrows a century-old tradition to let = denote a comparison for equality, a predicate that is either true or false. But Fortran made this symbol mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand, a variable, is to be made equal to the right operand, an expression. Thus, x = y does not mean the same thing as y = x. Algol corrected this mistake with a simple solution: Let assignment be denoted by :=.

This might appear as nitpicking to programmers accustomed to the equal sign meaning assignment. But mixing up assignment and comparison truly is a bad idea because it requires using another symbol for what the equal sign traditionally expresses. Comparison for equality became denoted by the two characters == (first in C). This is an ugly consequence that gave rise to similar bad ideas using ++, —, &&, and so on.

Published by the IEEE Computer Society 0018-9162/06/$20.00 © 2006 IEEE

[paule32.jk]

Zitat von Rollo62:

Ok, wenn wir schon beim theoretisieren sind.
Die Frage ist ja , warum gibt es ÜBERHAUPT zwei verschiedene Zeichen.

Das Problem sind wohl die direkten Zuweisungen aus einem boolschen Operator:

Code:

a = 1234;

b = a = 1234;   // Zuweisung und Vergleich, b wäre dann True

Im 2ten Fall weiß der Compiler nicht genau, ob er b zuweisen soll, oder a.
Wenn der Compiler schlauer wäre, dann sollte er das meiner Meinung nach trotzdem hinbekommen,
denn das erste "=" müsste IMMER eine Zuweisung sein, oder nicht?

Das hat damit zu tun, das die Werte bei C/C++ auf einen Stack gelegt werden - nach dem LIFO (last in first out) Prinzip:
die Werte gehen also immer nach unten bzw links nach rechts beim setzen aufgebaut:

seter:
push b
push a
push 1234

geter:
pop 1234
pop a
pop b

bei Pascal werden Variablen-ähnlich nach oben aufgebaut.
hat beides sein für und wider...

[freimatz]

Ich halte es für ein Gerücht, dass bei einer Zuweisung der Stack benutzt wird. Wir sind doch nicht bei FORTH