Die Funktion liest eine Seriennummer eines usbs aus einer ganz normalen text datei ein.

Doch fragt mich nicht wieso das nicht mehr geht.
Die funktion wird übersprunge. Ich bin im einzelschritt durchgegangen und habs im Codemarkiert von wo bis wo er springt.

void pcReadSerial(const char* fileName,char* key)
{ --> von genau dieser Zeile aus springt er runter bis zur markierten Stelle.
	ifstream stream;

	stream.open(fileName);
	string strSerial = string();

	if(stream == NULL)
	{
		key = NULL;
		return;
	}

	while(!stream.eof())
		strSerial.push_back(stream.get());

	stream.close();
	*key = *strSerial.c_str();
} --> Hier her springt das Programm

Und hier der Aufruf:

#define FileName "serialNumber.txt"
....
			char *key;
		#if _DEBUG
			cout << "DEBUG-BUILD" << endl;
			key = TestSerial;
		#else if _RELEASE
			cout << "RELEASE-BUILD" << endl;
			pcReadSerial(FileName, key);
		#endif

so habe ich getestet:

char* testptr;
	pcReadSerial(FileName, testptr);
	cout << testptr << endl;

Schau doch mal ob die funktion in einer ganz normalen main schleife geht

Neulich gab's schon switch-Schleifen. Es scheint, die if-Schleife bekommt Konkurrenz.

Wilde Vermutung: Du machst was falsch ;). Vermutlich bei der Bedienung deines Debuggers.

Außerdem machst du beim Einlesen so ziemlich alles maximal umständlich und/oder falsch. Da bei Programmen die auch in anderen Teilen so schlimm sind wie deine eine Funktion aussieht erfahrungsgemäß auch immer eine Menge undefiniertes Verhalten drin ist, ist dies auch eine durchaus nicht unwahrscheinliche Fehlerursache. Oder du interpretierst den Effekt deiner sonstigen Fehler falsch und das mit dem Funktion-Überspringen ist nur das was du dir zusammen gereimt hast (diese Möglichkeit halte ich für am wahrscheinlichsten). Oder der Compiler optimiert den ganzen Unsinn weg, weil er sowieso nichts macht (Falls du dich beispielsweise wunderst, warum key sich nicht wirklich ändert: Das liegt an deinen sonstigen Fehlern)

Neulich gab's schon switch-Schleifen. Es scheint, die if-Schleife bekommt Konkurrenz.

Alles gut bei dir x'D

Habe jetzt aber gerade gesehen. Die funktion wird nicht mehr komplett übersprungen sondern springt in das if(stream == NULL) rein.

An was liegt das?
Wieso kann ich die Datei nicht öffnen.

sorry für doppelpost.

Habe jetzt aber gerade gesehen. Die funktion wird nicht mehr komplett übersprungen sondern springt in das if(stream == NULL) rein.

An was liegt das?
Wieso kann ich die Datei nicht öffnen.

Dann wird sie wohl nicht da sein, wo sie gesucht wird. Und wo du denkst, dass sie gesucht wird, ist nicht da wo sie gesucht wird. Und das Vergleichen von Streams mit Null ist äußerst ungewöhnlich. Ich musste eine ganze Weile nachdenken, ob das überhaupt geht und wenn ja, was es macht. Wo auch immer du dies und den Rest her hast: Das muss das schlechteste Lehrmaterial aller Zeiten sein. Schlimmer als C++ von A bis Z und das will was heißen.

Das ist keine Kritik an dir, du kannst ja nichts dafür, dass du das beigebracht bekommen hast, aber dein Code gehört einfach zum mit Abstand schlechtestem was ich je gesehen habe. Vielleicht sogar das Schlechteste. Und ich bin seit Jahren hier aktiv.

Oder kann es sein, dass er einen anderen Startup-path verwendet?

Dann wird sie wohl nicht da sein, wo sie gesucht wird. Und wo du denkst, dass sie gesucht wird, ist nicht da wo sie gesucht wird.

Das errinert mich irgendwie an die sinnfreie szene aus Fluch der Karibik , wo jonny erklärt was es mit dem aufgemalten schlüssel von Jones auf sich hat ...

definitiv nicht. ich habe sogar noch ne neue Datei gemacht namens hallo.txt.
Diese liegt neben der exe im verzeichniss und hat den inhalt hallo welt.

Wo deine exe liegt hat nicht viel mit dem Ausführungspfad zu tun. Entscheidend ist, von wo du sie aufrufst (und wie du sie aufrufst).

#define FileName "serialNumber.txt"

dann hilft eine Datei Hallo.txt auch nicht weiter.
Ggf. solltest Du den vollständigen Pfad angeben...
Gruß

#else if _RELEASE
			cout << "RELEASE-BUILD" << endl;
			pcReadSerial(FileName, key);
		#endif

Da steht, dass die Funktion im Releasebuild aufgerufen wird. Welche Optimierungsstufen hast du im Releasebuild aktiviert? Hast du auch für die Source, in der die Funktion definiert ist, Debuginformationen eingestellt?

