ein object auf die festplatte schreiben?

Simon2

hahaha. schrieb:

Das hat doch keinen Sinn was du da machst. Du tust so als ob eine virtuelle Maschine und eine echte Hardware das gleiche wären, nur weil er es Maschine genannt hat.

Worin soll der Unterschied Deiner Meinung nach bestehen?
Was hindert mich daran, eine Java-Hardware zu bauen? Oder einen x86-Emulator auf einer anderen Plattform ?
Auf welcher anderen Plattform als der JavaVM funktioniert Java (bzw. die Serialisierung, um die es hier geht) plattformunabhängig?

Gruß,

Simon2.

Simon2

Tobiking2 schrieb:

...Immerhin gibt es unterschiedliche Virtuelle Maschinen. ...

...und zwischen denen sind Binärcode und serialisierte Daten beliebig austauschbar?

Ich will hier gar kein Java-Bashing betreiben (anscheinend ein Eindruck, der Java-Fanboys aus den Löchern und auf die Palmen getrieben hat ) - Java ist für viele reale Projekte die bessere Wahl. Aber ein Teil ihrer Stärke ist IMHO gerade durch die Bindung an eine konkrete VM gegeben.
... und ein Teil der Nachteile von C++ gerade dadurch, dass es sich NICHT auf eine Plattform festlegt.

(In anderen Projekten sind das dann eben gerade die Schwäche von Java und die Stärke von C++)

Gruß,

Simon2.

Simon2 schrieb:

hahaha. schrieb:

Das hat doch keinen Sinn was du da machst. Du tust so als ob eine virtuelle Maschine und eine echte Hardware das gleiche wären, nur weil er es Maschine genannt hat.

Worin soll der Unterschied Deiner Meinung nach bestehen?
Was hindert mich daran, eine Java-Hardware zu bauen?...

http://de.wikipedia.org/wiki/Virtuelle_Maschine schrieb:

Eine virtuelle Maschine, kurz VM, ist ein virtueller Computer. Eine solche Maschine besteht nicht aus Hardware, sondern aus Software.

Dein Vergleich basiert auf einem flaschen Verständnis von VM.

audacia

Simon2 schrieb:

Auf welcher anderen Plattform als der JavaVM funktioniert Java

CLR, mit Einschränkungen.

Simon2 schrieb:

(bzw. die Serialisierung, um die es hier geht)

Gewöhnliche Java-Serialisierung vielleicht nicht, aber wenn du z.B. XStream benutzt, bekommst du wunderbar plattformunabhängiges XML. Und für Größeres benutzt man ohnehin Hibernate o.ä..

Simon2 schrieb:

... und ein Teil der Nachteile von C++ gerade dadurch, dass es sich NICHT auf eine Plattform festlegt.

Ganz richtig. Allerdings ist Plattformneutralität keine Rechtfertigung dafür, daß C++ nicht einmal die Ansätze eines Reflection-Mechanismus bietet.

Michael E.

BTT: Zum Einlesen der Dateien und Erzeugen der Objekte gebe ich dir die Stichwörter virtueller Konstruktor und Abstract Factory.

Simon2

audacia schrieb:

Simon2 schrieb:

Auf welcher anderen Plattform als der JavaVM funktioniert Java

CLR, mit Einschränkungen....

Da hast Du aber das wesentliche Attribut in meiner Aussage unterschlagen.

audacia schrieb:

...

Simon2 schrieb:

(bzw. die Serialisierung, um die es hier geht)

Gewöhnliche Java-Serialisierung vielleicht nicht, aber wenn du z.B. XStream benutzt, bekommst du wunderbar plattformunabhängiges XML. Und für Größeres benutzt man ohnehin Hibernate o.ä...

Ich spreche hier allerdings von der Sprache selbst und nicht von irgendwelchen Bibliotheken. In C++ kann ich mein Objekt auch in XML-Serialisieren und dann habe ich es "plötzlich" plattformunabhängig.
(Natürlich habe ich es in C++ mangels Reflection schwerer, im Resultat bleibt es aber dasselbe).

audacia schrieb:

...Allerdings ist Plattformneutralität keine Rechtfertigung dafür, daß C++ nicht einmal die Ansätze eines Reflection-Mechanismus bietet.

