Codixx schrieb:
Hallo Leute,
bin dabei n File Binder zu coden.
Ich habe folgendes Problem:
Ich möchte gerade die Stub komplett einlesen und dann in die neue exe schreiben.
Das hab ich bis jetzt so realisiert:
[Codeausschnitt:]
ifstream in1(cstub,ios::in | ios::binary);
while(!in1.eof())
{
getline(in1,strinput);
}
Nun möchte ich ja die Stub (also Zeile für Zeile) in die exe fügen.
Habs so probiert:
ifstream in1(cstub,ios::in | ios::binary);
while(!in1.eof())
{
getline(in1,strinput);
if(!in1.eof()) {out<<strinput<<endl;} else {out<<strinput;} //"out" ist die exe
}
Das ganze klappt nicht.
Könnt ihr mir helfen?
Bitte..
Danke^^
Codixx
Edit:: hat geklappt..
loooool voll viel text
Danke. Damit werde ich es hinkriegen. Erinnert mich an alte MS-DOS Zeiten, wenn man direkt den Grafikkartenspeicher ansprechen wollte. Warum MS jedoch eine Testkonsole so designt, erschließt sich mir noch nicht ganz.
habs hinbekommen
stehe jetzt vor der nächsten hürde
es ist ein leerzeichen und der rest sind tabulatoren wie kann ich diese in ein anderes zeichen umwandeln?
mfg
Win32-Konsole n00b schrieb:
aaah jetzt ja!
man muss die zeilen:
#undef UNICODE
#undef _UNICODE
#define MBCS
über
#include <windows.h> packen, ich trollo!
danke, gruß und tschüs,
w.k.n
Absoluter Unfug. Stell Dein Projekt korrekt auf MBCS ein und nicht auf Unicode und dan nwird das auch richtig gemacht. Gehe in die Projekteinstellungen und auf der ersten Seite (VS-200x) findest Du diese Einstellung.
Mein Rat: Arbeite mit TCHAR. Dann hast Du solche Probleme nicht.
Also wenn du einen String (char-Array) nachträglich verändern willst, dann kannst du entweder direkt ein recht großes Array deklarieren, von dem du dir sicher bist (oder es im Programmablauf sicherstellst), dass die Feldgrenze immer ausreicht.
char myString[1024]; //char-Array der Länge 1024
strcpy(myString,"Hallo"); //String füllen
Oder du änderst dynamisch die Größe des Arrays, bevor du es mit neuem Inhalt füllst.
char *myString; //char-Pointer
myString=(char*)malloc(6*sizeof(char)); //6 Bytes Speicher allozieren (in C den Cast weglassen)
strcpy(myString,"Hallo"); //Zeichenkette von 6 Bytes (mit abschließender 0) reinkopieren
//erneut die Größe ändern kannst du dann mit realloc
Danke für die Antworten.
Also generell reicht für UTF-8 ja char locker aus von der Breite. Geht ja auch nicht um die Speicherung, damit hab ich mich schon oft befasst hehe. wchar_t wäre ja dann eher für UCS2 oder ähnliches, aber das funktioniert ja unter Windows eh, aber ich will das konvertieren umgehen.
Das Problem ist folgendes: Für meine moFileReaderSDK (http://mofilereader.googlecode.com/) will ich eine Locale-Klasse entwerfen, die sich genauso wie gettext verhält, sprich lädt die richtige .mo-Datei je nach lokale lädt über ein gebundenes Verzeichnis. Dabei bin ich auf das Problem gestoßen. Aber lt http://mail.python.org/pipermail/python-list/2003-April/200079.html ist das anscheinend ein klein wenig größeres Problem Windows auf UTF-8 zu bekommen, hehe. Man kann die CP 65001 zwar setzen, aber die Zeichen sind weiterhin Hieroglyphen.
Im prinzip net schlimm, weil ich verwende für Anwendungen eh wxWidgets und meine SDK zielt nicht darauf ab, eine komplette i18n-lib zu sein (: sondern nur ein Loader für .mo-Files und das funktioniert.
rya.
Ohne mir das Programm näher angesehen zu haben, ist mir doch direkt was ins Auge gesprungen: du musst an deiner Einrückung arbeiten! Manchmal rückst du einen Block (Inhalt zwischen 2 geschweiften Klammern) gar nicht ein, mal nimmst du 1 Zeichen und mal 2. Das ist inkonsequent. Du solltest dir von Anfang an eine Methode angewöhnen (ich empfehle 2-4 Zeichen, je nach Belieben). Auch sind hin und wieder Zeilen derselben "logischen Ebene" nicht untereinander (z.B. die system-Aufufe und die Folgezeilen).
Übrigens: deine vielen else-if-Verzweigungen könntest du prima durch eine switch-Anweisung ersetzen. Falls du nicht weißt, was das ist, google einfach mal danach.
