ich hab ein kleines spiel programmiert inklusive map editor. das problem ist, dass ich die maps irgendwie abspichern muss.

als java programmieren würde ich mein map-object einfach mit einem objectStream rausschreiben. habe auch shcon nach sowas in der art gesucht aber leider nichts gefunden.
also wie kann ich ein object in c++ ohne riesen aufwand, mit irgendeiner vorgefertigten klasse auf die platte schreiben , und dann natürlich auch wieder lesen?

ich hab in meinem map object auch einige pointer auf anderen objekte, werde ich dann dort probleme bekommen, oder werden die objekte hinter den pointern mit gespeichert?

vielen dank schonmal für eure hilfe!

mfg vischnu

Das sollte genügen. Steht aber in jedem drittklassigen C++-Buch.
Ein wenig Aufwand ist das zwar schon, aber es bleibt wirklich überschaubar.

ich hab in meinem map object auch einige pointer auf anderen objekte, werde ich dann dort probleme bekommen, oder werden die objekte hinter den pointern mit gespeichert?

Ja, da wirst du Probleme bekommen, da die Zeiger bei jedem Programmstart anders aussehen können. Mach es ganz logisch und speichere Verweise zum Beispiel mit Indizes. Referenzierte Objekte musst du natürlich separat speichern.

wegen den pointern, ich hab folgendes array:

EnviromentObject *object[500];

enviromentObject ist eine abstrakte klasse, dem array weise ich dann pointer auf objekte wie z.b tree, stone etc zu, also klassen die von enviromentObjekt erben.

ich würde gern das array ohne den pointer anlegen dann würde ich die objekte ja direkt im array speichern, aber der compiler meckert bei mir immer das die klasse abstrakt ist!
ist das irgendwie möglich? dann hätte ich lbeim auf die platte schreiben sicher wneiger probleme!

..oh man, man weiss java erst zu schätzen wenn man mit c++ arbeiten muss

ich würde gern das array ohne den pointer anlegen dann würde ich die objekte ja direkt im array speichern, aber der compiler meckert bei mir immer das die klasse abstrakt ist!
ist das irgendwie möglich? dann hätte ich lbeim auf die platte schreiben sicher wneiger probleme!

Nein, das ist nicht möglich - nicht nur, weil abstrakte Klassen nicht instanziiert werden dürfen. Wie stellst du dir das vor? Jedes Element im Array benötigt gleich viel Platz. Da können nicht plötzlich unterschiedliche Typen drin stehen. Und nein, du hättest dann auch nicht weniger Probleme. Du müsstest trotzdem wieder Fälle unterscheiden und je nach Typ separat speichern.

Wenn dein Design ein wenig durchdacht ist, solltest du über virtuelle Funktionen auf wichtige Eigenschaften gemeinsam über den Basisklassenzeiger zugreifen können. Dann sollte es auch kein Problem sein, eine einheitliche Speicher- und Ladefunktion zu schreiben. Allerdings kann es sein, dass mehrere Container (STL, ähnlich wie Collections in Java) mit jeweiligen Typen besser geeignet wären. Zu den STL-Containern gibt es hier einen Einführungsartikel.

Hast du eigentlich dran gedacht, deine Objekte mit delete freizugeben?
Und virtueller Destruktor ist auch deklariert?

Vischnu schrieb:

..oh man, man weiss java erst zu schätzen wenn man mit c++ arbeiten muss

Da gibt es nicht wenige Leute, die das Gegenteil behaupten würden. :p

..oh man, man weiss java erst zu schätzen wenn man mit c++ arbeiten muss

Abgesehen von dem was Nexus zu diesem Satz gesagt hat, möchte ich dir noch einen Tipp geben:
C++ ist eine Ebene näher an der Maschine und C++ ist etwas ganz anderes. Erst recht wenn du von Java her kommst, musst du unbedingt vergessen, was du aus Java kennst, denn du kannst es auf C++ so gut wie gar nicht anwenden.
Wenn du immer wieder an Java denkst und überlegst, wie du es in Java gelöst hättest und es dann probierst so in C++ zu lösen, wirst du gehörig auf die Schnauze fallen

