Eure größten Pannen bzw Macken beim Programmieren ....

Michael E.

Freak_Coder schrieb:

Ben04 schrieb:
const std::string&b0r
Fehlendes Leerzeichen ??? (Aber würde der Compiler schon meckern)

Nö, das Leerzeichen ist redundant.

Der Fehler ist, dass der Parameter des Konstruktors b0r (mit einer Null) heißt, der String aber mit bOr (mit großem O), also mit sich selbst initialisiert wird.

Hallo

Ich habe mal vergessen im der cpp-Datei vor die Memberfunktionen des Namen der Klasse zuschreiben und mich immer gewundert, warum mein VisualAssist spinnt und mir nichts anzeigt. Ich habe es echt nicht selber gesehen und dann hier gepostet.

Oder bei DirectX beim Vertexformat statt D3DFVT_XYZ habe ich D3DFVT_XYZW geschrieben und mich gewundert, warum ich nichts sehe.

chrische

LordJaxom

Mein Highlight (sinngemäß):

Thread 1 startet Thread 2 und wartet auf ein Signal von Thread 2
Thread 2 schickt nach dem Start das Signal an Thread 1

Führte dann dazu, dass der erste Test der NICHT auf meinem Entwicklungsrechner lief sich nen Deadlock einfing, weil Thread 2 das Signal schickte als Thread 1 noch garnicht darauf wartete.

Lyrix

Bei mir sind es meistens immer ziemlich dumme Fehler. Die eigentlich so einfach sind, dass ich meist ewig brauche um darauf zu kommen, da ich sowas nicht erwartet habe

Ben04

Michael E. schrieb:

Freak_Coder schrieb:
Ben04 schrieb:
const std::string&b0r
Fehlendes Leerzeichen ??? (Aber würde der Compiler schon meckern)
Nö, das Leerzeichen ist redundant.

Der Fehler ist, dass der Parameter des Konstruktors b0r (mit einer Null) heißt, der String aber mit bOr (mit großem O), also mit sich selbst initialisiert wird.

Korrekt, wie lang hast du gebraucht um dies herauszufinden?

Ich brauchte damals etwas mehr als einen ganzen Tag um den Fehler zu finden. War hier aber auch einfacher da der Name b0r äußerst verdächtig und gekünstelt aussah. Naja, heute ist es auf meiner Liste was ich überprüfe wenn ich nicht weiß was ich nicht weiter weiß.

JBeni

Die schlimmsten Fehler haben was mit dem Design zu tun. Ich mag mich da ein zwei Oberserver erinnern, die gegenseitig registriert waren.

A feuert ein Event. B reagiert, und feuert ein Event. A reagiert, und feuert ein Event. B...

Bei so einem Fehler kann man die Hälfte des Programmes wegwerfen.

Hallo

if(n==2)
// wir haben zwei Argumente
{ cout << "alles frisch hier?" ; }

Grüße

PS. Das Beispiel ist schon einige Jahre alt. Ob neuere Compiler
die Sache anmahnen oder korrekt compilieren, ist möglich, ich weiß
es nicht, da man so einen Fehler nur einmal macht.

CMatt

Immer wieder gerne:

for(size_t i=0;i<x;i++);
{
...
}

Termite

Hi

kleiner Embedded Fehler.

#define REBOOT__BOOT_CODE_SIZE (12*1024)

void REBOOT_RestartBooter( void )
{

   uint32_t i;        /* counter */

   uint8_t * sramAdr; /* internal sram adress */

   uint8_t dataBuffer[REBOOT__BOOT_CODE_SIZE]

   sramAdr = (uint8_t *) 0u;

   /* Read Booter from flash */
   REBOOT_ReadFLASH( 0, (REBOOT__BOOT_CODE_SIZE), dataBuffer );

   /* Disable IRQs */
   REBOOT__DisableIRQS();

   /* store Booter into internal SRAM */
   for ( i = 0; i < (16u * 1024u); i++)
   {
      sramAdr[i] = dataBuffer[i];
   }

   /* jump into internal sram adr 0x00000000 */
   REBOOT__Jump0();
}

Kann sich jemand denken wo der Fehler ist? Kleiner Tip im Ebeded bereich hat mal nur recht kleine stacks von maximal ein paar kB (1 - 4).

dataBuffer wurde auf dem stack angelegt. Somit wurde Daten die nach dem Stack der aufrufenden Task lagen gnadenlos überschrieben. Hatte zur folge das das Programm mit ner hässlichen exception hängen geblieben ist (sprung in die wüste). Das lustige war noch das es mit 11,5 kB ging mit 12 dann nicht mehr. Mittels nem Trace hab ich dan rausbekommen das das OS den Sprung in die Wüste veranlasst. grr hab ich geflucht als ich gemerkt hab, was für nen bock ich abgeschossen hab. dataBuffer global angelegt und schon lief alles wie erwartet.

