Ergebnis 1 bis 20 von 20

Thema: Fallstricke des Programmierens - Beispiele

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Zitat Zitat
    Also ich finde das etwas überheblich. o_O Jedem kann mal ein Tipp- bzw. Schlampigkeitsfehler passieren, gerade bei solchen Sachen, und da man da echt praktisch nie das meint, was es wirklich bedeutet, könnte/sollte da imo schon eine Warnung erfolgen. Tut es zwar anscheinend weder bei C, noch Java oder PHP (entgegen meiner Vermutung),
    Gerade in PHP wird zumindest das:
    Code:
    bool a, b;
    // ...
    if (a = b)
        // ...
    sehr häufig verwendet. Ich benutze es eig. jeden Tag.

    Das bekannteste Beispiel dürfte sein:
    PHP-Code:
    while($row mysql_fetch_assoc($result)) { 
    Btw. darf man in PHP nicht: $a < $b < $c schreiben

    Geändert von Xardas der Dunkle (02.09.2009 um 21:34 Uhr)

  2. #2
    Zitat Zitat von Xardas der Dunkle Beitrag anzeigen
    Gerade in PHP wird zumindest das:
    Code:
    bool a, b;
    // ...
    if (a = b)
        // ...
    sehr häufig verwendet. Ich benutze es eig. jeden Tag.
    Natürlich, da meinte ich auch mehr das andere, bzw. andere Sprachen. ^^" Aber hätte ich das jetzt alles gut ausformuliert, wäre der Post komplett unlesbar geworden. XD
    Und in Java z.B. geht sowas ja nur bei booleans, da braucht man das wohl deutlich seltener. Aber klar, in PHP verwende ich's auch ständig.

    Nur kann ich mir echt nicht vorstellen, dass hier jemals jemand a < b < c tatsächlich so gemeint hat. PHP verbietet das netterweise sogar. ^^ Naja, und in Java geht's ja sowieso nicht…
    Dass es jemand mal unabsichtlich schreibt, kann ich mir da schon deutlich eher vorstellen, auch wenn's mir persönlich afair noch nie passiert ist.

  3. #3
    Gerade C legt großen Wert darauf, dem Programmierer so viel Freiraum zu lassen, wie es möglich ist. Wie Ineluki schon schrieb, ist das Motto von C: Der Programmierer weiß was er tut. Das hat Nachteile, ganz klar, so wie beispielsweise in Inelukis Fall, aber auch enorme Vorteile in der Performance und Freiheit, Punkte, die für eine Systemsprache essentiell sind. (Das heißt natürlich nicht, dass C das Non plus ultra ist und es nicht mehr besser geht, aber im Moment reden wir von C und an dieser Sprache wird sich kaum etwas so schnell ändern.)
    Um zu verstehen, weshalb ich es nicht für sinnvoll halte, bei einer Verkettung wie 'a < b < c' eine Warnung zu generieren, musst du verstehen was ein Ausdruck in C ist, wie der Compiler Verkettungen auflöst, wozu implizite Konvertierung da ist, welcher Typ als Resultat einer Vergleichsoperation zurückgegeben wird, grundsätzlich alles über Typen in C, ihre Wertebereiche und wie zwischen verschiedenen Typen konvertiert wird, usw. In C gibt es keinen built-in Boolean-Typ. Bei einer Vergleichsoperation wird 0 oder 1 zurückgegeben, als int-Wert, so dass ein erneuter Vergleich mit dem zurückgegebenen Wert semantisch absolut Sinn macht, solange nicht mit einem Typ vergleichen wird, dessen Wertebereich kleiner ist, als der eines int.
    Dazu kommt noch, dass man mit einer Warnung, die 'a < b < c' in Frage stellt, noch lange nicht fertig ist mit Verkettungen von Ausdrücken in C, die zwar syntaktisch und semantisch korrekt sind, aber nicht das widerspiegeln könnten, was der (unerfahrene) Programmierer gemeint haben könnte, dazu lässt C einfach zu viel Freiraum zu, und zu versuchen alles abzudecken ist schier unmöglich. Es ist Cs Charakter, wenig Regeln aufzustellen und den Programmierer machen zu lassen, wozu er Lust hat, solange es syntaktisch und semantisch valide ist und du ahnst gar nicht wie kreativ dabei manche Programmierer werden können, auch außerhalb des Obfuscated C Code Contests. Wenn man Cs Tücken ohne jahrelanger Praxis effektiv vermeiden will, sollte man C einfach nicht benutzen und zu einer Sprache wechseln, die strikter ist.

  4. #4
    Zitat Zitat von Kyuu Beitrag anzeigen
    Um zu verstehen, weshalb ich es nicht für sinnvoll halte, bei einer Verkettung wie 'a < b < c' eine Warnung zu generieren, musst du verstehen…
    Ja, danke, das verstehe ich natürlich alles. Ich kann C, und bin mir auch, wie bereits geschrieben, darüber bewusst, dass der Ausdruck theoretisch komplett korrekt ist.
    Ich bin mir nur bei diesem speziellen sicher, dass der praktisch nie sinnvoll angewendet werden kann. Und da wäre, bei -Wall, mMn eine Warnung vertretbar, "Sorry, stimmt eigentlich eh, aber wolltest du das wirklich?".
    Luki ist sicher kein Anfänger, und wenn selbst ihm das mal passiert ist (anscheinend vor ziemlich kurzem), kann das auch anderen guten Programmierern passieren. Und warum dann nicht davor warnen, wenn das bei anderen Sachen, die Absicht sein könnten, ohnehin schon gemacht wird?

    Aber ist natürlich nur meine Meinung.

  5. #5
    Ich stimme Saeuferaeffchen voll zu. Ich habe schon fast ein Jahrzehnt Programmiererfahrung in C und etwa 2 Jahrzehnte Programmiererfahrung insgesammt.

    Trotzdem kann einem soetwas schnell passieren, insbesondere, wenn man mathematische Formeln/Algorithmen uebertraegt. Dass C nicht erkennt, was ein bool ist, und was ein int ist, nicht zwingend so. Es ist zwar nicht als eigener Datentyp spezifiziert, aber der Compiler hat alle Informationen, das zu entscheiden, und gerade hier WEISS der compiler, sogar, dass a<b ein bool ist, und es waehre ein Leichtes fuer ihn, es von einem int zu unterscheiden. Und wann testet man ein bool schon mal auf < oder > ? Auf bools operiert man mit == true, !, || und &&, normalerweise vergleicht man sich nicht mit < oder >, denn das entspricht nicht ihrer Natur. Und das weiss auch der Compiler, weswegen er einen indirect cast von bool nach double macht, um < anwenden zu koennen.

    In meinen Augen ist eine automatische Konvertierung von bool nach double zwar haeufig sinnvoll, jedoch in vielen Faellen eben nicht. Wenn ich unsigned int mit int vergleiche, warnt mich doch -Wall auch, und sei es nur, dass ich in meiner for-schleife den datentyp size_t verwende, und dann mit einem anderen berechneten Index von typ int vergleiche, auch wenn ich als Programmierer weiss, dass der Index sich im Bereich 0 bis ca. 100 bewegen wird.

    -Wall gibt schon SEHR viele Warnungen aus. Da wuerde diese eine mehr wirklich nicht schaden. Ausserdem heisst eine Warnung ja nich, dass man was falsch gemacht hat, sondern dass man moeglicherweise etwas getan hat, was man so nicht wollte. Und wenn man unbedingt mit a<b<c etwas anderes meint, kann man auch explizit ein ((double)a<b)<c schreiben. Dann weiss naemlich nicht nur der compiler, was abgeht, sondern auch der Programmiere beim ueberfliegen des Quellcodes. Ein Konstrukt wie a<b<c interpretiert man beim schnellen(!) Codescreening eben NICHT als das, was es eigentlich meint.

    Und mal ehrlich: Was ist Ziel des ganzen ? Eine Sprache, die jede Syntax unkommentiert uebernimmt (dann benutze einfach nicht -Wall) oder eine, die auch mal nachfragt, ob man das auch wirklich so meint. Es ist ohnehin sauberer, d.h. verstaendlicherer Code, wenn man in diesem Fall ausschreibt, dass man ein bool mit einem double vergleichen will.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •