Eure dümmsten Fehler bei der Programmierung



  • Hallo!

    Postet mal eure dümmsten Fehler die euch bei der Programmierung (in C++) passiert sind. 😃
    Oft ist es ja so, das man da in ganz doofe Situationen kommt und stundenlang an einem Problem sitzt und es dabei nur ein ganz simpler Fehler ist. 🙄
    Schreibt mal von euren Erlebnissen damit. 🕶

    Vielleicht kann man dadurch auch so eine kleine Checkliste erstellen anhand der man so kleine/dumme Fehler entlarvt werden können. 🙂



  • In einem Switch/Case-Block immer, immer, ich sage es noch mal: immer! die breaks reinsetzen. Ich hab mal ca. vier cases gehabt, in darin eigentlich auch die breaks reingesetzt. Bis auf einen, den ich vergessen habe. Darunter war aber ein anderes case, so das er immer da weiter mit reingesprungen ist. Ich hab zwei Abende wie ein bekloppter gedebugt, aber nie in dem case-Block. ARGH! Seit dem schreibe ich immer, nach dem case gleich das passende break dazu. IMMER! 😃



  • Hallo,
    immer prüfen welche Dateien man gerade bearbeitet. Ich habe mal mehrere Stunden nach einem Fehler gesucht, bis ich endlich feststellte, dass ich an meinen lokalen Dateien Änderungen vornahm, aber eine andere Version auf unserem Server testete 🙂

    [ Dieser Beitrag wurde am 17.11.2002 um 19:49 Uhr von HumeSikkins editiert. ]



  • Original erstellt von HumeSikkins:
    **Hallo,
    immer prüfen welche Dateien man gerade bearbeitet. Ich habe mal mehrere Stunden nach einem Fehler gesucht, bis ich endlich feststellte, dass ich an meinen lokalen Dateien Änderungen vornahm, aber eine andere Version auf unserem Server testete 🙂

    [ Dieser Beitrag wurde am 17.11.2002 um 19:49 Uhr von [qb]HumeSikkins** editiert. ][/QB]

    Das ist mir auch schon öfter passiert, aber spätestens als ich dann explicit eine Ausgabe gemacht habe, die kommen MUSSTE, aber nicht kam, ist mir aufgefallen, dass ich mit den falschen Dateien arbeite...



  • immer schön auf die for-schleife achten!
    Ich hab immer gedacht, dass bei einer for-schleife das zweite "Argument" der Endzustand sein soll und nicht die Bedingung während die Schleife läuft!



  • Seeehr beliebt ist auch:

    if( iVal = 10).... höhö

    oder aber eine Variable zuweisen, man debugt, der richtige Wert steht drinne, aber aus irgendwelchen Gründen arbeitet man an der entscheidenden Stelle im Programm mit einer ganz anderen, da sie rein zufällig so ähnlich hieß...



  • Ich baue gerne mal nen geilen Stack-Overflow.

    void func() {
       func();
    }
    

    natürlich nicht so offentlichsichtlich und deshalb hab ich da schon ne nacht für verbracht 🕶



  • was mir zur Zeit den Schlaf raubt ist irgend etwas, was den Heap zerstört, weiss aber nicht genau wo und durch die Zerstörung des Heaps hilft mir der Debugger wenig 😞 BTW. suche leute die mir beim Debuggen helfen 😉

    Ansonten sind beliebte Fehler Variablen nicht zu initalisieren, zum Glück warnt der GCC davor, wenn man die anschließend benutzt

    [ Dieser Beitrag wurde am 17.11.2002 um 20:43 Uhr von kingruedi editiert. ]



  • Original erstellt von kingruedi:
    Ansonten sind beliebte Fehler Variablen nicht zu initalisieren, zum Glück warnt der GCC davor, wenn man die anschließend benutzt

    Das sollte jeder halbwegs gute Compiler tun.



  • Mein letzter Fehler bei dem ich blöd dreingeschaut habe war:

    template<...>
    class Ref
    {
    ...
    void readFrom(istream& stream)
    {
      stream>>var;
    }
    };
    
    istream operator>>(istream& stream, const Ref<...>& ref)
    {
      ref.readFrom(stream);
      return stream;
    }
    

    Allerdings waren da eine handvoll Templates im Spiel und ich hab mindestens 5minuten lang blöd geschaut weil er gemeint hat readFrom() gibts nicht...
    🙄



  • Ooch...da gibt es so einiges...

    • Nicht initialiserte Objekte benutzen
    • while(true){....} ohne break;
    • Und so weiter, und so weiter...


  • Mein schönster bis jetzt war, als ich mit jemandem zusammen etwas programmiert habe. Ich habe konsequent mit x/y gearbeitet, er mit zeile, spalte

    Hat auch so weit alles geklappt, war ja so abgesprochen. Nur im Konstruktor hab ich seinem Objekt Breite, Höhe übergeben, es wollte aber Höhe/Breite...

    Da wo die Komponenten einzeln gearbeitet haben war's egal, nur im Zusammenspiel waren Zeilen plötzlich Spalten und umgekehrt...



  • Dieser Fehler hat mich 2 Tage in den Wahnsinn getrieben. Als ich ihn dann endlich gefunden hatte hab ich ernsthaft daran gezweifelt ob ich überhaupt programmieren kann 😃 🙄

    for (int x = 0; x < 12345; x++);
    {
      bla bla bla
    }
    


  • for (i = 0; i = 12; i++) ...

    for (i = 1; i < 11; i++);
    printf("%d",i);

    ...

    cYa
    DjR



  • Original erstellt von Cpp_Junky:
    **Dieser Fehler hat mich 2 Tage in den Wahnsinn getrieben. Als ich ihn dann endlich gefunden hatte hab ich ernsthaft daran gezweifelt ob ich überhaupt programmieren kann 😃 🙄

    for (int x = 0; x < 12345; x++);
    {
      bla bla bla
    }
    

    **

    So was passiert mir auch häufig ... wundere mich dann warum der Code nicht wiederholt wird 🙂



  • for (int x = 0; x < 12345; x++);
    {
      bla bla bla
    }
    

    Genau das ist mein lieblingsfehler. Inzwischen finde ich ihn aber recht schnell.



  • Ich mache nie Fehler! 😃 😃 😃

    Spass beiseite:
    Ich hab mit PostMessage einen lokalen String weggeschickt - und mich dann über die komischen Zeichen gewundert...

    [ Dieser Beitrag wurde am 18.11.2002 um 11:27 Uhr von Nemesyzz editiert. ]



  • Die Fehler

    for (int x = 0; x < 12345; x++);
    

    und

    if (i=0)
    

    kenn ich auch. Um die zu vermeiden hab ich mir bei ersterem angewöhnt die { nach oben zu ziehen. Also

    for (int i = 0;i < 12345; i++){
    

    Ist zwar eine Umstellung, hat aber bei mir gut funktioniert.
    Der zweite Fehler wird (meist) durch den Compiler gefunden. Falls aber der Warning-Level reduziert werden muss, schreib ich immer

    if (0==i)
    

    statt

    if (i == 0)
    

    dann gibts einen echten Fehler wenn = statt == geschrieben wird, den jeder Compiler immer moniert.

    Meine schlimmsten Fehler stammen aus meine C-Zeiten:
    Über Feldgrenzen rausschreiben. Meist verhält sich die Release-Version schon mal anders als die Debug-Version und für Fehlersuche kann leicht mal einen Tag in Anspruch nehmen.

    [ Dieser Beitrag wurde am 18.11.2002 um 11:36 Uhr von Kauz01 editiert. ]



  • Bei Header-Dateien

    #ifndef _BLA_H
    #define _BLA_H
    .
    .
    .
    #endif
    

    vergessen. Das gibt einen schön ekelhaften Fehler wenn man die .h Datei ohne sowas sowohl im Submodul als auch im Hauptmodul included. Meine Tastatur hat
    sehr darunter gelitten ("verdammte Scheisse, warum denn? (bumm,bumm ... knirsch). 😃



  • vergisst _nieeeeeeee_ das H

    ich hab mal anstat int 21h nur int 21 gehabt, das war meine 100% assembler 3d-engine und dieses int21 hab ich nur für die debug ausgabe gehabt, ich hab jeden polygonfüll algorithmuss 1000mal durchgesehen, alle rekursionen perfekt mit output versehen und bei zu großer tiefe abgebrochen, alles durchgesehen, außer beim int 21 für die fps das H... hab ne ganze woche dran gehangen, ich war soweit, dss mein pc innerhalb von 14sekunden beim booten in die dev umgebung meines masm rein kamm (weil es immer einen absturz gab).. ich hab bestimmt die hälfte meiner haare daran verloren...

    rapso->greets();


Anmelden zum Antworten