2009-07-16 4 views
0

Ich habe einen C++/CLI-Wrapper um native .lib und .h-Dateien. Ich verwende die AutoPtr-Klasse ziemlich umfassend in der Wrapper-Klasse, um die nicht verwalteten Objekte zu verwalten, die ich zum Wrapping erstelle. Ich habe einen Roadblock mit dem Kopierkonstruktor/Zuweisungsoperator getroffen.AutoPtr in C++/CLI gemischten Modus

Mit der AutoPtr Klasse von Herrn Kerr: http://weblogs.asp.net/kennykerr/archive/2007/03/26/AutoPtr.aspx

Er schlägt vor, die folgenden (in den Kommentaren), um das Verhalten des Zuweisungsoperators neu zu erstellen:

SomeManagedClass->NativePointer.Reset(new NativeType); 

Was ich glaube, ist wahr. Aber wenn ich kompilieren meinen Code:

ByteMessageWrap (const ByteMessageWrap% rhs) 
{ 
    AutoPtr<ByteMessage> m_NativeByteMessage(rhs.m_NativeByteMessage.GetPointer()); 
}; 

ByteMessageWrap% operator=(const ByteMessageWrap% rhs) 
{ 
    //SomeManagedClass->NativePointer.Reset(new NativeType); 
    if (this == %rhs) // prevent assignment to self 
     return *this; 

    this->m_NativeByteMessage.Reset(rhs.m_NativeByteMessage.GetPointer()); 
    return *this; 
}; 

- ich folgende Fehler:

Fehler C2662: 'WrapTest :: AutoPtr :: GetPointer': nicht konvertieren kann 'this' Zeiger von 'const WrapTest :: AutoPtr' to 'WrapTest :: AutoPtr%'

Hat jemand ähnliche Probleme erlebt?


Für weitere Hintergrundinformationen zur Antwort habe ich das Schlüsselwort "const" aus der Signatur entfernt. Ich weiß, dass das für einen copy-ctor in Bezug auf die Korrektheit des Codes nicht gelächelt wird, aber die CLR mag es überhaupt nicht - irgendwie täuscht die CLR im Kern mit der Speicherverwaltung.

Ich frage mich, ob es möglich ist, das const in der Signatur zu belassen und dann GCHandle oder pin_ptr zu verwenden, um sicherzustellen, dass sich der Speicher beim Kopieren nicht bewegt?

+0

Aus Gründen der Übersichtlichkeit erhalte ich diesen Fehler in beiden Codezeilen, die die GetPointer() -Methode aufrufen. – TomO

+0

Hmm ... Ich denke immer noch darüber nach. Welches Verhalten willst du wirklich? Soll eine ByteMessage native Byte-Nachricht verworfen oder geklont werden, wenn eine ByteMessage kopiert wird? Vielleicht sollte ByteMessage keinen Kopierkonstruktor haben, da es eine verwaltete Klasse ist - wie wäre es mit ICloneable? –

Antwort

0

Wenn man Kenny Kerrs AutoPtr betrachtet, überträgt es den Besitz in seinen Konstruktor - im Wesentlichen ein "move" -Konstruktor und kein Kopierkonstruktor. Dies ist analog zu std :: auto_ptr.

Wenn Sie wirklich Eigentumsrechte von rhs auf diese übertragen möchten (d. H. Verlassen rhs ohne es NativeByteMessage), müssen Sie Ihre Kopie ctor in eine Bewegung Ctor ändern.

Außerdem müssen Sie Initialisierungssyntax verwenden;