Templateparameter zu String

MatheStein schrieb:

Habe hier auch gerade etwas gefunden:
abi::__cxa_demangle(typeid(int).name(), 0, 0, &status)
Offensichtlich kann man hier mit die internen Namen des GCC in "sinnvollere" umwandeln, lese mich aber gerde selbst erst ein. Scheint aber zu klappen

Das ist allerdings wiederum GCC Abhängig.
Wofür brauchst du das überhaupt?

MatheStein

Ist eine etwas fiesere Geschichte..

Baue eine Art Interpreter der irgendwelche Codefragmente als String verarbeitet und an einer Stelle brauche ich von einem Templateparameter den Datentyp als String um vernünftigen Code generieren zu können.. Ungefähr so etwas in der Art

Gruß

cooky451

Eh.. ja, das hört sich nach Quatsch an.

pyhax

MatheStein schrieb:

Habe hier auch gerade etwas gefunden:
abi::__cxa_demangle(typeid(int).name(), 0, 0, &status)
Offensichtlich kann man hier mit die internen Namen des GCC in "sinnvollere" umwandeln, lese mich aber gerde selbst erst ein. Scheint aber zu klappen

Nicht vergessen: Der Pointer, der da zurückgegeben wird, muss selber wieder freigegeben werden!

MatheStein

Danke

Ist der Rückgabewert ein C-String, also macht man das ca so:

char* s = abi::__cxa_demangle(typeid(int).name(), 0, 0, &status);

// ...

free(s);

Oder macht man das mit "delete" ?

Gruß

Werner Salomon

MatheStein schrieb:

Oder macht man das mit "delete" ?

Nein - mit free (siehe http://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_demangling.html).

Besser als es selber später mit free freizugeben, ist die Verwendung von RAII im Allgemeinen und Smart-Pointer im Besonderen

std::shared_ptr< char > s( abi::__cxa_demangle(typeid(int).name(), 0, 0, &status), &::free ); // erfordert #include <memory> und C++11

danach brauchst Du Dich um das Freigeben nicht mehr zu kümmern.

Gruß
Werner

Ethon

Hmm, bevor ich für soetwas den Overhead eines shared_ptr in Kauf nehmen würde, würde ich eher an free denken.

char* demangled = abi::__cxa_demangle(typeid(int).name(), 0, 0, &status);
std::string s(demangled);
free(demangled);

Ja ... der Konstruktor von s kann bad_alloc werfen, sowas ist aber vermutlich in der Geschichte noch nie passiert, wenn es um Speicher für max. 15 Bytes geht.

cooky451

Ethon schrieb:

Hmm, bevor ich für soetwas den Overhead eines shared_ptr in Kauf nehmen würde, würde ich eher an free denken.

Ne, das ist nicht mal exception safe. Und der "overhead" von shared_ptr dürfte hier auch kaum spürbar sein, aber unique_ptr wäre natürlich trotzdem angebrachter.

Werner Salomon

cooky451 schrieb:

Ethon schrieb:

Hmm, bevor ich für soetwas den Overhead eines shared_ptr in Kauf nehmen würde, würde ich eher an free denken.

Ne, das ist nicht mal exception safe. Und der "overhead" von shared_ptr dürfte hier auch kaum spürbar sein, aber unique_ptr wäre natürlich trotzdem angebrachter.

ich wusste zunächst nicht, dass std::unique_ptr das kann. Man kann tatsächlich einen Deleter als zweiten Parameter angeben, aber so einfach wie beim shared_ptr geht es nicht (compiliert nicht mit VC10)!

Wer weiß, was man hier tun muss, um std::unique_ptr zu benutzen?

cooky451

unique_ptr will den deleter mit im Typen haben:

std::unique_ptr<char, decltype(&std::free)> p(.., &std::free);