Ich habe nie von einer "Rechtfertigung" gesprochen und würde es auch nicht wollen. Ich glaube aber, dass es deutlich schwerer ist, Reflection vollkommen ohne Bezug auf ein konkretes Darstellungsformat zu definieren. Ob das der Grund für das Fehlen von Reflection in C++ ist oder das ganz andere Ursachen hat (z.B. eine Paradigmengrenze), weiß ich aber nicht.

Wie schon oben geschrieben:

Simon2 schrieb:

...Nichtsdestotrotz ist C++-RTTI natürlich meilenweit hinter Java-Reflection zurück (auch wenn ich persönlich sie noch nie vermisst habe) und IMHO hätte es C++ gut getan, trotzdem eine ABI zu definieren - am besten als Option....

Gruß,

Simon2.

Simon2

hahaha. schrieb:

Simon2 schrieb:

hahaha. schrieb:

Das hat doch keinen Sinn was du da machst. Du tust so als ob eine virtuelle Maschine und eine echte Hardware das gleiche wären, nur weil er es Maschine genannt hat.

Worin soll der Unterschied Deiner Meinung nach bestehen?
Was hindert mich daran, eine Java-Hardware zu bauen?...

http://de.wikipedia.org/wiki/Virtuelle_Maschine schrieb:

Eine virtuelle Maschine, kurz VM, ist ein virtueller Computer. Eine solche Maschine besteht nicht aus Hardware, sondern aus Software.

Dein Vergleich basiert auf einem flaschen Verständnis von VM.

Du meinst also, in dem Augenblick, in dem ich eine Java-VM in Hardware gieße, funktioniert Java nicht mehr?
Ist in Java irgendwo festgelegt, dass es eine "Software-Emulationsschicht" geben muss?

Ich glaube, Du hast hier "Definitionsrichtungen" vermischt:
- Wenn jemand fragt: "Was ist denn eine VM?", ist er mit Deinem Artikel bestens bedient.
- Wenn jemand fragt: "In welcher Umgebung läuft denn Java?", bringt er nicht weiter.

Gruß,

Simon2.

audacia

Simon2 schrieb:

audacia schrieb:

Simon2 schrieb:

Auf welcher anderen Plattform als der JavaVM funktioniert Java

CLR, mit Einschränkungen....

Da hast Du aber das wesentliche Attribut in meiner Aussage unterschlagen.

Es war so verlockend

Simon2 schrieb:

audacia schrieb:

...

Simon2 schrieb:

(bzw. die Serialisierung, um die es hier geht)

Gewöhnliche Java-Serialisierung vielleicht nicht, aber wenn du z.B. XStream benutzt, bekommst du wunderbar plattformunabhängiges XML. Und für Größeres benutzt man ohnehin Hibernate o.ä...

Ich spreche hier allerdings von der Sprache selbst und nicht von irgendwelchen Bibliotheken.

Die Sprache selbst bietet überhaupt keine Serialisierungsmechanismen; das sind alles Library-Features, die sich auf ein wesentliches Sprachfeature stützen, namentlich Reflection. Ob du nun den in der Java-Bibliothek mitgelieferten Serialisierungsmechanismus oder eine externe Bibliothek wie XStream benutzt, macht da keinen Unterschied.

Simon2 schrieb:

In C++ kann ich mein Objekt auch in XML-Serialisieren und dann habe ich es "plötzlich" plattformunabhängig.
(Natürlich habe ich es in C++ mangels Reflection schwerer, im Resultat bleibt es aber dasselbe).

Plattformunabhängigkeit ist nur ein Implementationsaspekt einer Persistenz-Bibliothzek. Der Unterschied zwischen Java und C++ ist hier lediglich, daß du in C++ den Code für die Abbildung eines Objektes selbst schreiben mußt, in Java hingegen nicht. Punctum.

Simon2 schrieb:

tntnet schrieb:

...C++ ist, wie bereits erwähnt näher an der Maschine mit allen seinen Vor- und Nachteilen. ...

Ich empfinde es genau anders herum: Während Java ganz eng mit seiner (virtuellen) Maschine verheiratet ist, ist C++ ein maschinenunabhängiger Sprachstandard. Deswegen kann die Objektpräsentation auf den unterschiedlichen Plattformen variieren und tut das auch.

