ein object auf die festplatte schreiben?
-
Zusätzlich kannst du die Daten der Klasse (alle Attribute) serialisieren und eine Methode der Klasse, nennen wir sie Load() läd die Binärdaten aus der Datei, deserialisiert sie und fügt sie in ihre Attribute. Ganz easy.
-
Vischnu schrieb:
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.
-
danke für eure hilfe, werde mal ofstream ausprobieren!
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
-
Vischnu schrieb:
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
deletefreizugeben?
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
-
Vischnu schrieb:
..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)
-
Vischnu schrieb:
..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.
-
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.
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:
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...
-
hahaha. schrieb:
...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.
-
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.
-
Simon2 schrieb:
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.
-
tntnet schrieb:
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).
-
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.
-
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.
-
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.
-
BTT: Zum Einlesen der Dateien und Erzeugen der Objekte gebe ich dir die Stichwörter virtueller Konstruktor und Abstract Factory.
-
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.
-
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.
