basic_string<tchar>...??????
-
wozu TCHAR? das ist doch nur die Abfrage, ob UNICODE definiert ist. wenn ja dann wchar_t, ansonsten char. das kann man mit string und wstring auch über typedef.
-
Das saugt aber, die Standardtypedefs unintuitiv zu verändern. Die Idee mit TCHAR ist prinzipiell nicht schlecht.
Allerdings würde ich es noch sinnvoller finden, einfach immer Unicode zu verwenden.
-
Optimizer schrieb:
Das saugt aber, die Standardtypedefs unintuitiv zu verändern.
Wie schon vorgeschlagen, würde ich eher sowas machen:
#ifdef UNICODE typedef std::wstring string; #else typedef std::string string; //bzw. using std::string; #endifVerändert wird hier gar nichts, es wird lediglich ein Synonym im aktuellen Namensbereich erzeugt.
-
sag ich doch!
-
Die ersten paar Fehler kann ich eliminieren. Wenns eine eigene String-Klasse ist verwendest du offenbar strlen(), strcpy(), etc. in der Implementierung. Das geht aber mit wchar_t nicht mehr.
Die "dynamischen" Funktionen heißen: _tcslen(), _tcscpy(), etc. und sind ebenfalls in der <tchar.h> deklariert. Schau mal was dann noch übrigbleibt.
MfG SideWinder
-
@SideWinder: wie gesagt, ich habe bis jetzt noch keine implementierung... ich habe jhetzt den gesamten code nochmal gelöscht, und merkwürdigerweise findet der compiler immer nioch nicht memcmp und memset...
ich weuß echt nicht, was ich tun soll... hilfee
-
HAHA, hab den fehler gefunden, es lag daran, dass mein String header ("String.h") den gleichen namen wie string.h hatte (logisch ;-)), und das fat32 system nicht case intensive ist... sorry, hab nochmal gegooglet und eine erklärung gefunden, die ich nur halb verstanden hab... aber jetz gez, danke trotzdem an alle
cya
-
wenn du #include <string.h> und #include "String.h" schreibst sollte es aber gehen
-
Das kommt davon, wenn man <string.h> anstatt <string> inkludiert.
-
ich hatte ja string und nicht string.h, aber in windows.h beziehungsweise ein header, der von dieser includiert wird, bindet string.h ein.