C++ Linux-Windows Kompatiblität

Druckbare Version

28.02.2009, 02:46
nathex

C++ Linux-Windows Kompatiblität

Hallo Free-Hacker's,

Habe vor relativ kurzer Zeit angefangen C++ zu lernen. Zur Hilfe habe ich mir das VideoTutorial "Video2Brain" angesehen, um die Grundlagen zu verstehen, und anschließend habe/benutze ich das Buch "C++ von A-Z" um detailliertere Beschreibungen der einzelnen Funktionen zu bekommen.

...Soweit so gut...

Allerdings habe ich mich nun dazu entschieden, in Zukunft unter Linux zu programmieren, da Windows ja nun nicht das wahre ist (meiner Meinung nach).
Mein Problem ist allerdings, dass ich keine Ahnung hab, wie ich ein unter Linux (ubuntu) erstelltes C++ Programm, Windows kompatibel mache.
Ich denke mal, dass da eine Menge Unterschiede im Programm Code sind!

Es wär nett, wenn mir ein etwas Erfahrener C++ Programmieren von euch erklären könnte, wie ich das verwirklichen kann. Weil, was bringt ein Programm das nicht auf Windows läuft :/

Danke schonmal :]
L.G.
28.02.2009, 10:36
Fab

Ein Programm muss doch nicht umbediengt auf Windows laufen :D
...
Naja im Programmcode müssen je nach dem gar keine Unterschiede zu sehen sein.
Nur in der Executable sind die Unterschiede :P
... Wenn du reines ANSI-C++ schreibst und nicht ieine API oder so benutzt.

Also jetzt mal zur Verständlichkeit: C++ ist eine ziemlich hybride Sprache. Das heißt, sie kann mit so ziemlich dem deselben Programmcode unter dem jeweiligen Betriebssystem kompiliert werden. Vorraussetzung dafür ist jedoch, dass du keine OS spezifische Funktionen nutzt. Wenn du z.b. system("Pause"); versuchst unter Linux einzusetzten gibts Fehler :D

Aber ein Programmm wie:

#include <iostream>

int main() {
std::cout << "HelloWorld" << std::endl;
std::cin.sync();
std::cin.get();
return 0;
}

(Ein einfaches HelloWorld)
...würde auf keinem System Probleme beim Kompilieren bereiten.

Wenn du GUIs erstellen willst und die Programme auch auf Windows portieren willst, kannst du aber unter Linux natürlich keine WindowsAPI nutzen.
Ich würde dann z.B. eine Plattformunabghängige GUI-Lib wie wxWidgets nehmen.
Den Code kannste dann auch locker auf Windows kompilieren.

Jetzt kommen wir schon zu einer pikanteren Sache:
Wenn du kein Windows iwie zu verfügung hast und aus Folge dessem deine Programme für Windows unter Linux kompilieren willst, dann brauchste einen Cross-Compiler. (Ich weiß aber nicht wie sehr der in seinen Möglichkeiten eingeschränkt ist ... z.B. ob man damit dann auch unter Linux wxWidgets für Windows kompilieren kann).
Dann musste mal googlen. -> das ist ein etwas komplizierteres Thema.

ODER:

Du holtst dir Wine ... und eine Entwicklungsumgebung ... bzw einen Kompiler für Windows und installierst in auf Linux ... das wäre die einfachste Methode.
Bei mir hat das z.B. super mit Delphi 5 geklappt.
Es wurden einwandfreie GUI Programme für Windows ausgespuckt.
Hol dir aber dann am besten eine einfache IDE ... nicht das neuste Visual Studio ... ich weiß nämlich net, ob das unter Linux nicht Probleme macht, von wegen .Net (Ich weiß net wie Wine damit umgeht und/oder ob Wine sich dann auch Mono bedienen kann).

MFG
Fab
;)

PS: Ich hoffe ich konnte dir helfen. Bei fragen kannste dich ja nochmal melden.
28.02.2009, 13:26
-[RiDER]-

Hi :D

Schau Dir mal das an: http://highscore.de/cpp/einfuehrung/....html#section3, vor allem den Schluss von 8.3.

