C semikolon fehlt?!

[snow1]

Ich bin einmal so frech und antworte für antred.

Vor allem im SAP Umfeld kommt das leider noch zu oft vor.

Sowas kann doch kein Mensch vernünftig pflegen. Ok, ich habe nicht wirklich Ahnung von APAB, aber das lässt sich doch sicherlich anders lösen.

Sofern man Codemetriken einsetzt, würden da alle Alarmglocken klingeln. Ein gescheiter Entwicklungsleiter würde denjenigen der sowas verbricht einen Kopf kürzer machen.

 

[antred]

Sowas kann doch kein Mensch vernünftig pflegen. Ok, ich habe nicht wirklich Ahnung von APAB, aber das lässt sich doch sicherlich anders lösen.

Sofern man Codemetriken einsetzt, würden da alle Alarmglocken klingeln. Ein gescheiter Entwicklungsleiter würde denjenigen der sowas verbricht einen Kopf kürzer machen.

In meinem Fall handelt es sich zwar nicht um SAP, und aus Gründen der Arbeitsplatzsicherung möchte ich auch lieber verschweigen, worum es sich denn wirklich handelt , aber es ist leider traurige Wahrheit, daß es so was einfach gibt. Und verstehen geschweige denn pflegen kann so was natürlich wirklich niemand mehr.

 

[1668mib]

@IceMatrix: Der Ausdruck

if (pointer)

funktioniert ja nur, weil das Statement ja gar nichts anderes heißt wie

if (pointer != 0)

Es ist exakt das selbe. Es ist lediglich für den Menschen anders.

Oder ist bei dir

if (i) { ...}
if (i != 0) { ...}

auch ein Unterschied? Gegen irgendwas wird i bei der 1. Abfrage auch verglichen. Der Prozessor muss nen Vergleich machen. Für den Compiler ist das halt implizit ein Vergleich gegen 0.

Dass der obere Ausdruck geht liegt ja nur daran, dass ein C-Compiler eben fast jeden Ausdruck als boolschen Ausdruck interpretieren kann mit
* Ausdruck wertmäßig 0: false
* Ausdruck wertmäßig nicht 0: true
Und oh Wunder, nichts anderes ist ja "!= NULL" (bzw "!= 0")...

@gruffi:
Bei einer boolschen Variable finde ich Abfragen mit == auch unschön... es geht hier ja nicht um Zeiger. Schon mal aufgefallen, dass ich bei meiner Funktion, die ich als Beispiel gepostet hab, auch kein "== true" dran gemacht hab? oO

@antred:
Es gibt alt kaum was, was es nicht gibt. Ob das dann repräsentativ ist?

@Whiz-zarD
"Ich will ja nicht wissen, ob der Zeiger ungleich NULL ist, sondern ob der Zeiger auf eine Adresse zeigt"
Die Argumentation versteh ich nicht ganz muss ich sagen. Wenn der Zeiger nicht NULL ist, zeigt er ja auf eine Adresse... wann zeigt er nicht auf eine Adresse? Wenn er NULL ist (wobei NULL im Grunde ja auch ne Adresse ist...)

Es bleibt halt oft nichts anderes übrig, als auf das Gegenteil zu testen, was man wissen will...

Und gerade wenn die Variable eben wo anders definiert wurde, dann finde ich es lesbarer, wenn man die NULL-Prüfung ausschreibt, um eben klar zu zeigen, um welche Typen es sich handelt.

Außerdem ist es "typsicherer", wenn ich weiß ich muss nen Pointer prüfen, kann ich nicht versehentlich ne ähnlich klingende andere Variable nehmen...
also doofes beispiel:

int file = 1;
FILE* fileptr = fopen(filenames[file], ...);
if (file) {
  // file successfully opened
}

 

[antred]

Außerdem ist es "typsicherer", wenn ich weiß ich muss nen Pointer prüfen, kann ich nicht versehentlich ne ähnlich klingende andere Variable nehmen...
also doofes beispiel:

int file = 1;
FILE* fileptr = fopen(filenames[file], ...);
if (file) {
  // file successfully opened
}

Wieso?

int file = 1;
FILE* fileptr = fopen(filenames[file], ...);
if (file != NULL) {
  // file successfully opened
}

Ob du das nun explizit ausschreibst oder nicht, der Fehler kann dir so oder so passieren.


EDIT: Ok ok, wir reden über C ... da ist das wohl was anderes.

 

[Whiz-zarD]

@Whiz-zarD
"Ich will ja nicht wissen, ob der Zeiger ungleich NULL ist, sondern ob der Zeiger auf eine Adresse zeigt"
Die Argumentation versteh ich nicht ganz muss ich sagen. Wenn der Zeiger nicht NULL ist, zeigt er ja auf eine Adresse... wann zeigt er nicht auf eine Adresse? Wenn er NULL ist (wobei NULL im Grunde ja auch ne Adresse ist...)

Es bleibt halt oft nichts anderes übrig, als auf das Gegenteil zu testen, was man wissen will...

Und gerade wenn die Variable eben wo anders definiert wurde, dann finde ich es lesbarer, wenn man die NULL-Prüfung ausschreibt, um eben klar zu zeigen, um welche Typen es sich handelt.