Simon2 schrieb:

hahaha. schrieb:

Simon2 schrieb:

hahaha. schrieb:

Das hat doch keinen Sinn was du da machst. Du tust so als ob eine virtuelle Maschine und eine echte Hardware das gleiche wären, nur weil er es Maschine genannt hat.

Worin soll der Unterschied Deiner Meinung nach bestehen?
Was hindert mich daran, eine Java-Hardware zu bauen?...

http://de.wikipedia.org/wiki/Virtuelle_Maschine schrieb:

Eine virtuelle Maschine, kurz VM, ist ein virtueller Computer. Eine solche Maschine besteht nicht aus Hardware, sondern aus Software.

Dein Vergleich basiert auf einem flaschen Verständnis von VM.

Du meinst also, in dem Augenblick, in dem ich eine Java-VM in Hardware gieße, funktioniert Java nicht mehr?
Ist in Java irgendwo festgelegt, dass es eine "Software-Emulationsschicht" geben muss?

Ich glaube, Du hast hier "Definitionsrichtungen" vermischt:
- Wenn jemand fragt: "Was ist denn eine VM?", ist er mit Deinem Artikel bestens bedient.
- Wenn jemand fragt: "In welcher Umgebung läuft denn Java?", bringt er nicht weiter.

Wo war da jetzt was von "wo läuft Java" bei deinem Vergleich?
Du hast einfach so getan, als ob die Maschinennähe von C++ irgendwie was mit VMs zu tun hätte.

Und C++ ist maschinennah, auch wenn du da wieder eine eigene andere Definition von maschinennah hast.

http://de.wikipedia.org/w schrieb:

C++ ermöglicht sowohl die effiziente und maschinennahe Programmierung,...

Du hast irgendwie ne Menge an eigenen Definitionen, die nicht so ganz zu den allgemeinen passen.

Simon2

hahaha. schrieb:

...Wo war da jetzt was von "wo läuft Java" bei deinem Vergleich?...

Läuft Java denn nicht in einer "Java-VM"?
Ist nicht die komplette Java-Entwicklung daraufhin ausgelegt, in einer solchen zu laufen?
Bezieht Java nicht seine wesestlichen Vorteile aus dieser Tatsache?

Mehr habe ich nicht behauptet und genau daraum dreht sich diese ganze Subdiskussion: "Wo laufen Java-Programme? -> in einer JavaVM"
Die These, die JavaVM sei keine Maschine, kommt von Dir.

hahaha. schrieb:

...Und C++ ist maschinennah, ...

http://de.wikipedia.org/w schrieb:

C++ ermöglicht sowohl die effiziente und maschinennahe Programmierung,...

...

Deine Aussage steht aber gar nicht im Wikipedia-Zitat.
In C++ ist selbst ein "Byte" plattformunabhängig definiert ... auch ansonsten gibt es so gut wie keine Maschinenspezifika (ein wenig über Locales, Zeitzonen, In-/Output-Streams, ...). Da ist gar nichts "maschinennah".

Ich habe eher den Eindruck, dass Du Deinen recht eingeschränkten Begriff von "Maschine" (inkl. den Managementvorstellungen zum Thema "maschinennah" und "plattformunabhängig") zum Maß aller Dinge erheben möchtest.

Gruß,

Simon2.

P.S.: Das kann natürlich alles nur ein gräßlicher Irrtum von mir sein und Du bist in Wirklichkeit eine große Koryphäe ... aber wenn hier ein Unregistrierter mit einem "Spontannamen" und Post einsteigt, die Provokation in den Mittelpunkt stellen und dann außer ein paar halbgaren Wiki-Halbsätzen nichts beiträgt, habe ich kaum eine Chance, das zu erkennen.

Simon2

audacia schrieb:

...Der Unterschied zwischen Java und C++ ist hier lediglich, daß du in C++ den Code für die Abbildung eines Objektes selbst schreiben mußt, in Java hingegen nicht...

Wie ich schon schrob: 100% meine Meinung.

OT:

audacia schrieb:

...Punctum.

