C++ Linux-Windows Kompatiblität

[nathex]

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.

[Fab]

Ein Programm muss doch nicht umbediengt auf Windows laufen
...
Naja im Programmcode müssen je nach dem gar keine Unterschiede zu sehen sein.
Nur in der Executable sind die Unterschiede
... 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

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.

[-[RiDER]-]

Hi

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:

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

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

GreetZ RiDER

[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
Also welche quasi ganz auf Windows und Linux in gleicher Form laufen ...

MFG
Fab

[-[RiDER]-]

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

Inwiefern?

Ich setzte da eher auf plattformübergreifende Libs
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

[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

[-[RiDER]-]

Hi

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?

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!

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

Gewagte Behauptung!

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.

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.

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

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

[-[RiDER]-]

Hi

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.

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?

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

Richtig. Bei C und C++ nicht anders.

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

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

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.

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

[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