3. C++ Boost: Wirklich so wenig Lib-Dateien?

C++ Boost: Wirklich so wenig Lib-Dateien?

  • A

    Habe mir heute mal die Mühe gemacht und bei www.boost.org die Library und das jam Buildtool runter geladen. Habe alles nach der Step by Step Anleitung (Getting startet) installiert und er hat mir auch brav LIBs und DLLs erzeugt (habe VC++6.0).

    Nun meine Frage: sind es wirklich nur so wenige Libs die am Ende bei rauskommen? Kann sein das ich mich täusche, und es ist wirklich so i.O.

    Hier mal ein paar Fakten, falls ihr mir helfen könnt.
    An DLLs und LIBs habe ich folgende:

    date_time
    filesystem
    regex
    signals
    threads

    Sind praktisch fünf DLLs bzw. LIBs, plus die verschiedenen Runtime-Varianten.

    Reine LIBs habe ich jedoch auch (keine DLLs vorhanden):

    prg_exec_monitor
    regex
    text_exec_monitor
    unit_test_framework

    Alles natürlich wieder in verschiedenen Runtime-Varianten.

    Nun, ist das so i.O.? Sind insgesamt 49,3 MB in dem Boost\lib-Verzeichnis.

    Weiß jemand was diese exec Dinger sind?

    Was ist in regex drin?

    Werde mal morgen Boost ausprobieren, habs mir eigentlich nur wegen der Thread-Klasse runter geladen (scheint genial einfach benutzbar zu sein).

    0
  • S

    schaut OK aus.
    boost hat wenig libs, da fast alles templates sind.

    regex ist die Library fuer Regulaere Ausdruecke (REGular EXpressions)

    0
  • A

    Ok, danke! 🙂 Wenn ich so recht darüber nachdenke, fällt mir das mit den Templates jetzt auch auf. 🙄 Wundere mich nur, wo er die cpp-Dateien für die Templates kopiert hat? Bin der Meinung er hat nur die includes und Libs ins c:\boost kopiert bzw. erzeugt.

    Aber das kann ich erst heute Abend zu Hause überprüfen.

    0
  • S

    Templates besitzen keine .cpp Datei, die stehen in der Deklaration mit drin.

    0
  • J

    SirLant schrieb:

    Templates besitzen keine .cpp Datei, die stehen in der Deklaration mit drin.

    nicht unbedingt

    0
  • S

    Jover schrieb:

    SirLant schrieb:

    Templates besitzen keine .cpp Datei, die stehen in der Deklaration mit drin.

    nicht unbedingt

    Soweit ich weiß, gibt es noch keinen Compiler der export unterstützt, wenn
    ich mich da irre, dann nehme ich meine Aussage natürlich zurück.

    0
  • H

    SirLant schrieb:

    Jover schrieb:

    SirLant schrieb:

    Templates besitzen keine .cpp Datei, die stehen in der Deklaration mit drin.

    nicht unbedingt

    Soweit ich weiß, gibt es noch keinen Compiler der export unterstützt, wenn
    ich mich da irre, dann nehme ich meine Aussage natürlich zurück.

    Du musst deine Aussage zurück nehmen. Der Comeau-Compiler z.B. unterstützt export.

    0
  • ?

    Machmal behilft man sich, indem man die Header so schreibt:

    // blub.h
#ifndef blub
#define blub

// templates..

#include "blub.cpp" // <-- hier

#endif

    Dann hat man wenigstens Definition und Deklaration getrennt.

    0
  • S

    Gunnar_ schrieb:

    Dann hat man wenigstens Definition und Deklaration getrennt.

    Wobei man dann natürlich nicht die Endung *.cpp nimmt 😉

    0
  • A

    Shade Of Mine schrieb:

    Gunnar_ schrieb:

    Dann hat man wenigstens Definition und Deklaration getrennt.

    Wobei man dann natürlich nicht die Endung *.cpp nimmt 😉

    Welche dann? 😕

    0
  • S

    Artchi schrieb:

    Welche dann? 😕

    cpp, C, cc, cxx,... sind normalerweise Übersetzungseinheiten.
    man kann also ein einfaches
    g++ *.cpp
    machen um alle ÜE zu übersetzen.

    Allerdings ist eine Datei mit Template definitionen eben _keine_ ÜE - deshalb sollte man das im Namen festlegen.

    Ich verwende zB inl für inline definition, andere Leute verwenden auch tmpl, template, t, etc.

    Denn sonst kann man den Leser des Codes ganz schön verwirren - vorallem wenn ein
    g++ foo.cpp
    einfach nicht will - weil es eben keine ÜE ist (nur woher weiss der Leser das?)

    0
  • H

    Hallo,
    ich trenne meine Templateklassen mittlerweile eigentlich immer so auf:

    1. Foo.h : Klassendefinition und zusätzliche Deklarationen sonst nichts.
    2. Foo_impl.h : Definitionen der Memberfunktionen usw. Inkludiert Foo.h
    3. Foo_instantiate.cpp: explizite Instanziierungen für häufig verwendete Typen.

    "Normale" Clients inkludieren Foo.h und linken das Ergebnis der Übersetzung von Foo_instantiate.cpp. Vorteil: Kürzere Compilezeiten, da der Compiler nur einmal durch die Templatedefinition muss statt einmal pro ÜE die das Template verwendet. Nachteil: Man erhält im Zweifelsfalls mehr Spezialisierungen als nötig.

    Alternativ bindet man Foo.h und Foo_impl.h ein und kann sich dafür Foo_instantiate.cpp sparen. Damit hat man dann den klassischen inclusion-model-Ansatz.

    Das mache ich allerdings nur für Templateklassen die in den meisten Fällen nur für eine kleine und feste Menge von Typen spezialisiert werden. Wie z.B. für Template-Klassen deren Parameter irgendwelche Policies sind.

    Verfolgt man den Ansatz weiter, kommt man wohl irgendwann beim Instantiator von Eric Niebler raus (siehe CUJ Oktober 2003).

    0
Anmelden zum Antworten