Ich denke, dass es das ist, was Du suchst.
Ist übrigens die gängigste Methode, Sources für mehrere Systeme kompatibel zu machen (es gibt z.B. noch yacc, flex, bison, m4 usw., aber für normale Zwecke reicht der Präprozessor).

EDiT:

Zitat:

Zitat von Haaaxx

was bringt ein Programm das nicht auf Windows läuft :/

WTF?
Wieso programmierst Du mit dieser Auffassung überhaupt unter Linux?

GreetZ RiDER :D
28.02.2009, 13:38
Fab

Naja ... der Präporozessor ist ganz nützlich ... aber ich mag den iwie nicht.
Finde den ein bisschen zurückgeblieben ... :)
z.B. in D wurde der ganz weggelassen.
Ich setzte da eher auf plattformübergreifende Libs :D
Also welche quasi ganz auf Windows und Linux in gleicher Form laufen ...

MFG
Fab
;)
28.02.2009, 18:33
-[RiDER]-

Zitat:

Zitat von Fab

Naja ... der Präporozessor ist ganz nützlich ... aber ich mag den iwie nicht.
Finde den ein bisschen zurückgeblieben ... :)

Inwiefern?

Zitat:

Zitat von Fab

Ich setzte da eher auf plattformübergreifende Libs :D
Also welche quasi ganz auf Windows und Linux in gleicher Form laufen ...

Sehr gut! :)
Zumal viele dieser Libs auch gleich noch auf MacOS oder *BSD.
Ich denke auch, dass das die eigentlich beste Lösung ist, die man auch anstreben sollte, so man denn kann... z.B. in der Socketprogrammierung wird man ohne Präprozessordirektiven keine lauffähigen portablen Kodes schreiben können.

GreetZ RiDER :D
01.03.2009, 10:54
Fab

Ich finde der Präprozessor integriert sich nicht richtig in die Sprache.
Man kann das alles auch schöner Lösen.
In D wird pragma() wie eine Funktion behandelt ^^
Ich finde das besser. Und davon abgesehen: In D konzentriert man sich viel mehr auf die Hauptsache ... den Kompiler.
Man kann in D sogar plattformunabhängige Socketprogrammierung betreiben.
Das ganze lässt sich dann über ein paar Kompiler Flags lösen.

Ich halte das für die bessere Lösung. Wieso sollte man tausend weitere Programme über den Code laufen lassen. Zumal ich auch noch finde das durch die ganzen #if und wie sie alle heißen, der Code unübersichtlicher wird.
Ich versuche das immer zu umgehen.

MFG
Fab
;)
01.03.2009, 21:54
-[RiDER]-

Hi :D

Zitat:

Zitat von Fab

Ich finde der Präprozessor integriert sich nicht richtig in die Sprache.
Man kann das alles auch schöner Lösen.

Wie ersetzt Du den Verkettungsoperator ##?
Und wie __LINE__ und __FILE__ auf elegantere Weise?

Zitat:

Zitat von Fab

In D wird pragma() wie eine Funktion behandelt ^^

pragma() ist ein Funktion.
Wenn Du an die Direktive #pragma anspielst, gebe ich dir völlig Recht: Dabei handelt es sich um eine äußert schwammig spezifizierte Präprozessordirektive!

Zitat:

Zitat von Fab

In D konzentriert man sich viel mehr auf die Hauptsache ... den Kompiler.

Gewagte Behauptung!

Zitat:

Zitat von Fab

Man kann in D sogar plattformunabhängige Socketprogrammierung betreiben.

Nicht weniger plattformunabhängig, als in C oder C++.
Wenn man eine Waschmaschine (die durchaus in C programmierbar sein kann) als mögliche Plattform betrachtet (und das kann man durchaus!), kannst Du Dir Deine D-Socketprogrammierung in die Haare schmieren. Wo es keine Sockets gibt, kann man auch keine Sockets programmieren.
Einen "ganz normalen Computer" (oder einen sonstige Plattform, die über Sockets verfügt) kannst Du in C oder C++ auch portabel programmieren.

Zitat:

Zitat von Fab

Ich halte das für die bessere Lösung. Wieso sollte man tausend weitere Programme über den Code laufen lassen.

