jeder kennt doch das Phänomen, man sucht stundenlang nach nem dummen Fehler im Code, debugt sich zig mal hoch und runter und am Ende war das ein kleiner mini Fehler

Hier können wir ja solche Sachen mal sammeln und auch Sachen die man jedes mal falsch

Mir passier häufiger sowas :p

while(it!=dd.end()) {
   ...
   ...
   //++it vergessen
}

Dann einmal musste ich ne Verbindung zu einer Datenbank herstellen und in dem
Connection - String habe ich ein Semikolon vergessen und ich konnte keine Verbindung aufbauen, ich war mir sicher das der String völlig richtig war.
Bis ich dann nach 2 Stunden das fehlende Semikolon endeckte

Hmmm, da war noch mehr aber das fällt mir momentan nicht ein ...

dlg.m_strFileName = m_strName;
dlg.m_strProductName = m_strProductName;

Fazit: Er zeigte im Dialogfeld IDC_FILENAME den falschen Inhalt an und im Dialogfeld IDC_PRODUCTNAME den falschen Inhalt. Shit happens...
Es war einfach m_strName und m_strProductName vertauscht und Ich hab 1,5h dran gesessen und wußte nicht, wo der Fehler war. Stand übelst auf dem Schlauch!

class Foo{
public:
  Foo(const std::string&b0r):bOr(bOr){}
private:
  std::string bOr;
};

Wer findet den Fehler?

const std::string&b0r

Fehlendes Leerzeichen ??? (Aber würde der Compiler schon meckern)

Ben04 schrieb:

bOr(bOr)

Das sollte normal kein Fehler sein ...

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.

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

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.

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ß.

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.

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.

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

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

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.

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.

Hat mich zwei nächte gekostet.

MfG SideWinder

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?

#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;
   }
}

- 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...

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

@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.

std:.cout << "Hallo" << std:.endl;

geschrieben hab. Keine Ahnung warum immer nur da.
Noch jemand mit dem Leiden?