snake in c

[equest0r]

hi
habe probiert, snake in c zu schreiben.
was passiert? nach 3 durchläufen bekomme ich segmentation fault.
dachte, ihr könntet mir hier mal weiterhelfen.
Ich habe das ganze mit Listen programmiert, weil ich denke, dass dies ein guter Lösungweg wäre. Würde dies auch gern beibehalten
thx schonma !
ich poste mal main.c und funktionen.c

main:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "head.h"
#include "kbhit4linux.h"

#define ZEILEN 25
#define SPALTEN 8

int main()
{
	int i=0;
	int ende=0;
	int j=0;
	int startx=4;
	int starty=3;
	int keyAvail;
	snakeT *kopf=newelem();
	snakeT *new=NULL;
	char eingabe='d';

	kopf->daten.richtung=2;
	kopf->next=NULL;

	//Weitere 2 Elemente an die Schlange vorne anhaengen
	while(i<2)
	{
		new=newelem();	//Speicher anfordern
		new->next=kopf;
		new->daten.richtung=2;	// Osten/rechts als Startrichtung initialisieren
		kopf=new;
		i++;
	}
	i=0;

	//Startkoordinaten initialisieren

	while(i<3)
	{
		new->daten.x=startx;
		new->daten.y=starty--;
		new=new->next;
		i++;
	}

	char spielfeld[ZEILEN][SPALTEN];

	kopf->daten.richtung=2;	// Osten/rechts
	kopf->daten.laenge=3;
	do
	{
		// Zeilen mit Blanks befuellen
		memset(spielfeld,' ', sizeof(spielfeld));

		//positionsaenderung der schlange im feld umschreiben

		kopf=bewegung(kopf,spielfeld);
		if(kopf==NULL)
			ende=1;
		//Spielfeld zeichnen und ausgeben

		for(i=0;i<ZEILEN;i++)
		{
			spielfeld[i][0]='|';
			spielfeld[i][78]='|';
		}
		for(;j<SPALTEN;j++)
		{
			spielfeld[0][j]='_';
			spielfeld[24][j]='_';				
		}

		for(i=0;i<ZEILEN;i++)
			spielfeld[i][79]='\0';

		for(i=0;i<ZEILEN;i++)
			puts(spielfeld[i]);

		//Eingabe von w, a, s oder d des Benutzers für die Richtungsbestimmung der Schlange

		enablekbhit();
		keyAvail = kbhit(1);
		if (keyAvail)
			eingabe=getchar();
		usleep(500000);
		disablekbhit();

		//Richtungsbestimmung

		kopf->daten.richtung=richtungsbestimmung(eingabe);
		ClrScr();
		if(eingabe=='q')
			ende=1;
		}while(ende==0);

	return 0;
}

funktionen:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "head.h"

#include "kbhit4linux.h"

int richtungsbestimmung(snakeT *kopf, char richtung)
{
	if(richtung=='w')
		return 1;
	else if(richtung=='d')
		return 2;
	else if(richtung=='s')
		return 3;
	else if(richtung=='a')
		return 4;
	else
		return 0;
}

snakeT *newelem()
{
	snakeT *new=(snakeT *)malloc(sizeof(snakeT));
	if(new==NULL)
	{
		printf("Speicher für neues Element konnte nicht angefordert werden");
		exit(1);	
	}
	new->next=NULL;
	return new;
}