Der Präprozessor ist Bestandteil des Sprachstandards.
Gerade im Rahmen großer Projekte wird heutzutage Kode oft nur noch generiert und nicht mehr mühevoll von Hand programmiert. Da bekommst Du als Programmierer den Kode u.U. garnicht mehr zu Gesicht und es laufen ausschließlich Programme über den Kode.

Zitat:

Zitat von Fab

Zumal ich auch noch finde das durch die ganzen #if und wie sie alle heißen, der Code unübersichtlicher wird.

Wir leben im Zeitalter von Syntaxhighlighting. ;)
Und wo ist der visuelle Vorteil von integrierten inline-Funktionen gegenüber Präprozessormakros?

GreetZ RiDER :D
02.03.2009, 12:57
Fab

Klar
wo keine Sockets sind, da kann man auch net mit Sockets programmieren.
Kannst aber durchaus deine Waschmaschine ins Web hängen ... mit dem ein oder anderen Handgriff geht das ... ein Bekannter hat sich so was für die Heizung gebastelt :D -> Webinterface für die Heitzung.

Mit D kann man aber auf normalen Rechnern, die alle vorraussetzungen für die Socketprogrammierung mitbringen auch ohne weiteres mit Sockets hantieren. Und die dann auch zwischen Linux und Windows, von mir aus auch Mac OS hinund her schieben (also den Code). Das was dann in C++ mit den #if gemacht wird, kann hier durch ein paar Compilerflags gelöst werden.
Was nicht in den Code muss, darauf kann ich auch verzichten. Und Java, C#, Visual Basic brauchen ja auch keinen Präprozessor.
(Ok - haben auch alle ne Laufzeit .... :D )
Fakto ist aber, das in D kein Präprozessor vorhanden ist.
Und wie schon angedeutet - Syntaxhighlighting hin oder her ... der Code soll trotzdem kompakt bleiben ...

MFG
Fab
;)
02.03.2009, 19:48
-[RiDER]-

Hi :D

Zitat:

Zitat von Fab

Mit D kann man aber auf normalen Rechnern, die alle vorraussetzungen für die Socketprogrammierung mitbringen auch ohne weiteres mit Sockets hantieren. Und die dann auch zwischen Linux und Windows, von mir aus auch Mac OS hinund her schieben (also den Code).

Das ist sehr schön, aber kein konkreter Vorteil gegenüber C oder C++, da dies da ebenfalls möglich ist.

Zitat:

Zitat von Fab

Das was dann in C++ mit den #if gemacht wird, kann hier durch ein paar Compilerflags gelöst werden.

Du Du bist der Meinung, dass das komfortabler ist?
Immer ein extra Makefile mitliefern zu müssen, dass die entsprechenden Flags enthält, ist ökonomisch günstiger, als die entsprechenden Inkompatibilitäten direkt im Kode zu lösen?

Zitat:

Zitat von Fab

Was nicht in den Code muss, darauf kann ich auch verzichten.

Richtig. Bei C und C++ nicht anders.

Zitat:

Zitat von Fab

Und Java, C#, Visual Basic brauchen ja auch keinen Präprozessor.

HTML braucht auch keinen.
Ist es deshalb besser als C oder C++?

Zitat:

Zitat von Fab

Fakto ist aber, das in D kein Präprozessor vorhanden ist.

Fakt ist, dass D hier nichts zur Sache tut.

Der OP hat ein Problem in C++ und muss nunmal die ihm gegebenen Mittel nutzen.
Was bringt es also dem OP, dass D keinen Präprozessor hat oder braucht? C++ hat und braucht ihn und hier geht es eben um die konkrete Anwendung dieses Präprozessors.

Natürlich ist es nicht falsch, im Thread entstehende Fragen auch direkt dort zu behandeln, aber dieser Thread verliert den Bezug zum Topic.

Zitat:

Zitat von Fab

Und wie schon angedeutet - Syntaxhighlighting hin oder her ... der Code soll trotzdem kompakt bleiben ...

