3. Plattformunabhängig Programmieren.

Plattformunabhängig Programmieren.

  • T

    Hallo,

    ich weiss, dass dieses Thema für mich noch ziemlich früh ist, als Programmieranfänger, aber es interessiert mich eben doch sehr, ausserdem kann es ja vielleicht nicht schaden, es früh zu wissen, um es dann wenn man mal komplexer programmiert, gleich richtig anzufangen(?).

    Als ich danach googelte fand ich so ziemlich zuerst "WXWidgets". Wenn ich es richtig verstehe, ist es so eine Art Runtime Enviroment ähnlich dem von Java, dass dann für das Programm die "natürlichen" Fenster des Betriebssystems bzw unter Linux des Desktop Enviroments übernimmt?

    Ist das denn eigentlich alles, dass man beachten muss, um ein Programm für alle Betriebssysteme nutzbar zu machen? Also eigene Funktionen und nicht auf Betriebssystemfunktionen zurückgreifen + WXWidgtes und fertig?

    Was genau muss man beachten und ist es dem Benutzer nicht zuviel zugemutet, noch eine "virtuelle MAschine" (so es denn eine ist, bei java soll es ja so sein?) zu installieren?

    Mich würde das wirklich interessieren - aber habt bitte nachsicht mit mir da ich Programmierneuling bin (und behaltet im Hinterkopf das ich es nicht sofort benutzen will, also nicht böse sein für die Frage es ist ja nur reines Interesse kein "ich will das sofort können - sofort!)

    Grüße

    Gunnar

    0
  • G

    Hallo,

    ThaRealMatix schrieb:

    Als ich danach googelte fand ich so ziemlich zuerst "WXWidgets". Wenn ich es richtig verstehe, ist es so eine Art Runtime Enviroment ähnlich dem von Java, dass dann für das Programm die "natürlichen" Fenster des Betriebssystems bzw unter Linux des Desktop Enviroments übernimmt?

    Nein, wxWidgets ist ein Framework mit dessen Hilfe man Applikationen schreiben kann. Es beinhaltet u.a. GUI, Netzwerk, Sounds und noch 'n paar Sachen mehr. Allerdings stimmt es, dass wxWidgets Applikationen immer den nativen Look 'n Feel der Plattform annehmen.

    Ist das denn eigentlich alles, dass man beachten muss, um ein Programm für alle Betriebssysteme nutzbar zu machen? Also eigene Funktionen und nicht auf Betriebssystemfunktionen zurückgreifen + WXWidgtes und fertig?

    Prinzipiell ja. Solange du dich von Betriebssystemfunktionen fernhältst und nur wxWidgets oder die GTK Libs verwendest, ist dein Leben relativ sorgenfrei.

    Was genau muss man beachten und ist es dem Benutzer nicht zuviel zugemutet, noch eine "virtuelle MAschine" (so es denn eine ist, bei java soll es ja so sein?) zu installieren?

    Entfällt bei C++ Programmen. Das einzige was man da mal mitliefern muss, ist eine dynamische Bibliothek (dll auf Windows, so unter GNU/Linux).

    MfG

    GPC

    0
  • T

    Hm, also kann das ganze Ohne Mehraufwand oder große Zusatzinstallation von "Extra Paketen" auf jedem System ausgeführt werden? dlls werden ja von vielen Programmen mitgeliefert.

    Es tut mir leid, ich kenne zwar den Begriff Framework, ich schätze inzwischen haben die meisten das .Net Framework installiert weil irgendein Programm es eh braucht. Aber so wirklich verstanden habe ich es nie, speziell wieso Microsoft ein Framework für seine eigenes Betriebssystem liefern muss, wenn es doch alles bereits haben müsste?

    0
  • S

    Hi,

    ein klein wenig mehr gibt es schon noch zu beachten für plattformunabhängige Entwicklung. Für Vieles gibt es dazu Teile im Standard (numeric_limits, locales, (w)char-Unterstützung, ....), aber man muss sie auch konsequent anwenden. Und im realen Leben hat man dann doch schnell mal was geschrieben, was implizit
    - ASCII voraussetzt oder
    - eine bestimmte Byterepräsentation von long oder
    - eine bestimmte Form, eine Klasse aufzubauen oder
    - eine Dateinamenskonvention oder
    ....
    Außerdem kann man leider in der Realität nicht auf jeder Plattform dieselbe "Standardunterstützung" voraussetzen.

    Und spätestens, wenn man multithreaded arbeiten will oder mit anderen Programm(-iersprach-)en kommuniziert, muss man sich schon sehr die Finger brechen bzw. Abstriche machen (d.h. nicht mehr absolut plattformunabhängig programmieren, sondern nur noch so, dass die Plattformen A, B und C unterstützt werden).

    Ich will Dir damit nicht den Elan nehmen, sondern nur meine Erfahrungen als leidgeprüfter AIX/OS2/zOS-Programmierer (in C) mitteilen....

    Gruß,

    Simon2.

    0
  • A

    GPC hat das wichtigste gesagt. Hier meine weiteren Hinweise:

    Was meinst du, was std::cout macht? cout ist ein Library-Objekt. Im Inneren von cout wird je nach Platform (Linux, Windows usw.) eine Platform-abhängige Funktion für Textausgabe aufgerufen. cout wrappet letztendlich diese Funktion für dich. Du könntest die spezielle Windows-Funktion auch direkt aufrufen, dann wäre dein Programm nicht platformunabhängig.

    Wenn du gezielt nur Wrapper benutzt oder auch selber schreibst, die platformspezifische Funktionen aufrufen, ist dein Programm platformunabhängig. Du tauschst dann nur immer die Wrapper aus. Z.B. benutzt du unter Windows eine andere Standard-Library-Implementierung als unter Linux. Wichtig ist, das beide Implementierungen std::cout anbieten.

    http://www.boost.org hat z.B. einige Libraries, die System-Funktionen wrappen.

    wxWidgets ist eine weite Library, die diesen Zweck erfüllt.

    Sowas wie eine VM wie JavaVM bruahct man nicht für C++.

    0
  • A

    ThaRealMatix schrieb:

    Hm, also kann das ganze Ohne Mehraufwand oder große Zusatzinstallation von "Extra Paketen" auf jedem System ausgeführt werden? dlls werden ja von vielen Programmen mitgeliefert.

    Es tut mir leid, ich kenne zwar den Begriff Framework, ich schätze inzwischen haben die meisten das .Net Framework installiert weil irgendein Programm es eh braucht. Aber so wirklich verstanden habe ich es nie, speziell wieso Microsoft ein Framework für seine eigenes Betriebssystem liefern muss, wenn es doch alles bereits haben müsste?

    Microsoft hat nicht DAS Framework erfunden. Genauso wenig wie das Internet! 😉 Wir reden hier vom allgemeinen Fachbegriff "Framework". .NET-Framework ist dagegen eher ein Markenbegriff für ein Produkt. Aber Framework ist ein Begriff wie "Flugzeug" und nicht "Airbus 380".

    GPC hat nicht im geringsten an das .NET-Framework gedacht! Sondern daran: http://de.wikipedia.org/wiki/Framework

    0
  • G

    ThaRealMatix schrieb:

    Hm, also kann das ganze Ohne Mehraufwand oder große Zusatzinstallation von "Extra Paketen" auf jedem System ausgeführt werden?

    Bis zu einem gewissen Punkt: Im Normalfall ja.

    Es tut mir leid, ich kenne zwar den Begriff Framework, ich schätze inzwischen haben die meisten das .Net Framework installiert weil irgendein Programm es eh braucht.

    Also ein Framework kann man vereinfacht als eine Art Sammlung von Bibliotheken verstehen, die einem beim Entwickeln von Applikationen ein Gerüst vorgeben. Siehe auch wikipedia für nähere Infos.

    Aber so wirklich verstanden habe ich es nie, speziell wieso Microsoft ein Framework für seine eigenes Betriebssystem liefern muss, wenn es doch alles bereits haben müsste?

    Ne, .NET ist ja eine ganz andere Abstraktionsschicht. .NET kapselt und erweitert die WinAPI (die native Windows-Bibliothek, die in C geschrieben ist), um ein einfacheres und schnelleres Programmiermodell anbieten zu können.
    Dass eine VM benötigt wird, liegt halt am Design und Konzept von .NET.

    Simon2 schrieb:

    Und im realen Leben hat man dann doch schnell mal was geschrieben, was implizit
    - ASCII voraussetzt oder
    - eine bestimmte Byterepräsentation von long oder
    - eine bestimmte Form, eine Klasse aufzubauen oder
    - eine Dateinamenskonvention oder

    Das meiste dürfte sich mit GTK oder spätestens boost erledigt haben (auf den verbreiteten Plattformen).

    Außerdem kann man leider in der Realität nicht auf jeder Plattform dieselbe "Standardunterstützung" voraussetzen.

    Das ist richtig, evtl. empfiehlt Jürgen Wolf aus diesem Grund auch GTK-Lösungen anstatt Standardfunktionen zu verwenden, um möglichst portabel zu sein.

    Und spätestens, wenn man multithreaded arbeiten will oder mit anderen Programm(-iersprach-)en kommuniziert, muss man sich schon sehr die Finger brechen bzw. Abstriche machen (d.h. nicht mehr absolut plattformunabhängig programmieren, sondern nur noch so, dass die Plattformen A, B und C unterstützt werden).

    Richtig, aber totale Plattformunabhängigkeit gibt's eh nicht.

    meine Erfahrungen als leidgeprüfter AIX/OS2/zOS-Programmierer (in C) mitteilen....

    Hui, da hat aber einer die bitteren Pillen schlucken müssen^^
    *selber froh ist, auf x86 entwickeln zu dürfen*

    EDIT: Rechtschreibfehler

    MfG

    GPC

    0
  • T

    Simon2 schrieb:

    ein klein wenig mehr gibt es schon noch zu beachten für plattformunabhängige Entwicklung. Für Vieles gibt es dazu Teile im Standard (numeric_limits, locales, (w)char-Unterstützung, ....), aber man muss sie auch konsequent anwenden. Und im realen Leben hat man dann doch schnell mal was geschrieben, was implizit
    - ASCII voraussetzt oder
    - eine bestimmte Byterepräsentation von long oder
    - eine bestimmte Form, eine Klasse aufzubauen oder
    - eine Dateinamenskonvention oder
    ....
    Außerdem kann man leider in der Realität nicht auf jeder Plattform dieselbe "Standardunterstützung" voraussetzen.

    Und spätestens, wenn man multithreaded arbeiten will oder mit anderen Programm(-iersprach-)en kommuniziert, muss man sich schon sehr die Finger brechen bzw. Abstriche machen (d.h. nicht mehr absolut plattformunabhängig programmieren, sondern nur noch so, dass die Plattformen A, B und C unterstützt werden).

    hi,
    und gerade aus diesen gründen gibt es eben die 'virtual machine' umgebungen oder reine interpretersprachen. wenn plattformunabhängigkeit absolut im vordergrund steht, dann gilt: finger weg von C oder C++!
    :xmas2:

    0
  • C

    ten schrieb:

    und gerade aus diesen gründen gibt es eben die 'virtual machine' umgebungen oder reine interpretersprachen. wenn plattformunabhängigkeit absolut im vordergrund steht, dann gilt: finger weg von C oder C++!
    :xmas2:

    Aber Interpreter- oder VM-Sprachen sind genauso eingeschränkt in der Plattformunabhängigkeit wie Compiler-Sprachen (wenn ich keine VM für die Plattform xyz habe, kann ich meine Java-Programme auf einem xyz-Computer nicht verwenden).

    0
  • S

    ten schrieb:

    ...
    hi,
    und gerade aus diesen gründen gibt es eben die 'virtual machine' umgebungen oder reine interpretersprachen. wenn plattformunabhängigkeit absolut im vordergrund steht, dann gilt: finger weg von C oder C++!
    :xmas2:

    Ja, aus diesem Grunde gibt es sie .... aber ob sie das geringer Übel sind, muß jeder selbst entscheiden (ich habe in C/C++ viel schneller plattformunabhängig programmiert als Du auf 400 PCs die richtige VM installiert 😉 ).
    Auch hier gilt: Für den jeweiligen Anwendungszweck entscheiden, welche Lösung besser ist.

    Gruß,

    Simon2.

    0
  • A

    Die Schwierigkeiten, die Simon2 aufgeführt hat, sind ja nicht mit einer VM oder Sprache wie Java aus der Welt gesachafft! Teilweise sogar genau gleich wie in C++, teilweise einfach weggeblendet:

    - ASCII voraussetzt oder

    Ehm: PP (Persönliches Pech) 😃

    - eine bestimmte Byterepräsentation von long oder

    Interessiert selten, und wenn doch, dann weiß ich als C++ler (ja!), das ich mir ein Typedef mache. In Java dagegen muß ich notfalls Refactoring betreiben, wenn mir long nicht ausreicht. Auch nicht besser.

    - eine bestimmte Form, eine Klasse aufzubauen oder

    Weiß ich ich nicht was du damit meinst.

    - eine Dateinamenskonvention oder

    Die Probleme habe ich in Java auch. Ist nicht besser/anders gelöst, als wenn ich z.B. Boost.Filesystem nehme. Wenn ich auf Pathname-Ebene systemunabhängig sein will, gibt es in C++ Lösungen.

    In Java werden mir z.B. teilweise einfach die Hände gebunden, damit ich etwas nicht machen kann. Ist das die bessere Lösung? Einfach jemanden hindern, etwas zu machen? In C++ kann ich mich selber daran hindern. Siehe auch ASCII-Problematik oder Pathnames.

    0
  • ?

    Artchi schrieb:

    - eine bestimmte Byterepräsentation von long oder

    Interessiert selten, und wenn doch, dann weiß ich als C++ler (ja!), das ich mir ein Typedef mache. In Java dagegen muß ich notfalls Refactoring betreiben, wenn mir long nicht ausreicht. Auch nicht besser.

    Hä?

    0
  • L

    Ich glaube die beiden haben eine unterschiedliche Definition von "Byterepräsentation" 😉

    0
  • ?

    Das glaube ich mittlerweile auch :p

    0
  • T

    TactX schrieb:

    Artchi schrieb:

    - eine bestimmte Byterepräsentation von long oder

    Interessiert selten, und wenn doch, dann weiß ich als C++ler (ja!), das ich mir ein Typedef mache. In Java dagegen muß ich notfalls Refactoring betreiben, wenn mir long nicht ausreicht. Auch nicht besser.

    Hä?

    artchi ist java-coder. in java ist der interne aufbau von datentypen kein thema. damit müssen sich nur wir armseligen c/c++ -würstchen rumärgern...
    :xmas2:

    0
  • L

    ten schrieb:

    artchi ist java-coder. in java ist der interne aufbau von datentypen kein thema. damit müssen sich nur wir armseligen c/c++ -würstchen rumärgern...
    :xmas2:

    Müssen wir? Wenn mans richtig macht eigentlich nicht 😉
    Mit Cross-Language-Aufrufen hatte ich bisher selten Probleme (und wenn war COBOL im Spiel), und Bytestreams werden eh Byteweise interpretiert, da zählt eh die Ausrichtung die in den Specs steht.

    0
  • S

    Hi,

    nur zur Klärung:
    - Ich halte die "Plattformunabhängigkeit von Java" für einen ziemlich überhypten Popanz (wo ist denn der Javabytecode wirklich portabler als der C++-Source ?). Es gibt ein paar kleinere Vorteile, aber nichts wirklich Prinzipielles. Mitnichten wollte ich sie als der von C++ überlegen darstellen.
    - Mit der "Byterepräsentation" hat man z.B. bei Interlanguage-calls und "Serialisierung" (z.B. auf Platte oder in Protokolle) zu kämpfen. Da rutscht schnell mal ein BigEndian/LittleEndian- oder ein Padding-Problem rein, wenn man nicht aufpasst.
    Vielleicht trifft mich das auch mehr, weil wir halt sehr viel stärker "Byte-Kram" und für sehr unterschiedliche Plattform(-anforderung-)en programmieren ... da mussten wir uns ein recht enges Korsett anlegen (in den ersten paar Jahren war selbst dynamische Speicherverwaltung verboten, weil die zOS-Runtime da einen Bug hatte, der sich nicht mit dem Transaktionsumfeld vertrug)....

    Gruß,

    Simon2.

    0
Anmelden zum Antworten