Klotzkopp

Es stehen auch nicht mehr drin. Aber die String- und Ausgabefunktionen wissen nichts von Arrays. Die Größeninformation geht sowieso verloren, wenn man Arrays an Funktionen übergibt. Für strcmp oder den operator<< ist das nur ein Zeiger auf das erste Element deines Arrays. Um zu ermitteln, wie lang der String ist, müssen diese Funktionen die Nullterminierung suchen. Nach drei Zeichen ist zwar dein Array zuende, aber da ist immer noch keine Nullterminierung. Darum wird in dem dahinterliegenden Speicher weitergesucht, solange, bis entweder durch Zufall ein Nullbyte im Speicher steht, oder das ganze mit einer Zugriffsverletzung abstürzt. Ja, setz eine Nullterminierung. Wie gesagt, strncpy macht das nicht automatisch für dich.

Du solltest dich entscheiden, ob du die C-Dateifunktionen (printf) oder die C++-Streams (cout) benutzt. Mischen ist nicht so gut. Außerdem benutzt du veraltete C++-Headerdateien. #include <iostream> // cin, cout #include <fstream> // ifstream, ofstream #include <cstdlib> // exit, rand #include <iomanip> // setw #include <conio.h> // getch #include <sys/types.h> // off_t #include <sys/stat.h> // stat #include <ctime> // ctime, time //#include <cstdio> // NICHT MISCHEN #include <cstring> //strcmp [/code] So müsste das aussehen, wenn du nicht gerade einen sehr alten Compiler benutzt. Jetzt aber zum eigentlichen Problem: Du hast nur drei Zeichen für die Dateierweiterung. Da passt kein Nullzeichen mehr rein, wenn die Erweiterung selbst schon drei Zeichen hat. Ohne Nullterminierung werden die Daten, die im Speicher hinter deinem Array stehen, als Bestandteil des Strings interpretiert. Das kommt daher, dass strncpy keine Nullterminierung anhängt, wenn der Quellstring mehr Zeichen hat, als maximal kopiert werden sollen. Darum musst du dich also selbst kümmern, wenn du strncpy benutzt. Du solltest auch bedenken, dass Dateierweiterungen auch mehr als drei Zeichen haben können, ".jpeg" und ".html" zum Beispiel. Dein Programm wird außerdem wohl abstürzen, wenn du eine Datei ohne Erweiterung darauf ablegst. Was passiert, wenn du eine Datei benutzt, die selbst keine Erweiterung hat, die aber in ihrem Verzeichnispfad einen Punkt hat, will ich mir grad nicht ausmalen Ich frage mich allerdings, warum du dich überhaupt so mit char-Array abplagst. Warum nicht std::string?

Einfach mit "COM1" als Dateinamen. Näheres in der MSDN Library, CreateFile, unter "Communications Resources".

Weil es kein gültiges C++ mehr ist, wenn du einfach eckige Klammern um einen Bezeichner machst. In Delphi mag das funktionieren oder sogar notwendig sein, aber in C++ ist das ein Syntaxfehler.

Es ist immer eine ganz schlechte Idee, Projekte nachträglich umzubenennen. Meist ist ein einfacher, ein neues Projekt zu erstellen. Die Sourcedateien kann man ja einfach wieder hinzufügen. In deinem Fall sieht es so aus, als ob einfach nur eine Bibliothek nicht dazugelinkt wird (X-Plane?).

Was genau verstehst du denn daran nicht? -1 hoch Vorzeichen, also -1 bei Vorzeichen 1, 1 bei Vorzeichen 0. Das wird multipliziert mit 1 + Mantisse / 2 hoch 23 und mit 2 hoch (Exponent - 127).

Das Problem dürfte sein, dass links neben einer öffnenden eckigen Klammer immer ein Bezeichner stehen muss. Für sich allein genommen, ist [loPartialKey] ein Syntaxfehler. Welchen Typ braucht Locate denn als dritten Parameter?

Dazu kommt noch, dass Standard-C++ (noch) keine Threads kennt. Du müsstest also auch verraten, mit welcher Entwicklungsumgebung / Bibliothek du arbeitest.

Das ist eine Frage des Compilers, nicht des Betriebssystems Außerdem ist das hier das Standardforum. Compilerspezifische Erweiterungen gibt's nebenan

