Boost mit einer Library verwenden - wie vorgehen?

[DStefan]

Hallo Forum,

ich plane, meine Klassenbibliothek für Windows einer Generalüberholung zu unterziehen. Das Ding ist fast zehn Jahre alt und verwendet zur Zeit nur die Standard C++-Libraries. Das möchte ich ändern und zumindest einige Elemente von Boost hinzu nehmen.

Dabei plagt mich die Frage, wie das zu bewältigen ist. Eine Library soll ja per Definition von anderen verwendet werden, und ich finde, man sollte den Einsatz so leicht wie möglich machen. Wenn ich nur auf Standard-Libraries aufbaue, ist das kein Problem, deren Vorhandensein kann ich ja voraussetzen. Bei Boost allerdings ist das eine andere Sache. Ich finde drei Standpunkte plausibel (oder wenigstens diskutierbar ):

1. Setze das Vorhandensein von Boost voraus. Wer's nicht hat, muss es halt installieren, um meine Libarary verwenden zu können.

2. Stelle eine eigene Kollektion der verwendeten Boost-Libraries zusammen, die als eigene DLL mit meiner Library gebaut und ausgeliefert wird. (Copyright-mäßig müsste das ja möglich sein?).

3. Zum Teufel mit Boost! Verwende ausschließlich die Standard-Libraries und mache den Rest selbst. (Baue vielleicht deine Library später um, wenn der neue Standard mit neuen Bibliotheken draußen ist).

Was ratet ihr mir? Wie würdet ihr vorgehen?

Stefan.

[unskilled]

