qtforum.de

Hallo Gemeinde,

in Qt habe ich die Möglichkeit Container über Qt direkt einzubinden, oder über STL alternativ kann ich mir noch die bekannte C++ Lib hohlen und das ganze dann über Boost machen. Alle 3 Methoden funktionieren auf dem ersten blick sehr gut und sind auch leicht zu handhaben. Nun stellt sich für mich aber die Frage was sind die Unterschiede zwischen Qt-Container der STL und Boost. Welches Einsatzgebiet finden die jeweiligen Methoden in Qt. Ich denke mal es ist etwas naiv wenn man sagt Qt-Container verwenden, weil sie dabei sind. Soweit ich gelesen habe gibt es da schon sehr rudimentäre Unterschiede, vor allem was Qt und STL angeht. Nun wollte ich mal fragen, wleche das sind und ob mir mal jemand was dazu sagen kann, oder schon Erfahrungen gemacht hat, was gegen Qt-Container spricht. Oder was für STL / Boost spricht.

so long
jd

Für den Qt-Part: http://doc.trolltech.com/4.3/containers ... er-classes

Ich benutze stl so selten wie möglich - die API ist einfach Dreck. Boost benutze ich nur wenn ich wirklich was zeitkritisches brauche - also auch nicht wirklich oft.

was gegen die QT container spricht:
- naja leichte abweichung von namenskonentionen zur STL (List und Linked List bei der QT)
- und die abhaengigkeit von der QT, sprich du muesstest immer die qtcore libs mit ausliefern ....
- die QT container haben einige "Konfortfunktionen", die die STL bewusst aus technischer hinsicht ned bietet. grad beim multithreading muss man da bissi aufpassen.

was fuer die QT container spricht:
- die QT selber arbeitet sinniger weisse mit denen zusammen ^^

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 ...

Proggst du direkt nur fuer die QT, also nen "Anzeigemodul" was mit QT realisiert wird, hasst die QT abhaengigkeitwen sowieso, und viele QT klassen schlucken QT container direkt. Was wird man dann wohl nehmen ...

Alles andere dazwischen ist wahrscheinlich geschmackssache ...

Ciao ...

RHBaum hat geschrieben:
- und die abhaengigkeit von der QT, sprich du muesstest immer die qtcore libs mit ausliefern ....

1. es sind templates - wieso sollte ich dann qtcore brauchen?
2. wir sind hier ein Qt-Forum - also ist es eigentlich klar dass man ein Qt-Programm erstellt, also eh schon Qt als Dependency hat

es sind templates - wieso sollte ich dann qtcore brauchen?

Schon mal versucht ?
Also bei der qt3 z.b. haben die QList und die anderen templates intern funktionen aus der qt lib verwendet.

also ist es eigentlich klar dass man ein Qt-Programm erstellt,

Trennst du eigentlich deine Programme ned in einzelne Module/EInheiten ? Und verwendest du diese nicht auch in andere Programmen ?

Ich benutze stl so selten wie möglich - die API ist einfach Dreck

Die API iss ned wirklich einfach, und auch ned schoen ...
Aber wenn man sich bissi mit performanter Programmierung, threading und erwartetes verhalten etc auseinander setzt, wird man sehen das diese Bloede API grad auf performance, definiertes verhalten aufbaut, und hoechstmoegliche flexiblitaet bietet. Auch auf kosten des komforts ....

Oberflaechenprogrammuierung und biblotheksprogrammierung sind halt 2 paar Schuhe ... Also mit der QT ne Oberflache zusammenzustricken, das hat mehr mit javaprogrammierung zu tun als mit richtigen C++ ^^
Iss aber auch gut so ....
Trotzdem sollten programmierer beides koennen.

Ciao ...

Dein Problem ist das Du Qt als GUI-Bibliothek ansiehst was es definitiv nicht (mehr) ist.

Ich benutze stl so selten wie möglich - die API ist einfach Dreck. Boost benutze ich nur wenn ich wirklich was zeitkritisches brauche - also auch nicht wirklich oft.

full ack... !

naja leichte abweichung von namenskonentionen zur STL (List und Linked List bei der QT)

Das dreh ich gleich um: "verwende nur Qt, weil die Namenskonvention der STL abweicht"...

Bei groesseren Projecten wirst hoffentlich modular programmieren, und mehr selber auf der "Biblothekseite" sein.

Genau! Zur Qt-GUI auch die passenden Qt-Libraries und -Plugins... Das macht Sinn.. der Code sieht einheitlich aus, die Interfaces passen perfekt und Qt-Konzepte wie "Implicit Sharing" werden durch das gesamte Projekt gezogen. Den Rest deines Kommentares ("ist ein Segen") klingt daher in meinen Ohren widerspruechlich..

es sind templates - wieso sollte ich dann qtcore brauchen?

Nicht vollstaendig, nein.. diese Shared-Daten (shared_null usw) sind im Qt-Core.. aber egal, du hast ja selbst schon geschrieben, warum dies keine Rolle spielt.

Ja sicher, weil die QT fuer Biblotheksentwicklung eher ungeeignet ist.

Und zumindest bei uns gibt mir die Praxis recht ... aus organisatorischen gruenden ....
Erklaer mal jemanden, der von dir ne dll fuer sein programm braucht, was MFC oder wxWidgets nutzt, das er sich nu qt dlls installieren muss.

Oder das nen zulieferer fuer Module fuer dein Framework in den Schnittstellen ploetzlich QT klassen drinne hat, und er sich ne QT Lizenz kaufen muesst.

QT iss nen tolles tool, wenn man es dafuer einsetzt wofuer es gemacht ist.

Denk mal, dass Du die Probleme aus Professionellen Umfeld, was halt weit ueber 1 Programm = 1 Projekt hinausgeht, ned so kennst.

Wenn ich hier ne exe baue, link ich meist 10 oder mehr bibs zu, die von anderen entwicklern kommen, teilweisse aus anderen Abteilungen. Meine Bibs/dlls gehen auch durch unternehmen, und viele, bzw. die meisten nutzen (noch) kein QT ...

@solarix
Wenn alle QT und den selben compiler einsetzen, kannst natuerlich tolle sachen machen ... was aber wiederum bedeutet, das deine Libs / Module nie deinen einflussbereich verlassen duerften ....
schon mal versucht nen QT plugin zu verwenden, was mit dem mingw/gcc erstellt wurde, und du selber VS verwendest ?
Und das jede Firma ihren Quellcode Preisgibt, iss (leider) auch ned praktikabel oder ?

Ciao ....

RHBaum hat geschrieben: Denk mal, dass Du die Probleme aus Professionellen Umfeld, was halt weit ueber 1 Programm = 1 Projekt hinausgeht, ned so kennst.

Sei mal nicht so überheblich ( das darf nur ich )

/edit:

RHBaum hat geschrieben: Und zumindest bei uns gibt mir die Praxis recht ... aus organisatorischen gruenden ....
Erklaer mal jemanden, der von dir ne dll fuer sein programm braucht, was MFC oder wxWidgets nutzt, das er sich nu qt dlls installieren muss.

Irgendwie kapierst Du es nicht - wir sind hier ein Qt-Forum. D.h. der Fragende will sicher kein MFC-Proggie bauen sondern ein Qt-Programm. Warum sollte man also dann nicht die Qt-Container benutzen?

Ich bin ned ueberheblich, hoffentlich ...

Ich hab halt nur genau die probleme die durch sowas entstehen immer an der Backe, und darf dann den Buhmann spielen

wie gesagt, hab mal laenger mit sowas zu tun, dann wirst du C-Schnittstellen lieben lernen .... und das sogar in der heutigen zeit

Ciao ...

Irgendwie kapierst Du es nicht - wir sind hier ein Qt-Forum

Glaub das ist mir langsam zu doof ....

wenn fuer dich QT der Nabel der Welt ist, bitte, aber lass andere Programmierer ueber den Tellerand schauen, und probleme vermeiden, die du gar ned kennst ....

Ciao ...

@RHBaum: Das Problem ist das Du die Frage von jd nicht gelesen hast. Ihm ist wohl sehr klar das es sinnlos ist die Qt-Container zu benutzen wenn man sonst kein Qt weiter benutzt und das hat niemand bestritten. Das ist uns allen klar. Alles was Du bist jetzt geschrieben hast geht darauf genau darauf hinaus. Das Du Qt benutzt hast und jetzt Probleme bekommst - dafür können wir ja nichts.

Den Standpunkt von RHBaum kann ich nur verhärten. Standardisierte Schnittstellen sind eben großer Luxus. Ich arbeite täglich mit Geldwechselsystemen, da gibt es Standard Protokolle, die man überall eingebunden werden kann. Beispiel EC-Automat kennt ja jeder das teil. Da wo die schicken scheine raus kommen, ist ein Dispenser, dieser kann über USB COM LPT angesteuert werden, Schnittstellen zur Programmierung gibt es dann beim jeweiligen Hersteller, dort ist es auch so, das man entweder eine C-Schnittstelle / C++ bekommt oder gleich den Quellcode. Von daher kann ich das problemlos in Qt einbetten und das Terminal hat dann mal eine Qt-Gui .

