Erweitern von String-Funktionalität

[Niki]

Hallo Leute,

habe endlich mal wieder Zeit etwas privat zu proggen, und will bei den Strings weitermachen. Momentan benutze ich typedef's von std::basic_string:

Code: Alles auswählen

typedef std::basic_string<QxNativeChar, std::char_traits<QxNativeChar>, std::allocator<QxNativeChar> >  QxNativeString;
typedef std::basic_string<QxUtf8, std::char_traits<QxUtf8>, std::allocator<QxUtf8> >                    QxUtf8String;
typedef std::basic_string<QxUtf16, std::char_traits<QxUtf16>, std::allocator<QxUtf16> >                 QxUtf16String;
typedef std::basic_string<QxUtf32, std::char_traits<QxUtf32>, std::allocator<QxUtf32> >                 QxUtf32String;

Das funktioniert natürlich, ist aber für meinem Geschmack etwas limitierend, wenn es darum geht die Strings mit zusätzlicher Funktionalität zu versehen. Wie genau diese "zusätzliche Funktionalität" aussieht, das will ich hier mal undefiniert lassen. Als Diskussionsbeispiel könnte man sich jedoch eine Methode à la String::AppendPathComponent(const String & rPathComponent) vorstellen, welche eine Pfadkomponente an einen String anhängt und sich automatisch um Pfadseparatoren kümmert.

Nun habe ich mehrfach gelesen, dass man von std::basic_string nicht ableiten soll. Also suche ich nun nach Alternativen, und wollte mal hören für welche Alternative Ihr Euch eintscheiden würdet. Spontan fallen mir folgende Ansätze eine:

(1) Hilfsklassen mit statischen Methoden schreiben. Zum Beipsiel

Code: Alles auswählen

String StringUtils::AppendPathComponent(const String & rPath, const String & rPathComponent);

(2) std::basic_string wrappen

Code: Alles auswählen

class QxUtf8String
{
    ...
	
    private:
	    std::basic_string<QxUtf8, std::char_traits<QxUtf8>, std::allocator<QxUtf8>> m_string;
};

(3) std::basic_string nicht benutzen und eigene Template-Basisklasse schreiben, von der ich ableiten kann.

(4) Was auch immer Euch und mir noch so einfällt.

Freue mich auf Eure Meinungen.

[eXile]

So wie in (1), nur nicht als statische Methode einer wie auch immer gearteten Hilfsklasse, sondern als freie Funktion in einem eigenen Namespace:

Code: Alles auswählen

namespace StringUtils
{
    String AppendPathComponent(const String & rPath, const String & rPathComponent);
}

[Niki]

So wie in (1), nur nicht als statische Methode einer wie auch immer gearteten Hilfsklasse, sondern als freie Funktion in einem eigenen Namespace:[/code]

Danke eXile! Deine Antwort bringt mich allerdings ein wenig ins Grübeln. Ich schreibe relativ oft Hilfsklassen, die nur statische Hilfsmethoden enthalten. Logisch, dass Dein Ansatz mit den freien Funktionen im Namespace mindestens ebenso gut funktioniert. Allerdings frage ich mich nun ob Deine Variante irgendwelche Vorteile birgt, die mir vielleicht unbekannt sind? Wenn ja, dann wäre das sehr interessant zu wissen. Man lernt halt nie aus :)

Zumindest der generierte Code sollte doch eigentlich derselbe sein, oder nicht? Muss ich unbedingt mal im Assembler-Listing überprüfen. (EDIT: Ja, der generierte Code ist erwartungsgemäß identisch)

[Sternmull]

Im Gegensatz zu einem Namespace erwartet man von einer Klasse normalerweise das man davon Instanzen erzeugn kann die dann auch Zustand halten. Um das zu verhindern muss man schon etwas Hand anlegen (private Konstruktoren). Um zu erkennen das eine Klasse für den Verwendungszweck eines Namespaces "missbraucht" wird, muss man also erst mal genauer hingucken.
Namespaces bieten gegenüber einer Klasse auch die Möglichkeit sie mehrfach auf/zu zu machen.

[dot]

Schau dir mal an, was Argument Dependent Lookup (aka Koenig Lookup) ist... ;)

[Niki]

Schau dir mal an, was Argument Dependent Lookup (aka Koenig Lookup) ist... ;)

Das ist doch dieses Ding wo der Compiler Funktionen in den Namespaces sucht in denen die Argumenttypen definiert sind?! Damit habe ich vor tausend Jahren mal rumgespielt... ich glaube um das STL-Streaming via "operator <<" mit eigenen Typen zu erweitern, wenn ich mich recht entsinne. Mir ist jetzt nur nicht ganz klar, worauf du da hinaus willst. Hattest du da vielleicht irgendeinen genialen Gedankengang, der sich gerade vor mir verstecken will?

[Niki]

Im Gegensatz zu einem Namespace erwartet man von einer Klasse normalerweise das man davon Instanzen erzeugn kann die dann auch Zustand halten.

Ja, da hast du irgendwie schon recht. Diese statischen Klassen sind bei mir eine Gewohnheitssache, weil ich beruflich sehr viel Code schreiben musste, der möglichst einfach zwischen C++, C#, und Java portierbar sein musste. Bedeutet jetzt nicht, dass das deswegen so viel extra Aufwand gewesen wäre, aber hat sich halt so ergeben.

