Zustand eines STL Strings

Hallo.

Gibt es eine Möglichkeit, dass man bei einem std::string den Zustand abfragen kann?
Mittels size() und empty() erfährt man wieviel bzw. ob etwas in einem String steht, jedoch weiß man nie ob quasi vorher ein Leerstring gesetzt wurde oder nicht.

Ich bräuchte so eine Art active() --> true = string wurde irgendwas zugewiesen, false = wurde noch nie benutzt

Mir ist klar, man könnte das ganze mittels (shared-) pointer lösen, aber irgendwie wäre es mir lieber, wenn ich in der std::string klasse was wichtiges übersehen hätte

DANKE
lg

SeppJ

Die Frage macht keinen Sinn. Ein std::string ist, wie jede gute Klasse, so designed, dass es keine ungültigen oder inaktiven Objekte gibt. Ist er erstellt, ist er voll funktionsfähig.

Zwei Ansätze:
1. Du erklärst uns, was du wirklich vor hast, nicht, wie du dir die technische Umsetzung vorstellst. Dann sagen wir dir, wie man es richtig machst.
2. Falls dein Problem wirklich nach einen aktivierbaren String verlangt, was ich bezweifle, dann musst du dir das eben selber schreiben. Das Problem ist so exotisch, da kenne ich keine fertige Lösung (ironischerweise entspricht ein Zeiger auf einen C-String fast schon dem, was du suchst. er ist bloß etwas unhandlich). So schwer sollte das nicht sein, einfach einen string und einen bool kapseln und deine Aktivierungsfunktionen dazu packen.

Mach jetzt nicht einfach 2., sondern fang mit 1. an, das ist sehr wahrscheinlich der bessere Ansatz.

wenn man einem string einen leerstring zuweist, dann passiert doch nichts. also kannst du den zustand eines unbenutzten strings nicht von dem eines string, dem ein leerstring zugewiesen wurde, unterschieden.

ich sehe jetzt auch keinen fall wo man so etwas braucht.

Youka

Warum genügt der leere String nicht als Angabe der Ungültigkeit? Alternative wäre SeppJs Vorschlag mit dem zusätzlichen bool, aber das wäre unschön.

Ich lese zb. ein config-file mit div. Werten aus und da habe ich folgenden Zustand:
-) CfgValue ist nicht vorhanden
-) CfgValue ist vorhanden und ein Leerstring oder ein x-beliebiger Wert.

In diesem Fall sagt eben ein "nicht vorhanden" etwas anderes aus als ein Leerstring.

Ich habe einen extrem alten vorhandenen Sourcecode und da wurde eine String-Klasse von meinen Vorgängern selbst gebastelt und diese Klasse kann eben diese drei Zustände.

Da ich gerne diese String-Klasse durch std::string ersetzten möchte, habe ich wie gesagt nur das eine Problem mit dem dritten Zustand

grob aus dem bauch geschätzt:
stellst du dein config-file als std::map< <enum-typ>, std::string> dar? wenn ja, dann kannst du da die property - wenn sie nicht in der datei ist - einfach nicht in die map eintragen, was dann beim suchen auffällt.

daddy_felix

boost::optional

oder eine eigene Wrapper-Klasse

asdfsadf schrieb:

grob aus dem bauch geschätzt:
stellst du dein config-file als std::map< <enum-typ>, std::string> dar?

Nein wird nicht so abgebildet, sondern direkt als string-values in div. Klassen.

daddy_felix schrieb:

oder eine eigene Wrapper-Klasse

Ja wäre auch eine Möglichkeit, nur wie sieht es dann mit der Performance aus? Wird die nicht um einiges schlechter.

Marthog

stringasker schrieb:

Ja wäre auch eine Möglichkeit, nur wie sieht es dann mit der Performance aus? Wird die nicht um einiges schlechter.

Du musst immer checken, ob der string vorhanden ist und das braucht natürlich ein bisschen Leistung, aber da du das auch willst, sehe ich da kein Problem. Außerdem solltest du die move-operatoren auch überladen, sonst verlierst du hier wieder Performance.

daddy_felix

stringasker schrieb:

daddy_felix schrieb:

oder eine eigene Wrapper-Klasse

Ja wäre auch eine Möglichkeit, nur wie sieht es dann mit der Performance aus? Wird die nicht um einiges schlechter.

Die Performance wird sicherlich schlechter, aber garantiert nicht "um einiges".

Mach dir um Performance erstmal keine Gedanken. Wenn dein Programm zu langsam ist und du gemessen(!!!) hast, dass diese Wrapper-Klasse für die miese Performance verantwortlich ist, kannst du das immer noch ändern.

Marthog schrieb:

Außerdem solltest du die move-operatoren auch überladen, sonst verlierst du hier wieder Performance.

Meinst du hier Move/R‑Value-Referenz oder append/insert/operator+/etc-Methoden?

@daddy_felix:
ok. Danke!