Meine Meinung ist, das die Qt-Container auch nur intern richtig Sinn machen. So wie man mit Bibliotheken anfängt die unabhängig sein müssen, Macht STL oder Boost schon mehr Sinn. Man kann mir ja nicht vorschreiben welches Framework ich nutzen soll. Was ich so gelesen habe nehmen sich STL Boost und Qt-container nicht viel von der Performance etc. Die Leistungsfähigkeit ist bei allen gut. Natürlich kommt es auch immer auf das Einsatzgebiet an.

Ich habe vor einer halben Stunde einen Link gehabt da gab es eine Diskussion über KDE4-Entwicklung was denn Qt-Container vs STL.

Die Meinungen sind sehr umstritten, alle Argumente sind gut und im Endeffekt kommt wirklich darauf an. Was man macht und wie es gehandhabt werden soll. Wenn man eine Lib hat die auch für MFC sein soll machen Qt-Container keinen sinn, das ist klar. Ansonsten kann ich Christian und Solarix nur zustimmen.

Im internen Ablauf machen Qt-Container mehr Sinn als alles andere, da das ganze Framework damit umgehen kann.

wie gesagt, hab mal laenger mit sowas zu tun, dann wirst du C-Schnittstellen lieben lernen .... und das sogar in der heutigen zeit

Ich mache (im professionellen Umfeld) genau die umgekehrte Erfahrung.. ich musste fast 10 Jahre lang C-Schnittstellen einsetzen und hasse das Zeug dafür. Wenn jemand in der Position/Lage ist, auf gruener Wiese anzufangen (und davon gehe ich beim Ursprungspost aus), sollte so lange wie möglich in der Qt-Welt bleiben.

Im Endeffekt steht und faellt jedes Argument mit genau nur einem Punkt:

Kann man "sicherstellen" das der Code den man schreibt, nie in einer anderen Umgebung wiederverwendet werden soll/wird.


Und genau das ist der Knackpunkt .... und auch ein Fakt, der aus der Fragestellung ueberhaupt ned hervorgeht.
Deshalb die Antwort: wenn er code schreibt fuer ne QT GUI, ist die chance das er den code fuer NichtQT dinge verwenden muss nahezu NULL.
Dort soll er ruhig die QT einsetzen ...

Aber schreibt er code, wo er irgendwelche logischen dinge umsetzt, irgendwas baut, was spaeter nur von der QT Gui dargestellt wird, sollt er halt 2 mal ueberlegen .... entscheidet er sich fuer die QT, entscheidet er sich fuer eine weitere einschraenkung, und genau das muss er selber verantworten.
Ich kann es nie sicherstellen ....

Was ich aber echt bedenklich finde, ist das Leute hier schreiben und zustimmen, das die voraussetzung von QT nun mal C++ ist. Und die STL gehoert nunmal dazu.
Soweit noch ok. Aber sich dann auessern, das die STL haesslich sei, sich ueberhaupt ned mit technischen Vor und Nachteilen auseindersetzen wollen, und dann argumentiert, das hier waer nen QT forum ... das ist scho arg.
Mal abgesehen davon, das man sich selber damit einschraenkt, waer die Frage selber doch gar ned zulaessig hier im Forum dann oder ? Was eigentlich schade fuer das Forum waer ...

Das ganze fuehrt eigentlich in genau eine Richtung, wo SW eigentlich ned hinfuheren soll. Wo der Programmierer bestimmt was wie funktioniert, und nicht der "benutzer" oder ?

ich musste fast 10 Jahre lang C-Schnittstellen einsetzen und hasse das Zeug dafür. Wenn jemand in der Position/Lage ist, auf gruener Wiese anzufangen (und davon gehe ich beim Ursprungspost aus), sollte so lange wie möglich in der Qt-Welt bleiben.

Ich kann deine "gefuhle" durchaus verstehen ... aber sollten diese die Entscheidung ueber die Technik sein ?
Wenn ich die Wahl hab, zwischen schoener toller Schnittstelle, oder kompatiblitaet, dann sollt ich sicher ned die Gefuehle entscheiden lassen.
Fuer mich waer die entscheidung klar davon abhaengig, ob ich dieses Modul mal irgendwann von nem anderen Programm/script einsetzen koennt, was von nem anderen kompiler gebaut wird. Kann ich das ned ausschliessen, verwend ich definitiv c schnittstellen.

Wobei Schnittstellen hier auch wirkliche Schnittstellen sein sollten ...
Und Die grosse der Module auch ne Rolle spielt. Sind das module mit weniger als 100 Zeilen, kann man sich scho ueberlegen, das man die im Zweifelsfall bei Bedarf ned komplett neu schreibt ....



Ciao ...