C-String in ein C-String einbetten (beliebige Position)
-
Wenn du mit dem Debugger durchgegangen bist, wirst du sicherlich in der Zeile
size_t gesamt = ms.len + len;gesehen haben, wie gross ms.len und len letztlich waren. Und wenn dort irgendwo ein falscher Wert rauskam, hast du einen Fehler gefunden.
Was manni sagt stimmt auch, da du die abschließende NULL nicht anhängst. Am Ende einfahc noch das hier reinschreiben:temp[gesamt] = 0;
-
Hi manni,
Mein Bild zeigt ja dass es soweit Funktioniert aber nach der gelungene einbettung kommen willkürliche Zeichen (Wie du sehen kannst) und ich denke mir diese bedeuten dass der reservierte Platz nicht belegt ist, nicht?
-
Zenter schrieb:
denke mir diese bedeuten dass der reservierte Platz nicht belegt ist, nicht?
Das bedeutet, das ein '\0' fehlt. Ob der Platz überhaupt allokiert wurde bzw. bis zu welchem Byte kann man daraus nicht ableiten. Deinem Text folgen halt Bytes mit irgendwelchen Bitmustern und das erste Byte mit '\0' beendet die Ausgabe.
-
Zuerst: Bitte schlag im Lexikon nach, was Logarithmus bedeutet! Sofort! (edit: Ok, hat sich wohl erledigt
)Zu deinem Problem: Es wird nicht zu viel reserviert. Das Problem, das sich hier äußert ist, dass deine Längen nicht richtig passen. Anscheinend benutzt du deine Längenangabe bei der Ausgabe gar nicht, sondern gibst deine Daten aus, als wären sie nullterminerte char-Arrays (sogenannte C-Strings)*. Was sie aber nicht sind, da du dich nirgends um Nullterminierung kümmerst.
An dem Programm könnte man noch vieles auf sehr leichte weise verbessern, der gravierendste Punkt ist derzeit wohl die manuelle Speicherverwaltung. Diese sollte ganz dringend von einer Ressourcenhalterklasse (RAII Idiom) übernommen werden (vector, Smartpointer oder etwas selbstgeschriebenes mit gleicher Funktionalität). Derzeit bekommst du Speicherlöcher beim kleinsten Programmierfehler sowie bei fast jeder Form von Exception. Mit RAII kann dir das gar nicht mehr passieren und du musst doch sogar um weniger kümmern.
*: Das ist zum Beispiel schlecht, da deine MStrings somit keine Nullzeichen enthalten können
.
-
Hi manni und Skymosho,
dies hat mein Problem gelöst, danke!
MfG
-
Hey Seppj,
danke für die viele Verbesserungsvorschlägen.
SeppJ schrieb:
Zuerst: Bitte schlag im Lexikon nach, was Logarithmus bedeutet! Sofort! (edit: Ok, hat sich wohl erledigt
)Ich weiß sehr wohl was Logarithmus bedeutet :), hatte es nur im Kopf .. doch ich meinte Algorithmus.
SeppJ schrieb:
da du dich nirgends um Nullterminierung kümmerst.
Das ist wahrscheinlich auch das Problem - ich werde die Klasse natürlich umgehend überarbeiten (Soweit funktioniert es aber ich muss sehen wo noch solche Schlüpflöcher sind).
Mit RAII hab ich noch garnichts gemacht aber sehr viel davon gehört, werde es mir aber ankucken und ggf. meine Klasse abändern.
MfG
-
Besser als das Einführen einer Nullterminierung wäre, konsequent überall die Länge zu benutzen. Die speicherst du doch sowieso schon mit ab. Du darfst eben nirgendwo Funktionen aus dem Header cstring benutzen und bei der Ausgabe nicht einfach dein Datenfeld wie einen C-String ausgeben. Gib die Zeichen deiner Zeichenkette einzeln oder mit write aus. Auf jeden Fall muss auch hier die Länge berücksichtigt werden.
-
Hey, danke Seppj
eine Frage die mit meine erste nichts zu tun hat. Die Funktionen die in <cstring> bzw <algorithm> usw. schon bereitstehen sind auf die Perfomance bezogen bestens programmiert? D.h Ob sie alles raus holen, oder sind selber geschriebene (nicht von mir, da noch Fehler nicht ausgeschlossen werden) von erfahrene Programmierer besser geeignet?
Damit will ich nicht sagen dass vllt Microsekunden damit gespart werden können sondern etwas mehr. Es könnte ja sein das solche Funktionen viele Umwege gehen um ans Ziel zu gelangen.Die Frage dient nur zur Persönlichen Information bzw Interesse
MfG
-
Die "Algorithmen" aus algorithm sind letztlich normale Loops, die das machen was sie sollen.
Wenn du auf den C++ Referenz-Seiten guckst wird oft eine kleine Beispiel-Implementierung angeboten, viel mehr ist das meist auch nicht. Normalerweise sind noch sowas wie Debuginformationen oder sowas dabei, damit man Fehler einfacher findet, aber das wars auch.Die Komplexität, also etwa die Performance, ist durch den Standard vorgegeben. Aber das sind halt Komplexitätsklassen, die in der Realität nicht viel aussagen.
Und es gilt immer. Je mehr du über deine Daten und deine Probleme weist, desto besser kannst du optimieren. Aber desto spezieller ist diese Implementierung auch.
Die std::Algorithmen verlangen einige Operationen, die unterstützt werden müssen und dann arbeiten sie. Und das mit jeglichen Daten, die diese Operationen unterstützen.
Weist du nun mehr über ein Objekt (seien es Interna oder Implementierungen) kannst du darauf abzielend optimieren und kriegst so meistens ein bisschen besseren Speed raus. Aber das geht dann nur für diese Objekte und nicht für alles andere.
-
Skym0sh0 schrieb:
Die "Algorithmen" aus algorithm sind letztlich normale Loops, die das machen was sie sollen.
Wenn du auf den C++ Referenz-Seiten guckst wird oft eine kleine Beispiel-Implementierung angeboten, viel mehr ist das meist auch nicht. Normalerweise sind noch sowas wie Debuginformationen oder sowas dabei, damit man Fehler einfacher findet, aber das wars auch.Das ist nicht wahr. Zumindest beim GCC sind die so gut optimiert, wie es geht. copy wird zum Beispiel automatisch zu memmove (trivial kopierbare Objekte). Wenn das nicht geht, dann wird wenigstens die Schleife ggf. vom Optimierer entrollt (random access iteratoren) und erst wenn das auch nicht mehr geht, dann ist es eine naive Schleife. Außerdem werden parallele Algorithmen benutzt, sofern man den entsprechenden Compilerschalter umlegt. Das heißt man ist so schnell wie eine optimierte Funktion, aber dank Template-/Optimierermagie kann man immer copy benutzen, ohne sich Gedanken zu machen.
Ich vermute mal ganz stark, dass der andere große STL-Schreiber (Microsoft), das nicht großartig anders handhabt. Die Geschwindigkeit der STL-Implementierung ist eine wunderbare Möglichkeit zum Schwanzvergleich zwischen den verschiedenen Machern.