Eigentlich finde ich es unglaublich arrogant, wenn jemand nach seiner These die Diskussion für beendet erklärt .... auch, wenn sich das leider in INetforen so eingebürgert hat.
Aber ich gehe mal davon aus, dass Du das nicht böse meinst. PUNKT!

Gruß,

Simon2.

Tachyon

Simon2 schrieb:

[...]Nichtsdestotrotz ist C++-RTTI natürlich meilenweit hinter Java-Reflection zurück[...]

Dabei könnte das Leben deutlich einfacher sein, wenn RTTI wenigstens zum Teil plattformanabhängige Informationen liefern würde. Wenn type_name z.B. immer scope::T liefern würde. So wie es im Moment im Standard definiert ist, kann man es fast nicht gebrauchen.

Dravere

@Simon2,
Verwechselst du nicht zwei Dinge?
Der Maschine nah <-> An die Maschine gebunden

Eine Sprache kann nahe an einer Maschine sein, ist aber nicht an eine Maschine gebunden.
Eine Sprache kann an eine Maschine gebunden sein, muss aber nicht nahe an der Maschine sein.

Grüssli

Simon2

Dravere schrieb:

@Simon2,
Verwechselst du nicht zwei Dinge?
Der Maschine nah <-> An die Maschine gebunden...

Kann sein, dass da eine Differenzierung sinnvoll sein kann.
Allerdings habe ich (wenn ich mich recht entsinne) den Begriff der "Maschinennähe" gar nicht ins Spiel gebracht, sondern hahaha... und das auch nur aus der (richtigen aber in den falschen Zusammenhang gerückten) Wiki-Aussage, dass C++ maschinennahe Programmierung ermögliche.

Ich habe nicht einmal behauptet, dass irgendeine Sprache an eine Maschine "gebunden" (im Sinne von "untrennbar eineindeutig") sei, sondern lediglich "verheiratet" ... meinte damit: Eng verknüpft.
Meine Kernaussage war: In Java gibt's ein ABI (für eine bestimmte Plattform) und es ist der Standardfall ... in C++ gibt's gar kein ABI.
Und: Mit ABI wird Reflection deutlich einfacher ... und mit beiden zusammen Serialisierung erst Recht.

Gruß,

Simon2.

Dravere

Simon2 schrieb:

Kann sein, dass da eine Differenzierung sinnvoll sein kann.
Allerdings habe ich (wenn ich mich recht entsinne) den Begriff der "Maschinennähe" gar nicht ins Spiel gebracht, sondern hahaha... und das auch nur aus der (richtigen aber in den falschen Zusammenhang gerückten) Wiki-Aussage, dass C++ maschinennahe Programmierung ermögliche.

Nein, tntnet hat es getan und du hast ihm widersprochen (erste Seite):

Simon2 schrieb:

tntnet schrieb:

...C++ ist, wie bereits erwähnt näher an der Maschine mit allen seinen Vor- und Nachteilen. ...

Ich empfinde es genau anders herum: Während Java ganz eng mit seiner (virtuellen) Maschine verheiratet ist, ist C++ ein maschinenunabhängiger Sprachstandard. Deswegen kann die Objektpräsentation auf den unterschiedlichen Plattformen variieren und tut das auch.

Du hast das "näher an der Maschine" von tntnet mit gebunden, bzw. eng verheiratet, gleichgesetzt. Das ist meiner Meinung nach eine falsche Schlussfolgerung.

Grüssli

Simon2 schrieb:

hahaha. schrieb:

...Und C++ ist maschinennah, ...

http://de.wikipedia.org/w schrieb:

C++ ermöglicht sowohl die effiziente und maschinennahe Programmierung,...

...

Deine Aussage steht aber gar nicht im Wikipedia-Zitat.

Der link wurde abgeschnitten
http://de.wikipedia.org/wiki/C%2B%2B

Simon2 schrieb:

Dravere schrieb:

@Simon2,
Verwechselst du nicht zwei Dinge?
Der Maschine nah <-> An die Maschine gebunden...

Kann sein, dass da eine Differenzierung sinnvoll sein kann.
Allerdings habe ich (wenn ich mich recht entsinne) den Begriff der "Maschinennähe" gar nicht ins Spiel gebracht, sondern hahaha...

So.

Simon2 schrieb:

tntnet schrieb:

