[C++] String Problem

[7H3 N4C3R]

Was spricht gegen:

std::string s( "Hammo Wemt");
std::replace( s.begin(), s.end(), 'm', 'l');

So erspart man sich das ganze hässliche, unsichere char* Gefrickel und benutzt einen hervoragend getesteten Algorithmus der Standard Bibliothek.

 

[arc_user]

@Philifish
ok, aus while()-schleifen erzeugen die meisten compiler besseren code, aber der zugriff ueber index is auch nicht schlecht, da dies die schleife schneller macht, was aber durch das benutzen einer for(; wieder verspielt wird. eine fehlende begrenzung des string sollte von haus nicht moeglich sein, deswegen is der wert MaxChars ueberfluessig.
wenn man einen externen pointer auf einen localen umlegt, wird die verarbeitung im aktuellen stack gemacht und man spart zeit beim inkrementieren. wenn man zum programmieren anfaengt, sollte man schon da erfahren, dass schleifen killer von ausfuehrungs-zeit sind.

 

[arc_user]

@7H3 N4C3R
man sollte noch dazu erwaehnen, dass standard bibliothen ein monster aus unueberschaubaren zeug sind und jeder programmierer wissen sollte wie ein string funktioniert.

 

[Siberian..Husky]

jemand der probleme mit der stl hat sollte auf garkeinen fall selbst mit char arrays rumspielen...

ausser du möchtest noch ein wenig mehr zum thema "c ist gefährlich" beitragen.

 

[7H3 N4C3R]

@7H3 N4C3R
man sollte noch dazu erwaehnen, dass standard bibliothen ein monster aus unueberschaubaren zeug sind und jeder programmierer wissen sollte wie ein string funktioniert.

Sind sie das? Es gibt btw. nur eine C++-Standardbibliothek (die u.a. die STL beinhaltet). Diese ist sehr genau konzipiert und durchdacht, leicht anzuwenden, vermeidet Design- und andere Fehler.

Um einen String zu verstehen muss man nichts von character-arrays und Speicher wissen. Oftmals hilft es, zuerst die Abstraktion zu verstehen und später ins Detail zu gehen. Ganz nebenbei ging es dem OP eh um std::strings.

Im Übrigen sind deine Ausführungen über die Geschwindigkeiten von Schleifen ziemlich hahnebüchen und bei den Haaren herbeigezogen. Wo ein Programm langsam ist und realistischen Optimierungsbedarf hat, sagt dir ein Profiler im Nachhinein und keine wagemutigen Behauptungen im Vorherein. "Premature optimistation is the root of all evil" Aber das wird so langsam offtopic.

 

[arc_user]

Im Übrigen sind deine Ausführungen über die Geschwindigkeiten von Schleifen ziemlich hahnebüchen und bei den Haaren herbeigezogen. Wo ein Programm langsam ist und realistischen Optimierungsbedarf hat, sagt dir ein Profiler im Nachhinein und keine wagemutigen Behauptungen im Vorherein. "Premature optimistation is the root of all evil" Aber das wird so langsam offtopic.

weshalb soll man sich das nachher ueberlegen, wenn man vorher weiss was der kompilierer
mit schleifen macht. keine ahnung was "hahnebüchen " is, aber die sache is nicht an den haaren herbeigezogen.
konfiguriere doch einfach deinen compiler so, dass er fuer jedes modul ein assambler-file
erzeugt und betrachte die entstehung einer schleife. dann kopiere einfach grosse datenmengen von einer stelle speicher zur anderen und messe die zeit oder den datendurchsatz.

 

[7H3 N4C3R]

Was ist daran richtig:
-

Was ist daran falsch:
1. Es werden syntaktische Elemente der Sprache missbraucht, weil man glaubt ein Sprachelement sei schneller als ein anderes (Sinn von Abstraktion und Hochsprache verfehlt). Darein fällt auch, dass Schleifen ein Killer von Ausführungszeit sein sollen.
2. Es gibt Compiler und Hardware wie Sand am Meer. Auf Garantie wird dir nicht jeder Compiler den selben Code generieren (auch nicht die meisten).
3. Man sieht einem Assemblercode quasi nicht mehr an wie schnell er ist. Zyklen zählen war schon mit dem 8086 nicht mehr durchführbar. Der Code muss richtig an den Prozessor angepasst sein hinsichtlich Pipelines, Caching, Branch Prediction etc. .
4. Würde es einen tatsächlichen Unterschied zwischen den Schleifen geben, so müsste man quasi eine leere Schleife haben, damit dieser Effekt die verbrauchte Zeit dominiert. Anderenfalls, speziell beim sehr teuren Speicherzugriff (im Gegensatz zu Cache, im Gegensatz zu Registern) wird das nicht feststellbar sein. Zudem in einer for-Schleife typischerweise Zählvariablen eine bessere Lokalität haben und somit potenziell besserer geeignet wären schnellen Code zu erzeugen.
5. Letztere von dir beschriebene Problematik klingt eher danach, als wenn der Cache gesprengt wird. Ein Profiler wird dir das verraten können.
6. Ein Design von potenziell besserer Performance abhängig zu machen ist quasi immer ein Fehler und schränkt den Entwurf ein.

Wenn du deine Behauptungen irgendwie untermauern willst, bring doch bitte handfeste Beweise an.