snake in c

Mario Sandler

Erwartest du jetzt das wir das alles durchlesen und deinen Fehler suchen?
Schnapp dir deinen Debugger und schau wenigstens nach in welcher Zeile
oder Funktion dein Programm abstürzt.
Bei einem Speicherzugriffsfehler wirst du wahrscheinlich irgendwo außerhalb
der Grenzen deiner Liste zugreifen.

bobo001

kannst mal das Header file posten damit wir es debbugen können?

Bitte ein Bit

Ich muss Shade of Mine Recht geben, wirf deinen Debugger an und schaue wo der Fehler liegt. Denn alle Debugger werden an dem Segmentation fault hängenbleiben und dir genau die Codezeile zeigen an der der Fehler auftritt. Wenn du nun noch die Variablen untersuchst, wirst du vermutlich feststellen, dass du auf einen nicht initialisierten Pointer zugreifst, oder über Array Grenzen hinausschreibst (denn dass sind meistens die Ursachen für einen Segmentation fault). Bei dem GNU Debugger gdb geht dies einfach über den Aufruf gdb snake.exe. Danach landet man auf der gdb Konsole wo man run eingeben muss. Da er nun das Programm aufruft, wird der Debugger die Segmentation fault Meldung bringen. Wenn man nun backtrace eingibt bekommt man genau die Zeile angezeigt, wo der Fehler aufgetaucht ist. Unter guten IDEs (VS/Kdevelop/Anjuta) ist dies grafisch eingebaut.

Wenn dass was ich gesagt habe fremd für dich war, würde ich dir einen Grundkurs in Debugging empfehlen.

Generell habe ich bei dem Segmentation fault die Variablen kopf in Verdacht.

memset(spielfeld,' ', sizeof(spielfeld));

  //positionsaenderung der schlange im feld umschreiben

  kopf=bewegung(kopf,spielfeld);
  if(kopf==NULL)  
    ende=1;            // <- Die Variable kopf kann durchaus NULL sein

  ...

  //Richtungsbestimmung       
  kopf->daten.richtung=richtungsbestimmung(eingabe); // <- Wenn hier kopf gleich NULL ist, kracht es

Übrigens habe ich auch noch einen Fehler gefunden.

snakeT *new=NULL;

Denn das Wörtchen new ist ein Schlüsselwort in C++ und sollte daher nicht als Variablennamen verwendet werden.

Bitte ein Bit schrieb:

Übrigens habe ich auch noch einen Fehler gefunden.
snakeT *new=NULL;
Denn das Wörtchen new ist ein Schlüsselwort in C++ und sollte daher nicht als Variablennamen verwendet werden.

fehler? das solltest du jetzt aber erklären...

Bitte ein Bit

Ganz einfach.

Wenn man die C-Datei als C++ Datei kompiliert, hat man das Problem das die Variable den gleichen Namen hat wie das Schlüsselwort new. Das könnte durchaus ein Problem mit so manchem Compiler geben, da es zu einer Mehrdeutigkeit kommen kann.

Man sollte am besten Variablennamen nicht nach Schlüsselwörten oder bereits vorhandenen Variablen-Namen bezeichnen.

supertux

Bitte ein Bit schrieb:

Wenn man die C-Datei als C++ Datei kompiliert,

und wieso sollte man das machen wollen? C ist nicht C++ und umgekehrt. Wenn man C Code mit C++ Compilern übersetzen will, dann man macht etwas ganz falsches.

Bitte ein Bit schrieb:

Man sollte am besten Variablennamen nicht nach Schlüsselwörten oder bereits vorhandenen Variablen-Namen bezeichnen.

richtig, aber 'new' ist kein Schlüsselwort in C, demnach frei wählbar --> also hat der OP keinen Fehler gemacht.

Bitte ein Bit

Bitte ein Bit schrieb:

Wenn man die C-Datei als C++ Datei kompiliert,

und wieso sollte man das machen wollen? C ist nicht C++ und umgekehrt. Wenn man C Code mit C++ Compilern übersetzen will, dann man macht etwas ganz falsches.

Bitte ein Bit schrieb:

Man sollte am besten Variablennamen nicht nach Schlüsselwörten oder bereits vorhandenen Variablen-Namen bezeichnen.

richtig, aber 'new' ist kein Schlüsselwort in C, demnach frei wählbar --> also hat der OP keinen Fehler gemacht.

Eine solche Antwort musste ja kommen. Ich habe das Gefühl dass einige Mitglieder diese Forums eine Lieblingssprache haben und alle anderen Programmmiersprachen deswegen automatisch schlecht sind.

Aber mal zurück zu deiner Bemerkung supertux. Was macht man, wenn man ein Projekt hat, das auf einem normalen PC laufen soll, deren Berechnungsalgorithmen aber auch auf einem embedded Controller laufen soll ? Der Controller soll dabei mit C programmiert werden, während die Teile für den PC mit C oder C++ entwickeln werden kann.

Soll man alles in C entwickeln ? Nein danke, damit würde man sich nur selbst in Knie schiesen. Was ich an C kritisiere ist unter anderem das Fehlen von Templates. Will man beispielsweise Objekte in ein AVL-Baum oder einer doppelt-verketteten Liste speichern will, so muss man entweder für jeden Typ eine seperate Liste erzeugen (viel Code), oder als Datentyp void* akzeptieren (und damit die Typsicherheit aufgeben) oder die Template Klasse in Form eines riesigen #define nachprogramieren (was Selbstmord vom Feinsten ist). Wenn man es ganz bös nimmt, zeigen viele Vorteile der STL die Nachteile von C.

Aber, C ist Standard bei der Entwicklung von Programmen auf embedded Controllern. Und so habe ich mich entschieden Teile des Projektes in C und andere Teile in C++ zu schreiben. Und daran ist beim besten Willen nix falsches dran. Genausgut könntest du den Java - Entwickler das JNI verbieten, oder der Aufruf von C-Bibliotheken aus einem C++ Projekt her.

Bitte ein Bit schrieb:

Eine solche Antwort musste ja kommen. Ich habe das Gefühl dass einige Mitglieder diese Forums eine Lieblingssprache haben und alle anderen Programmmiersprachen deswegen automatisch schlecht sind.

'ne lieblingssprache hat wohl jeder, aber andere sprachen kann man auch gut oder schlecht finden.

Bitte ein Bit schrieb:

Was macht man, wenn man ein Projekt hat, das auf einem normalen PC laufen soll, deren Berechnungsalgorithmen aber auch auf einem embedded Controller laufen soll ? Der Controller soll dabei mit C programmiert werden, während die Teile für den PC mit C oder C++ entwickeln werden kann.

dann schickst du die c-codes durch einen c-compiler und bindest ihn (statisch oder dynamisch, je nach belieben) in dein 'anderes-sprachen' -projekt ein. c-codes umzufrickeln, dass sie c++ o.ä. kompatibel werden, ist selten sinnvoll.

supertux

Bitte ein Bit schrieb:

Eine solche Antwort musste ja kommen. Ich habe das Gefühl dass einige Mitglieder diese Forums eine Lieblingssprache haben und alle anderen Programmmiersprachen deswegen automatisch schlecht sind.

Zeig mir, an welches Stelle habe *ich* gesagt, C++ wäre schlecht, weil ich C-Fan bin (ja, C ist meine Lieblingsprache)? Ich habe gesagt, es ist nicht gut, C Code mit einem C++ Compiler zu kompilieren und das hat nichts mit der Tatsache zu tun, dass ich ein C-Freak bin.

Bitte ein Bit schrieb:

Soll man alles in C entwickeln ?

nein, geb ich dir vollkommen Recht. Das hat aber trotzdem nichts mit meiner Bemerkung zu tun.