[dot]

Mir ist jetzt nur nicht ganz klar, worauf du da hinaus willst. Hattest du da vielleicht irgendeinen genialen Gedankengang, der sich gerade vor mir verstecken will?

ADL ist eines der imo wichtigsten Features von C++ und von grundlegender Bedeutung für generischen Code und Erweiterbarkeit. Deine statischen Methoden können nicht wirklich von ADL Profitieren, freie Funktionen dagegen schon... ;)

[Niki]

Deine statischen Methoden können nicht wirklich von ADL Profitieren, freie Funktionen dagegen schon... ;)

Ach so! Ich hatte das Gefühl, dass du ein bestimmtes "Schema" für meine String-Erweiterungen im Kopf hattest; à la ADL auf eine bestimmte Art und Weise zu benutzen :) Den allgemeinen Vorteil von ADL verstehe ich schon. Ich habe mich schon vor Stunden für freie Funktionen entschieden, war aber neugierig ob du dir bestimmte Ansätze vorgestellt hattest.

[Jonathan]

Also, wenn ich Erweiterung der String-Funktionalität höre, denke ich zuerst an die ganzen Boost-Bibliotheken, z.b. die String-Algorithms oder Filesystem. Die erweitern auch den String-Typ in keinster Weise, und ich wüsste auch nicht, was dafür sprechen sollte. "Eine Klasse - eine Aufgabe" so sagte man doch. Wieso sollte ich mich mit einer komplexen Klasse rumschlagen, wenn ich den Großteil der Funktionalität niemals benötigen werde? Außerdem kann ja ein String alles und gar nichts repräsentieren, die Stringklasse sollte also auch nur das Abdecken, was ein String ist, und nicht all das, wofür man einen String möglicherweise verwenden könnte.

[Niki]

...ganzen Boost-Bibliotheken, z.b. die String-Algorithms oder Filesystem. Die erweitern auch den String-Typ in keinster Weise, und ich wüsste auch nicht, was dafür sprechen sollte.

Jupp! Die Entscheidung nicht den String-Typ selbst zu erweitern ist schon längst gefallen. Stattdessen werden freie Funktionen benutzt.

Wieso sollte ich mich mit einer komplexen Klasse rumschlagen, wenn ich den Großteil der Funktionalität niemals benötigen werde?

Da hat sicher jeder seine eigene Meinung. So sind die Standard C++ Strings aus meiner Sicht oberpeinlich. Das ich mir da mit UTF-Konvertierungen, Localized Compares, etc. noch einen abkrampfen muss ist schon der Hammer. Als Alternative kann ich ICU oder Boost nutzen, um eine Funktionalität zu erhalten die schon lange in den Standard Bibliotheken enthalten sein sollte. Zumindest ist das meine Meinung zum Thema.

[Jonathan]

Ich gebe zu, dass ich im Bereich Unicode bisher wenig Erfahrung habe. Mit ASCII, ANSI, oder was auch immer lebt es sich halt irgendwie so bequem. In diesem Sinne sind die C++ Strings wohl eher der minimalistische Ansatz, bei dem man für nichts bezahlt, was man nicht nutzt, aber dementsprechend wohl auf einem niedrigeren Ebene bleibt. Wobei ja eigentlich alles, was Strings verwaltet nicht Performancekritisch sein sollte (in normalen Anwendungen, natürlich nicht bei sowas wie Datenbanken). Was für boost-String Klassen meinst du da denn genau? Mich würden ein paar Alternativen da schon interessieren.

[Niki]

Was für boost-String Klassen meinst du da denn genau?

Haha, da hast du mich jetzt aber erwischt :D Mein Wissen über Boost ist eher verschwindend gering. Ich glaube es gibt da irgendein Boost Locale Zeugs, aber ob das die wesentliche Funktionalität hat, dass weiß ich ehrlich gesagt nicht. Ich habe Boost aufgezählt, weil du es als erster erwähnt hast. Bin deshalb davon ausgegangen, dass Boost die Funktionalität hat.

[BeRsErKeR]

In den meisten Fällen würde ich eXiles Vorschlag zustimmen. Dennoch finde ich z.B. den Ansatz von glib::ustring auch sinnvoll. Dort wurde eine komplett neue Klasse geschrieben, die ein identisches Interface zu std::string bietet plus zusätzliche Methoden. Ich finde es dort deshalb sinnvoll, da es ein spezieller String-Typ, nämlich ein UTF8-String, ist, der intern teilweise eine andere Logik benötigt aber dennoch ein spezialisierter String, also ein String, ist. Hier wäre meiner Meinung nach eine Vererbung (wenn es möglich wäre) korrekt.

Wenn du natürlich nur ein paar Extras wie Pfad-Spielereien haben willst, sind die freien Funktionen schon der richtige Weg. In C# gibt es dafür die Extensions, aber wohl eher deshalb, weil es in C# keine freien Funktionen gibt. Ich verstehe daher gut, warum du anfangs auf statische Klassen zurückgegriffen hast. ;)