Dumme Frage: Lib die von zwei weiteren. libs abhängt, includes richtig setzen
-
Belli schrieb:
Dabei muss es ja nicht mal um eine Klasse gehen, für einfache Funktionsimplementierungen in eigenen *.cpp s würden doch die gleichen Regeln gelten, also müsste man ständig über so was stolpern?
Eine Bibliothek ist nichts anderes als der Objektcode den du aus den cpp erstellst in eine einzige Datei gestopft. Ich spekuliere mal, daher kommt auch der Name.
Das verstehe ich nicht ...
Ich meine: Wenn du fremde Bibliotheken mit in deine stopfst, dann musst du auf einmal deren Support mitleisten.
-
SeppJ schrieb:
Belli schrieb:
Das verstehe ich nicht ...
Ich meine: Wenn du fremde Bibliotheken mit in deine stopfst, dann musst du auf einmal deren Support mitleisten.
Ahh ... jetzt ja ...
Wenn ich aber ein paar Klassen schreibe, die ich in meiner lib benutze, dann ist es sinnvoll, diese gleich zu integrieren.
Wenn ich fremde Klassen/Libs benutze, dann kann sich der Benutzer meiner lib diese bei Bedarf selbst zusammensuchen.
Hab ichs nun?
-
Belli schrieb:
Wenn ich fremde Klassen/Libs benutze, dann kann sich der Benutzer meiner lib diese bei Bedarf selbst zusammensuchen.
Dann lieferst du die Lib, die du benutzt mit deiner Lib mit (in der Version, gegen die du implementiert hast). Der Benutzer kann dann nach eigenem Gutdünken und auf eigene Gefahr neuere Versionen dieser 3rd-party Lib an Stelle der von dir mitgelieferten einsetzen.
-
pumuckl schrieb:
Belli schrieb:
Wenn ich fremde Klassen/Libs benutze, dann kann sich der Benutzer meiner lib diese bei Bedarf selbst zusammensuchen.
Dann lieferst du die Lib, die du benutzt mit deiner Lib mit (in der Version, gegen die du implementiert hast). Der Benutzer kann dann nach eigenem Gutdünken und auf eigene Gefahr neuere Versionen dieser 3rd-party Lib an Stelle der von dir mitgelieferten einsetzen.
Dafür gibts verschiedenste Gründe. Stell dir vor, ich benutze in meiner Lib (pumu.lib) boost.Serialization. Die Lib ist gegen eine relativ alte Version, sagen wir v1.32, implementiert worden und funktioniert wunderbar damit zusammen.
Du willst pumu.lib in deinem Projekt benutzen, außerdem willst du für einige deiner Klassen auch Boost.Serialization benutzen, und zwar einige Features, die erst in version 1.45 dazugekommen sind. Wenn ich jetzt Boost.Serialization in pumu.lib mit reingelinkt habe, hast du keine Chance, weil die Definitionen aus Boost.Serialization v1.32 in pumu.lib UND in boost_serialization_1_45.lib vorhanden sind. Der Linker spuckt Zähne und du kannst dir aussuchen, auf welche von beiden Libs du verzichten willst.Wenn ich die Boost-Lib nicht mit reinlinke, kannst du pumu.lib, boost_serialization_1_45.lib und den von mir mit der Lib mitgelieferten Testcode zusammenlinken und schauen, ob pumu.lib auch mit der neuen Serialization version funktioniert - wegen backward-compatibility der Boost-Bobliotheken sollte das in den meisten Fällen möglich sein.
-
Ja, ich habs ja, obwohl die doppelten Definitionen sind wohl kein Problem, zumindest nicht, soweit sie identisch sind, das hab ich nochmal ausprobiert, indem ich mylib.lib nach b.lib kopiert habe, und test.obj mit mylib.lib und b.lib gelinkt habe.
Aber vom Prinzip her habe ichs nun kapiert - ich hatte halt irgendwie verdrängt, dass eine statische lib nichts anderes ist, als eine Sammlung von obj s ...
-
Vielen Dank Euch allen!
Ich denke das ist jetzt geklärt