Bitte ein Bit schrieb:

... oder die Template Klasse in Form eines riesigen #define nachprogramieren (was Selbstmord vom Feinsten ist). Wenn man es ganz bös nimmt, zeigen viele Vorteile der STL die Nachteile von C.

im Wesentlichen geb ich dir Recht. OO in C zu programmieren ist nicht immer einfach. Das hat aber trotzdem nichts mit meiner Bemerkung zu tun.

Bitte ein Bit schrieb:

Aber, C ist Standard bei der Entwicklung von Programmen auf embedded Controllern. Und so habe ich mich entschieden Teile des Projektes in C und andere Teile in C++ zu schreiben. Und daran ist beim besten Willen nix falsches dran.

Wenn der Code sauber voneinander getrennt ist, dann ist sicherlich nichts falsches dran. Aber dann hat man auch keinen Grund, C Code durch den C++ Compiler zu schicken da hat vista ganz schön geschrieben:

c-freak schrieb:

dann schickst du die c-codes durch einen c-compiler und bindest ihn (statisch oder dynamisch, je nach belieben) in dein 'anderes-sprachen' -projekt ein. c-codes umzufrickeln, dass sie c++ o.ä. kompatibel werden, ist selten sinnvoll.

Ich verstehe eines nicht: Warum sollte man den Controller-Code mit dem PC-Code verlinken? Stehe ich gerade auf dem Schlauch?

Tim schrieb:

Ich verstehe eines nicht: Warum sollte man den Controller-Code mit dem PC-Code verlinken?

z.b. ein crypto-code, einen treiber (bis auf die hardwareanbindung) o.ä., auf'm PC testen und debuggen will. das geht oft einfacher, als den code auf dem target zu debuggen. oder ein proprietäres protokoll, über das sich die MCU und der PC unterhalten. der gleiche code steckt dann in beiden programmen.

Bitte ein Bit

c-freak schrieb

dann schickst du die c-codes durch einen c-compiler und bindest ihn (statisch oder dynamisch, je nach belieben) in dein 'anderes-sprachen' -projekt ein. c-codes umzufrickeln, dass sie c++ o.ä. kompatibel werden, ist selten sinnvoll.

Umfrickeln ist bei mir nicht nötig. Denn im Gegensatz zur Windows / DirektX Bibliothek mische ich nicht C mit C++, sondern ich schreibe nur ANSI C Dateien oder C++ Dateien. Programmiertechnisch sind die C-Dateien sauber von den C++-Dateien voneinander getrennt.

Das einzigste was ich umändern muss sind die malloc/calloc Aufruf, welche ich casten muss. Sonst nix.

Trotzdem ist es mir aber nicht klar, warum man nicht C-Dateien nicht in einem C++ Projekt kompilieren sollte. Wenn doch der Compiler C-Projekte und C++-Projekte kompilieren kann, warum sollte es dann schlimm sein C-Dateien in eim C++ Projekt einzubinden ?

Bitte ein Bit schrieb:

warum sollte es dann schlimm sein C-Dateien in eim C++ Projekt einzubinden ?

wegen der unterschiede: http://david.tribble.com/text/cdiffs.htm
gib doch

sizeof('a');

mal in einem c und einem c++ programm aus.

supertux

Bitte ein Bit schrieb:

Trotzdem ist es mir aber nicht klar, warum man nicht C-Dateien nicht in einem C++ Projekt kompilieren sollte. Wenn doch der Compiler C-Projekte und C++-Projekte kompilieren kann, warum sollte es dann schlimm sein C-Dateien in eim C++ Projekt einzubinden ?

weil C *keine* exakte Untermenge von C++ ist. C und C++ ähneln sich in der Synatx aber sind trotzdem zwei verschiedene Sprachen, die an manchen Stellen anders arbeiten. Du willst doch nicht Fahrrad Reifen im Motorrädern einsetzen, auch wenn Fahrräder und Motorräder fast dasselbe sind, oder?

