🚀 go-pugleaf

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

> Ja, sicher. Wie gesagt, das ist, IMHO, kein vernuenftiger Vergleich.

Das ist schon ein vernuenftiger Vergleich, wenn man bedenkt, warum ich das
gesagt habe: Es ging um eine generelle Kritik an char* aufgrund von ein
paar Zeilen Code. Keiner von uns wusste, warum dieser Code genau so
aussieht, und ich habe lediglich Szenarios gebildet, warum dieser Code so
aussehen kann. Meine Szenarios sind aber im Rahmen von realen Aufgaben-
stellungen durchaus denkbar, Dein Argument

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

[Checks im Produktionscode]
Das mache ich auch (bereits seit ca. 5 Jahren). Der Geschwindigkeits- 
unterschied spielt normalerweise keine Rolle, und wenn doch, dann lohnt es
sich normalerweise eher, einen schnelleren Rechner einzusetzen (wo moeglich),
als Checks zu disablen. Die paar Mark, die man fuer ein schnelleres System
ausgibt sind schnell wieder weg, wenn man irgendwo einen Fehler hat, bei dem
man noch nicht mal andeutungsweise sagen kann, wo er herkommt, weil man
saemtliche Checks disabled hat.

Insofern sind wir da durchaus einer Meinung :-)

Gruss


        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com