🚀 go-pugleaf

Hi,

ich hab' leider das ursprüngliche Posting nicht mitgekriegt, ging es
um eine spezielle Stringklasse oder um Stringklassen im allgemeinen?

uz@wuschel.ibb.schwaben.com (Ullrich von Bassewitz) wrote:
>Dietmar Kuehl (kuehl@uzwil.informatik.uni-konstanz.de) wrote:
>> Bei dem vorgeschlagenen
>> Vergleich gibt es da schon einen deutlich groesseren Faktor in der
>> Groessenordnung von ~30.

>Der in einer "echten" Applikation nochmals um den Faktor 2-3 ansteigt, weil
>dann der Heap fragmentiert ist...

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. 

War die fragliche Stringklasse irgendwie optimiert?

[...]

>> 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.

Jochim


"Man faengt Forellen mit der Hand, indem man zuerst ihr Vertrauen gewinnt 
und es dann missbraucht."                              Robert A. Heinlein