pointercrash**

supertux schrieb:

weil C *keine* exakte Untermenge von C++ ist. C und C++ ähneln sich in der Synatx aber sind trotzdem zwei verschiedene Sprachen, ...

Ich habe da zwei Bespiele:
In einem Fall hatte ich eine Sache, wo ich eine GUI- gesteuerte Testumgebung für meinen C-Core einer Steuerung gebraucht habe. Da ich seit sechs Jahren nichts mehr mit Win- GUIs gemacht habe, wurde mein Code in die ANSI-C- Pragmas gepackt und ich konnte dort drin nach Herzenslust debuggen, der Rest war in C++ und hat mich nicht interessieren müssen. Das in DLLs zu kapseln, wäre zuviel Aufwand gewesen. Der Weg zurück in den Controller war auch völlig unspektakulär - nur als Tagesgeschäft würde ich das so nicht empfehlen, es war eben dieser spezielle Fall.

Das Negativbeispiel ist das Eindringen von C++ in den embedded- Bereich, wenn dann ein Ahnungsloser (meistens der Firmenleitung zugehörig) der Meinung ist, daß C uncool und C++ hip ist und fürderhin die Produktpalette in C++ weiterzuentwickeln sei. Mir ist sowas schon angetragen worden, ob ich machen kann, daß es geht, da hatten sich schon zwei Leute dran versucht und einen brutalen Mischmasch hinterlassen. Ehrlicherweise muß ich zugeben, daß ich in C++ nahezu ohne Kenntnisse war und mit zwei Büchern aufm Schreibtisch und ein paar Websites offen zu werkeln angefangen habe, aber als ich nach einem Tag erst zwei Bugs raushatte, wobei einer auf einen der kleinen Unterschiede zurückzuführen war, habe ich aufgesteckt und nahegelegt, die Codeuhr auf die Zeit vor C++ zurückzudrehen.

Ist auch Schuld der Compiler- Hersteller, die in der Werbung jubeln, daß sie jetzt auch plusplus können und nachher können sie beides nicht mehr richtig, weder ANSI-C, noch C++. Hauptsache, die Einkäufer können die Entwicklungsabteilungen mit "zwingend notwendigen" Upgrades quälen. Wenn ich jetzt noch anhänge "alter Schwede", dürften die embedded- Leutchen wissen, wem mein Zorn gilt ... :p

supertux

Du sagst ja auch: das war ein spezieller Fall und durchaus berechtigt. Aber man sollte dennoch nicht seinen C Code so schreiben, dass er wir C++ Code aussieht, sondern eben wie C Code.

pointercrash() schrieb:

Wenn ich jetzt noch anhänge "alter Schwede", dürften die embedded- Leutchen wissen, wem mein Zorn gilt

meinste IAR? falls ja, ich kann nicht klagen. die EW für ARM ist gar nicht mal so schlecht, jedenfalls der C-compiler taugt was. was C++ angeht, kann ich aber nichts sagen.

Bitte ein Bit

Wow, danke supertux und mixing-freak, dass ihr mich auf die Unterschiede zwischen C und C++ aufmerksam gemacht habt. Ich habe das immer ein wenig geglaubt dass man Sprachen mischen kann, wenn man sich an gewisse Regeln hält.

Insbesondere die Seite http://david.tribble.com/text/cdiffs.htm gefällt mir sehr gut. Gott sei Dank habe ich die C-Dateien gut funktioniell gekapselt, ich dürfte sie ohne größere Probleme in C-Bibs auslagern können.

Ich frage mich aber wie da im Compiler rumgehackt wird, wenn man C-Dateien mittels extern einbindet.

Bitte ein Bit schrieb:

Ich habe das immer ein wenig geglaubt dass man Sprachen mischen kann, wenn man sich an gewisse Regeln hält.

