C++ benutzerdefinierte Konvertierungsoperatoren ohne Klassen?

Question

In C++ ist es möglich, Konvertierungsoperatoren zu definieren, die keine Klassenmitglieder sind? Ich weiß, wie man das für reguläre Operatoren (wie +) macht, aber nicht für Konvertierungsoperatoren.

Hier ist mein Anwendungsfall: Ich arbeite mit einer C-Bibliothek, die mir eine PA_Unichar * aushändigt, wo die Bibliothek PA_Unichar zu einem 16-Bit-int definiert. Es ist eigentlich eine Zeichenfolge, die in UTF-16 codiert ist. Ich möchte es in eine std::string konvertieren, die in UTF-8 codiert ist. Ich habe alle der Conversion-Code bereit und arbeiten, und ich bin nur die syntaktische Zucker fehlen, die mir schreiben lassen würde:

PA_Unichar *libOutput = theLibraryFunction(); 
std::string myString = libOutput; 

(in der Regel ohne die temporäre Variable in einer Zeile).

Auch erwähnenswert:

• Ich weiß, dass std::string nicht implizite Konvertierung von char* nicht definiert, und ich weiß, warum. Der gleiche Grund könnte hier gelten, aber das ist nebensächlich.

• Ich habe eine ustring, Unterklasse von std::string, die den richtigen Konvertierungsoperator aus PA_Unichar* definiert. Es funktioniert, aber dies bedeutet ustring Variablen anstelle von std::string und dann erfordert Konvertierung in std::string, wenn ich diese Zeichenfolgen mit anderen Bibliotheken verwenden. Das hilft also nicht sehr.

• Die Verwendung eines Zuweisungsoperators funktioniert nicht, da Klassenmitglieder sein müssen.

So ist es möglich, implizite Konvertierung Operatoren zwischen zwei Typen definieren Sie nicht kontrollieren (in meinem Fall PA_Unichar* und std::string), die nicht Klassentypen sind oder nicht?

Wenn nicht, was könnte Workarounds sein?

Answer 1

Was ist los mit einer freien Funktion?

std::string convert(PA_Unichar *libOutput); 

std::string myString = convert(theLibraryFunction()); 

bearbeiten Beantwortung auf den Kommentar:

Als DrPizza says: Alle anderen versucht, die Löcher durch implizite Konvertierungen geöffnet zu stopfen durch sie mit denen explizite Konvertierung zu ersetzen, die Sie „visuelle Unordnung“ nennen.

Was die temporäre Zeichenfolge: Warten Sie auf die nächste Compiler-Version. Es wird wahrscheinlich mit Rvalue-Referenzen kommen und seine std::string Implementierung wird zusätzlich eine Verschiebungssemantik implementieren, die die Kopie eliminiert. Ich habe noch eine billigere Möglichkeit gesehen, um Ihren Code zu beschleunigen, als wenn Sie einfach auf eine neue Compiler-Version aktualisieren.

Answer 2

Ich glaube nicht, dass Sie "globale" Konvertierungsoperatoren definieren können. Die Standards sagen, dass conversion functionsspecial member functions sind. Ich würde die folgende propse, wenn ich die folgende Syntax Zucker in Erwägung ziehen könnte:

struct mystring : public string 
{ 
    mystring(PA_Unichar * utf16_string) 
    { 
     // All string functionality is present in your mystring. 
     // All what you have to do is to write the conversion process. 
     string::operator=("Hello World!"); 
     string::push_back('!'); 
     // any string operation... 
    } 
}; 

Beachten Sie, dass polymorphe Verhalten dieser Klasse gebrochen ist.Solange Sie kein Objekt über einen Zeiger vom Typ string* erstellen, sind Sie in der sicheren Seite! Also, dieser Code ist perfekt:

Wie schon gesagt, der folgende Code ist kaputt!

string* str = new mystring(....); 
.... 
delete str; // only deleting "string", but not "mystring" part of the object 
// std::string doesn't define virtual destructor 

Answer 3

Implizite Konvertierungen sind sowieso der Teufel. Machen Sie es explizit mit einem Conversion-Funktionsaufruf.

Answer 4

Nein, das geht nicht. Alternativ können Sie einen Konvertierungskonstruktor in der Zielklasse erstellen (nicht in Ihrem Fall, da Sie ihn in std :: string konvertieren möchten - sofern Sie ihn nicht ableiten). Aber ich stimme den anderen Antworten zu, ich denke, eine implizite Konvertierung wird in diesem Fall nicht empfohlen - besonders, weil Sie nicht von einem Objekt, sondern von einem Zeiger konvertieren. Besser, eine freie Funktion zu haben, wird Ihr Code einfacher zu verstehen sein und der nächste Programmierer, der den Code erbt, wird Ihnen sicher danken.