...C++ ist, wie bereits erwähnt näher an der Maschine mit allen seinen Vor- und Nachteilen. ...

Ich empfinde es genau anders herum: ...

Dann hast du wohl gemeint, dass tntnet mit "näher an der Maschine" auch dein komisches "verheiratet" meint.

Badestrand

Man könnte fast meinen, ihr versteht euch absichtlich falsch

Ansonsten sehe ich's so wie Simon: Java basiert auf VM und Bytecode, C++ legt sich auf absolut nix fest, schwebt haltlos im Raum; womit Java enger verbunden ist mit der/einer Maschine.

Simon2

hahaha. schrieb:

Simon2 schrieb:

hahaha. schrieb:

...Und C++ ist maschinennah, ...

http://de.wikipedia.org/w schrieb:

C++ ermöglicht sowohl die effiziente und maschinennahe Programmierung,...

...

Deine Aussage steht aber gar nicht im Wikipedia-Zitat.

Der link wurde abgeschnitten
http://de.wikipedia.org/wiki/C%2B%2B...

ähhh ... ich hatte schon den richtigen Artikel.
Da steht lediglich, dass C++ "maschinennahe Programmierung ermöglicht", nicht, dass C++ maschinennah sei.

Dravere schrieb:

...
...Du hast das "näher an der Maschine" von tntnet mit gebunden, bzw. eng verheiratet, gleichgesetzt. Das ist meiner Meinung nach eine falsche Schlussfolgerung....

Das stimmt.
Da hatte ich tntnet wohl mißverstanden.
Nichtdestotrotz sehe ich
- weder, wo C++ maschinennah
- noch, wo es auf eine Plattform festgelegt sei.
(wie gesagt: Der gesamte Standard abstrahiert extrem von der Laufzeitplattform)
Was ich schon sehe ist, dass C++ Sprachmittel bereitstellt, die sich gut in (bestimmte) native Plattformmechanismen übersetzen lassen ... und deshalb das Schreiben "maschinennaher Programme" (will sagen: Programmstruktur im Source ähnelt der Ablaufstruktur innerhalb der Plattform) ermöglicht.
So wie C++ auch templates zur Verfügung stellt, aber deshalb noch keine "template-Sprache ist".

Bei Java sehe ich da eine engere Verbindung.
Nicht zuletzt spiegelt sogar der Bytecode (= der "Maschinencode") immer noch sehr viel von der Sourcestruktur wieder (was ja Reflection vereinfacht) ...

Badestrand schrieb:

Man könnte fast meinen, ihr versteht euch absichtlich falsch ...

Den Eindruck habe ich langsam auch.

Badestrand schrieb:

...
Ansonsten sehe ich's so wie Simon: Java basiert auf VM und Bytecode, C++ legt sich auf absolut nix fest, schwebt haltlos im Raum; womit Java enger verbunden ist mit der/einer Maschine.

Danke.

Gruß,

Simon2.

Vischnu

danke jungs für eure hilfe, habs hinbekommen, maps sind jetzt abspeicher- und ladbar
den letzten satz hätte ich wohl weglassen sollen, wenn ich mir ansehen was für eine diskusion ich hier losgetreten habe^^

ich hätte aber nochmal eine kurze frage:
ich habe eine klasse CollitionManager, und eine klasse Ball. der Ball ruft aus dem collition manager die methode

int testCollision(Ball *ball);

auf. also muss ich in beiden klassen die jeweils andere klasse includieren. nur bekomm ich dann eine endlos schleife beim compilieren oder wenn ich #define & #ifndef benutzen bekomme ich bei einer der klassen fehlermeldung dass ball oder der manager nicht definiert ist!

also mach ich da irgendwas beim includieren falsch (was ich denke) oder geht das mit c so nicht?

den vergleich mit java spar ich mir dieses mal

Simon2 schrieb:

Nichtdestotrotz sehe ich
- weder, wo C++ maschinennah

std::cout<<sizeof(int)

Gibt dir z.B. unterschiedliche Werte auf unterschiedlichen Maschinen (16/32 Bit) aus. Wenn das nicht maschinennah ist, was ist es dann?

- noch, wo es auf eine Plattform festgelegt sei.

Hab ich nie behauptet.