Plattformunabhängig Programmieren.

[Artchi]

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

[GPC]

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

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