Es gibt nicht den operator+. Es gibt viele Überladungen davon. Du kannst für eigene Typen neue Operatorüberladungen anlegen. Aber du kannst nicht die bereits vorhandenen überschreiben. Du kannst Operatoren keine neue Identität zuweisen, insofern ist "du bist ab jetzt *" schlecht ausgedrückt. Du kannst für eigene Datentypen eine Überladung von operator+ erzeugen, die multipliziert - auch wenn sich mir der Sinn nicht erschließt. Operatoren überlädt man dann für eigene Datentypen, wenn das die Verwendung erleichtert. Wenn du z.B. eine Klasse für Brüche hast, würde es sich anbieten, für diese Klasse die arithmetischen Operatoren zu überladen, damit du sie intuitiver verwenden kannst. Ausnahme ist hier der operator=, den du immer dann überladen solltest, wenn eine Klasse mit dynamischem Speicher hantiert.

Ist das, was unter "ausgangspunkt" steht, der Code, der dir vorgegeben wurde? Da ist gar kein benutzerdefinierter Operator drin, den du umwandeln könntest. Wenn du willst, dass bei a+b multipliziert wird: Dazu müsstest du den operator* für int überladen, und das geht nicht - du kannst Operatoren für eingebaute Typen nicht überladen. Ganz allgemein kann man aber sagen, dass Funktionsdefinitionen kein Semikolon am Ende benötigen, und dass fflush(stdin) undefiniertes Verhalten erzeugt.

Eigentlich sollte operator+ seinen linken Operanden nicht ändern

Das sieht aus, als ob gar kein Arbeitsbereich geladen wurde. Kannst du die .dsp-Datei öffnen?

Sind Klassen- und Dateiansicht vielleicht einfach nur ausgeblendet? Drück mal Alt+0 (Null).

Dann fang doch mal an der Stelle an, an der du text füllst. Und zeig bitte auch, wie du diese Funktion aufrufst.

Das Vorhaben, aus einem compilierten Programm wieder C oder C++-Quellcode zu machen, wird oft mit dem Vorhaben verglichen, aus einem Hamburger wieder eine Kuh zu machen. Beim Compilieren geht nun mal ein großer Teil der Informationen im Quellcode verloren. Es ist nur mit sehr guter Kenntnis des Compilers möglich, überhaupt etwas daraus zu machen, das auch nur halbwegs an von Menschen geschriebenen Code erinnert. Variablen- und Funktionsnamen sind auf jeden Fall weg.

MessageBox in der Kopierschleife? Dann liegt der Fehler in dem Teil des Codes, den du weggelassen hast. Möglichweise hantierst du mit mehr als einer Instanz einer Dialogklasse. Vielleicht modifizierst du eines der Arrays auch noch an anderer Stelle. Ohne mehr von dem Code zu sehen, kann man das nicht sagen.

Das ist erst mal nur eine Klasse, da kann nichts ausgeführt werden. Und werden sie das auch? Bau doch mal eine MessageBox in deine Kopierschleife ein, um zu prüfen, ob in text überhaupt etwas drin steht.

Wie und wo füllst du denn das Array text?

In beiden Fällen?

Rückübersetzung (in dem beschränkten Maße, wie es bei C und C++ möglich ist), würde nicht zur Laufzeit stattfinden, dagegen kann sich dein Programm also gar nicht schützen. Je nach Betriebssystem gibt es z.B. Möglichkeiten, zu erkennen, ob an deinem Programm ein Debugger hängt. Einen sicheren Schutz gibt es aber nicht.

Die Speicherfunktionen von C darfst du für Klassen nicht benutzen, weil sie keine Konstruktoren oder Destruktoren aufrufen können. Die können nur den Speicherinhalt kopieren, was bei Klassen, die dynamisch Speicher anfordern, zwangsläufig zu Problemen führt. Wenn du aber sowieso C++ benutzt, brauchst du gar kein realloc, denn dafür gibt es in C++ die Container der Standardbibliothek: vector<string> v; while(getline(file, line)) { v.push_back(line); }[/code]

Dann compilierst du das vermutlich als C++, denn da gibt es diese implizite Konvertierung von void* nicht.

Da fehlt IMHO ein Kommentar: // BLUTIGER HACK Nach dem Standard ist das undefiniertes Verhalten.

Richtig. Deshalb aber vorher zu zählen, ist ineffizient und unnötig. Der Begriff "nächster" Speicherblock ist ungünstig gewählt. Unterhalb von malloc liegt das Speichermanagement des Betriebssystems. Das kann mit deinem Speicher machen was es will. Es muss nicht sein, dass zwei Elemente eines Arrays in C im physischen Speicher nebeneinander liegen. Es kann sein, dass sie überhaupt nicht im RAM liegen. Du sorgst dich da um Dinge, auf die du sowieso keinen Einfluss hast, zumindest wenn du ein heute aktuelles Betriebssystem benutzt, um deine Programme auszuführen. Nein, dafür gibt es realloc. Damit kann man ein Array einfach zur Laufzeit vergrößern. Und da es sich nur um ein Array von Zeigern handelt, ist das nicht einmal besonders aufwändig.