Followup: STL vs. Qt (konkret)

kaizimir

Moin,

nach den vielen hilfreichen posts in diesem Thread: http://www.c-plusplus.net/forum/viewtopic-var-t-is-246297-and-start-is-10-and-postdays-is-0-and-postorder-is-asc-and-highlight-is-.html habe ich mich jetzt also entschieden, möglichst viel mit der STL zu machen und den Einsatz von Qt auf ein Minimum zu beschränken.

Folgende Gründe haben mich dazu bewogen:
- möglichst nahe am Ansi-C++ Standard bleiben
- möglichst unabhängiges Design von Drittanbietern
- deutliche Trennung von Back- und Frontend
- die Herausforderung

Allerdings habe ich festgestellt, dass ich doch ein wenig Starthilfe gebrauchen könnte und mich sehr für eure professionelle Meinung interessiere. Daher hier eine weitere Frage:
Ich benutze also den QFileDialog, um den Pfad und Namen einer Datei zu ermitteln. Diese Angaben liegen also jetzt als QString vor. Wann ist der richtige Zeitpunkt, um zur STL zu switchen: Den QString jetzt direkt in ein char* umwandeln (wenn jetzt jemand den Code dafür direkt aus dem Arm schütteln kann, danke!) oder erstmal die Daten mit Qt auslesen?

Hinzu kommt, dass später unterschiedliche Dateiformate gelesen bzw. importiert werden sollen.
Meine Idee hierzu:
Eine Klassenhierarchie aufbauen, in der für jedes Format eine entsprechende Klasse angelegt ist, die neben den allgemein notwendigen Methoden die jeweils formatspezifischen Methoden enthält.
Sehe ich es richtig, dass ich meine Frage gerade selbst beantwortet habe und so schnell wie möglich den QString umwandeln sollte?

Und wenn ich noch ein bißchen mehr von eurer Erfahrung profitieren dürfte, würde ich gerne wissen, wie ihr so etwas designen würdet.

greetz, kai

Don06

Ein char* ist ziemlich Low-Level. Ich würde im Frontend versuchen die Datei zu öffnen und als std::istream an das Backend weitergeben. Sonst müsstest du im Fehlerfall ja sowieso die Meldung bis ins Frontend durchreichen. Kleines Beispiel.

void backend(std::istream& input);

void frontend()
{
    QString file_name = "some_file.xml";
    std::ifstream input_file(file_name.ascii()); // oder so ähnlich, schau in die Doku!
    if (input_file)
        backend(input_file);
}

Julian__

anstatt von char* solltest du in c++ evtl. besser std::string benutzen (oder wahlweise std::wstring).
dazu bietet QString entspr. konvertierungsmethoden:
http://doc.qtsoftware.com/4.5/qstring.html#toStdString
http://doc.qtsoftware.com/4.5/qstring.html#toStdWString

wo du genau aus dem QString ein std::string/wstring machst, bzw. wo es am sinnvollsten ist, musst du gucken.
wenn du bspw. vorher noch mit anderen Qt-Klassen arbeitest, macht es wohl sinn, erstmal die daten in form eines QString zu behalten.

zu den versch. dateiformaten:
brauchst du dazu unterschiedliche methoden fuer jedes format?
ansonsten evtl. eine abstrakte basisklasse mit allen noetwendigen methoden, ggf. virtual, die dann in den implementierungen fuer jedes format ueberladen werden.
gibt aber sicherlich mehrere moeglichkeiten.

mfg,
julian

Umwandeln zwischen QString<->std::string nur an der Grenze zur GUI. Wenn also neue Daten da sind, liegen die als std::string vor (bitte nimm nicht char*... du willst kein ANSI-C sonder ISO-C++). Die Gui macht dann sowas:

textEdit->setText( QString::fromStdString(dataObject->stringValue()) );

Also nicht schon in den Bereichen, die du eigentlich trennen wolltest, mit QString "infizieren".
Umgekehrt geht das dann so:

dataObject->setStringValue( textEdit->plaintText().toStdString() );

Im übrigen solltest du dir genau überlegen, was du willst. Beschäftige dich erstmal ein wenig mit Qt, und erörtere, ob du nicht in den Core-Sachen schon auf QObject setzen willst, um zwischen den Objekten mittels SIGNAL/SLOT Daten austauschen willst. Dann kannst du gleich alles in Qt schreiben.

DStefan

Meiner Meinung nach sollte man in Modulen denken. Beispielsweise könnte das GUI-Modul Qt verwenden, während alle anderen Module auf die Standardbibliotheken beschränkt bleiben. Innerhalb des GUI-Moduls kann man Qt und STL mischen, die Übergänge sind natürlich auf STL beschränkt. Auf diese Weise hast du letztlich einen genau definierten Bereich, der geändert werden muss, sollte Qt einmal ausgetauscht werden.

Ich habe zwei Projekte auf diese Weise erstellt, allerdings nicht kommerziell, sondern nur, um Qt kennen zu lernen. Über einen Austausch von Qt kann ich also nicht berichten. Die größte Versuchung war, nicht überall Qts Signal-Slot-Mechanismus zu verwenden. Damals gab es Boost.Signal noch nicht oder zumindest kannt ich diese Library nicht, also musste ich mir selbst Notifier und Observer schreiben. Alles andere war nicht weiter schwierig. Das Design war sauber und stabil.

Stefan.

kaizimir

Super Leute, vielen Dank für die Antworten, dass ging wirklich schnell.

DStefan schrieb:

Beispielsweise könnte das GUI-Modul Qt verwenden, während alle anderen Module auf die Standardbibliotheken beschränkt bleiben.

So in etwa hatte ich mir das vorgestellt. Ich werde auch deinen Denkanstoss zu berücksichtigen und versuchen in Modulen zu denken. Sollte ja eigentlich selbstverständlich sein, muss man eben nur ein bißchen üben.

Kohlrabe schrieb:

Im übrigen solltest du dir genau überlegen, was du willst.

Das Programm soll große Datensätze verarbeiten können. Hierbei wird es zu umfangreichen Berechnungen kommen, deren Ergebnisse anschließend grafisch dargestellt werden müssen. Der User nimmt dabei Einfluss auf die Art der Berechnung (Parameter setzen, Auswahl unterschiedlicher Methoden,...) und die Form der Darstellung (Wertetabellen und Graphen). Es wird also eine erhebliche Kommunikation zwischen Front- und Backend geben. Auf der anderen Seite sollten Berechnungen (z.B. Crosscorrelations, FIR, usw.) möglichst unabhängig einsetzbar sein, so dass sie in nicht-Qt basierten Programmen wiederverwendet werden können.

Letzen Endes wird es ein sehr umfangreiches Projekt, also von den Rohdaten zur veröffenlichungsreifen Abbildung...wow, ob ich das in diesem Leben noch schaffe weiß ich nicht. Mit eurer Hilfe vielleicht . Aber keine Sorge, ich fang erstmal in kleinen Etappen an.