du kannst natürlich in c++ 'so ähnlich' wie in c coden, indem du keine klassen, namespaces, templates und ähnlichen c++ schnickschnack verwendest, aber es bleibt dann trotzdem c++ -code, auch wenn dich die hardcore-c++-fans dafür hassen werden.

Bitte ein Bit schrieb:

Ich frage mich aber wie da im Compiler rumgehackt wird, wenn man C-Dateien mittels extern einbindet.

naja, falls du z.b. visual studio verwendest: der hat für c und c++ separate compiler. die IDE entscheidet anhand der datei-extension (.c oder .cpp), welcher compiler aufgerufen werden soll. wenn du vom cpp-code aus c-routinen aufrufen willst, dann musste die im c++ code als extern "C" deklarieren.

pointercrash**

ikea-freak schrieb:

meinste IAR? falls ja, ich kann nicht klagen. die EW für ARM ist gar nicht mal so schlecht, jedenfalls der C-compiler taugt was. was C++ angeht, kann ich aber nichts sagen.

Die Workbenches sind ja nicht generell schlecht, in dem Fall war's die für irgendein Turbokrüppel- Derivat des leider unausrottbaren 8051.

Es ist damit möglich, C und C++ zu mischen, in der Werbung hieß es: "Erweitern Sie Ihre C-Projekte einfach um die Mächtigkeit von C++" oder so ähnlich. Eine IT- Sachentscheidung zur Bauchgefühlsparole zu machen, ist schon mal hanebüchen, aber ich kann mir vorstellen, daß nicht nur ein Mittelständler auf so eine Einflüsterung gehört hat. Die Entwickler wurden in der Folge durch die Firmenleitung dazu angehalten, das alte Zeug in Klassen zu packen und neue Funktionalitäten in C++ abzufassen - eine haarsträubende Idee.

Die Entwickler waren in der Folge zwar besten Willens, aber ohne jede Chance, in der Source war an jeder Ecke ein Workaround- Kommentar mit der Compilerversionsnummer vermerkt, häufig "// C/C++?", aber auch triviale Dinge scheinen zeitweise nicht richtig funktioniert zu haben, sogar mit Inline- ASM wurde gepatcht.
Einen Compilerfehler konnte ich zwar selbst nicht ausmachen, aber der C-Spy hat reproduzierbar an einer Stelle das Target gecrasht, was das Debuggen sehr mühselig gemacht hat. Da hilft mir dann auch die hübscheste Workbench nichts, die bei IAR zugegebenermaßen gut gelungen ist.

Mitte der 90er hatte ich selbst mal kurz einen C- IAR für MELPS77, der hatte einen Bug mit unsigned/signed- Vergleichen, in der 3- monatigen Update- Zeit wurde das nicht behoben und mit dem Support war ich auch unzufrieden. Der Distri hat das Ding zwar zurückgenommen, aber er hätte auch auf stur schalten können; ohne Upgrade- Vertrag hätte ich ansonsten ca. 5000 DM in den Müll hauen oder mich täglich ärgern können. War auch ein Grund, C den Rücken zu kehren und mit FORTH zu arbeiten.

Damals gab es für embedded relativ wenige Compiler, die Hersteller konnten irre Preise verlangen und ihre Kunden behandeln wie lästige Störungen des Tagesgeschäfts. Hat sich in den letzten Jahren drastisch geändert, man kriegt für fast jeden Prozessor einen GCC- Port und an integrierenden Plattformen wie Eclipse mangelt's auch nicht mehr. Dazu die Erkenntnis der µC- Hersteller, daß sich Prozessoren besser verkaufen lassen, wenn man ein (vielleicht bißchen limitiertes) C- Compilerchen verschenkt.
Das zusammengenommen mit den schlechten Erfahrungen mit den "Großen" (mit Keil hatte ich auch mal Spaß) berechtigt zur Frage: Wozu brauch' ich dann die noch?