Das ist richtig. :)
Aber der Präprozessor eröffnet Dir Möglichkeiten, die Dir (in C++) auf andere Weise nicht gegeben sind.
Außer durch weitere zusätzliche Software, die Du ja gerade vermeiden möchtest.

Ich möchte Dir in Deinem Anliegen gar nicht so sehr widersprechen, ich sehe aber den Präprozessor eben nicht als einen der immanenten Nachteile von C und C++ gegenüber anderen Sprachen, die in dieser Sektion übrigens sowieso nichts zu suchen haben.
Wenn wir die Diskussion über D vertiefen möchten, sollten wir vielleicht einen Thread in "C&S -> Sonstige Programmiersprachen" aufmachen.

GreetZ RiDER :D
07.03.2009, 17:23
nathex

Hey und sorry, dass ich mich in der letzten Zeit hier nicht gemeldet habe. Hatte auf Grund unseres Umzuges, bis heute kein Internet.
Erstmal danke an euch beide, für die guten Beschreibungen.
Ich habe auf jeden fall vor, später Programme mit grafischer Oberfläche zu schreiben. Da Consolen-Applikationen bei zu "großen" Programmen einfach unübersichtlich bzw. unschön wirken.
Leider habe ich noch keinerlei Erfahrung in Programmierung mit GUI's... Evtl könntest du, Rider, mir genauer erklären, wie ich mich mit GUI's am besten auseinander setzen könnte. Evtl kennst du ein paar Tutorials oder ähnliches :), da im Video ausschließlich Consolen Programme angesprochen werden und im Buch auch nicht soo genau darauf eingegangen wird.

Danke schonmal...
und das mit dem Programmieren unter Linux werde ich mir evtl nochmal genauer überlegen, da ich ja eigendlich nur Programme für Windows schreiben möchte. Naja ich hatte halt Zweifel bekommen, da viele gesagt haben, dass programmierung unter Linux besser sei.

Gruß nathex
07.03.2009, 18:30
-[RiDER]-

Zitat:

Zitat von nathex

Evtl könntest du, Rider, mir genauer erklären, wie ich mich mit GUI's am besten auseinander setzen könnte. Evtl kennst du ein paar Tutorials oder ähnliches :)

Ich würde mich da Fabs Empfehlung von wxWidgets anschließen.
Oder GTK, Qt, Allegro (letzteres ist etwas unzeitgemäß, aber sehr einfach handhabbar) oder für den absoluten Uralttrend ncurses.

Zitat:

Zitat von nathex

und das mit dem Programmieren unter Linux werde ich mir evtl nochmal genauer überlegen, da ich ja eigendlich nur Programme für Windows schreiben möchte. Naja ich hatte halt Zweifel bekommen, da viele gesagt haben, dass programmierung unter Linux besser sei.

"Besser" ist subjektiv. Für Anfänger solltes kaum entscheidend sein.

GreetZ RiDER :D
07.03.2009, 19:09
nathex

Alles klar, dann seh ich mir das alles mal genauer an. Aber ich hab immernoch das Problem, dass ich nit weiss, wie ich so plötzlich auf Programmierung mit ner GUI umsteigen soll...? Irgendwie scheint der Code im gegensatz zur Konsolen-Programmierung doch ziemlich anders zu sein, oder nit?

Kannst du mir ein paar Tipps geben, wie ich da richtig umsteigen kann? Ich hab bisher nähmlich ausschließlich Consolen-Programme geschrieben :/

L.G

//edit
und kannst du mir direkt einen guten Compiler nennen? :D
Ich benutze im Moment MS Visual Studio 2005... soll aber nicht sehr empfehlenswert sein.
Welches benutzt du, und welches ist gut zur "plattformunabhängigen" Programmierung?

Danke ;)
10.03.2009, 13:36
Fab

So
ich weile wieder unter den Lebenden ...
War leider ne Woche krank.

Visual C++ ist unter Windows in meinen Augen einer der besten Compiler.
Son würde ich halt GNU oder Digitalmars empfehlen.
Die anderen sind nicht so der bringer.

... Intel soll auch ganz gut sein ... kostet aber.
10.03.2009, 20:07
-[RiDER]-

Zitat:

Zitat von Fab

