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?
Aus Gründen der Übersichtlichkeit erhalte ich diesen Fehler in beiden Codezeilen, die die GetPointer() -Methode aufrufen. – TomO
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? –