2017-12-07 6 views
0

Ich verwende eine 3rd-Party-Bibliothek, die zum größten Teil besteht aus POD-Strukturen. Mehr noch, diese Strukturen werden von einem speziellen Bibliothekszeiger gezeigt, der mit einer speziellen Bibliotheksfabrik erstellt wurde, so dass sie in Form von Ptr<APod> kommen und gehen. Da PODs per Definition alle öffentlich sind, hat dies dazu geführt, dass sie überall auf der Codebasis modifiziert wurden, wobei der Code überall verteilt wurde. Ich versuche einen besseren Ansatz zu finden. Ich mag sie, um wickeln, um sie echte Klassen machen werden, so dass jeder Betrieb in Bezug auf diese Daten gezwungen ist, innerhalb der Wrapper-Klasse zu sein:So behandeln Sie korrekt 3rd Party POD

class Wrapper 
{ 
public: 
    Wrapper(/* params to correcly build APod */); 

    /** required when it needs to be sent back to the library **/ 
    const Ptr<APod>& unwrap() const; 
private: 
    Ptr<APod> m_data; 
}; 

Aber selbst wenn dies ist für die meisten der Bibliothek PODs Fein Es ist ein wenig schwierig, wenn PODs Felder haben, die aus anderen PODs bestehen, oder wenn es eine Sammlung von PODs gibt (die Bibliothek hat auch ihren eigenen Vektor von Ptr zu PODs). Eine andere knifflige Sache ist, dass, da die Bibliothek nur const Ptr<APod>& zurücknimmt, was einen konstanten Zeiger auf ein nicht konstantes Objekt bedeutet, meine unwrap() Methode immer noch zulässt, dass Programmierer zu viel Freiheit auf diesen PODs haben. Kann mein Ansatz verbessert werden? Oder ist es völlig falsch und sollte durch einen anderen Ansatz ersetzt werden?

Antwort

0

Wenn einige der PODs in anderen PODs oder in Arrays/Containern enthalten sein können, sollten Sie niemals versuchen, den POD selbst zu erstellen, sondern einfach davon ausgehen, dass Sie Ihren Wrapper aus einem Zeiger auf POD oder in der Fall Ihrer spezifischen Bibliothek ein Ptr<APod>.

Ohne die Semantik von Ptr (einzigartig/geteilt/schwach) zu wissen, kann ich nicht sagen, ob Sie dann eine Kopie des ursprünglichen Ptr<APod> oder eine Referenz darauf behalten sollten.

+0

Das Verhalten ist das gleiche wie ein gemeinsamer Zeiger, aber es wird von der Bibliothek getan, es ist nicht die STL, aber es ist ziemlich ähnlich. Die von der Bibliothek bereitgestellte Factory kann Zeiger oder ein Array von Zeigern erstellen. Ich kann auch ein vollständiges Array von PODs umschließen, aber manchmal haben andere PODs ein Feld, das ein einzelnes POD-Element ist und das nicht ausgepackt wird, wenn ich dies tue. Was könnte ein richtiger Weg sein, um Informationen zu verstecken und einzukapseln, die so viele PODs haben? – nyarlathotep108

+0

Idealerweise hätte ich gerne, dass nur die Wrapper-Klassen die Factory kennen und wissen, wie man sie benutzt, und sie wissen, wie man mit dem spezifischen POD-Datentyp umgeht. – nyarlathotep108

+0

@ nyarlathotep108: Das Umbrechen einer komplexen Bibliothek kann komplex sein ... Vielleicht könnten Sie eine [mcve] erstellen, die das Problem mit einer Stub-Bibliothek demonstriert. Sie werden wahrscheinlich alle Funktionen der Fabrik explizit bearbeiten müssen, aber ohne ein Beispiel kann ich nicht mehr sagen. –