Reality Geschrieben 1. Juni 2006 Geschrieben 1. Juni 2006 hey, also ich glaub das ist jetzt eine echt dumme Frage, aber wär es möglich, dass man in c++ keine Strings deklarieren kann?? Ich habe da nämlich nix gefunden... Welchem Datentyp weist man denn dann eine Zeichenkette zu? *verwundertis* Mfg, Reality Zitieren
russkij Geschrieben 1. Juni 2006 Geschrieben 1. Juni 2006 hi, wenn du es nicht kennst, solltest dir erst paar basics ansehen: http://www.c-plusplus.de/cms/modules.php?op=modload&name=Downloads&file=index&req=viewsdownload&sid=2 es gibt mehrere möglichkeiten strings in c++ zu verwenden, es ist etwas komplizierter wie zum beispiel in VB gruss Zitieren
Klotzkopp Geschrieben 1. Juni 2006 Geschrieben 1. Juni 2006 wenn du es nicht kennst, solltest dir erst paar basics ansehen:Bei einer so konkreten Frage auf eine Sammelseite für Tutorials zu verweisen, halte ich für etwas unangebracht. Welchem Datentyp weist man denn dann eine Zeichenkette zu?Dafür gibt es die Klasse std::string, die im Header <string> definiert ist. Zitieren
Reality Geschrieben 2. November 2006 Autor Geschrieben 2. November 2006 hi, wie kann ich denn einen Wert vom Typ ulong oder integer in einen string aus der Klasse std::string verwandeln? Gibt es da eine Möglichkeit? Mfg, Reality Zitieren
Klotzkopp Geschrieben 2. November 2006 Geschrieben 2. November 2006 Das geht mit Stringstreams, die findest du im Header <sstream>: int a = 42; std::ostringstream stream; stream << a; std::string s = stream.str();[/code] Zitieren
Hakawamu Geschrieben 2. November 2006 Geschrieben 2. November 2006 ist auch das möglich? std::string meinStr; int meinInt = 531; sprintf(meinStr.c_str(), "%d", meinInt); [/PHP] Zitieren
Guybrush Threepwood Geschrieben 2. November 2006 Geschrieben 2. November 2006 Nein, das ist ganz ganz übel und sollte auch gar nicht vom Compiler akzeptiert werden weil dir c_str() einen const Zeiger zurück liefert. Der Zeiger ist Konstant damit du nicht einfach so wild in internen String der Klasse rumschreibst und so über den reservierten Speicher hinausschreibst oder sonst irgendwas änderst was deine std::string Instanz zerstören würde. Zitieren
Hakawamu Geschrieben 2. November 2006 Geschrieben 2. November 2006 hehe, danke *g* gut zu wissen - denn ich hätts wohl so gemacht :> Zitieren
Guybrush Threepwood Geschrieben 2. November 2006 Geschrieben 2. November 2006 Wie gesagt das dürfte dein Compiler nicht akzeptieren sondern er wird einen Fehler schmeißen. Die einzige Möglichkeit das zu machen wäre das const wegzucasten, aber wer sowas macht verdient es damit erstmal hinzufallen Zitieren
Tux.Penguin Geschrieben 7. November 2006 Geschrieben 7. November 2006 hehe, danke *g* gut zu wissen - denn ich hätts wohl so gemacht :> Du kannst auch deinen std::string vorher groß genug dimensionieren, dann "funktioniert" auch das sprintf. Aber die alten C-Funktionen sollten sowieso nicht mit STL-Sachen verwendet werden. Seit VS2500 wird man auch ständig vom Compiler dafür angeblafft Der saubere Weg ist der stringstream! Zitieren
Klotzkopp Geschrieben 7. November 2006 Geschrieben 7. November 2006 Du kannst auch deinen std::string vorher groß genug dimensionieren, dann "funktioniert" auch das sprintf.Das mag auf die eine oder andere STL-Implementierung zutreffen. Aber der Standard garantiert weder, dass der Speicher eines std::string am Stück vorliegt, noch dass der Speicher nur diesem einen std::string gehört, und sich nicht mehrere Strings den Speicher teilen. Zitieren
Tux.Penguin Geschrieben 7. November 2006 Geschrieben 7. November 2006 Das mag auf die eine oder andere STL-Implementierung zutreffen. Aber der Standard garantiert weder, dass der Speicher eines std::string am Stück vorliegt, noch dass der Speicher nur diesem einen std::string gehört, und sich nicht mehrere Strings den Speicher teilen. Naja, zumindest ist nicht sichergestellt, dass c_str den tatsächlichen Puffer des strings zurückliefert. Dass c_str einen zusammenhängenden Speicherbereich referenziert ist dagegen garantiert (nullterminiertes array). Wie gesagt ist die zu empfehlende Methode aber der stringstream! Zitieren
TDM Geschrieben 17. November 2006 Geschrieben 17. November 2006 hi, wie kann ich denn einen Wert vom Typ ulong oder integer in einen string aus der Klasse std::string verwandeln? Gibt es da eine Möglichkeit? Mfg, Reality Neben Klotzkopfs Vorschlag gibt es da noch die Funktionen _itoa(int, char*, int) und _ftoa(...) Zitieren
Guybrush Threepwood Geschrieben 21. November 2006 Geschrieben 21. November 2006 Neben Klotzkopfs Vorschlag gibt es da noch die Funktionen _itoa(int, char*, int) und _ftoa(...) welche man auch nicht bei einem std::string anwenden kann Zitieren
maddin Geschrieben 22. November 2006 Geschrieben 22. November 2006 naja ob ich jetzt den 'Umweg' über den stringstream oder _itoa und den Zuweisungsoperator std::string::operator= gehe dürften sich einzig in der Performance unterscheiden - wenn überhaupt ein nicht vernachlässigbare Unterschied festzustellen ist? Zitieren
Klotzkopp Geschrieben 22. November 2006 Geschrieben 22. November 2006 itoa ist nicht portabel, weil es nicht Bestandteil des Standards ist. Zitieren
Guybrush Threepwood Geschrieben 22. November 2006 Geschrieben 22. November 2006 itoa ist nutzlos weil es als 2. Parameter einen char Pointer erwartet wo es den umgewandelten String speichern soll. Das heißt man müsste das erst im C-String speichern um es dann dem std::string zuzuweisen. Das wiederum bedeutet das man entweder erstmal prüfen muss wieviele Stellen man für den C-String reservieren muss oder einen anlegen muss der in jedem Fall passt, so oder so ist das verschwendung weil es anders einfacher geht Zitieren
maddin Geschrieben 22. November 2006 Geschrieben 22. November 2006 käme auf die Implementierung an. Welcher der beiden Methoden mehr Speicherplatz benötigt möchte ich nicht unbedingt vorhersagen wollen. Und soviel mehr zu schreiben ist es letzendlich auch nicht. char buf[20]; std::string s = _itoa(10, buf); Zitieren
Tux.Penguin Geschrieben 26. November 2006 Geschrieben 26. November 2006 käme auf die Implementierung an. Welcher der beiden Methoden mehr Speicherplatz benötigt möchte ich nicht unbedingt vorhersagen wollen. Und soviel mehr zu schreiben ist es letzendlich auch nicht. char buf[20]; std::string s = _itoa(10, buf); Das ist unsicherer C-Code!!! Hat das mal jemand auf einem 64 Bit-System ausprobiert? Hat da der standard-int 64 Bit? Das wären dann 20 Stellen, evtl. mit Vorzeichen und zack würd's hier krachen! Kommt natürlich auf den Compiler an, was der aus dem Code bastelt - ob er immer einen 32-Bit int nimmt, oder das, was auf dem System standard ist. Zitieren
Hakawamu Geschrieben 26. November 2006 Geschrieben 26. November 2006 Hat da der standard-int 64 Bit? nein, hat er normalerweise nicht Zitieren
Guybrush Threepwood Geschrieben 27. November 2006 Geschrieben 27. November 2006 Doch klar, int ist unter C Plattform abhängig. Auf einem 16 Bit System hat er 16 Bit, auch einem 32 Bit System 32 Bit usw. Zitieren
Klotzkopp Geschrieben 27. November 2006 Geschrieben 27. November 2006 Auf einem 16 Bit System hat er 16 Bit, auch einem 32 Bit System 32 Bit usw.Mag sein, dass das so üblich ist, aber es muss nicht so sein. Zitieren
Hakawamu Geschrieben 27. November 2006 Geschrieben 27. November 2006 Also soweit ich weiss war das so gedacht (lt. Kernighan/Ritchie), aber es wurde mit den 64Bit Maschinen nicht gemacht. Diese haben im Regelfall (soweit ich weiss) auch nur 32bit (werds gleich testen). Pointer dagegen sind 64bit lang, so wie die long ints auf den 64Bit Maschinen. Zitieren
Hakawamu Geschrieben 27. November 2006 Geschrieben 27. November 2006 sooo, hier kommt der test: printf("int: %d\n", sizeof(int)*8); printf("long int: %d\n", sizeof(long int)*8); [/PHP] ergibt folgenden output: # g++ test.c -o test # ./test int: 32 long int: 64 und noch der beleg dafür, dass es eine 64Bit Maschine ist: # file test test: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped und # cat /proc/cpuinfo | grep "model name" model name : AMD Athlon 64 X2 Dual Core Processor 4400+ model name : AMD Athlon 64 X2 Dual Core Processor 4400+ Zitieren
Guybrush Threepwood Geschrieben 27. November 2006 Geschrieben 27. November 2006 Schön aber Klotzkopp hat schon recht es kann so sein muss es aber nicht. Der Standard schreibt nicht vor wie groß diese Typen genau sein müssen sondern nur wie groß sie im Vergleich mit anderen Typen sind (größer oder kleiner bzw gleich groß). Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.