snake in c

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?

pointercrash() schrieb:

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.

als IDE finde ich sie nicht so berauschend. da gibt's wesentlich besseres. aber die c-compiler (ich kann nur für ARM und MSP sprechen) sind ganz brauchbar.

pointercrash() schrieb:

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.

ich kenne zum glück 'nen FAE bei einem grossen distributor, der mich mit endlos lauffähigen 'evaluationsversionen' versorgen kann. gekauft wird dann nur, wenn das zeug auf herz und nieren getestet wurde.

pointercrash() schrieb:

...man kriegt für fast jeden Prozessor einen GCC- Port und an integrierenden Plattformen wie Eclipse mangelt's auch nicht mehr.

naja, mit gcc, open-source IDEs und -debuggern hab' ich mich eigentlich mehr rumgeärgert, als damit produktiv gearbeitet. den kram würde ich nur nehmen, wenn's wirklich keine alternative gibt.

pointercrash**

Hui, jetzt simmer echt OT ... was soll`s?

embedded-freak schrieb:

als IDE finde ich sie nicht so berauschend. da gibt's wesentlich besseres. aber die c-compiler (ich kann nur für ARM und MSP sprechen) sind ganz brauchbar.

Umpff, wollte nur sagen, daß ich darüber nicht motzen kann - die IDE war`s nicht, in dem Fall der C-Spy. Die Leutchen davor waren zudem offensichtlich mit den Compilern unzufrieden.

embedded-freak schrieb:

ich kenne zum glück 'nen FAE bei einem grossen distributor, der mich mit endlos lauffähigen 'evaluationsversionen'.

Schön für Dich, ich muß leider Geld dafür ausgeben oder kriege was hingeklatscht, womit ich arbeiten soll/muß.

embedded-freak schrieb:

naja, mit gcc, open-source IDEs und -debuggern hab' ich mich eigentlich mehr rumgeärgert, als damit produktiv gearbeitet.

Aus dem heutigen Blickwinkel nicht mehr richtig, weil viele Compiler/Debugger - Sets von den Herstellern kommen, die sich irgendwo einklinken lassen. Die AVRgcc z.B. muß sich vor den kommerziellen Lösungen nicht verstecken, die KPIT- GCC integriert sich super in die HEW, einfach nur exemplarisch genannt.

Wenn ich gut 2000 Teuronen abdrücke, erwarte ich vom Support freundlichere Plattmache als "lernen Sie erstmal C", und nach drei Monaten echte, nachweisbare Fehler nicht geflickt zu bekommen, kann ich auch kostenlos haben. Bei Open Source kann ich mich bedarfsweise selbst darum kümmern, daß das funzt. Letztendlich hat diese Änderung C für mich wieder attraktiv gemacht ...

pointercrash() schrieb:

embedded-freak schrieb:

ich kenne zum glück 'nen FAE bei einem grossen distributor, der mich mit endlos lauffähigen 'evaluationsversionen'.

Schön für Dich, ich muß leider Geld dafür ausgeben oder kriege was hingeklatscht, womit ich arbeiten soll/muß.

ach herrje, dann biste bestimmt 'consultant' oder sowas. aber was solls, irgendwie haben wir alle probleme mit halbfertigem zeug von drittanbietern. ist z.b. auch immer wieder lustig, als hardwaredebugger missbraucht zu werden. neulich erst ein hochkompexes SoC, das nur dadurch zuverlässig zum leben erweckt werden konnte, wenn man einen 10nF kondensator gegen 1nF tauscht. laut hersteller müssen 10nF dran, damit intern 3 spannungen in der richtigen reihenfolge hochlaufen. hat er auch alles getestet und 100mal versichert, dass es so läuft. jetzt liefert er's urplötzlich mit 1nF aus.
wer sich mit sowas herumärgert, der kann behinderungen bei der softwareentwicklung, auswahl der tools usw. absolut nicht gebrauchen.

pointercrash() schrieb:

embedded-freak schrieb:

naja, mit gcc, open-source IDEs und -debuggern hab' ich mich eigentlich mehr rumgeärgert, als damit produktiv gearbeitet.

Aus dem heutigen Blickwinkel nicht mehr richtig, weil viele Compiler/Debugger - Sets von den Herstellern kommen, die sich irgendwo einklinken lassen. Die AVRgcc z.B. muß sich vor den kommerziellen Lösungen nicht verstecken...

ich hab' vor ca. einem jahr 'nen code für eine Star12 CPU (Freescale) durch einen GCC gejagt. das binary war fast doppelt so gross wie das des original-freescale compilers. sowas schreckt mich immer ziemlich ab.