[c++] plattformabhängig - plattformunabhängig??
-
ich habe eine frage zu den verschiedenen plattformen und c++ programmierung: wenn ich standart c++ programmiere kann ich damit auch fenster machen?? sind diese dann plattforumunabghägnig?? oder gehen fesnter nur mit einer art visual c++ unterschiedlich auf jeder plattform?? ich blick da nicht so durch. also was ich eigentlich wissen will: kann ich fenster machen, die plattformunäbhängig funktionieren??
ich hoffe ihr versteht mich
-
Sili schrieb:
ich habe eine frage zu den verschiedenen plattformen und c++ programmierung: wenn ich stan**** c++ programmiere kann ich damit auch fenster machen??
nein, standard C++ kennt keine fenster.
sind diese dann plattforumunabghägnig?? oder gehen fesnter nur mit einer art visual c++ unterschiedlich auf jeder plattform??
es gibt zeimlich paltformaunabhängige gui libs die man benutzen kann z.b. Qt aber ich bin da nich so auf dem laufenden.
ich blick da nicht so durch. also was ich eigentlich wissen will: kann ich fenster machen, die plattformunäbhängig funktionieren??
jein, halt eben wenn du eine gui lib nimmst ist dein programm so plattformunabhängig wie die lib...
-
Der Standard kennt keine Fenster. Diese müssen immer vom entsprechenden Betriebssystem geliefert werden.
Wenn Du da portabel sein willst musst Du versuchen die Benutzeroberfläche vom rest zu trennen so das da nicht allsoviel zu tun ist.
Es gibt aber auch eine Oberfläche die unter linux verwendet wird die mittlerweile auch auf WIndows portiert wird. (so was im gedächnis habe).
100% portabel wirst also nie sein mit Oberflächen.
-
100% portabel bist du nur mit Java
*duck*
-
Es gibt eine Klassen-Sammlung die sich wxWindows nennt, und zimelich viele Klassen mitbringt, die System-unabhängig sind. Wichtig ist eigentlich nur, das wxWindows für die gewünschten Plattformen verfügbar ist. Das sind zur Zeit Windows, Unix, OS/2, MacOSX und Linux.
D.h. um ein Fenster mit Buttons usw. zu erzeugen benutzt du die wxWin-Klassen und compilierst dein Programm für jede gewünschte Plattform einmal - fertig.
Es gibt auch andere Klassen-Sammlungen, wie Qt und GTK, aber mir pers. gefällt wxWin sehr gut. Denn es bringt nicht nur GUI-Klassen mit, sondern auch ODBC (Datenbank-Interface), Socket uvm. mit. Im Gegensatz zu Qt ist es auch kostenlos und im Gegensatz zu Qt und GTK gibt es das nicht nur für Linux und Windows.
-
Doktor Prokt schrieb:
100% portabel bist du nur mit Java
*duck*Durch das ducken wird die Aussage leider nicht richtiger. Statt einer falschen Aussage + ducken, wäre gar keine Aussage sicher besser gewesen
-
@Hume
das *duck* ist denke ich als
aufzufassen (also ironie)@Artchi
GTK und Qt sind nicht nur auf Linux und Windows vorhanden! Aber meine Meinung zu wxWindows kennst du. wxWindows benutzt ein schreckliches (MFC like) Interface und ist riesen groß und bloatig. So weit meine Meinung zu wxWindows.
-
Letztendlich muß sowieso jeder selber das nehmen, was ihm besser gefällt. Solange man die Möglichkeit hat es sich selbst auszusuchen. Und das ist auch ein Vorteil von C++, wie ich finde. Diesen sollten wir hier als C++-Fans auch mal zeigen.
Übrigens ein Vorteil gegenüber Java. OK, für Java gibts neben AWT/Swing mittlerweile die SWT (die sogar native auf das OS zugreift!), aber dann läuft auch dieses nicht mehr auf jeder Java-Plattform, sondern nur auf der es die SWT gibt.
-
danke für eure antworten
ich glaube dann werde ich mit visual c++ beginnen. als tutorial hab ich die onlineversion von visual c++ in 21 tagen, ist die gut?? weiss da einer was??
dazu brauche ich ja ein programm, gibt es das auch gratis oder muss man das kaufen??vielen dank
-
HumeSikkins schrieb:
Doktor Prokt schrieb:
100% portabel bist du nur mit Java
*duck*Durch das ducken wird die Aussage leider nicht richtiger. Statt einer falschen Aussage + ducken, wäre gar keine Aussage sicher besser gewesen
Stimmt, Javacode ist überhaupt nicht portabel. Der Code muss ja nicht portiert werden. Aber man kann mit Java Programme mit Fenstern usw. schreiben, die auf einer Vielzahl von Plattformen ausgeführt werden können. Es muss nur eine JVM installiert sein. Wenn man davon nicht ausgehen kann, kann man ja eine mitliefern.
Für welche Plattformen gibt es JVMs? Naja, ich habe hier mal die JVMs aufgeschrieben, die ich so kenne. Welche GUI-Lib für C++ kann da mithalten?
-
Deshalb mein Beitrag. Es ist völlig offensichtlich, dass Java nicht 100% portabel ist (weder gibt es für jedes Sytem ein JVM, noch läuft Code immer problemlos bei unterschiedlichen Versionen und von Konflikten bei gleichen Versionen auf unterschiedlichen Systemen kann man auch hin und wieder lesen).
Trotzdem kommt natürlich sofort einer angerannt und macht aus dem 100% sofort ein "aber ihr mit eurem scheiß C++ seit auch nicht besser"-Wettkampf.
Das es darum gar nicht geht, spielt ja keine Rolle.Portabilität ist eine Design-Sache. Es erfordert *aktive* Planung. Man bekommt sie nicht geschenkt. Egal ob man Java, C++, D, E, Smalltalk oder C# verwendet.
Insofern sind Aussagen wie "Java ist 100% portabel" schlicht und einfach Müll.Und das ist völlig unabhängig von der Anzahl der vorhandenen JVMs, von der Programmiersprache C++, vom Sternzeichen des Posters und vom Wetter auf Amrum.
-
@Sili
Wenn du mit Visual C++ und der MFC arbeitest (was einem wohl in Visual C++ in 21 Tagen beigebracht wird), dann bist du nicht Platform unabhängig, du bist noch nicht mal wirklich Compiler unabhängig (und das, wenn man hören muss, dass MS die MFC einstellen will).Besorg dir am besten einen kostenlosen Compiler. Für Windows ist der mingw (eine GCC Portierung) wohl sehr gut. Als IDE soll DevC++ sehr gut sein.
Dann lern erstmal C++ Programmieren, bevor du GUI Zeugs oder so was machst
http://www.schornboeck.net/ckurs/index.htm
http://www.volkard.de/vcppkold/inhalt.html
http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
http://www.c-plusplus.net/tutorials.htmund dann kannst du dir Platform unabhängige GUI Librarys angucken
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
-
HumeSikkins schrieb:
Portabilität ist eine Design-Sache. Es erfordert *aktive* Planung. Man bekommt sie nicht geschenkt. Egal ob man Java, C++, D, E, Smalltalk oder C# verwendet.
Das kann ich nicht nachvollziehen. Bei dem Javaprogramm, das ich momentan programmiere, habe ich kein bischen auf "Portabilität" geachtet, trotzdem habe ich es schon ohne Änderungen und ohne Fehler auf Windows, Solaris und Linux laufen lassen. Also: inwiefern soll soetwas am Design liegen? IMHO hängt das eben nicht davon ab, ich denke, Probleme bei einer Portierung liegen am ehesten in Implementierungsdetails, wobei es abhängig von der Sprache ist, wieviele und welche Details man beachten muss.
Naja, ok: Bei C++ ist das etwas anders, da man hier viel mehr auf Bibliotheken von Drittanbietern angewiesen ist. Die Wahl der richtigen Bibliotheken gehört natürlich in den Bereich der Planung. Wolltest du etwa darauf hinaus?
-
Bei dem Javaprogramm, das ich momentan programmiere, habe ich kein bischen auf "Portabilität" geachtet, trotzdem habe ich es schon ohne Änderungen und ohne Fehler auf Windows, Solaris und Linux laufen lassen
Und das heißt was? Ich habe auch schon C++ Programme geschrieben, die auf Windows, Solaris und Linux laufen. Sogar mit Bibliotheken von Drittanbietern (CORBA-Zeugs).
Das macht meine Aussage aber imo nicht falsch. Das heißt ja nur, dass wir beide schon genügend einfache Programme geschrieben habeninwiefern soll soetwas am Design liegen? IMHO hängt das eben nicht davon ab, ich denke, Probleme bei einer Portierung liegen am ehesten in Implementierungsdetails, wobei es abhängig von der Sprache ist, wieviele und welche Details man beachten muss.
Was meinst du genau mit Implementierungsdetails? Und warum designst du die nicht? Design findet doch nicht nur auf konzeptioneller Ebene statt.
Bei C++ ist das etwas anders, da man hier viel mehr auf Bibliotheken von Drittanbietern angewiesen ist. Die Wahl der richtigen Bibliotheken gehört natürlich in den Bereich der Planung. Wolltest du etwa darauf hinaus?
Bei C++ gehört das auf jeden Fall dazu.
Ich meine das aber in der Tat grundsätzlich. Z.B. habe ich in einem der letzten Java-Specialist-Newslettern gelesen, dass es platformabhängige Unterschiede in der Darstellung von modalen Dialogen gibt. Wenn das für eine Anwendung relevant ist, dann muss ich das von beginn an bedenken.
Ein anderes Beispiel ist die unterschiedliche Thread-Implementation auf verschiedenen Platformen. Wenn ich ein bestimmtest Verhalten benötige, dann muss ich das spezifizieren und aktiv dafür sorgen, dass ich es auch erhalte.
-
Sili! VC++ als Compiler und IDE ist i.O. Jedoch solltest du nicht MFC lernen, wenn du portablen GUI-Programme entwickeln willst. Denn VC++-Tutorials lehren meistens die MFC... keine Ahnung warum sie sich immer VC++-Lehrbücher nennen, obwohl sie die MFC lehren.
Die MFC von MS ist auch nur auf den VC++ beschränkt, also selbst in der Windows-Welt kann man keinen anderen Compiler nehmen. Ich pers. benutze VC++6.0 Standard in Kombination mit wxWindows - kein Problem. (vorher hab ich nur MFC programmiert, hab mich aber jetzt in wxWin eingearbeitet)
VC++ kannst du dir bedenkenlos kaufen, ich finde die IDE und Compiler gut. Aber die MFC zu lernen, wenn man Multiplattform entwickeln will, ist Zeitverschwendung. Willst du nur für Windows entwickeln, ist die MFC natürlich i.O.
Wie andere hier aber schon sagten: lern erstmal C++, falls du es noch nicht richtig kannst (hast du uns leider nicht verraten).
-
Artchi schrieb:
Die MFC von MS ist auch nur auf den VC++ beschränkt, also selbst in der Windows-Welt kann man keinen anderen Compiler nehmen.
*seufz*
Doch, der Borland C++ Builder. Der kann auch MFC. Borland hat schon seit jeher die MFC lizenziert und immer mitgeliefert.
-
Gregor schrieb:
Stimmt, Javacode ist überhaupt nicht portabel. Der Code muss ja nicht portiert werden. Aber man kann mit Java Programme mit Fenstern usw. schreiben, die auf einer Vielzahl von Plattformen ausgeführt werden können. Es muss nur eine JVM installiert sein. Wenn man davon nicht ausgehen kann, kann man ja eine mitliefern.
Ach ich weiß nicht. Die Probleme sind vielfältig, und man sieht das auch bei den Client-Anwendungen im Internet. Z.B. bieten viele Anbieter für den Druck von Digitalbildern außer einem Java-Client auch noch einen nativen Windows-Client an, der dann meistens schneller ist und zuverlässiger.
Und ich habe das auch anders selbst erlebt: als ich für ein Java-Buch einige Dinge ausprobieren wollte, habe ich mir die aktuelle VM + JDK geladen und installiert. Alles Prima soweit. Als ich das nächste Mal Online-Banking machen wollte, ging das nicht mehr. Das Applet stürzte mit einer Null-Ptr-Exception ab. Ich konnte erst dann wieder Online-Banking machen, als ich die neue VM (das war wohl .3 Version) deinstallierte und mit der alten weiterfuhr.
Kann ja sein, daß das alles Schuld der Entwickler ist und nicht an Java liegt, aber mir als Kunde ist das eigentlich egal warum es nicht geht, wenn es nicht geht. Es war ein riesiger Akt das wieder richtig hinzubiegen, vor allem weil die Deinstallation nicht problemlos funktionierte.
-
Marc++us schrieb:
Artchi schrieb:
Die MFC von MS ist auch nur auf den VC++ beschränkt, also selbst in der Windows-Welt kann man keinen anderen Compiler nehmen.
*seufz*
Doch, der Borland C++ Builder. Der kann auch MFC. Borland hat schon seit jeher die MFC lizenziert und immer mitgeliefert.
und mit dem Zeta Compiler lassen sich auch MFC PRogramme compilieren
ebenso mit dem von Digital MArs
-
Trotzdem ist die MFC ungeeignet für Platform unabhängigkeit und nebenbei ist sie auch ein teurer Spaß. Wozu sollte ich Geld ausgeben, wenn ich Librarys ihm modernem C++ Design gratis und mit Sourcen bekomme und wo die Librarys nicht in den nächsten Jahren eingestellt wird? Support kann ich auch erhalten, oft sogar kommerzielle Support Verträge.
Gregor schrieb:
Welche GUI-Lib für C++ kann da mithalten?
also wenn ich mir ein Widget System auf SDL Basis nehme oder bastel, bin ich mindestens genauso portabel. Dann nehm ich eben für Thread und Socket Zeugs einfach ACE.
Marc++us schrieb:
Das Applet stürzte mit einer Null-Ptr-Exception ab.
ich dachte in Java gibt es keine Pointer, sondern nur Referenzen und die können ja nicht NULL sein. Das war doch immer das Argument für Java.
-
kingruedi schrieb:
ich dachte in Java gibt es keine Pointer, sondern nur Referenzen und die können ja nicht NULL sein. Das war doch immer das Argument für Java.
DAS war sicherlich nie das Argument für Java. Java-Referenzen können null sein, sie können aber nicht auf Unsinn zeigen.
Als ich das nächste Mal Online-Banking machen wollte, ging das nicht mehr. Das Applet stürzte mit einer Null-Ptr-Exception ab. Ich konnte erst dann wieder Online-Banking machen, als ich die neue VM (das war wohl .3 Version) deinstallierte und mit der alten weiterfuhr.
War das zufällig die VM von MS? AFAIK wurden früher viele Applets genau für diese VM entwickelt. MS hat den Entwicklern und Nutzern da mehr oder weniger vorgegaukelt, dass es sich hierbei um Java handelte, aber die VM war inkompatibel zu Java. Sun hat diesbezüglich gegen MS geklagt und vor Gericht Recht bekommen. Das Resultat: Kein Java mehr von MS, dafür gibt es jetzt .NET!