snakeT *bewegung(snakeT *kopf, char spielfeld[ZEILEN][SPALTEN])
{
	snakeT *laeufer=NULL;
	snakeT *vorgaenger=NULL;
	snakeT *aktuell=kopf;
	int laenge=kopf->daten.laenge;
	int i=kopf->daten.richtung;
	short x,y;

	if(i==1)	// Norden/oben
	{
		while(aktuell->next!=NULL || laenge==0)	//Schlange bis zum Ende durchlaufen lassen und vorgaenger bestimmen
		{
			laenge--;
			if(laenge==1)
				vorgaenger=aktuell;
			aktuell=aktuell->next;

		}
		laenge=kopf->daten.laenge;
		x=aktuell->daten.x;
		y=aktuell->daten.y;
		spielfeld[x][y]=' ';	//Letztes Element der Schlange aus dem Feld löschen
		vorgaenger->next=NULL;	//Letztes Element wird hinten ausgehängt
		aktuell->next=kopf;		//und vorne als neuer kopf angehängt
		aktuell->daten.x=(kopf->daten.x) - 1;	//x Koordinate um 1 veringern --> Bewegung nach rechts
		x=aktuell->daten.x;
		y=aktuell->daten.y;	
		laeufer=aktuell;
		while(laenge!=0)
		{
			y=laeufer->daten.y;
			spielfeld[x][y]='o';	//Elemente ins Feld schreiben
			laeufer=laeufer->next;
			laenge--;
		}

		if(x==0 || y==0 || y>=ZEILEN || x>=SPALTEN)	//Prüfung ob die Schlange aus dem Feld läuft
			return NULL;

		return aktuell;	//Neuen Kopf zurückgeben
	}
	else if(i==2)	// Osten/rechts
	{
		while(aktuell->next!=NULL || laenge==0)	//Schlange bis zum Ende durchlaufen lassen und vorgaenger bestimmen
		{
			laenge--;
			if(laenge==1)
				vorgaenger=aktuell;
			aktuell=aktuell->next;

		}
		laenge=kopf->daten.laenge;
		x=aktuell->daten.x;
		y=aktuell->daten.y;
		spielfeld[x][y]=' ';	//Letztes Element der Schlange aus dem Feld löschen
		vorgaenger->next=NULL;	//Letztes Element wird hinten ausgehängt
		aktuell->next=kopf;		//und vorne als neuer kopf angehängt
		aktuell->daten.y=(kopf->daten.y) + 1;	//y Koordinate um 1 erhöhen --> Bewegung nach rechts
		x=aktuell->daten.x;
		y=aktuell->daten.y;	
		laeufer=aktuell;
		while(laenge!=0)
		{
			y=laeufer->daten.y;
			spielfeld[x][y]='o';	//Elemente ins Feld schreiben
			laeufer=laeufer->next;
			laenge--;
		}

		if(x==0 || y==0 || y>=ZEILEN || x>=SPALTEN)	//Prüfung ob die Schlange aus dem Feld läuft
			return NULL;

		return aktuell;	//Neuen Kopf zurückgeben
	}
	else if(i==3)	// Süden/unten
	{
		while(aktuell->next!=NULL || laenge==0)	//Schlange bis zum Ende durchlaufen lassen und vorgaenger bestimmen
		{
			laenge--;
			if(laenge==1)
				vorgaenger=aktuell;
			aktuell=aktuell->next;

		}
		laenge=kopf->daten.laenge;
		x=aktuell->daten.x;
		y=aktuell->daten.y;
		spielfeld[x][y]=' ';	//Letztes Element der Schlange aus dem Feld löschen
		vorgaenger->next=NULL;	//Letztes Element wird hinten ausgehängt
		aktuell->next=kopf;		//und vorne als neuer kopf angehängt
		aktuell->daten.x=(kopf->daten.x) + 1;	//x Koordinate um 1 erhöhen --> Bewegung nach rechts
		x=aktuell->daten.x;
		y=aktuell->daten.y;	
		laeufer=aktuell;
		while(laenge!=0)
		{
			y=laeufer->daten.y;
			spielfeld[x][y]='o';	//Elemente ins Feld schreiben
			laeufer=laeufer->next;
			laenge--;
		}

		if(x==0 || y==0 || y>=ZEILEN || x>=SPALTEN)	//Prüfung ob die Schlange aus dem Feld läuft
			return NULL;

		return aktuell;	//Neuen Kopf zurückgeben
	}
	else if(i==4)	// Westen/links
	{
		while(aktuell->next!=NULL || laenge==0)	//Schlange bis zum Ende durchlaufen lassen und vorgaenger bestimmen
		{
			laenge--;
			if(laenge==1)
				vorgaenger=aktuell;
			aktuell=aktuell->next;

		}
		laenge=kopf->daten.laenge;
		x=aktuell->daten.x;
		y=aktuell->daten.y;
		spielfeld[x][y]=' ';	//Letztes Element der Schlange aus dem Feld löschen
		vorgaenger->next=NULL;	//Letztes Element wird hinten ausgehängt
		aktuell->next=kopf;		//und vorne als neuer kopf angehängt
		aktuell->daten.y=(kopf->daten.y) - 1;	//y Koordinate um 1 verringern --> Bewegung nach rechts
		x=aktuell->daten.x;
		y=aktuell->daten.y;	
		laeufer=aktuell;
		while(laenge!=0)
		{
			y=laeufer->daten.y;
			spielfeld[x][y]='o';	//Elemente ins Feld schreiben
			laeufer=laeufer->next;
			laenge--;
		}

		if(x==0 || y==0 || y>=ZEILEN || x>=SPALTEN)	//Prüfung ob die Schlange aus dem Feld läuft
			return NULL;

		return aktuell;	//Neuen Kopf zurückgeben
	}
	else
		printf("Error: Funktion bewegung: keine Richtungsangabe in Kopf vorhanden");

	return NULL;
}

[Shade Of Mine]

Wirf deinen Debugger an und gehe in einzelnen Schritten durch das Programm durch bis der Fehler auftritt und schau dir an warum er passiert.

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

[keyword-freak]

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.

[c-freak]

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.

[Gast]

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

[µC-freak]

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 ?

[mixing-freak]

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.

[ikea-freak]

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.

[multilanguage-freak]

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.