........... schrieb:
Für die Treiberprogrammierung musst du ein Genie sein! Also vergiss es lieber.
Naja, das ja nicht gerade aber man sollte sich schon dessen bewusst sein, dass das ein gänzlich anderes Programmierkonzept ist als man von "normalen" Applikationen gewohnt ist, zumal man immer um die Gunst des Kernels kämpfen muss.
http://www.c-plusplus.net/forum/viewtopic-var-t-is-41477.html ok... Hmm.. der Compiller hat was gegen das Verzeichnis... in nem anderne Verzeichnis nimmt der alle Files...
http://vertigo.hsrl.rutgers.edu/ug/make_help.html?the_id=80
Artchi schrieb:
Sehr witzig!
Extras->Optionen->Projekte->Verzeichnisse->Verzeichnisse anzeigen für->Quelldateien!!!
Selbe Combobox wie für die Header-Dateien!
Das hat auf das Bauen aber keine Auswirkung, sondern bezieht sich auf das Suchen von IntelliSense (Autovervollstädigung, etc.) und wenn ich nicht irre des Debuggers (um z.B. den Source von zusätzlichen Libs zu sehen, so diese Debug-Infos enthalten), ersetzt also keineswegs, entweder die CPPs in das Projekt zu packen oder eine Lib aus ihnen zu machen und die zu benutzen.
@f.-th.: Den "pathzugriff" des OS zu manipulieren hilft da im übrigen auch nicht weiter.
Also hilft nichts, wenn Du es in mehreren Projekten benötigst am besten eine Lib draus machen, sonst evtl. halt einfach mit ins Projekt packen.
Hallo ich hab ein kleines Problem.
Ich soll/muss/will ein Programm Compilieren/Linken das aber 1988 erstellt wurde, damals mit dem Microsoft C Compiler 5.1. Ich hab nun das Project schon mal durchgearbeitet (sind ca. 1000 Files in Ansi-C (soll zumindest so sein)). Die Errors hab ich alle soweit behoben. Nun lass ich den Linker durchlaufen und bekomm bei 300 Fkt immer den Fehler LNK2001 | LNK2019 also nichtaufgelöstes Symbol! So dass Programm (denk ich mir) ist ja für 16-Bit geschrieben könnte es schon daran liegen? Denn der jetzige MSVC++ Compiler ist ja 32-Bit ODER???
Weiter hab ich mir mal die Fkt, in denen der Fehler passiert angeschaut, und dabei festgestellt das andere "baugleiche" Fkt die auch vorhanden sind ja gelinkt werden!! Kann das auch sein das Microsoft seine libs im Laufe der Zeit so verändert hat das was fehlt was es führer gab??? Oder an was kann das vielleicht noch liegen??? Die Libs die selber in dem Projekt erstellt werden, mit LIB.EXE, werden ja alle auch schön fein erstellt!
Wo kann ich vielleicht ein komplettes MSC5.1 herbekommen oder etwas gleichwertiges??? (wenigstens die Lib's Header's etc von damals)
Übrigens es handelt sich um Spice von der Uni Berkley!
MfG
Superkauli
"Nichtaufgeloestes externes Symbol " heißt immer, das eine Lib nicht eingebunden ist, oder das die Lib eine bestimmte Funktion, Methode, Variable etc. nicht implementiert hat, die man benutzen will.
imhotep:Ich frag mich zum Beispiel, warum du cstdlib includes?
Das sollte da eigentlich gar nicht rein, aber auch ohne ist es noch so groß.
ChockoCookie: In den Compiler Einstellungen von Dev-Cpp gibt es schon eine Option "Strip Executable". In der deutschen Version ist das irgendwie mieß übersetzt mit "Ausführbare Dateien Entfernen" oder so. Falls dus nicht findest versuch mal ein "strip <dateiname>". Dazu muss das strip Programm (Teil von Dev-Cpp) im Suchpfad sein.
Das hat mir geholfen... Hab den Eintrag zwar nicht gefunden, aber habe mir ein werkzeug erstellt. Jetzt ist die Datei nur noch ca.260kB groß.
Vielen Dank für die Antworten
CU Postman
thx au wenn ichs net so ganz verstanden habe, weil es unter windoof soetwas net gibt zumindest bei solchen kleinen programmen net
gibts irgendwo ne beschreibung welche lib ich für welche headerdatei brauch und wie der compilierbefehl heisst?
system("pause") ist eben nicht der gute Weg, für den Anfang reichts zwar zur Not auch -> besser aber wie gesagt der Weg in der Konsolen-FAQ (Forenübersicht -> runter scrollen).
Mit return 0 in main() lässt du dein Programm nur korrekt beenden, das signalisiert dem aufrufendem Programm "Alles okay abgelaufen".
MfG SideWinder
Danke für deine Antwort!! Ich habe dann doch mal den Autor angemailt und der hat mir auch ne Nachricht geschickt:
The problem is because MinGW is weird about the __int64 datatype. To fix it, change __int64 into LONGLONG, and put the suffix LL at the end of the integer constants in that function.
So geht's natürlich auch.
rya.
Scorcher24
Hi, vielleicht hilft der folgende Link zu einem Artikel, der beschreibt, wie man das freie VC++ Toolkit 2003 (mit dem Compiler aus der Pro- Version) in eine VC++ .NET 2003 Standard Editon integriert. Ich habs aber noch nicht ausprobiert.
http://sapdb.2scale.net/moin.cgi/MS_20C_2b_2b_20Toolkit
Ich habe meinen Fehler mittlerweile gefunden.
Das Problem war wirklich dass ich über alloziierte Speichergrenzen hinausgeschrieben hab. Jedoch war das Programm so meiner Ansicht nach logisch korrekt.
Eine Schleife in der Speicher freigegeben und dann gleich darauf wieder neu alloziiert wurde, hat bei mir den Fehler verursacht.
Hat ja auch die ersten Male immer funktioniert, aber nicht immer
MfG
Vic
ich weiß nicht ob es so eine Option gibt.
Aber das ist C, das ist nicht immer C++ kompatibel. Muss der C++ Code denn unbedingt in die C-Dateien? IMHO sollte man dann entweder alles korrekt nach C++ konvertieren oder das ganze einfach getrennt halten.
--linuxuser-- schrieb:
(windows) saug dir bloodsheed dev-ccp hier ist der gcc dabei ist zwar in der konsole etwas nervig zu compilieren da man immer den ganzen pfad zum gcc angeben muss aber sonst funzs ganz jut! bekommt man richtig linuxfeeling
Schonmal was von Umgebungsvariablen unter Windows gehört?
Oder meinst du was anderes?
Caipi
Ja, sowas nennt sich Folding. Dev-C++ unterstützt das aber nicht, afair. Jedoch bietet fast jede professionelle IDE Folding, oder auch einige Freeware IDEs, wie zB CodeBlocks.