Objekt im Speicher verschieben ; Speicherabbild erstellen
-
general bacardi schrieb:
Objekte serialisieren kann schwierig sein, wenn diese Zeiger auf andere Objekte enthalten, die wiederum auf was anderes verweisen usw. Echte tiefe Kopien von objekten sind in C++ allgemein nicht möglich, so wie etwa in Java und anderen SPrachen, die sehr viele dynamische Laufzeitinformationen enthalten.
Man kann die Objekte, die an den Pointern hängen ebenfalls Serialisierbar machen. In der Serializefunktion wird dann in die entsprechende Funktion des Memberobjekts gesprungen. Ist überhaupt kein Problem.
-
In C++0x gibts zusätzlich RValue-Referenzen.
Hier Blicke ich nicht ganz durch.
A a(); // Worin Unterscheiden sich diese Zeilen, oder sind sie alle gleich? // Was passiert mit der Variable a nach dem Verschieben? a == NULL? A b = std::move(a); A&& c = a A&& d = std::move(a); // benötige ich std::move überhaupt oder ist dies Werkzeug für ältere Klassen? // Eine neuere wäre für mich eine, die einen RValue-Konstruktor bestitzt. // Oder bekommen alle Klassen automatisch einen RValue-Konstruktor?Warum willst du Speicher verschieben?
Speicher verschieben? Du meinst sicherlich ein Objekt vom Speicherplatz A zum Platz B.
Warum? Es gibt keinen konkreten Anwendungsfall. Alleine aus Interesse an C++0x und den Möglichkeiten in C++. Ich arbeite mich in das Pool-Concept ein wenig ein und suche nach Möglichkeiten, einer Fragmentation entgegen zu wirken. Hierzu muss ich ein Objekt verschieben. Oder ein Objekt aus dem Pool A in den Pool B verschieben, oder aus dem Pool p in den Heap. So langsam glaube ich, dass rvalue und std::move das Richtige sind. Leider komme ich mit den Erklärungen im Web (eigentlich nur eine und tausendmal abgeschrieben) nicht ganz so klar. Siehe oben
A& a = pool->create<A>(); B& b = pool->create<B>(); A& c = pool->create<C>(); pool->free(b); // ordne den Speicher pool->collect(); //... // Zerstöre Pool und alle beinhaltete Objecte delete pool;
-
schmuessla schrieb:
general bacardi schrieb:
Objekte serialisieren kann schwierig sein, wenn diese Zeiger auf andere Objekte enthalten, die wiederum auf was anderes verweisen usw. Echte tiefe Kopien von objekten sind in C++ allgemein nicht möglich, so wie etwa in Java und anderen SPrachen, die sehr viele dynamische Laufzeitinformationen enthalten.
Man kann die Objekte, die an den Pointern hängen ebenfalls Serialisierbar machen. In der Serializefunktion wird dann in die entsprechende Funktion des Memberobjekts gesprungen. Ist überhaupt kein Problem.
Er meinte, dass Reflection in C++ nicht standardmäßig dabei ist. Mit einer Reflection-API kannst du das alles automatisieren.
-
Siassei schrieb:
Speicher verschieben? Du meinst sicherlich ein Objekt vom Speicherplatz A zum Platz B.
Ja, "Speicherinhalt" wäre besser formuliert gewesen.
Siassei schrieb:
Warum? Es gibt keinen konkreten Anwendungsfall. Alleine aus Interesse an C++0x und den Möglichkeiten in C++. Ich arbeite mich in das Pool-Concept ein wenig ein und suche nach Möglichkeiten, einer Fragmentation entgegen zu wirken. Hierzu muss ich ein Objekt verschieben. Oder ein Objekt aus dem Pool A in den Pool B verschieben, oder aus dem Pool p in den Heap. So langsam glaube ich, dass rvalue und std::move das Richtige sind.
Du solltest bedenken, dass die RValue-Referenzen aus C++0x nicht konzipiert sind, Objekte physikalisch zu verschieben. Vielmehr stellen sie besondere Regeln bereit, die Optimierungen erlauben, zum Beispiel bezüglich Umgang mit temporären Objekten und Elimination unnötiger Kopien.
Für deinen Anwendungsfall scheinen mir wie gesagt Zeiger besser geeignet. Oder du machst etwas mit
swap(), das besonders bei grösseren Objekten wahnsinnig effizient sein kann.
-
theta schrieb:
Irgendwie scheint mir das ein gefrickel.
Bestimme ein (allg.) Format wie Du deine Objekte serialisieren / deserialisieren möchtest (als ascii, xml, etc.) und impl. Mechanismen dafür.
Baue eine Zwischenlayer ein und verlasse dich nicht auf das C++ Objekt Layout (welches Kompiler- und Platformabhängig ist).
Simon
Es graut mich hier gleich wieder von ASCII und XML zu lesen!
Wieso kommen so viele Leute automatisch auf die Idee irgendwelche Daten als Text interpretieren zu müssen?!Die grundsätzliche Idee des Themas interessiert mich auch sehr.
Es währe extrem nützlich wenn alle Datentypen der Standardbibliothek in binäre Datenblöcke ausgegelesen und daraus wieder interpretiert werden könnten. Natürlich müsste man dann für benutzerdefinierte Typen in den Strukturen das dann auch definieren.
-
sqrt(-1) schrieb:
Es graut mich hier gleich wieder von ASCII und XML zu lesen!
Wieso kommen so viele Leute automatisch auf die Idee irgendwelche Daten als Text interpretieren zu müssen?!Warum denn nicht? - Warum sollte man es binär machen? - Das bringt nur viele Probleme und wenn man die geringere Speicherkapazität nicht wirklich braucht, dann fährt man besser, wenn man was Textbasiertes hat.
-
sqrt(-1) schrieb:
Es graut mich hier gleich wieder von ASCII und XML zu lesen!
Wieso kommen so viele Leute automatisch auf die Idee irgendwelche Daten als Text interpretieren zu müssen?!In welche Form man die Daten letztendlich bringt, ist doch nebensächlich und hängt letztendlich davon ab, was man damit machen will. Textformate sind oft erste Wahl, weil sie leicht zu debuggen sind und man sich nicht mit Problemen wie Endianess oder Datenwortbreiten rumschlagen muss.
-
drakon schrieb:
Warum denn nicht? - Warum sollte man es binär machen? - Das bringt nur viele Probleme und wenn man die geringere Speicherkapazität nicht wirklich braucht, dann fährt man besser, wenn man was Textbasiertes hat.
Wieso? Welche Probleme?
Nur weil es für XML viele Werkzeuge existieren, begründet sich nicht der Sinn die Daten als Text interpretieren zu müssen! Dass heutzutage selbst http-Daten letztendlich kaum noch auf Text hinauslaufen muss man da garnicht mal als Argument vorbringen.
-
sqrt(-1) schrieb:
Nur weil es für XML viele Werkzeuge existieren, begründet sich nicht der Sinn die Daten als Text interpretieren zu müssen! Dass heutzutage selbst http-Daten letztendlich kaum noch auf Text hinauslaufen muss man da garnicht mal als Argument vorbringen.
Probleme: Einfache Lesbarkeit/Veränderung ohne einen zusätzlichen Editor. Wenn man gewisse Dateien für verschiedene Systeme haben will, dann kann man diese nicht gleich speichern/laden, sondern muss auf Sachen, wie z.B Alignment.
Gegenfrage: Warum sollte ich etwas binär speichern, wenn das speichern der Daten in Textform viel einfacher und portabler ist?
-
sqrt(-1) schrieb:
Wieso? Welche Probleme?
Zum Beispiel ist Portabilität nahezu unmöglich, du musst selbst auf dem gleichen Compiler sehr aufpassen (Alignment & Co.), kleinste Änderungen an an einer Klasse können die gespeicherten Daten unbrauchbar machen, Debugging ist massiv schwieriger.
-
Registrierter Troll schrieb:
In welche Form man die Daten letztendlich bringt, ist doch nebensächlich und hängt letztendlich davon ab, was man damit machen will.
Ich sehe das anders wenn man die Petawatt an Energie betrachtet, die nur deswegen anfallen weil Daten und Strukturen in Textformaten zwischengespeichert werden.
Textformate sind oft erste Wahl, weil sie leicht zu debuggen sind und man sich nicht mit Problemen wie Endianess oder Datenwortbreiten rumschlagen muss.
Das Textformate "leicht zu debuggen sind" ist doch eine absolute Nullaussage. Klar kann ich eine Konfiguration.txt lesen und eine Konfiguration.dat nicht. Bei OfficeDatei.xml ist es wieder absolut hinfällig.
Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.
-
sqrt(-1) schrieb:
Ich sehe das anders wenn man die Petawatt an Energie betrachtet, die nur deswegen anfallen weil Daten und Strukturen in Textformaten zwischengespeichert werden.
Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.
sqrt(-1) schrieb:
Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.
Das kannst du sicher begründen.
-
Nexus schrieb:
sqrt(-1) schrieb:
Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.
Das kannst du sicher begründen.
Wozu? Es sind keine Gründe. Wie will er begründen, was gar keinen Halt hat?
Er kann nur Theorien widerlegen, die behaupten, man bräuchte wegen Endianess oder Datenwortbreite ein Binärformat. Dazu muß jemand begründen, weshalb er ein Textformat braucht und diese Begründung kann leicht zerfetzt werden.
-
[quote="Nexus"]Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.
Der Leistungsaufwand ist um Größenordnungen geringer. Was soll denn daran komplizierter sein die Auszeichnung von Daten und Strukturen mittels Binärdaten anstatt von Text zu realisieren?
sqrt(-1) schrieb:
Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.
Das kannst du sicher begründen.
Es ist doch simpel auch plattformunabhängig binär zu beschrieben in welchem Platformformat die Daten vorliegen um dann gegebenfalls Anpassungen beim Interpretieren vorzunehmen.
-
Nexus schrieb:
Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.
Der Leistungsaufwand ist um Größenordnungen geringer. Was soll denn daran komplizierter sein die Auszeichnung von Daten und Strukturen mittels Binärdaten anstatt von Text zu realisieren?
Nexus schrieb:
sqrt(-1) schrieb:
Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.
Das kannst du sicher begründen.
Es ist doch simpel auch plattformunabhängig binär zu beschrieben in welchem Platformformat die Daten vorliegen um dann gegebenfalls Anpassungen beim Interpretieren vorzunehmen
-
volkard schrieb:
Wozu? Es sind keine Gründe. Wie will er begründen, was gar keinen Halt hat?
Er kann nur Theorien widerlegen, die behaupten, man bräuchte wegen Endianess oder Datenwortbreite ein Binärformat. Dazu muß jemand begründen, weshalb er ein Textformat braucht und diese Begründung kann leicht zerfetzt werden.Bitte lesen lernen. Hier steht nirgends, dass man deswegen Textformate braucht, sondern dass man mit Textformaten weniger Probleme dieser Art hat.
Die Gründe liegen auf der Hand: Die Bedeutung von ASCII-Text bleibt eindeutig, auch wenn er auf verschiedenen Plattformen eingelesen wird. Von ganz exotischen Ausnahmen mal abgesehen. Der gleiche Parser kann somit auf vielen verschiedenen Plattformen unverändert verwendet werden.
-
sqrt(-1) schrieb:
Nexus schrieb:
Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.
Der Leistungsaufwand ist um Größenordnungen geringer. Was soll denn daran komplizierter sein die Auszeichnung von Daten und Strukturen mittels Binärdaten anstatt von Text zu realisieren?
Nexus schrieb:
sqrt(-1) schrieb:
Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.
Das kannst du sicher begründen.
Es ist doch simpel auch plattformunabhängig binär zu beschrieben in welchem Platformformat die Daten vorliegen um dann gegebenfalls Anpassungen beim Interpretieren vorzunehmen
boar..
jz google(oder bing(?!^^) oder such direkt bei wikipedia oder was auch immer) halt endlich mal nach endianess und datenwortbreite! (mit floating-point values wirds dann ganz lustig, weil dir der standard da(im Bezug auf den internen Aufbau) rein gar nichts garantiert xD)
es ist eben _kein_ triviales problem...Performance ist zwar ein nicht von der Hand zu weisendes "Problem", aber was schreibst du denn für ein Programm, dass es so extrem schnell gehen muss?
bb
-
Es ist doch offensichtlich das die Auszeichnung von Daten mittels Text bis auf die theoretisch bessere menschliche Lesbarkeit absolut Null Vorteile, aber viele Nachteile mit sich bringt. Denn letztendlich ist Text ja auch nur ein Format für Binärdaten.
Dass Datenstrukturen als Text gelesen werden können erachte ich für nicht triviale Falle (wie Konfigurationsdateien) als ganz klar nicht amortisierend, da die Strukturen sowieso dokumentiert sind oder gar die Interpretationsalgorithmen vorliegen. Dass man mit Textformaten etwas einfacher reverse-engineering betreiben kann halte ich für keine Begründung das (professionell) einzusetzen.
-
Ich schreibe gern als Text hex statt dez und spare mir damit die Divisionen. Daß ich 2 Ziffern statt einer pro Byte Nutzdaten brauche, stört mich weniger.
-
unskilled schrieb:
boar..
jz google(oder bing(?!^^) oder such direkt bei wikipedia oder was auch immer) halt endlich mal nach endianess und datenwortbreite! (mit floating-point values wirds dann ganz lustig, weil dir der standard da(im Bezug auf den internen Aufbau) rein gar nichts garantiert xD)
es ist eben _kein_ triviales problem...Es geht doch nur darum ob es einfacher ist binär oder im Textformat das Platformformat der Daten zu beschreiben. Was da an Standardisierungkomplexität dahinter steht ist doch in beiden Fällen identisch.
Performance ist zwar ein nicht von der Hand zu weisendes "Problem", aber was schreibst du denn für ein Programm, dass es so extrem schnell gehen muss?
Um meine Person müssen wir uns doch an der Stelle nicht kümmern.