Hatte den vorteil, das wir mal wieder unsern trace reaktiviert haben. hat auch gut 1 1/2 tage gedauert das ding dazu bewegen was aufzuzeichnen.

gruss

Michael E.

Ben04 schrieb:

Korrekt, wie lang hast du gebraucht um dies herauszufinden?

Ich brauchte damals etwas mehr als einen ganzen Tag um den Fehler zu finden. War hier aber auch einfacher da der Name b0r äußerst verdächtig und gekünstelt aussah.

Ebend Nachdem ich keinen Fehler gefunden hab, hab ich mirs mal in Notepad kopiert und da fällts direkt auf.

Michael E. schrieb:

Ben04 schrieb:

Korrekt, wie lang hast du gebraucht um dies herauszufinden?

Ich brauchte damals etwas mehr als einen ganzen Tag um den Fehler zu finden. War hier aber auch einfacher da der Name b0r äußerst verdächtig und gekünstelt aussah.

Ebend Nachdem ich keinen Fehler gefunden hab, hab ich mirs mal in Notepad kopiert und da fällts direkt auf.

Ich könnt mich zwar nicht mit ner anderen Schriftart zum programmieren anfreunden, aber ne Überlegung wäre es sicher wert um solche Fehler zu vermeiden.

Von meinen schlimmsten Fehlern hab ich gerade keinen da. Aber da gibts auch einige.

struct VERTEX{
vec3 pos;
vec3 normal;
vec2 tex;
DWORD diffuse;
};

Hat mich zwei nächte gekostet.

SideWinder

diffuse vor tex?

MfG SideWinder

Jup
Ich bin fast durchgedreht weil immer nur murks angezeigt wurde. Irgendwie habe ich gedacht das ich die Reihenfolge durch die FVF angebe bis mir dan kalr wurde das das nur ein bitflag war und dx die reihenfolge ja gar nicht kennen kan.

net 0

Termite schrieb:

Hi
kleiner Embedded Fehler.

das geht ja noch
lustig wird's erst, wenn man überhaupt keine variablen und keinen stack in solchen flashercodes benutzen darf weil der ganze ram überschrieben wird... wie programmiert man sowas? wer hat 'ne idee?

Neku

Besonders schön ist es auch eine Warnmeldung in MSVC++ zu deaktivieren, welche einen später auf ein Problem aufmerksam gemacht hätte (In meinem Fall hatte meine Klasse keinen expliziten operator=, wodurch MSVC++ einfach einen enthaltenen Pointer kopiert hat.)

net 0

auch noch was für windoofs fans. warum läuft das saulangsam?

#include <stdio.h>
#include <windows.h>

volatile int flag = 0;

void thread (void)
{
   while (1)
   {
      if (flag)
      {
         flag = 0;
         putchar('*');
      }
   }
}

void main()
{
   DWORD tid;
   CreateThread (NULL, 0, (LPTHREAD_START_ROUTINE)thread, 0, 0, &tid);
   while (1)
   {
      flag = 1;
   }
}

pZy

Die nervigsten Fehler aren für mich immer

- Linkerfehler. Die Meldungen sind für Anfänger selten verständlich.
- Binäre Inkompatibilitäten (.lib mit Stlport gebaut, später Linkerfehler weil im Projekt MS STL benutzt...)
- In einer lib Language Runtime statisch gelinkt, im Projekt stehts default auf dynamisch.
- ...und viele Fehler bez. RAPI und WindowsCE Geräten...

Das fehlende Modulsystem ärgert mich am meisten an der ganzen Programmiersprache.

Vor ein paar Tagen erst:

1. tstring GetFileSize(HANDLE);
2. tstring GetFileSize(const tstring& path);

-> GetFileSize( _T("C:\\AUTOEXEC.BAT") ); // Was möchte ich da wohl aufrufen?

Ja, hab da nicht dran gedacht, dass ein HANDLE eigentlich auch nur ein Pointer ist...

Termite

@net:

Lass mich raten Bandwurmprogramierung mit vielen goto ohne call und ret. so wie früher in basic ohne funktionen.

net 0

Termite schrieb:

@net:
Lass mich raten Bandwurmprogramierung mit vielen goto ohne call und ret. so wie früher in basic ohne funktionen.

nee, schlimmer. es geht nur in assembler. als variablen dürfen nur prozessorregister verwendet werden.