Ein gutes C++ Buch hast du hoffentlich?

Grüssli

Vischnu

Hihi, hier hat wohl jemand einen Superioritätskomplex, wenn das sinnlose Fremdwort gestattet ist
(EDIT: ist nicht bös gemeint, ich find den Nick nur lustig)

..oh man, man weiss java erst zu schätzen wenn man mit c++ arbeiten muss

Das wird zwar wieder ausarten, aber ich kann mich einfach nicht zurück halten. Und gehört ja durchaus auch zum Thema.

In Java unterstützt jedes Objekt reflection. Es führt also Typinformationen mit sich. C++ ist, wie bereits erwähnt näher an der Maschine mit allen seinen Vor- und Nachteilen. Vorteil ist der geringere Overhead bezüglich Laufzeit und Speicher. Nachteil ist eben, dass zur Laufzeit keine Typinformationen zur Verfügung stehen. Daher ist das Speichern und Laden von Objekten mit mehr Aufwand verbunden.

Das Stichwort ist hier Serialisierung. Du musst dein Objekt irgendwie in eine flache Form bekommen, die Du dann in eine Datei schreiben kannst und auch der rückwärtige Weg der Deserialisierung muss implementiert werden.

Da gibt es verschiedene Ansätze und auch Bibliotheken, die einem ein grossteil der Arbeit abnehmen. Das ist sicherlich ein wenig mühsamer als in vielen anderen Sprachen, aber das Ergebnis sind sehr effiziente Programme. Meiner Meinung nach (und zum Glück auch von vielen, die für die Programmierung bezahlen) ist es die Mühe alle mal Wert.

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

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.

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 logik, verstehe sie wer will...

...logik, verstehe sie wer will...

Nö - aber wer es versucht.

Wer natürlich nur seine eigene Meinung bestätigt sehen will, dem gelingt es halt nicht.

Kleiner Ansatz: Zeige mir eine Festlegung im C++-Standard, die auf eine konkrete Maschine zugeschnitten ist.

Gruß,

Simon2.

Kleiner Ansatz: Zeige mir eine Festlegung im C++-Standard, die auf eine konkrete Maschine zugeschnitten ist.

Und in Java hat solche Festlegungen? Immerhin gibt es unterschiedliche Virtuelle Maschinen. Die VM in Google Android basiert sogar auf einem ganz anderen Rechenmodell als die standard Sun VM. GCJ und einige andere Compiler erzeugen dir sogar nativen Maschinencode. Das klingt nicht, als wäre Java auf eine feste Maschine zugeschnitten.

Da gibt es verschiedene Ansätze und auch Bibliotheken, die einem ein grossteil der Arbeit abnehmen. Das ist sicherlich ein wenig mühsamer als in vielen anderen Sprachen, aber das Ergebnis sind sehr effiziente Programme. Meiner Meinung nach (und zum Glück auch von vielen, die für die Programmierung bezahlen) ist es die Mühe alle mal Wert.

Meine Erfahrung sagt:
- Für das Persistieren von Objektgraphen überschaubarer Ausmaße ist ein Reflection-basierter Mechanismus ideal. Hier verursacht C++ nur mehr Arbeit ohne Zugewinn.
- Im Falle exorbitant großer Datenmengen (etwa Spielstände in einem 3D-Shooter) ist man ohnehin besser beraten, den persistierenden Code selbst zu schreiben, da gewöhnliche Serialisierungslösungen nicht nur zu langsam, sondern vor allem zu unflexibel sind.

Theoretisch kann ein Reflection-basierter Serialisierer durchaus die Performance eines handgeschriebenen erreichen, insbesondere dann, wenn er Code-Generation zur Laufzeit benutzt (ich glaube, Hibernate tut das).

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.

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

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.

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.

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

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.

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

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