Re: std::facet nicht auf dem Heap erzeugbar?
Ralf Pichocki wrote:
Der Punkt ist dass auf die obige Art der Code den Du hattest ein Leak
erzeugt:
Ach, so: wenn ich mit ref=0 starte und die Facette in ein locale stopfe,
dann darf DER sie auch zerst??ren; wenn ich das selbst tun will, muss ich
mit ref=1 beginnen. Korrekt?
Ja.
Irgendwo hast du wohl #define new DEBUG_NEW stehen. Das kannst Du wenn Du
willst auch so lassen, aber dann brauchst Du den ueberladenen 'operator
new' von den MFC (keine Ahnung welcher Header).
Na, toll! Was hat denn der MFC-DebugNew in der STL-Implementierung zu
suchen? Bl??d, so was!
Nene, den wirft doch VS immer in seine Project-Templates, irgendsowas wie
das hier:
#ifdef _DEBUG
# define new DEBUG_NEW
char const this_file[] = __FILE__
#endif
Kennst Du Dich auch mit der Borland-Implementierung aus? Auf die muss ich
n??mlich jetzt portieren...:((
Nein, aber wenn dann wuesste ich dass STLport auch auf Borland portiert ist,
was ein Ausweg waere falls diese Implementierung doch zu schrecklich ist.
Welche Version strebst Du denn an?
Da gibt es dann "noch seltsamere" Fehlermeldungen.
1) Wenn ich meine Klasse von std::codecvt< char, wchar_t, mbstate_t >
ableite und wie wohl richtig do_in() und do_out() ??berschreibe, erhalte
ich die Meldung, dass "nur Nicht-Template-Funktionen virtuell sein d??rfen"
!?
2) Weil's mir letztlich wurscht ist, wie herum ich konvertiere, habe ich
es jetzt umgedreht, also von std::codecvt< wchar_t, char, mbstate_t >
abgeleitet, und jetzt gibt es ganz tief in Borlands _locale.h kuriose
Fehlermeldungen...
Hmmm, in meiner Doku steht:
template<typename internT, typename externT, typename stateT>
class codecvt;
'externT' ist immer 'char', 'internT' kann 'char' oder 'wchar_t' sein. Der
(Un)Sinn hinter externT ist dass es eigentlich wohl eher 'byte' heissen
sollte, weil als solches muss man es letztendlich behandeln. Das ist auch
der Grund warum es keinen Sinn macht andere Typen als 'char' zu nehmen.
Anders gesagt ist es richtig(!) wie Du es unter 2) machst. Die Frage stellt
sich jetzt warum es die Standardlib von Borland nicht verkraftet. Eine
Sache auf die man aufpassen muss ist dass bei do_in/do_out diverse
Parameter als Referenz uebergeben werden, andere jedoch nicht. Ich weiss
auch dass STLport 4.x lange Zeit einen Parameter selber nicht als Referenz
uebergab, was aber nie jemandem aufgefallen ist weil dieses Feature niemand
benutzt hat, ich schliesse also einen Bug in der Borland-Implementierung
nicht aus.
Uli