std::string benötigen zuviel Speicherplatz?
-
Hi, probiere gerad ein wenig mit strings herum und wollte mal fragen obs ne Möglichkeit gibt, strings als Element einer Klasse kleiner zu halten, wenn ich vorher zu 100 % weiss, dass ein String nie mehr als 10 Zeichen haben wird:
class string_class { string a; string b; }; class char_class { char a[10]; char b[10]; };sizeof(string_class) ergeben bei mir 64 byte und char_class ist ja klar.
Mit 2 string Pointern komme ich, auch wenn die Klasse selbst dann nur 8 byte gross ist, letzlich auf einen ähnlichen Wert.
sizeof(string_class) gibt wie erwähnt 64 zurück,
bei capacity() beider strings, wenn ich diese mit 10 Zeichen initialisiere,kriege ich 15 zurück. Teste ich die grössen der Strings einzeln: sizeof(a) 32 bzw sizeof(*a) 32, wenn die Zeichenkette auf dem heap ist.Gibts eine Möglichkeit einen String bei der Initialisierung eine feste Grösse zuzuordnen?
danke für jede hilfe!
grüsse
chris
-
Nein, das gibt es so nicht.
Da müsstest du dir schon deine eigene String-Klasse schreiben, welche mit Strings fixer Größen arbeitet.
Allerdings kannst du dann auch gleich ein char[]-Array in einen Smart-Pointer packen. Und die String-Funktionen aus boost benutzen, weil std::string bietet ja kaum was und man muss beim ernsthaften Arbeiten mit Strings sowieso auf eine 3rd Party Bibliothek zurückgreifen.
-
ein sizeof() auf ein objekt bringt die groesse des objekts nicht wieviel speicher es besitzt.
was genau willst du denn machen? ich habe naemlich das gefuehl du willst etwas falsches machen...
-
naja eigentlich nichts bestimmtes, wollte nur mal wissen, ob man mit der string version ähnlich sparsam mit Speicherplatz umgehen kann wie mit normalen arrays, in einer Situation, wo die Grösse der Zeichenkette vorher bekannt ist.
Wäre interessant zu wissen, ob beispielsweise ein einfaches Adressbuch(name/strasse) unter Verwendung dieser beiden Techniken(boost ist mir leider noch nicht bekannt) in der String Version tatsächlich 3x mehr Speicher frisst als die ArrayVersion.
-
nein - fixe größe kannst du nicht angeben - aber das geht:
class string_class { string a; string b; string_class () {a.reserve (10); b.reserve (10);} };wie viel speicher a bzw b dann haben lässt sich leider nicht sagen, aber für 10 zeichen ist auf jeden fall platz - wenn du glück hast, dann 16 byte - aber so viel sollte bei nem char * mit new auch alloziert werden...
ich weiß allerdings nicht genau, was passiert, wenn string standard-mäßig mehr als 16 zeichen reserviert hat (was ja durchaus sinn macht, weil strings meist nicht für nur 3 zeichen verwendet werden ^^) und man weniger speicherplatz anfordert, als man bereits hat - denke ja fast mal, dass man dann trotzdem mehr hat ^^ naja - so ist das nun mal ^^
bb
-
nein - fixe größe kannst du nicht angeben - aber das geht:
class string_class { string a; string b; string_class () {a.reserve (10); b.reserve (10);} };wie viel speicher a bzw b dann haben lässt sich leider nicht sagen, aber für 10 zeichen ist auf jeden fall platz - wenn du glück hast, dann 16 byte - aber so viel sollte bei nem char * mit new auch alloziert werden...
ich weiß allerdings nicht genau, was passiert, wenn string standard-mäßig mehr als 16 zeichen reserviert hat (was ja durchaus sinn macht, weil strings meist nicht für nur 3 zeichen verwendet werden ^^) und man weniger speicherplatz anfordert, als man bereits hat - denke ja fast mal, dass man dann trotzdem mehr hat ^^ naja - so ist das nun mal ^^
bb
-
Wenn du dich wirklich um Speicherplatz sorgen musst, kommst du wohl nicht darum,
char*zu nutzen (oder in eine Klasse zu stecken). Aber ich denke, in den meisten Fällen kommt es auf die paar Bytes eh nicht drauf an - der Aufwand und die Fehleranfälligkeit mitchar*lohnen sich kaum.Aber das ist sowieso häufig so in C++, dass verschwenderisch mit Speicherplatz umgegangen wird (häufig zu Gunsten der Performance, siehe STL-Container).
-
chris19 schrieb:
Wäre interessant zu wissen, ob beispielsweise ein einfaches Adressbuch(name/strasse) unter Verwendung dieser beiden Techniken(boost ist mir leider noch nicht bekannt) in der String Version tatsächlich 3x mehr Speicher frisst als die ArrayVersion.
Adressbuch ist zB ein super Beispiel warum du eben keine statischen Arrays verwenden sollst. Denn wie willst du
Karl Maier
und
Karl-Heinz-Stefan Obermaierhausens-Hinterdingens
auf einen Nenner bringen?
Entwder ein Eintrag ist zu lang und kann so nicht vorkommen oder der andere verschwendet sinnlos Platz.Weiters sagt sizeof nicht aus wieviel Speicher einem Objekt gehoert, sondern wie gross das Objekt ist. Mach mal sizeof auf einen leeren string und einmal auf einen sehr langen string.
Du denkst komplett in die falsche Richtung. Wenn du wirklich total RAM sparen willst und jedes Bytes einzeln einsparen willst, dann schreib dir eine String Klasse die nur soviel Speicher allokiert wie notwending. std::string holt sich immer etwas mehr, damit einfuegeoperationen halbwegs schnell gehen.
idealerweise wuerde man dann aber ohne kopien arbeiten und nur mit memory mapped files hantieren - wenn denn performance so wichtig waere.
-
chris19 schrieb:
...wollte nur mal wissen, ob man mit der string version ähnlich sparsam mit Speicherplatz umgehen kann wie mit normalen arrays, in einer Situation, wo die Grösse der Zeichenkette vorher bekannt ist....

Also da hast Du aber schon mit Deinem ersten Versuch ins Klo gegriffen. :p

Erstmal macht std::string ziemlich viel Anderes als ein char-Array (std::string verwaltet eine Zeichenkette und nutzt dazu ggf. ein char-Array - muss es aber nicht).
Und zum Anderen hast Du spontan falsch gemessen. Stell' Dir mal eine (schlechte) Simpelimplementierung von std::string vor:
class simple_String { char* ps; size_t len; public: // verschiedene Konstruktoren, getter, setter und andere Memberfunktionen, ... };Was bekommst Du nun raus, wenn du ein "sizeof(simple_String)" machst ?
Und was, wenn Du diesen simple_String einmal 10 und ein anderes Mal 10.000 Zeichen verwalten lässt ?Ich sage einfach mal: Wenn man string/vector mit einfachen Arrays vergleichen will, muss man vorher auch die zusätzliche Funktionalität vo string/vector um die Arrays herumstricken, sonst sind wir wieder in "Äpfel und Birnen"-Land.
Gruß,
Simon2.