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

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

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.

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

Das geht mit Stringstreams, die findest du im Header <sstream>:

int a = 42;

std::ostringstream stream;

stream << a;

std::string s = stream.str();[/code]

ist auch das möglich?

std::string meinStr;

int meinInt = 531;


sprintf(meinStr.c_str(), "%d", meinInt);

[/PHP]

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.

hehe, danke *g*

gut zu wissen - denn ich hätts wohl so gemacht :>

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

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!

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.

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!

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(...)

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

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?

itoa ist nicht portabel, weil es nicht Bestandteil des Standards ist.

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

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);

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.

Hat da der standard-int 64 Bit?

nein, hat er normalerweise nicht

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.

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.

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.

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+

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ß).