- Wenn die Debuginformationen fehlen, springt der Debugger meist einfach drüber.
- Wenn du einen optimierten Build hast, kann der Compiler alles mögliche mit deinem Code anstellen, z.B. wegoptimieren, umstellen etc. Der ausgeführte Code entspricht dann nicht mehr wirklich den Codezeilen, die du geschrieben hast. Deshalb hüpft der Debugger scheinbar unmotiviert herum, bis er wieder ein Debugsymbol erkennt. Zum Beispiel Eintritt und Austritt in die Funktion.

2. Aber wieso hat es dann bis jetzt immer funktioniert? Und ist nicht immer der erste Parameter von argv --> argv[0] der Pfad zum Programm und beinhaltet damit auch das Ausführungsverzeichniss. Weil das würde stimmen.
Außerdem ich werde das einmal überprüfen, doch ich sehe den Sinn darin nicht wieso man soetwas optimieren sollte. Das führt doch nur zu Fehler wenn der Pfad nicht mehr gefunden wird. Und wenn ich dich richtig verstanden habe sollte man also nicht einfach eine Datei in das selbe Verzeichniss legen und dann mit dem Dateinamen aufrufen. Sondern muss den Vollständigen Pfad angeben?

3. Gibt es vll. eine Funktion mit der man den Ausführungspfad bekommt?

http://s1.directupload.net/images/110914/rklikkzm.png

Und 2. Wie soll man bitte das ganze verstehen (als Anfänger).

Und ist nicht immer der erste Parameter von argv --> argv[0] der Pfad zum Programm und beinhaltet damit auch das Ausführungsverzeichniss.

Nein und nein. argv[0] beinhaltet den Aufruf des Programms, d.h. wenn du in der Konsole nur "myprog.exe" eingibst, steht dort auch nur das. Wenn du "D:\progs\myprog.exe" eingibt, dann steht dort auch der Pfad, wo das Programm liegt. Das Ausfürhungsverzeichnis ist aber ein ganz anderes, das muss nichts damit zu tun haben!

verwirrt schrieb:

Außerdem ich werde das einmal überprüfen, doch ich sehe den Sinn darin nicht wieso man soetwas optimieren sollte. Das führt doch nur zu Fehler wenn der Pfad nicht mehr gefunden wird.

Falls sich das auf meinen Beitrag bezieht, es geht bei mir um die Optimierung des Programmcodes, nicht um irgendwelche Pfadangaben.

Das Anfügen heißt, dass du zuerst den Prozess startest und dann deinen Debugger an den laufenden Prozess hängst. Das brauchst du nicht. Du kannst einfach aus der IDE heraus mit F5 das Programm starten. Eventuell in den Optionen deines Projektes noch ein Ausführungsverzeichnis angeben.

Und das komische ist, dass es so wie der Fehler kam die Datei findet.

Ich kapiere jetzt zwar gar nichts mehr und denke mir das kann doch nicht sein. Doch immerhin findet er die Datei wieder und kann diese in den String einlesen.

Doch dann scheitert es anscheinend beim speichern in den char zeiger.

hatte es ja erst so:

*key = *strSerial.c_str();

Doch das geht aufeinmal nicht mehr obwohl der string den gewünschten Wert beinhaltet.

Habe es jetzt mal testweise so probiert:

key = const_cast<char*>(strSerial.c_str());

Doch auch das klappt nicht... und in was für einem Buch steht bitte wie man solche Fehler beheben soll. Anstatt, dass ich dazu lern steht bei mir nur immer noch nen größeres ? über meinem Kopf. Bin mittlerweilse dermaßen verwirrt...

Denn früher ging alles einwandfrei. Hab sogar extra noch die Sicherungen angeschaut. Und kann mir das ganze nicht erklären. Ich habe nämlich an der Funktion keine einzige Zeile geändert sondern in einer ganz anderen Klasse die rein gar nix mit dieser Funktion zu tun hat gearbeitet. Bis ich irgendwann feststellte, dass es einen Fehler gab. Machte mich also auf die Suche und fand ihn hier... Und jetzt kapier ich mal gar nix mehr.

Und jetzt kapier ich mal gar nix mehr.

Ganz ehrlich, und wie schon oben gesagt, die Funktion ist totaler Müll. Kannste direkt wegschmeißen. Ist praktisch alles falsch, was man falsch oder schlecht machen kann. Ich kann nicht glauben, dass sie jemals so oder ähnlich jemals funktioniert hat.

und in was für einem Buch steht bitte wie man solche Fehler beheben soll

Diese Fehler kannst du nicht beheben, das sitzt zu tief. Aber du kannst es neu und richtig machen. Und dann ist das mit einem Schlag viel robuster, sicherer, kürzer, einfacher. Kurz: Besser. Wie das geht, sollte in jedem guten Buch stehen. Und wenn dich ein Buch auf die bisherige Funktion gebracht hat, dann war es kein gutes Buch. Dein hilfloses Gewurschtel mit dem key deutet da drauf hin, dass dies der Fall ist.

Leider habe ich im Moment keine Zeit, es dir richtig zu machen. Vielleicht wäre es didaktisch auch ganz gut, dich einfach lernen zu lassen und dir nicht einfach die Lösung hinterher zu werfen.