Visual C++ ist unter Windows in meinen Augen einer der besten Compiler.
[...]
... Intel soll auch ganz gut sein ... kostet aber.

Visual C++ kostet nichts?

GreetZ RiDER :D
10.03.2009, 20:32
noctem

Die Express Version von VC++ ist zumindest kostenlos auf der Seite von M$ erhältlich.

Ansonsten den gcc (Linux/Unix) bzw. MinGW, welcher die/den gcc auch unter Windows zur Verfügung stellt.
10.03.2009, 21:24
blackberry

Zitat:

Zitat von noctem

Ansonsten den gcc (Linux/Unix) bzw. MinGW, welcher die/den gcc auch unter Windows zur Verfügung stellt.

Also wenn der Thread doch schon "C++ Linux-Windows Kompatiblität" heißt ist GCC/MinGW32 doch die beste Wahl!
10.03.2009, 21:32
-[RiDER]-

Zitat:

Zitat von BlackBerry

Also wenn der Thread doch schon "C++ Linux-Windows Kompatiblität" heißt ist GCC/MinGW32 doch die beste Wahl!

Naja... wenn man standardkonform bliebe, sollte der Compiler ja eigentlich egal sein...
Aber was sich heute alles C++-Compiler zu nennen erlaubt...

Wobei das bei C++ noch nicht mal ganz so schlimm ist wie bei C99... dafuer gibt es schon genau keinen einzigen Compiler.

Mies, Leute... ganz mies!
GreetZ RiDER
10.03.2009, 21:43
blackberry

Zitat:

Zitat von -[RiDER]-

Naja... wenn man standardkonform bliebe, sollte der Compiler ja eigentlich egal sein...
Aber was sich heute alles C++-Compiler zu nennen erlaubt...

Du wiedersprichst dir ja eigentlich schon wieder mit deinem zweiten Satz.
Mir ist momentan kein Compiler bekannt, der den kompletten Standard unterstützt und wie du ja bereits gesagt hast gibt es viele sehr unkonforme Compiler.
Somit komme ich zu dem Schluss, dass es zwar zugegebener Maßen theoretisch egal sein sollte, das in der Praxis aber nicht der Fall ist.

Und mal ehrlich: wenn du Windows und Linux (bzw. für dich ja eher FreeBSD, oder?) benütztest - zögest du die Kombination Visual C++ & GCC, MinGW32 & GCC vor? Also ich nicht.
Besser man kann mit einem Compiler und dessen Optionen gut umgehen, als mit zwei Compilern schlecht.

mfG. BlackBerry
10.03.2009, 23:16
-[RiDER]-

Zitat:

Zitat von BlackBerry

Und mal ehrlich: wenn du Windows und Linux (bzw. für dich ja eher FreeBSD, oder?)

Auch. Und nicht gerade ungern, das ist richtig. ;)

Zitat:

Zitat von BlackBerry

benütztest - zögest du die Kombination Visual C++ & GCC, MinGW32 & GCC vor?

Nein, gewiss nicht.
Aber wenn sich die Compiler an den Standard hielten, saehe das vllt. anders aus.

Zitat:

Zitat von BlackBerry

Besser man kann mit einem Compiler und dessen Optionen gut umgehen, als mit zwei Compilern schlecht.

Das hat wiederum reichlich wenig mit "C++ Linux-Windows Kompatiblität" zu tun, denn Compileroptionen haben nichts mit der Implementierung der Sprache (gemaess ihrem Standard - von Bibliotheken wollen wir garnicht erst reden) zu tun (insofern das der Standard nicht fordert, und das tut er bei C++ afaik nicht).

Wenn zwei (und zwar nur genau diese zwei) unterschiedliche Compiler auf unterschiedlichen Systemen mit identischem Kode genau identisch umgingen (wobei es ausreichen wuerde, das sie daraus zwei sich identisch verhaltende Programme erstellen wuerden), sich aber von der Bedienung her stark unterschieden, dann sollte das vom Programmierer in Kauf genommen werden.
In der Architektur heisst das "Form follows function". ;)

Aber das gibt es nicht (fuer C++), die Argumentation ist also in diesem Rahmen hinfaellig...
GreetZ RiDER :D