Eigenen Typ "String" in c++ deffinieren - wie?

[volkard]

Don06 schrieb:

Falls es dich noch interessiert, hier ein uszug aus der Delphi-Doku zu "ShortString", der aus Kompatibilität zu TP auch heute noch zur Verfügung steht.

danke. das hat die sache noch hübsch abgerundet.

[Bitsy]

volkard schrieb:

Bitsy schrieb:

Dazu muß man aber auch sicherstellen, daß es einfach nicht gelingt, nachträglich ein 0-Zeichen in dem String unterzubringen.

WARUM?

Für eine solche Operation wäre eine von String abgeleitete Klasse sinnvoll.

WARUM?

Ich sehe die Gefahr nicht. In einen std::string kann ich auch 0-Zeichen reinstopfen, wie ich mag und habe ich damit keinen Ärger.

Ganz einfach 'axiomatisch'. Wenn du irgendwann aus irgendwelchen Gründen den eigentlichen cString mal wieder rausholst, kann der Zirkus losgehen.
Wie ich geschrieben hatte, eine abgeleitete Klasse bei der das 0 erlaubt ist, z.B. mit Namen stringbuffer, sagt mir da rein gefühlsmäßig mehr zu.

Ich glaube, ich hatte damals sogar Gründe dafür, frag nicht, ist so lange her.

[JnZn558]

Dravere schrieb:

Ehm, hä? Ich verstehe immer noch nicht, was gegen die Klasse std::string spricht
Im Gegenteil, es erscheint mir die bessere Lösung zu sein. std::string führt schliesslich intern die Grösse des Strings mit.

Zur Lösung von Nexus:
Das geht nur, so lange das Array vorhanden ist. Sobald du ein Zeiger hast, geht diese Lösung nicht mehr.

Grüssli

so kannst du verstehen, das erwähnen lieber std::string zu bevorzugen ist ein netter hinweis, doch jeder hat vl ein vorhaben, std::string erst mal zu verzichten und eigene string zu bauen, um mehr kenntnis zu erwerben. diese vl nur zum Testzwecke.

[Nexus]

JnZn558 schrieb:

so kannst du verstehen, das erwähnen lieber std::string zu bevorzugen ist ein netter hinweis, doch jeder hat vl ein vorhaben, std::string erst mal zu verzichten und eigene string zu bauen, um mehr kenntnis zu erwerben. diese vl nur zum Testzwecke.

Hättest du den Thread gelesen, wüsstest du, dass es um etwas völlig anderes geht.

[Simon2]

Bitsy schrieb:

...Wenn du irgendwann aus irgendwelchen Gründen den eigentlichen cString mal wieder rausholst, kann der Zirkus losgehen....

Zum einen gibt's keinen "eigentlichen cString da drin" - es ist vollkommen egal, wie std::string seine Daten intern organisiert.

Zum Anderen: Wieso sollte das mit einem "Pascalstring" anders sein, wenn man "den eigentlichen cString wieder rausholt" ?
Du erzählst hier von einer grundlegenden Schwäche von CStrings ... egal, ob Du sie aus irgendeinem Datentyp konvertierst und wenn, aus welchem.

Gruß,

Simon2.

[Bitsy]

...aus einem selbstkonstruierten. Über den STL-string selbst habe ich gar kein Wort verloren.

[Simon2]

Bitsy schrieb:

...aus einem selbstkonstruierten....

Auch wenn der CString aus einem von Dir selbst konstruierten Stringobjekt konstruiert wurde, hat er keine Möglichkeit, mehrere '\0'-en zu enthalten.
... oder er ist kein CString (oder exakter gesprochen: "NTCS" = "Null Terminated Character String").

Die Quelle ist egal: JEDER CString hat diese Schwäche.

Gruß,

Simon2.

[Nexus]

Was aber nicht allzu dramatisch sein sollte. Oder wie oft benutzt ihr '\0' als Zeichen im std::string ?

[Simon2]

Nexus schrieb:

Was aber nicht allzu dramatisch sein sollte. Oder wie oft benutzt ihr '\0' als Zeichen im std::string ?

Sehe ich ja auch so ... aber es ist als einziges (vermeintliches) Argument gegen std::string stehengeblieben und das ist auch noch falsch.

Gruß,

Simon2.

[knivil]

Ganz einfach 'axiomatisch'. Wenn du irgendwann aus irgendwelchen Gründen den eigentlichen cString mal wieder rausholst, kann der Zirkus losgehen.

Nein nicht wirklich. Da length() eine Laenge liefert und man mit 0-terminierten Strings z.B. mittels strncat, strncmp, strncpy ... arbeiten kann. Somit ist die 0-terminierung fuer cStrings nicht zwingend noetig. Diese Funktionen sind auch den normalen vorzuziehen, da sie bei richtiger Verwendung die Gefahr fuer Bufferoverflows, code injection etc vermindern. Leider sind sie aus Bequemlichkeit recht selten im Einsatz oder verbreitet.

[Simon2]

knivil schrieb:

...

Hmmm, ich sehe nicht, wie die n-Varianten (die ich natürlich auch vorziehe - mal abgesehen von der a) oftmals falschen Anwendung und b) der Schwäche (IMHO) in der Definition) bei "doppelten \0-en" helfen soll. Z.B. zu strncpy(): "...If the length of the C string in source is less than num, only the content up to the terminating null-character is copied...."

Ich sehe das schon so, dass "CStrings" per definitionem auf Nullterminierung angewiesen sind...
Selbst da, wo man mittels "n-Funktionen" die Wahrscheinlichkeit von Bufferoverflows verringert, muss man die Nullterminierung sicherstellen, wenn man wieder "vernünftig" damit arbeiten will....

Gruß,

Simon2.