3. Eigene Klassen, die Pointer enthalten in Binary-Datei speichern?

Eigene Klassen, die Pointer enthalten in Binary-Datei speichern?

  • 3

    Wenn du reinterpret_cast willst, dann sag auch reinterpret_cast und nicht static_caststatic_cast.

    0
  • O

    314159265358979 schrieb:

    Wenn du reinterpret_cast willst, dann sag auch reinterpret_cast und nicht static_caststatic_cast.

    du willst immer die Methode, die den defensiveren programmierstil ermoeglicht ->static_cast.

    0
  • 3

    Ich will die Methode, die möglichst direkt ausdrückt was ich will, und das ist der reinterpret_cast. Der ptr_cast wäre auch okay, wahrscheinlich sogar die beste Lösung.

    0
  • O

    314159265358979 schrieb:

    Ich will die Methode, die möglichst direkt ausdrückt was ich will, und das ist der reinterpret_cast. Der ptr_cast wäre auch okay, wahrscheinlich sogar die beste Lösung.

    der reinterpret_cast tut das nicht, weil er noch VIEL MEHR ausdrueckt.

    0
  • T

    otze schrieb:

    314159265358979 schrieb:

    Ich will die Methode, die möglichst direkt ausdrückt was ich will, und das ist der reinterpret_cast. Der ptr_cast wäre auch okay, wahrscheinlich sogar die beste Lösung.

    der reinterpret_cast tut das nicht, weil er noch VIEL MEHR ausdrueckt.

    Ne, Pi hat da schon recht. Du willst einen Pointer auf T als Pointer auf char interpretieren. Da liegt reinterpret_cast direkt nahe.

    0
  • E

    Und was ist mit der Erhöhten Fehleranfälligkeit?

    0
  • C
    Mod

    Beide haben Varianten - garantiert - das gleiche wohldefinierte Verhalten (wobei der Grund, weshalb static_cast hier funktioniert, etwas subtiler ist). Mithin ist das primär eine Stilfrage.
    Im Allgemeinen kann ein Objekt T nicht als ein Array aus Elementen U betrachtet werden ohne UB zu verursachen. Ausnahmsweise darf aber auf jedes Objekt über eine char/unsigned char-Array zugegriffen werden (Modifikationen sind allerdings auf Standardlayouttypen beschränkt).
    static_cast ist primär ein Operator für "sichere" Konvertierungen innerhalb des Typsystems von C++. Eine Konvertierungsequenz, die per expliziter Typvernichtung über void* arbeitet, fällt sicherlich nicht in diese Kategorie.

    @pi: Es ist ein typischer Anfängerfehler beim Studium des Standards aufzuhören, sobald man eine Stelle gefunden hat, die für die jeweilige Fragestellung relevant sein könnte. Leider ist es in der Regel nicht so einfach. In diesem Fall solltest du mindestens das gesamte Kapitel zu reinterpret_cast durchlesen. Insbesondere der letzte Absatz ist hier relevant. Durch diesen wird erst erklärt, in welchem Rahmen eine Implementation hier Wahlmöglichkeiten hat. Soweit ich sehe, ist sie nämlich nur hinsichtlich der Repräsentation nicht eingeschränkt, d.h. in Fällen, in denen ein Zeiger auf die gleiche Adresse verschiedene interne Darstellungen haben kann, ist es der Implementation freigestellt, eine davon zu wählen.

    0

  • Nur um hier auch mal meinen Senf zum eigentlichen Thema abzugeben: ich würde vermutlich erstmal einen Funktion mit void* Parameter machen, ala memcpy.
    Und die dann einfach ohne Cast aufrufen - die Konvertierung zu cv void* ist ja implizit.

    std::ostream& binary_write(std::ostream& os, void const* ptr, size_t byteCount)
{
    os.write(static_cast<char const*>(ptr), byteCount);
    return os;
}

void foo()
{
    int i = 42;
    binary_write(std::cout, &i, sizeof(i));
}

    Und alles weitere dann darauf aufbauen.

    0
  • 3

    Also ist das Verhalten der static_cast Variante nicht definiert und der reinterpret_cast die richtige Möglichkeit, verstehe ich dich richtig?

    0
  • O

    314159265358979 schrieb:

    Also ist das Verhalten der static_cast Variante nicht definiert und der reinterpret_cast die richtige Möglichkeit, verstehe ich dich richtig?

    nein, beides ist definiert.

    0
  • 3

    Ich sollte Beiträge öfters lesen - dann wäre mir aufgefallen, dass er genau das im ersten Satz geschrieben hat. 💡

    0
Anmelden zum Antworten