Letztes Jahr war ich auf der Suche nach einer String-Klasse, die man ohne große Abhängigkeiten von Toolkits einfach in ein Projekt in C++ einhaken konnte, und die einem das Leben einfacher machen sollte. Obwohl String-Klassen eigentlich grundlegendes Handwerkszeug und Übungsaufgaben für Informatikstudenten im dritten Semester sind, konnte ich nichts finden was in Frage kam; zugleich wollte ich string aus der STL nicht verwenden.
Es läuft also darauf hinaus, dass ich mir eine eigene String-Klasse zusammenzimmerte und in den letzten Monaten immer wieder mal daran herumbastelte, bis sie die wichtigen Methoden besaß (und einige die weniger häufig benötigt werden). Diese Klasse habe ich nun veröffentlicht und würde mich über Kommentare dazu freuen.
hi murphy
was spricht gegen die STL string klasse?
gruß,
harald
Sie existiert schon ;-) Im Ernst, ich habe bei der Programmierung der Klasse den einen oder andere Kniff gelernt und endlich mal einige Konstrukte verwendet, die ich zwar aus der Theorie kannte, aber bisher im “täglichen Betrieb” nie benötigt habe. Mir gefällt das string-Interface nicht, und es fehlen einige komfortable Methoden. Man hätte zwar einen darauf basierenden Wrapper erstellen können, jedoch sind IMHO die Möglichkeiten größer wenn man die Speicherstrukturen vollständig selbst handhabt. Im Übrigen kenne ich noch erstaunlich viele Programmierer, die auch unter C++ trotz aller Probleme noch mit str[n]cpy & Co. arbeiten. Das könnte entweder Gewohnheit sein oder… Mehr »
Im Übrigen kenne ich noch erstaunlich viele Programmierer, die auch unter C++ trotz aller Probleme noch mit str[n]cpy & Co. arbeiten Das liegt meistens an der Benutzung veralteter Literatur beim Einstieg in C++. Da gibt es leider tonnenweise Bücher, die irgendwo am Stand Anfang der 90er hängengeblieben sind. Oder manchmal auch Programmierer die von C kommen und als Neuerung in C++ nur die Möglichkeit sehen, eigene Klassen zu benutzen. Zu deiner Stringklasse: Ist der vtable nicht bischen Overkill für eine Datenklasse? size_t für Längen? Gibt es den operator+= nur f+r char* und nicht für mstring? Ein char& operator[](int pos) ist… Mehr »
Ist der vtable nicht bischen Overkill für eine Datenklasse? Wie meinen? Welche vtable? size_t für Längen? Hmmm, warum? Da size_t letztendlich sowieso ein unsigned int ist finde ich es so eigentlich präziser. Weiteres Beispiel: QString. Gibt es den operator+= nur f+r char* und nicht für mstring? Richtig. Ich wollte das Interface so übersichtlich wie möglich halten, deshalb habe ich nachträglich alle mit mstring& überladenen Methoden zu Gunsten von const char* und impliziter Konvertierung herausgenommen wo möglich. Sollte ich da Probleme zu erwarten haben? Der Verzicht auf operator+(const mstring&) würde leider explizite Casts notwendig machen, deshalb habe ich ihn dringelassen. Ein… Mehr »
Wie meinen? Welche vtable? Durch die virtuellen Methoden braucht eine Instanz der Klasse zusätzlich zu ihrem Datenspeicher noch Platz für die Pointer auf diese Methoden. Üblicherweise versucht man daher Datenklassen so leicht wie möglich zu machen, also keine virtuals. Da size_t letztendlich sowieso ein unsigned int ist finde ich es so eigentlich präziser. Leichter an größere Größen anpassbar. Wäre zB statt time_t ein unsigned long in Benutzung, könnte man nicht einfach durch Neudefinition und Neukompilierung das Überlaufproblem korrigieren. Natürlich ist int nicht nötigerweise 4 Byte sondern könnte auch größer sein, aber das nicht so wahrscheinlich. size_t könnte durchaus so definiert… Mehr »
Üblicherweise versucht man daher Datenklassen so leicht wie möglich zu machen, also keine virtuals. Interessant; das steht anscheinend in keiner C++-Referenz. Den Destruktor kann ich wohl problemlos nicht-virtuell machen; die beiden anderen sind aber wie die Doku erwähnt dafür gedacht für wrap() alternative Metriken bereitzustellen. Ich denke ich werde die wrap()-Funktionalität und auch die bool-Konvertierung jeweils per Define abschaltbar machen. Die Sache mit size_t muß ich mir noch überlegen; was mich daran stört ist daß man immer erst nachsehen muß wie groß diese Typen auf dem Zielsystem wirklich sind; bei den Standarddatentypen (numerisch) ist auf einen Blick erkennbar was maximal… Mehr »
Interessant; das steht anscheinend in keiner C++-Referenz. Das ist eine Implikation der Sprache, die den meisten Entwicklern egal ist, weil die meistens keine Standardtypen neu implementieren. Das trifft dann eigentlich nur Leute, die selber Container oder Basistypen implementieren um bestimmtes Verhalten zu erreichen, oder ähnliches. Ist jetzt nicht so tragisch, man muß sich dessen aber bewußt sein, daß man durch eine einzige virtual Methode einen Overhead durch die vtable Verwaltungsstruktur in Kauf nimmt. Nicht umsonst sind praktisch die STL Typen und Container ohne Virtuals und machen die Anpassbarkeit über Templates. was mich daran stört ist daß man immer erst nachsehen… Mehr »
bei der Verwendung von size_t nicht nötig, weil das immer der Typ für Größenangaben ist. Glückwunsch, jetzt hast du mich völlig verunsichert… ;-) Ich gebe zu, size_t würde dahingehend Sinn machen weil alle relevanten C- und C++-Funktionen (new, str[n]* etc.) es benutzen und er gleichzeitig das obere Limit der handlebaren Speichergröße repräsentiert. Andererseits unterstreicht Schildt in seiner C++-Referenz (mein primäres Nachschlagewerk) immer wieder daß size_t in allen wesentlichen Sachen wie unsigned int behandelt werden kann… Ich werd’s mal im Hinterkopf behalten. Interface Bloat ist eher so ansich feine Methoden wie replace und ähnliches, siehe std::string und dessen ziemlich minimales Interface.… Mehr »
Sofern es noch jemanden interessiert: Es gibt eine neue Version, in die einige der obigen Anregungen eingeflossen sind.