Fun-Soft - Programmierforum

Autor

Thread - Seiten: > 1 < [ 2 ]

000
05.10.2009, 13:57 Uhr
~Gast2010
Gast

Hallo!

Ich habe zwar keine Frage zu MFC, jedoch zu Code bzw.
Projektmanagement in Visual Studio (Visual C++).

Ich habe einen Solution-Ordner in dem sich mehrere
Projekte befinden. Die meisten sind Win32 Projekte
ohne MFC.

Diese Projekte enthalten in ihrem jeweils eigenen
Source Ordner ALLE einen Unterordner der eine
Sammlung von Klassen enthält (*.cpp/*.h files).

Dieser Haufen von Klassen ist in jedem Projekt gleich,
daher würde ich gerne die Redundanz loswerden.

Ich hab mir gedacht ich erstelle ein neues Projekt,
das nur diese redundanten Klassen compiliert.
Und alle anderen Projekte verwenden dann irgendwie
den compilierten Code (ist das dann eine *.lib,
die ich bei denen einbinden muss?).

Da in den Klassen auch WinAPI code verwendet wird,
lege ich am besten ein win32 Projekt an oder eine
win32 Console Projekt? Die WinMain bleibt dann
einfach leer?

Hoffe Ihr könnt mir weiterhelfen.

Und noch ne dumme Frage zum Schluss. Ich hab gesehen,
das der Compiler für meine Projekte auch immer eine
*.lib erstellt. Befinden sich in der lib ALLE compilierten
Klassen und Methoden die es überhaupt gibt oder nur
Code der in dem Projekt auch von der Applikation
verwendet wird (sprich eine Methode die nie aufgerufen
wird, kommt auch nicht in die lib? (was ein Problem wäre,
wenn ich die lib von einem anderen Programm aus einbinden
will welches die Methode vielleicht braucht)).

Danke!!

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

001
05.10.2009, 14:03 Uhr
~Gast20010
Gast

Achso oder muss ich statt nem win32 Projekt
irgendwie ein static library Projekt anlegen?

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

002
05.10.2009, 15:58 Uhr
0xdeadbeef
Gott
(Operator)

Ich würde ein leeres Projekt anlegen und die Einstellungen in den Projekteigenschaften von Hand vornehmen, sonst erstellt der dir allen möglichen Unfug, den du bei bestehendem Code nicht brauchst.

Wenn du gemeinsamen Code hast, den mehrere Projekte verwenden, gibt es mehrere Möglichkeiten, das umzusetzen. Naja, im Grunde zwei - eine dynamische Bibliothek und eine statische.

Eine statische Bibliothek ist eine große .lib-Datei, die alle Funktionen beinhaltet, eine dynamische besteht aus einer .lib und einer .dll, wobei die .lib-Datei Funktionen enthält, die im Grunde die wirklichen Funktionen aus der .dll nachladen und ausführen. In beiden Fällen linkst du nachher gegen die .lib-Datei, im Falle der dynamischen Bibliothek muss die .dll zur Laufzeit neben dem Programm (oder im %PATH%) liegen. Die .lib-Dateien werden nur zur Linkzeit gebraucht.

Welche die bessere Option ist, hängt meiner Ansicht nach stark von der Größe des Unterprojekts ab. Wenn das ein großer Haufen ist, pack's in eine DLL, wenn's um ein, zwei Hilfsklassen geht, link's statisch rein.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

003
05.10.2009, 17:40 Uhr
~Gast20010
Gast

Ok ich habe eine static library erstellt, compiliert auch wunderbar.

Jedoch habe ich 28 warnings:

Z.B.:

Zitat:

version.lib(VERSION.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in fmodvc.lib(fmod.dll); second definition ignored
1>version.lib(VERSION.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible

Das erste leuchtet mir ein: version.lib und fmodvc.lib definieren beide das gleiche Symbol.
Aber wie gehe ich geschickt mit diesem warning um? Einfach ignorieren? Ich habe gerne
0 warnings, möchte allerdings nicht einfach pauschal alle warnings ausblenden.

Mit dem zweiten kann ich insofern nichts anfangen, weil das warning auch für *.obj
Dateien aus meiner eigenen lib geschmissen wird. In der lib soll doch aber am Ende jede
Klasse und jede Methode vorcompiliert sein, damit ein externes Programm die lib
verwenden kann. Die Compiler Meldung klingt für mich aber so, als ob er manchen
Code NICHT in die lib packt weil er denkt die werden nicht verwendet? (no public
symbols found).

D.h. die lib ist dann unvollständig? Bin grad verwirrt =/

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

004
05.10.2009, 18:03 Uhr
~Gast2010
Gast

Nachtrag zum zweiten warning:

Bei den *.obj aus meiner eigenen lib handelt es sich um reine template Klassen,
ich hoffe die gelangen dann trotzdem in die lib.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

005
05.10.2009, 18:41 Uhr
0xdeadbeef
Gott
(Operator)

Naja, schöner wär's, wenn nur eine DLL das Symbol exportierte und die andere sich das Symbol von der ersten holte. Oder beide DLLs sich das Symbol aus einer dritten besorgen. Wie man das am besten löst, kann ich allerdings ohne genauere Kenntnis des Projektes nicht sagen.

Was die "template Klassen" angeht, das sind keine Template-Klassen, sondern Klassentemplates bzw. Klassenvorlagen. Sie werden erst vom Compiler zu Klassen konkretisiert, wenn sie gebraucht werden, was bedeutet, dass sie dem Compiler zur Compilezeit vollständig bekannt sein müssen. Du kannst zwar explizit einzelne Konkretisierungen vornehmen, die dann auch gelinkt werden können, aber mit der Vorlage selbst geht das nicht.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

006
05.10.2009, 20:10 Uhr
~Gast2010
Gast

Ok also die Klassentemplates holt sich der Compiler dann beim Bauen
nicht aus der lib sondern aus den includes (headern) der lib, richtig?

Noch ne Frage, ich hab gerade gesehen, dass ich mit dem Debugger
sogar den Source Code meiner lib durchsteppen kann. Dafür öffnet
mir Visual Studio einfach die Source file aus meinem lib Projekt.

Ich frage mich grade woher Visual Studio weiß wo diese Source
File liegt? Eigentlich ist ja in der lib nur die debugging info
(habe die lib mit C7 compatible debug gebaut).

Natürlich liegen die Projekte in der gleichen Solution, aber es
interessiert mich doch mal wie genau der Debugger diese
Source Datei findet?

Danke!

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

007
05.10.2009, 21:06 Uhr
0xdeadbeef
Gott
(Operator)

Das steht bei den Debugsymbolen dabei. Macht ja auch Sinn - üblicherweise wird der Kram da gedebuggt, wo er auch kompiliert wird.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

008
05.10.2009, 23:03 Uhr
~Gast2010
Gast

Ich hab ehrlich gesagt dein Eindruck, dass der Visual Studio Debugger sich
einfach eine passende Source Datei aus allen Projekten in der Solution sucht.

Ich habe probeweise mal die Source Datei umbenannt, nachdem ich eine Kopie davon in
ein anderes Projekt der Solution kopiert habe. Die lib habe ich aber nicht neu gebaut.

Der Debugger öffnet nun die Source Datei an dieser neuen Stelle. D.h. er durchsucht
offenbar alle geöffneten Projekte in der Solution nach einer passenden Quelldatei.

D.h. wie du schon sagst schaut er in den Debug Symbolen nach, wie eine passende
Quelldatei aussehen muss, diese Quelldatei muss aber nicht unbedingt an dem Ort
liegen, wo sie kompiliert wurde.

Wenn ich das richtig verstehe wird in der lib ein kleiner Eintrag angelegt welche
*.pdb Datei zum Debuggen verwendet werden sollte. Beim debuggen der lib
schaut der Debugger also in die entsprechende *.pdb Datei (wie er die findet
weiß ich nicht, vermutlich sucht er in der ganzen Solution, denn in der lib
steht ja bestimmt kein absoluter noch relativer Pfad zu der *.pdb Datei?).
Durch die *.pdb Datei weiß er, wie die Quelldatei "aussehen" muss (Signatur usw),
diese Quelldatei sucht er dann innerhalb der Solution?

Oder liege ich komplett daneben?

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

009
06.10.2009, 19:40 Uhr
0xdeadbeef
Gott
(Operator)

Hm. Ich hatte gedacht, dass der Pfad fest verdrahtet wird. Wenn das nicht der Fall ist, weiß ich es auch nicht, aber ich bin sicher, dass das in der MSDN irgendwo dokumentiert ist.

Was die .pdb-Datei angeht: http://en.wikipedia.org/wiki/Program_database
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

Seiten: > 1 < [ 2 ] [ C / C++ (WinAPI, Konsole) ]

ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: