🚀 go-pugleaf

Hi,
Joachim Zobel (a2597420@athena.rrz.uni-koeln.de) wrote:
: ich hab' leider das ursprüngliche Posting nicht mitgekriegt, ging es
: um eine spezielle Stringklasse oder um Stringklassen im allgemeinen?

Der Anfang der (recht ergiebigen) Diskussion war in dem Thread ueber
den Aufruf eine Konstruktormethod und begann mit meiner sehr
verallgemeinerten Behauptung, dass die Deklaration 'char *string' "GANZ
SCHLECHT" ist... Um den Thread, der sich daraufhin um mehrere Aspekte
drehte (Art und Weise von Kritik an andere Leute Code; "to pointer or
not to pointer"; 'string' und die Kosten von Abstraktion) ein wenig
handhabbarer zu machen, habe ich ihn einfach mal aufgeteilt...

Es ging an dieser Stelle ganz direkt um einen Vergleich zwischen
'char*' und der Standardklasse 'string' i.e. 'basic_string<char,
string_char_traits<char>, allocator>' (siehe DWP). Den Vergleich habe
ich mit der (fast) Standard konformen Implementation aus libg++-2.7.1
mit gcc-2.7.2 auf einer Sparc 1000 mit Solaris 2.4 gemacht.

: Falls man tatsächlich ein Performanceproblem hat, liegt es für Strings
: nahe, eine eigene Allocationsf'n zu schreiben, die einen Pool von
: Bloecken von z.B. 64 Byte Länge unterhält, aus dem alle 'kleinen'
: Allokationen genommen werden. 

Jau, das kann man in einer Standard konformen Implementation z.B. in
den Allocator packen (in diesem Punkt libg++ ganau vom Standard ab,
i.e. es gibt keine Allocator). Allerdings ging es nicht um ein
Performanceproblem, sondern um einen vollkommen naiven, unrealistischen
Test (einfach ein paar tausend mal zwei Strings miteinander
vergleichen, wobei lediglich sichergestellt wurde, dass der Vergleich
nicht wegoptimiert wird), der die Kosten der Abstraktion untersuchen
sollte (es gab da eine Behauptung, dass 'string' um Klassen langsamer
sei, was, je nachdem, wie man es sieht, stimmt bzw. nicht stimmt...).

: War die fragliche Stringklasse irgendwie optimiert?

Keine Ahnung... 'bastring.h' halt. Gibt es z.B. von Musser's ftp site
oder in der libg++.

: >> Wenn man wirklich und fuer alles 'string' verwendet, tut sie das aber
: >> nicht.

: >ist falsch, ich kann Dir auf Anhieb ein Dutzend Moeglichkeiten nennen, warum
: >Du trotzdem char*'s kriegst (ein Beispiel habe ich bereits genannt [Shared
: >Memory], das zweite sind z.B. Betriebssystemfunktionen, die char*
: >zurueckliefern, auch hier musst Du jedesmal(!) einen string konstruieren).

: Ich habe bisher char * verwendet und ueberlege im Moment, für den
: Uebergang eine Stringklasse einzufuehren, die nicht alloziiert,
: sondern nur die Länge prueft, und ansonsten den im _ctor uebergebenen
: Speicher verwendet. So eine Art Wrapper fuer strncpy.

Ich denke, es ist fast immer sinnvoll, eine Stringklasse zu verwenden:
Man kann zunaechst eine triviale Klasse implementieren, die man
"smarter" macht, wenn es sich anbietet (selbstverstaendlich aendert man
dabei das Interface nicht...). D.h. man kann z.B. "under the hood"
sowas wie "lazy evaluation" machen.

Man koennte, auch in bei der Implementation von 'basic_string' von
"lazy evaluation" gebrauch machen: Man "opfert" halt ein bischen
Speicher fuer Verwaltung der "lazy evaluation" (z.B. um zu speichern,
ob der String derzeit ge'share't wird, ob man ihn freigeben muss etc.),
z.B. einen 'int' und einen zusaetzlichen Pointer. Dafuer reduziert man
die Anzahl der Allokationen, tatsaechlich ausgefuehrten Kopien etc.
(Siehe etwas Scott Meyers' "More Effective C++"; Item weiss ich gerade
nicht...).
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic