Qt-Container VS STL und Boost

[franzf]

In der Praxis:
Bei groesseren Projecten wirst hoffentlich modular programmieren, und mehr selber auf der "Biblothekseite" sein. Da versuchts natuerlich, abhaengigkeiten zu vermeiden -> die STL und Boost ist ein Segen ...

Ich hab noch nie Boost in meinen Projekten verwendet, hauptsächlich daher:

Code: Alles auswählen

genlop -i boost  
 * dev-libs/boost


   Total builds: 4
   Global build time: 1 hour, 40 minutes and 7 seconds.
   Average merge time: 25 minutes and 1 second.

25 Minuten Kompilieren (auf nem AMD64 3700+) nur wegen Containern ist mindestens so verwerflich wie auf Qt-Container setzen
Aber das merken reine "Binär-installier-Freaks" nicht so sehr...
Auf meinem "kleinen" Rechner ist boost schon mal mit >2 Stunden dabei...

Nicht zu vernachlässigen ist der zusätzliche Speicherbedarf.

Grüße
Franz

[RHBaum]

Die boost komplett compiliert hier in 4 min .... ok, es ist windows (XP) und nen Intel Prozessor. Aber noch nich mal nen EXxxx sondern nen aelterer Pentium

Und ja, fuer windows gibts auch fertige binaries

Aber wenn dich mit der boost naeher beschaeftigst, wirst mitbekommen, dass alles andere kompiliert hasst, nur nix was mit containern zu tun hat ... naja fast

Die boost ist mittlerweile auch fett wien ... naja lassen wir das
zum glueck brauchst fuer die wichtigen "container" ja auch keine lib zum linken, da langen einfach die includes. Steht in der doku uebrigens auch dabei

Die meisten Dinge aus der boost hab aich auch noch nie wirklich gebraucht ... sind wohl eher doch bissi speziell. Einzig was ich gut fand waren die smartpointer. Aber spaetestens wenn alle compiler TR1 unterstuetzen, wird die boost eh wieder in den hintergrund ruecken ...

Ciao ...

[Nash]

ich verwende für die Core-Module so gut es geht die STL und wenn es sein muss Boost. Die Oberfläche selbst ist strikt davon getrennt, dort setze ich dann Qt ein und kann dort auch auf alle Qt-Module zugreifen.

Das hat wie beschrieben u.a. den Vorteil: sollte Qt mal ausgetauscht werden, durch z.B. wxWidget brauch ich den core code nicht umschreiben.

[PeterLustig]

Das hat wie beschrieben u.a. den Vorteil: sollte Qt mal ausgetauscht werden, durch z.B. wxWidget brauch ich den core code nicht umschreiben.

Und den Nachteil das man die ganzen nützlichen Klassen von Qt nicht im Core nutzen kann. Qt ist mittlerweile mehr als nur ein GUI-Framework.

[RHBaum]

Und den Nachteil das man die ganzen nützlichen Klassen von Qt nicht im Core nutzen kann

also ich programmier in C/C++ ned nur weil ichs toll finde, sondern weil konkrete anforderungen hinter unseren Programmen stehen.

Die QT ist fuer mich nichts mehr als eine Bruecke zwischen der "schoenen Javawelt" und der Welt, wo es um speicherverbrauch und Performance geht ...
Also ein Mittel, wo sogar ich schnell Oberflaechen bauen kann, ohne mein gelerntes C++ zu verlassen.
Aber wenn ich alles technisch so programmieren wuerde, wie oberflaechen usw. dann wuerd mein Chef sicher ned bereit sein,mir mein Gehalt weiter zu bezahlen, weil das koennt nen Student mit Visual Basic auch ...


Ein technischer Grund, warum ich die QT als generisches C++ Framework sofort ablehnen wuerd, ist der:
http://doc.trolltech.com/4.4/shared.htm ... it-sharing
sowas hat in nem lowlevel Framework nix zu suchen .... es sei denn man sucht expliziet ne lib die sowas macht. Aber meistens braucht mans ned ... bzw. wenn man c++ da einsetzt, wo es vorteile gegenueber anderen sprachen hat, isses sogar eher schaedlich ...

Ciao ...

[Nash]

Das hat wie beschrieben u.a. den Vorteil: sollte Qt mal ausgetauscht werden, durch z.B. wxWidget brauch ich den core code nicht umschreiben.

Und den Nachteil das man die ganzen nützlichen Klassen von Qt nicht im Core nutzen kann. Qt ist mittlerweile mehr als nur ein GUI-Framework.

klar verleitet es die core klassen von Qt auch im eigenem Core-Modul zu nutzen, aber Qt ist nunmal kein weltweiter Standard.

Eines der obersten Ziele bei der Softwareentwicklung ist es flexibel auf Veränderungen zu reagieren. Das bedeutet z.B. ein Verhalten oder ein Modul schnell und unkompliziert durch ein anderes zu ersetzen ohne das du den ganzen Quelltext nochmal umbauen musst.

Für die Entwicklung von schnellen und kleinen Anwendungen ist Qt mit all seinen vielen Klassen sicherlich eine gute Wahl, aber nicht für den Aufbau von komplexen und umfangreichen Programmen.

Daher setze ich Qt dafür ein, für was es ursprünglich gedacht war: Eine plattformübergreifende GUI-Bibliothek.