Portable Bitfelder für Handles

Question

Ich möchte "Handles" zu Daten in einem Objektpuffer verwenden und speichern, um den Overhead der Zuweisung zu reduzieren. Der Handle ist einfach ein Index in ein Array mit dem Objekt. Allerdings muss ich nach-Neu-Zuweisungen erkennen, da dies sehr leicht möglich ist. Der übliche Ansatz scheint Bitfelder zu verwenden. Dies führt jedoch zu zwei Problemen:

1. Bitfelder sind Implementierung definiert
2. Bit Verschiebung über große/Little-Endian-Maschinen nicht tragbar ist.

Was ich brauche:

• Shop Griff in einer Datei (Datei-Handler entweder Integer-Typen verwalten können (Byteaustausch) oder Byte-Arrays)
• Speicher 2 Werte im Griff mit minimalem Platz

Was ich bekommen habe:

template<class T_HandleDef, typename T_Storage = uint32_t> 
struct Handle 
{ 
    typedef T_HandleDef HandleDef; 
    typedef T_Storage Storage; 

    Handle(): handle_(0){} 
private: 
    const T_Storage handle_; 
}; 

template<unsigned T_numIndexBits = 16, typename T_Tag = void> 
struct HandleDef{ 
    static const unsigned numIndexBits = T_numIndexBits; 
}; 

template<class T_Handle> 
struct HandleAccessor{ 
    typedef typename T_Handle::Storage Storage; 
    typedef typename T_Handle::HandleDef HandleDef; 

    static const unsigned numIndexBits = HandleDef::numIndexBits; 
    static const unsigned numMagicBits = sizeof(Storage) * 8 - numIndexBits; 

    /// "Magic" struct that splits the handle into values 
    union HandleData{ 
     struct 
     { 
      Storage index : numIndexBits; 
      Storage magic : numMagicBits; 
     }; 
     T_Handle handle; 
    }; 
}; 

A Verwendung wäre zum Beispiel:

typedef Handle<HandleDef<24> > FooHandle; 
FooHandle Create(unsigned idx, unsigned m){ 
    HandleAccessor<FooHandle>::HandleData data; 
    data.idx = idx; 
    data.magic = m; 
    return data.handle; 
} 

Mein Ziel war es, den Griff so undurchsichtig wie möglich zu halten, einen Bool Scheck, aber sonst nichts hinzuzufügen. Benutzer des Griffs sollten nicht in der Lage sein, etwas damit zu tun, sondern ihn herumreichen.

So Probleme, die ich laufe in:

• Union ist UB -> Ersetzen seines T_Handle durch Storage und Ctor hinzufügen von Speicher
• Wie funktioniert die Compiler Layout des Bit-Feld zu behandeln? Ich fülle die ganze Union/Typ, so sollte es keine Auffüllung geben. Wahrscheinlich ist das einzige, was anders sein kann, welcher Typ zuerst kommt, abhängig von Endianess, korrekt?
• Wie kann ich handle_ in einer Datei speichern und es von einem möglichen anderen endianess Maschine laden und immer noch index und magic korrekt sein? Ich denke, ich kann die Storage "Endian-Korrekt" speichern und korrekte Werte erhalten, IF beide Mitglieder belegen genau die Hälfte des Platzes (2 Shorts in einem Uint) Aber ich will immer mehr Platz für den Index als für den magischen Wert.

Hinweis: Es gibt bereits Fragen zu Bitfeldern und Verbindungen. Zusammenfassung:

• Bitfelder unerwartete Polsterung (hier nicht möglich, da ganzer Typ besetzt) ​​hat
• Reihenfolge der „Mitglieder“ ist abhängig von Compiler (nur 2 Möglichkeiten hier, speichern sollte, um hängt ganz von Endianess zu übernehmen, so kann dies hier helfen oder nicht)
• Spezifisches binäres Layout von Bits kann durch manuelles Verschieben erreicht werden (oder zB Wrapper http://blog.codef00.com/2014/12/06/portable-bitfields-using-c11/) -> Ist hier keine Antwort. Ich brauche auch ein spezifisches Layout der Werte IN das Bitfeld. Ich bin also nicht sicher, was ich bekomme, wenn ich z. Erstellen Sie ein Handle als handle = (magic << numIndexBits) | index, und speichern/laden Sie es als Binärdatei (keine Endianess-Konvertierung). Eine BigEndian-Maschine zum Testen fehlt.

Hinweis: Kein C++ 11, aber Boost ist erlaubt.

Answer 1

Antwort ist ziemlich einfach (basierend auf einer anderen Frage, die ich den Link zu und Kommentare werden von @ Jeremy Friesner vergessen):

Als „Zahlen“ sind bereits eine Abstraktion in C/C++ kann man sicher sein, immer die müssen gleiche Bit-Darstellung, wenn die Variable in einem CPU-Register ist auch (wenn es für etwas Berechnung dergleichen verwendet wird) Bitverschiebungen in C in einer endian-unabhängigen Art und Weise definiert sind. Das bedeutet, x << 1 ist immer gleich x * 2 (und damit Big-Endian) Nur einmal get Endianess Probleme sind, wenn eine Datei zu speichern, senden/recv über das Netzwerk oder aus dem Speicher zugreifen anders (zB über Zeiger ...)

man kann nicht verwendet werden (C) bitfields hier, da man nicht 100% sicher über die Reihenfolge der „Einträge“ sein kann. Bitfeld-Container sind möglicherweise in Ordnung, wenn sie den Zugriff auf die Daten als "Nummer" erlauben.

Savest verwendet (immer noch) Bitshifts, die in diesem Fall sehr einfach sind (nur 2 Werte) Während der Speicherung/Serialisierung muss die Nummer dann endian-agnostisch gespeichert werden.