On Sat, Mar 03, 2001 at 09:16:30AM +0100, Tilo Wetzel wrote:
Guten morgen alle zusammen,
erstaml vielen Dank für Euer Wissen. Ich bin nun schon ein Stück weiter.
Hat zwar eine Weile gedauert bis ich dahinter stieg - ein Fehler lag allerdings bei mir. Ich hatte die string mit #include <string.h> eingebunden - muß aber #inlcude <string> lauten. Bei mir gibt es u.a. mehrer string-files /usr/include/bits/string.h /usr/inlcude/string.h /usr/src/linux (im Kernel)
/usr/include/strings.h
Worin besteht der Unterschied zwischen: ...<string> - .... <string.h> und ... <strings.h> ?
Also: - /usr/include/bits/string.h wird von /usr/include/string.h eingebunden und wird sich ansonsten weigern zu kompilieren (es liefert grundlegende Stringoperationen). - /usr/include/string.h liefert die Stringfunktionen für C (also strcpy(), strdup() etc., alle benötigen einen char*) - /usr/include/strings.h ist meines Wissens nur zur Kompatibilität, weil einige Unixe ihre Stringfunktionen in <string.h>, andere in <strings.h> hatten. (strings.h sieht ziemlich primitiv aus, also nicht benutzen) - /usr/include/g++-3/string (ohne .h!!) liefert die Stringklasse für C++. Das fehlende .h ist nur, damit es sich nicht mit string.h beharkt.
Genau genommen ist string nur ein typedef von basic_string<char>. Wenn du also die Stringklasse um Unicode erweitern willst, würde ein basic_string<int> zum Datenzusammenhalten ausreichen (auch wenn das keine ideale Speicherausnutzung ist). Das nur so nebenbei.
Solange ich keine Variable als Typ string definierte lief der der Compiler problemlos. Es gab erst Probleme als ich eine Variable deklarierte.
s.o., in <string.h> war die Stringklasse nicht definiert.
Ihr könnt Euch Zeit lassen mit der Beantwortung dieser Frage, da ich übers Wochenende (sprich nachher) erstmal wegfahre.
Naja, bevor ich es vergesse...
Ein schönes Wochenende wünscht Euch
Tilo
dir auch, Ulf