Ich würde boost vorraussetzen.
Der Rest wäre entweder viel mehr Arbeit(alles selbst schreiben) oder je nach System unbrauchbar(z.bsp. libs bauen oder dll`s) und damit auch wieder viel zu viel Arbeit...

Und so schwer ist boost ja nun auch nicht zu bekommen und einzurichten/zu bauen

bb

[hustbaer]

Naja bei der Boost gibt's wohl zu beachten, dass es keine standardisierten Binaries gibt. Zumindest nicht für Windows.

Wenn der Source nicht mit ausgeliefert werden soll, wäre es vermutlich eine gute Idee, die Boost DLLs umzubenennen, und mit auszuliefern.

[pumuckl]

hustbaer schrieb:

Naja bei der Boost gibt's wohl zu beachten, dass es keine standardisierten Binaries gibt. Zumindest nicht für Windows.

Wenn der Source nicht mit ausgeliefert werden soll, wäre es vermutlich eine gute Idee, die Boost DLLs umzubenennen, und mit auszuliefern.

Setzt natürlich voraus dass er überhaupt eine der wenigen Boost-Bibliotheken verwendet die nicht header-only sind.
@OP: Falls du nur eine Handvoll der Boost-Headerbibliotheken benutzt würde ich die header gesondert in ein eigenes Unterverzeichnis zu deinen Sourcen packen.

[DStefan]

@unskilled, hustbaer, pumuckl

Nein, es ist nicht schwer, Boost zu bekommen und selbst zu bauen. Das Problem ist aber, dass man genau die richtige Version bauen muss, also die, mit der auch die Library gebaut wurde. Das ist doch kaum zumutbar.

Ja, man könnte nur die Boost-Libraries verwenden, die Header-Only sind. Aber dann müsste ich unter anderem auf Serialization und Signals verzichten, was mir schwer fiele. Vorausgesetzt, ich verwende Boost überhaupt.

Und mal angenommen, ich nähme nur die Header-Only-Libraries: Könnte jemand, der meine Bibliothek zusammen mit einer anderen Boost-Version verwendet sicher sein, dass alles funktioniert? Wohl eher nicht - vor allem, wenn die Version meiner Library eine deutlich ältere Boost-Version verwendet. Dann wäre die Wahrscheinlichkeit groß, dass es irgendwo knallt.

Tja - wie es aussieht kristallisiert sich immer mehr heraus, dass ich entweder meine Library als Source verfügbar machen oder konsequent auf Libraries verzichten muss, die nicht Standard sind. Oder ich stelle für jede (Major-)Boost-Version eine eigene Binärversion bereit. Und jetzt kombiniert das mal mit allen unterstützten Versionen aller unterstützten Compiler. Es ist zum Haareraufen

Vielleicht erinnert ihr euch an meine Beiträge zu mehr Standard-Libraries in einem anderen Thread? Jetzt wisst ihr warum ich mir das so sehr wünsche

Jedenfalls danke für eure Tipps.

Stefan.

[VuuRWerK]

An dieser Stelle sein noch BCP erwähnenswert

Gut Schuß
VuuRWerK

[DStefan]

VuuRWerK schrieb:

An dieser Stelle sein noch BCP erwähnenswert

Gut Schuß
VuuRWerK

Verdammt! Nach den vielen Stunden auf der Boost-Site hätte ich das auch selbst finden können. Danke für den Tipp!

Stefan.

[hustbaer]

@DStefan:

Und mal angenommen, ich nähme nur die Header-Only-Libraries: Könnte jemand, der meine Bibliothek zusammen mit einer anderen Boost-Version verwendet sicher sein, dass alles funktioniert? Wohl eher nicht - vor allem, wenn die Version meiner Library eine deutlich ältere Boost-Version verwendet. Dann wäre die Wahrscheinlichkeit groß, dass es irgendwo knallt.

Wenn du Boost-Klassen (oder Typedefs) im Interface verwendest, dann kann es ganz schnell irgendwo knallen.

Sollte das der Fall sein, ist es vermutlich wirklich das Beste, wenn du die nötigen Teile aus der Boost raustrennst, und in einen eigenen Namespace verpackst.
Gerade bei Dingen wie shared_ptr ist das allerdings etwas lästig - der User kann deinen shared_ptr dann ja nicht einfach einem "normalen" Boost shared_ptr zuweisen.

[DStefan]

hustbaer schrieb:

@DStefan:

Und mal angenommen, ich nähme nur die Header-Only-Libraries: Könnte jemand, der meine Bibliothek zusammen mit einer anderen Boost-Version verwendet sicher sein, dass alles funktioniert? Wohl eher nicht - vor allem, wenn die Version meiner Library eine deutlich ältere Boost-Version verwendet. Dann wäre die Wahrscheinlichkeit groß, dass es irgendwo knallt.

Wenn du Boost-Klassen (oder Typedefs) im Interface verwendest, dann kann es ganz schnell irgendwo knallen.

Naja - das ist doch der Sinn der Sache (oder wenigstens ein Sinn ). Smart Pointer, Datum und Uhrzeit, vielleicht Any usw. würden bestimmt in den Interfaces auftauchen. Signals würden geradezu fordern, dass Library-User sie verwenden.

hustbaer schrieb:

Sollte das der Fall sein, ist es vermutlich wirklich das Beste, wenn du die nötigen Teile aus der Boost raustrennst, und in einen eigenen Namespace verpackst.
Gerade bei Dingen wie shared_ptr ist das allerdings etwas lästig - der User kann deinen shared_ptr dann ja nicht einfach einem "normalen" Boost shared_ptr zuweisen.

Es ist lästig, und ich glaube, es könnte "tödlich" sein, wenn die Boost-Versionen von User und Lib nicht übereinstimmen. In einer anderen Boost-Version braucht sich ja nur die interne Repräsentation ändern....

Stefan.

[hustbaer]

DStefan schrieb:

Es ist lästig, und ich glaube, es könnte "tödlich" sein, wenn die Boost-Versionen von User und Lib nicht übereinstimmen. In einer anderen Boost-Version braucht sich ja nur die interne Repräsentation ändern....

Da hast du mich falsch verstanden. Ich meinte wenn du die Boost-Teile kopierst und in einen eigenen Namespace verfrachtest (so dass es "sicher" ist), ist es lästig.

deine_library::shared_ptr<deine_klasse> p = lala();
boost::shared_ptr<deine_klasse> p2 = p; // geht nicht -> lästig

Wird aber wohl nicht anders gehen.
Bei Dingen wie intrusive_ptr ist es dagegen wieder ziemlich egal.