Wie portablen Code schreiben

SeppJ

Und wenn du zwei verschiedene Klassen schreiben würdest, was dann? Willst du dir den ganzen Rest vom Programm mit ifdefs zukleistern, anstatt nur die eine Stelle an der tatsächlich etwas anders gemacht werden muss?

hustbaer

Du kannst auch zwei verschiedene Projekte machen, und die gemeinsam genutzten Teile in eigene Source-Files packen, und diese in beiden Projekten einbinden.

SeppJ schrieb:

Und wenn du zwei verschiedene Klassen schreiben würdest, was dann? Willst du dir den ganzen Rest vom Programm mit ifdefs zukleistern, anstatt nur die eine Stelle an der tatsächlich etwas anders gemacht werden muss?

Wieso zukleistern?
Ich mache an EINER Stelle im Code Dialog.Show(). Unter Linux soll halt ein Linux Fenster und unter Win ein Windows Fenster aufgehen.

@hustbaer: Keine AHnung, was du meinst. Ein Dialog ist unter Win total anders als unter Linux.

Du bist zu dumm zum Programmieren, aber mit KEINER Antwort zufrieden und weißt es besser. Warum fragst du überhaupt?

ohma nnn schrieb:

Du bist zu dumm zum Programmieren, aber mit KEINER Antwort zufrieden und weißt es besser. Warum fragst du überhaupt?

Sagt einer, der aus flamen nichts beiträgt. Sehr erwachsen.

C++er22 schrieb:

Hat auch jemand mal eine sinnvolle Antwort?

Nochmal: Schreibt man für sowas eher EINE Klasse (EINE Dialog.cpp/h) und hat dann IN den Methoden #ifdef) oder legt man 2 Plattformspezifische Klassen an?

Für kleine Projekte benütze ich gern eine statische QT-Lib. Da hast du dann eine EXE oder ELFe. Die QT-Klassenbibliothek hat sich bei mir sehr bewährt um schnell gute Software zu entwickeln. Mit WX,Boost,... ist das vermutl. ähnlich.

m_mm schrieb:

C++er22 schrieb:

Hat auch jemand mal eine sinnvolle Antwort?

Nochmal: Schreibt man für sowas eher EINE Klasse (EINE Dialog.cpp/h) und hat dann IN den Methoden #ifdef) oder legt man 2 Plattformspezifische Klassen an?

Für kleine Projekte benütze ich gern eine statische QT-Lib. Da hast du dann eine EXE oder ELFe. Die QT-Klassenbibliothek hat sich bei mir sehr bewährt um schnell gute Software zu entwickeln. Mit WX,Boost,... ist das vermutl. ähnlich.

Wie siehts denn da lizenztechnisch aus, wenn ich statisch linke? Gilt dann nicht nur noch GPL statt LGPL?

Klar ist QT klasse, aber für ein einziges Fenster finde ich es schon etwas Overkill. Müsste ja extra QT statisch kompilieren (das dauert schon Stunden) und dann alles einrichten nur wegen einem Fenster...

hustbaer

C++22er schrieb:

@hustbaer: Keine AHnung, was du meinst. Ein Dialog ist unter Win total anders als unter Linux.

Ja, genau. Deswegen ist es ja auch eine Option zwei verschiedene Projekte zu machen, eben weil der GUI Code total unterschiedlich ist.

Aber der GUI Code wird ja wohl nicht alles sein, dein Programm wird ja auch noch irgendwelche Sachen machen wollen, ausser einen Dialog anzuzeigen, nen?
Diese Sachen sind der gemeinsame Teil, den du in beiden Projekten verwenden kannst.
Du hast dann z.B.:

Windows-Projekt:
* WinGui.cpp
* Sachen1.cpp
* Sachen2.cpp

Linux Projekt:
* LinuxGui.cpp
* Sachen1.cpp
* Sachen2.cpp

Die eigentliche Funktionalität ist in Sachen1/Sachen2 implementiert, mit portablem C++ Code. Und die beiden GUIs rufen Funktionen aus Sachen1/Sachen2 auf, um die eigentliche Arbeit zu verrichten.
Anders gesagt: du teilst dein Programm in Frontend und Backend, und schreibst dann ein einziges Backend, und je ein Frontend für Windows und Linux.

Vermutlich ist die von hustbaer skizzierte Lösung die pragmatischste für dich.
Als schlanke, portable GUI-Lib ist vielleicht FLTK mehr nach deinem Geschmack. Dort ist neben der LGPL explizit das statische Linken für proprietäre/kommerzielle Software erlaubt.

C++er22 schrieb:

Wie siehts denn da lizenztechnisch aus, wenn ich statisch linke? Gilt dann nicht nur noch GPL statt LGPL?

Inzwischen (Qt4.5?) ist auch die statische Variante LGPL. In der LGPL ist aber das statische Linken wohl etwas Grauzone. Im QT-Forum äußert sich Nokia zumindest so, dass es die dynamische Variante empfiehlt, aber gegen das statische Linken eigentlich nichts dagegen hat. http://lists.qt.nokia.com/pipermail/qt-interest/2009-December/016090.html

C++er22 schrieb:

Klar ist QT klasse, aber für ein einziges Fenster finde ich es schon etwas Overkill. Müsste ja extra QT statisch kompilieren (das dauert schon Stunden) und dann alles einrichten nur wegen einem Fenster...

Du kannst beim Configure nicht benötigte Dinge (Webkit, Multimedia, Phonon, Declarative, Examples, Demos, Sql,...) weglassen. Wenn du dann nur eine Release-
Version erzeugts, hält sich das ganze in Grenzen ca. 30 min). Bei mir sieht das z.B. so aus

mkdir c:\Qt\4.8s
cd c:\Qt\4.8s
C:\Qt\4.8s>set QMAKESPEC=win32-g++
C:\Qt\4.8s>set QTSOURCE=c:\qt\qt-source
C:\Qt\4.8s>set QTDIR=C:\Qt\4.8s
C:\Qt\4.8s>PATH C:\Qt\4.8s\bin;c:\perl\bin;c:\mingw32\bin;c:\programme\cmake\bin;C:\WINNT\system32
C:\Qt\4.8s>c:\qt\qt-source\configure  -opensource -confirm-license -release -static -fast -no-phonon ...
    -no-qt3support -no-multimedia -no-webkit -no-declarative -no-opengl ...
    -no-script -no-native-gestures -no-xmlpatterns -no-sql-sqlite -no-sql-mysql
qmake c:\qt\qt-source/projects.pro -o Makefile -spec win32-g++ "QT_BUILD_PARTS=libs"

CCodex

ich kann nur Qt empfehlen.
Man kann damit schnell gui's zusammenbauen wenns nichts spezielles seien soll.
Opengl ist auch gut dort zu verbauen.