Wie neue Memberfunktion zu std::string adden (Wrapperfunktionen, um CString unter linux zu "simulieren")

[Caligulaminus]

rean schrieb:

Damit wirst du dir ein schönes Speicherleck einfangen weil der Destruktor von std::string nicht virtual ist. Außerdem ist die Verwendung von using namespace std; in Header-Dateien auch nicht grad toll.

Ich schrieb:
"Achtung! Das hier ist hingeschmiert."

Aber danke für den Hinweis.

[ChangeMyString]

Wow, danke für all die Antworten

So wie ich das verstanden habe will er erreichen, dass er seinen CString-Client-Code möglichst nicht ändern muss.

Genau so ist es, deswegen ist deine Lösung, Nexus, leider sehr umständlich in meinem Fall

noch eine dritte Möglichkeit: Alles auf std::string zu portieren

Dann muss ich, genau wie beim Lösungsansatz oben, wieder alles umschreiben

C++? Vererbung!
Ich hab mal sowas gemacht:
[...]

Danke, ich blick den Code zwar nicht so 100% aber ich versuchs dann mal.

Gibts sonst keine Lösung für das Problem?
Spricht irgendwas dagegen einfach in den standardt Include Files rumzuwerkeln und std::string so zu erweitern?

mfg

[SeppJ]

ChangeMyString schrieb:

Spricht irgendwas dagegen einfach in den standardt Include Files rumzuwerkeln und std::string so zu erweitern?

Portabilität. Ansonsten darfst du natürlich an deiner Standardbibliothek rumschustern wie du willst.

[Nexus]

Ich verstehe immer noch nicht, warum du dich so an std::string festklammerst. Dessen Schnittstelle nützt dir ja eh nichts, weil die Memberfunktionen bei CString eine andere Namenskonvention haben, du also doch viel ändern müsstest. Wieso also keine eigene Klasse, die std::string enthält und das Interface von CString anbietet?

Ja, gegen das Verändern der Standardbibliothek spricht die Vernunft. Dein Code wird so maximal unportabel, ist an eine einzige Version gebunden, und kann sogar undefiniertes Verhalten auslösen (denn ein Compiler darf Meta-Informationen über seine Standardbibliothek besitzen, z.B. zu Optimierungs- oder Debugzwecken).

[ChangeMyString]

Ok vielen Dank für eure Hilfe, ich werd jetzt eine eigene Klasse machen die das Interface von CString anbietet

mfg

[Tachyon]

SeppJ schrieb:

ChangeMyString schrieb:

Spricht irgendwas dagegen einfach in den standardt Include Files rumzuwerkeln und std::string so zu erweitern?

Portabilität. Ansonsten darfst du natürlich an deiner Standardbibliothek rumschustern wie du willst.

Es ist tatsächlich so, dass laut Standard alle Änderungen im Namensraum std:: (mit genau einer Ausnahme) ins Reich des UB definiert werden.

[SeppJ]

Tachyon schrieb:

Es ist tatsächlich so, dass laut Standard alle Änderungen im Namensraum std:: (mit genau einer Ausnahme) ins Reich des UB definiert werden.

Ja, aber praktisch würde das schon funktionieren. Trotzdem ist es natürlich eine schlechte Idee, weil maximal unportabel.

[Nexus]

ChangeMyString schrieb:

Ok vielen Dank für eure Hilfe, ich werd jetzt eine eigene Klasse machen die das Interface von CString anbietet

Ich würde auch mal im Internet suchen. Vielleicht gibt es Leute, die schon vor dem gleichen Problem gestanden haben. String-Implementierungen gibt es sicher auch Millionen, möglicherweise kommt ja eine deinen Wünschen recht nahe.

[Tachyon]

Nexus schrieb:

ChangeMyString schrieb:

Ok vielen Dank für eure Hilfe, ich werd jetzt eine eigene Klasse machen die das Interface von CString anbietet

Ich würde auch mal im Internet suchen. Vielleicht gibt es Leute, die schon vor dem gleichen Problem gestanden haben. String-Implementierungen gibt es sicher auch Millionen, möglicherweise kommt ja eine deinen Wünschen recht nahe.

Ist die CString-Klasse nicht auch einfach nur ein Klassen-Template? Man könnte sich das Ding ja kopieren und dann zum Funktionieren bringen. *hüstel*

[wxSkip]

@Tachyon: Was ist die Ausnahme?