String kürzen
-
MFK schrieb:
Ich halte das für Quatsch.
Da bist du nicht der einzige. Es ist schlichtweg gesagt, vollkommener Blödsinn, wegen einem Zeichen realloc zu bemühen. Dynamischen Speicher reservieren und freigeben kostet nunmal Zeit. Und da sollte man sich schon sinnvolle Strategien erarbeiten, wann und wie man das macht. Zudem reicht ein realloc allein auch nicht aus. Das abschliessende Nullzeichen musst man trotzdem verschieben.
-
Da bist du nicht der einzige. Es ist schlichtweg gesagt, vollkommener Blödsinn, wegen einem Zeichen realloc zu bemühen. Dynamischen Speicher reservieren und freigeben kostet nunmal Zeit. Und da sollte man sich schon sinnvolle Strategien erarbeiten, wann und wie man das macht. Zudem reicht ein realloc allein auch nicht aus. Das abschliessende Nullzeichen musst man trotzdem verschieben.
Ddu hast wohl noch nie auf Ressourcen-knappen Maschinen geschrieben, oder?
Tatsache ist, dass man lieber realloc bemueht als am Ende Memoryleichen zu haben. Stell dir mal vor, du sagst das bei jedem deiner Strings.. "Och, wegen einem byte, da schreib ich kein realloc mehr". Bei 1024 Strings waeren das 1kb. Usw.
-
@[0x[90]| : Schön, das wenigstens auch Du das so siehst!
-
[0x[90]| schrieb:
Ddu hast wohl noch nie auf Ressourcen-knappen Maschinen geschrieben, oder?
Doch, hab ich. Allerdings mit weniger als 32KB musste ich noch nie auskommen. Und selbst da war eher die Geschwindigkeit das Problem, als das Einsparen von diesem oder jenen Byte.
[0x[90]| schrieb:
Tatsache ist, dass man lieber realloc bemueht als am Ende Memoryleichen zu haben.
Wo hast du denn Memoryleichen, wenn du einfach nur das Nullzeichen änderst? Nirgendwo! Tatsache ist, dass man seiner Situation entsprechend vorgehen soll. Und wenn Bambusjunge für gängige x86 Hardware programmiert, dann gibt es keinen Grund wegen einem Byte realloc aufzurufen. Und das war selbst zu DOS Zeiten schon so.
[0x[90]| schrieb:
Stell dir mal vor, du sagst das bei jedem deiner Strings.. "Och, wegen einem byte, da schreib ich kein realloc mehr". Bei 1024 Strings waeren das 1kb. Usw.
Na und? Was ist heutzutage 1 KB? Vielleicht hast du's noch nicht mitbekommen, aber wir leben nicht mehr in der Steinzeit. Jedes Programm hat heutzutage mehr ungenutzten Speicher durch Alignment, als du mit String-Byte-Einsparungen wieder reinholen kannst.
Versteh mich nicht falsch, ich bin auch jemand, der optimiert, wenn es sinnvoll ist. Nur hier sehe ich keinen Grund dafür. Wozu 2 Sachen machen, wenn es mit einer auch getan ist. Und wenn du dich mal näher mit Speichermanagern befasst, dann wirst du 'eh merken, dass es letztendlich aufs gleiche hinausläuft, ob du realloc aufrufst oder nicht. Denn in den meisten Fällen kann das gewonnene Byte gar nicht wieder verwendet werden, weil es nicht aligned ist oder bis zum nächsten belegten Speicherbereich zu wenig Reserve ist, um es für irgendwas sinnvoll zu nutzen.
-
Das sind Mutmassungen welche du hier aufstellst. "Och, das Byte, ist vllt. sowieso nicht nutzbar". Ich koennte auch sagen: "Och, der Pointer, den muss ich nicht malloc'en, der Zeigt schon irgendwo auf geeigneten Speicher"
Ich fuer meinen Teil habe eine Funktion mit welcher ich strings in buffer kopiere und gleichzeitig den speicher (re)allociere. Als alternative koennte man free(); und strdup(); verwenden. Waere aber umstaendlicher.
-
[0x[90]| schrieb:
Das sind Mutmassungen welche du hier aufstellst.
Nee, das ist einfach nur ein bisschen Wahrscheinlichkeitsrechnung.
[0x[90]| schrieb:
Ich koennte auch sagen: "Och, der Pointer, den muss ich nicht malloc'en, der Zeigt schon irgendwo auf geeigneten Speicher"
Ich diskutiere gerne weiter, aber nur wenn du sinnvolle Argumente bringst.
[0x[90]| schrieb:
Ich fuer meinen Teil habe eine Funktion mit welcher ich strings in buffer kopiere und gleichzeitig den speicher (re)allociere. Als alternative koennte man free(); und strdup(); verwenden. Waere aber umstaendlicher.
Und alles nur um einen String um 1 (in Worten ein!) Zeichen zu kürzen? Na super. Du schiesst sicherlich auch mit Kanonen auf Spatzen.
-
Apropos Mutmassung: Wer sagt, das der Speicher des Strings mit malloc geholt wurde?
Bye, TGGC (Denken, und gut ist.)
-
warum '\0' anhängen!?!?!?!
ist ja ein "ZAHLENARRAY"!!!mfG (c)h
PS.: ich würde den speicher auf alle fälle mal freigeben
-
chille07 schrieb:
warum '\0' anhängen!?!?!?!
ist ja ein "ZAHLENARRAY"!!!Niemand hat von anhängen gesprochen. Ausserdem war die Frage
Bambusjunge schrieb:
Habe einen String Zahlen[], den ich um ein Zeichen kürzen muß.
Und in C sind Strings immer noch nullterminiert. Keine Ahnung wie du auf "ZAHLENARRAY" kommst.
Wer lesen kann, ist klar im Vorteil.
-
mit dem "anhängen" habe ich mich verschrieben, ich meinte das letzte Zeichen mit '\0' überschreiben (das letzte das nicht '\0' ist)
"String" sind eigendlich Zeichenketten, jep..
ich habs mit einem Array verwechselt... dann wäre eher ein Zahlenarray gemeint"String zahlen[]"
mfG (c)h
-
chille07 schrieb:
mit dem "anhängen" habe ich mich verschrieben, ich meinte das letzte Zeichen mit '\0' überschreiben (das letzte das nicht '\0' ist)
"String" sind eigendlich Zeichenketten, jep..
ich habs mit einem Array verwechselt... dann wäre eher ein Zahlenarray gemeint"String zahlen[]"
mfG (c)h
da wir hier im ansi c forum sind, ging es wohl eher um nen string zahlen[] .. und n string lässt sich nur mit nem array von char darstellen.. und das kann man ja ruhig mit nem array verwechseln, is ja eins :). und n array is aber nicht immer n zahlenarray...
-
Apropos Mutmassung: Wer sagt, das der Speicher des Strings mit malloc geholt wurde?
Niemand. Kann natuerlich auch sein, dass er Variablen auf dem Stack verwendet. Ist es dann aber nicht so, dass durch umsetzen der \0 Speicher auch verloren geht? Ich meine, strlen gibt die laenge bis zur \0. Habe ich nun ein char bla[10] und setze \0 auf bla[4], ist alles vom 5ten bis zum letzten array weg, sofern man sich die tatsaechliche laenge nicht merkt, oder?
-
Durch Umsetzen des Nullzeichens geht überhaupt kein Speicher "verloren", egal wo der Speicher allokiert wurde. Das Nullzeichen ist nur eine Markierung für die Stringfunktionen. Mit der Größe des allokierten Speichers hat das gar nichts zu tun.
-
Ja, das ist klar. Du verstehst jedoch nicht das was ich sagen wollte: Wenn du nun die string funktion strlen nutzt um, nach setzen des \0 Zeichens die laenge des Puffers zu erfahren, wirst du nicht die komplette laenge zurueck bekommen sondern nur die, bis zum \0. D.h.: Hat man vorher die laenge des Puffers in einer variable abgespeichert, so wird man nicht mehr an sie herankommen. Oder etwa doch?
-
[0x[90]| schrieb:
Wenn du nun die string funktion strlen nutzt um, nach setzen des \0 Zeichens die laenge des Puffers zu erfahren, wirst du nicht die komplette laenge zurueck bekommen sondern nur die, bis zum \0.
strlen liefert auch vor dem Setzen eines Nullzeichens nicht die komplette Länge des Puffers. strlen ist nicht dazu da, die Länge des Puffers zu ermittlen. strlen liefert die Position des terminierenden Nullzeichen. Mit der Größe des allokierten Speichers hat das nichts zu tun.
Es gibt in Standard-C und Standard-C++ keine Funktion, die über einen Zeiger die Länge des allokierten Speichers liefert. Für Arrays kann man sizeof benutzen, ansonsten war's das.
D.h.: Hat man vorher die laenge des Puffers in einer variable abgespeichert, so wird man nicht mehr an sie herankommen. Oder etwa doch?
Verstehe ich nicht. Du kannst die Länge des Puffers und die Position des Nullzeichens in zwei getrennten Variablen speichern. Nochmal: Diese beiden Werte haben nichts miteinander zu tun.
-
Wenn ich mich recht erinner dient strlen() lediglich dazu, die Länge eines Strings zu ermitteln und fertig. Und da ist es schon sinnvoll, wenn strlen beim finden des Zeichens '\0' aufhört zu zählen und nicht noch die restlichen reservierten Bytes mitzählt. Das wäre ein falsches Ergebnis.
Edit: Ein Tick zu langsam
-
Ja mensch, dass weiss ich doch. Es ging aber doch darum, dass man den Speicher nach \0 verliert, wenn man nicht weiss wie gross der Puffer wirklich ist. D.h: Wenn \0 am Ende gesetzt ist, weiss ich wie gross er ist, strlen(). Setze ich \0 nun aber an [4], ist der rest weg. (vorausgesetzt ich habe die echte laenge nicht abgespeichert)
-
[0x[90]| schrieb:
Es ging aber doch darum, dass man den Speicher nach \0 verliert, wenn man nicht weiss wie gross der Puffer wirklich ist.
Mir ist nicht klar, was du in diesem Zusammenhang mit "verlieren" meinst.
D.h: Wenn \0 am Ende gesetzt ist, weiss ich wie gross er ist, strlen().
Nein, strlen + 1.
Setze ich \0 nun aber an [4], ist der rest weg.
Was meinst du mit "weg"? Durch Schreibzugriffe verschwindet kein Speicher. delete stört sich nicht am Inhalt des Speichers. Ich kann ja auch jederzeit wieder einen längeren String reinschreiben, solange ich die ursprüngliche Länge nicht überschreite.
-
Ich meine mit verlieren, dass man ihn wohl nicht mehr verwenden kann, da man nicht weiss wie weit der Speicher noch reicht. Du hast einen buffer, von welchem strlen() dir 4 zurueckgibt. Du hast davor die \0 jedoch auf die 5te stelle des buffers geschoben. D.h. du kennst den Wert der anfaenglichen initialisierung des Buffers nicht mehr. Der buffer koennte 10byte lang sein, oder 1024.
-
Du hast einen buffer, von welchem strlen() dir 4 zurueckgibt. Du hast davor die \0 jedoch auf die 5te stelle des buffers geschoben. D.h. du kennst den Wert der anfaenglichen initialisierung des Buffers nicht mehr. Der buffer koennte 10byte lang sein, oder 1024.
Ich weiß genau, wie lang der Puffer ist. Was mir strlen zurückgibt, interessiert mich gar nicht. Wenn ich mir die Länge eines Puffers merken muss, dann nutze ich dazu eine separate Variable, nicht strlen. Das ist nicht der Sinn und Zweck von strlen.
Wenn du strlen zur Bestimmung von Pufferlängen benutzt, dann ist klar, dass du nach jeder Änderung der Stringlänge realloc machen musst. Das liegt aber daran, dass strlen dafür ein ungeeignetes Werkzeug ist.
Du brauchst auch jedesmal neue Radmuttern, wenn du zum Radwechsel die Bohrmaschine benutzt.
