Plattformunabhängig Programmieren.

[ten]

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:

[CStoll]

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

[Simon2]

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.

[Artchi]

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.

[Gast]

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ä?

[LordJaxom]

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

[Gast]

Das glaube ich mittlerweile auch :p

[ten]

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:

[LordJaxom]

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.

[Simon2]

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.