Ich muss zugeben, dass es relativ schwer ist, den Sachverhalt zu erklären.
Es ist schon richtig, wenn ein Zeiger nicht NULL ist, dass er auf eine reale Adresse zeigt und im Endeffekt ist die Übrprüfung gegen ungleich NULL das selbe, als wenn ich nur das boolsche Ergebnis einer Adresse haben möchte. Nur die Semantik ist eine andere.
Ich weiß auch nicht so recht, wie man das am Besten erklären könnte aber ich probiere es noch einmal:
Hier wird ja mittels datei = fopen("matrix.txt", "r"); versucht, eine Datei lesend zu öffnen. Im nächsten Schritt wollen wir aber nur wissen, ob die Datei geöffnet werden konnte und nicht ob der Zeiger ungleich NULL ist, deswegen ist hier eine if (datei) { ... } Abfrage sinnvoller, als if (datei != NULL) { ... }. Es geht nur rein um die Interpretation für einen Menschen. Also es wird nach "Ist datei vorhanden?" gefragt und nicht "Ist Zeiger von Variable datei ungleich NULL?". Beides ist das selbe aber das erste Interpretiert sich leichter. Es gibt doch den schönen Spruch "Der Ton macht die Musik".

Außerdem ist es "typsicherer", wenn ich weiß ich muss nen Pointer prüfen, kann ich nicht versehentlich ne ähnlich klingende andere Variable nehmen...
also doofes beispiel:

int file = 1;
FILE* fileptr = fopen(filenames[file], ...);
if (file) {
  // file successfully opened
}

Darum sollte man auch den Variablen schon zutreffende Namen geben, die nicht zu einer Verwechslung führen können. Eine Integer-Variable würde ich nie den Namen file geben. In deinem Beispiel würde ich sie index nennen, weil die den Index des Arrays entspricht.

 

[1668mib]

Also es wird nach "Ist datei vorhanden?" gefragt

Also unabhängig davon, dass "datei" eine Variable ist, über deren Vorhandensein gar nicht diskutiert wird, ist in der Frage "Ist datei vorhanden?" schon mehr Information drin, als "Ist Zeiger datei ungleich NULL" (wieso so kompliziert mit "von Variable"?) - aus der einen Abfrage kann man nicht wirklich rauslesen, wie die Datei geöffnet wurde... steht ja nicht immer nen fopen in der Zeile drüber...

Wenn dann musst du fragen: "Ist datei nutzbar?". Und irgendwie kommt das eben bei der Abfrage mit != NULL auch auf raus.

Darum sollte man auch den Variablen schon zutreffende Namen geben

Deshalb hab ich auch geschrieben doofes Beispiel... aber selbst wenn sie fileidx heißt könnte man es passieren... Fehler sind menschlich. Und das tolle ist, dass so ein Fehler evtl gar nicht wirklich auffällt...


Aber eines sollte man wirklich sagen:
Weder das eine, noch das andere ist "richtig" oder "falsch". Klar gibt es gewisse Stil-Sachen, die sich etabliert haben und sinnvoll sind. Aber wichtig ist vor allem, dass man den Stil konsequent macht.

Und ich muss sagen, dass in meinen Augen oft zu wenig über Stil diskutiert wird ;-)

 

[IceMatrix]

Das scheint mir jetzt ein bißchen an den Haaren herbeigezogen. Ich schätze, der Standard schließt auch nicht aus, daß irgend ein Spielzeugcompiler 20 nop's generiert, bevor der eigentliche if-Ausdruck ausgewertet wird.

Der Standard sagt rein gar nichts über die Codegenerierung im Compiler-Backend, aber sehr wohl über das Parsing und die Semantik der Programmiersprache.

Deshalb ist es sehr wichtig zu sehen, dass explizit ein Vergleich auf gleich oder ungleich 0 gefordert wird. In Java sieht es beispielsweise etwas anders aus. Dort wird explizit verlangt, dass der Ausdruck in der If-Bedingung vom Typ boolean oder ein Boolean-Objekt ist.

Was ein Compiler aus der Spezifikation macht ist die Sache des Compilers, solange das Ergebnis die Spezifikation erfüllt!

Das heißt nichts anderes als dass es legitim ist einen Doppel-Compare für einen Ausdruck if (file != 0) zu generieren. Wenn ein Compiler das nicht tut, dann nur auf Grund einer Optimierung.

 

[7H3 N4C3R]

Also um das mal abzukürzen

6.8.4.1 The if statement
2 In both forms, the first substatement is executed if the expression compares unequal to 0.
In the else form, the second substatement is executed if the expression compares equal
to 0. If the first substatement is reached via a label, the second substatement is not
executed.

Wen es interessiert, unter 6.3.2.3 ist Vergleich von Nullpointer-Konstanten beschrieben und die implizite Konvertierung der Zahl 0 in eine Nullpointer-Konstante.

Ob man != 0 hinschreibt oder nicht, ist eine Frage von Geschmack, Lesbarkeit und Coding Guidelines. Auf das sprachliche Konstrukt hat es keinen Einfluss. Eventuelle Optiemierung sind "beyond scope" aus Sicht des Standards.