std::string durchsuchen, aber ohne auf Groß- und Kleinschreibung zu achten... ? -Wie?
-
das ist doch zu unperformant
-
-
transformer schrieb:
das ist doch zu unperformant
Macht nix, dein Beitrag ist es auch nicht (und produktiv ebensowenig)
@Knuddlbaer: thx
-
@Vellas: Danke für dein Beispiel, habs nit erwähnt, aber deine Methode war mir eben zu langsam, aber trotzdem vielen Dank für dein post. Habs vergessen zu schreiben, meine Schuld, sry.
@Knuddlbaer: El perfecto, genau das!
thX @ All.
-
std::string schrieb:
@...Methode war mir eben zu langsam...
Wie hast Du das denn festgestellt und welche Auswirkungen hatte das ?
Gruß,
Simon2.
-
Simon2 schrieb:
Wie hast Du das denn festgestellt und welche Auswirkungen hatte das ?
das sieht ein blindes huhn mit holzauge... da werden strings en masse kopiert...
die loesung ist fuerchterbar
-
Shade Of Mine schrieb:
... da werden strings en masse kopiert...
Das habe ich auch gesehen; aber das sagt noch nciht, dass es zu unperformant ist.
Shade Of Mine schrieb:
... die loesung ist fuerchterbar
Daß eine Lösung das ästhetische Empfinden reizt, ist aber ein anderes Argument.
Eine Lösung wie die Obige kann durchaus sinnvoll sein und ist erst dann zu unperformant, wenn sie nachweislich im konkreten Programmlauf nicht den Anforderungen entspricht.
Beisp.: Ich muß einmalig zwei relativ kurze Strings vergleichen ... warum sollte ich mir noch 4 Stunden Gedanken über die Performance machen, wenn ich Obiges in 10min. programmiert und ausgeführt habe ?Die Frage des Threaderstellers war: "Wie kann man ... ?" - und darauf ist das eine durchaus berechtigte Antwort (zumal der Code einfach und gut durchschaubar ist).
Worauf ich hinauswill: IMO habe sich C/C++-Programmierer leider angewöhnt, viel Zeit mit (Pseudo-)Optimierung zu verschwenden, statt erst einmal das Problem zu lösen und dann nach Bedarf genau da zu oprimieren, wo es notwendig ist.
Gruß,
Simon2.
-
Simon2 schrieb:
Shade Of Mine schrieb:
... da werden strings en masse kopiert...
Das habe ich auch gesehen; aber das sagt noch nciht, dass es zu unperformant ist.
LOL, na darum gehts noch nun wirklich nicht, oder?!
-
CodeFinder schrieb:
Simon2 schrieb:
Shade Of Mine schrieb:
... da werden strings en masse kopiert...
Das habe ich auch gesehen; aber das sagt noch nciht, dass es zu unperformant ist.
LOL, na darum gehts noch nun wirklich nicht, oder?!
transformer schrieb:
das ist doch zu unperformant
Worum dann ?
Gruß,
Simon2.
-
Was ist los mit euch in letzter Zeit?
100 mal einen string kopieren verkauft ihr als gute Loesung. Wobei ich einfach Humes stricmp.h nehmen kann und alle probleme geloest habe. Dazu ist die Loesung sauber und performant.
Wir wollen doch nicht ehrlich den Leuten hier erklaeren: kopier ganz oft deine strings rum, weil das ist eh egal.
Strings kopieren ist ne einfache variante, aber wie Hume in seiner FAQ super beschrieben hat: ziemlich problematisch (von der miesen performance mal abgesehen).
Warum kann man nicht einfach eine perfekte antwort stehen lassen? Humes FAQ eintrag ist genau die Antwort auf die Frage hier. Wir koennen gerne ueber eine andere Moeglichkeit Diskutieren die Hume ausgelassen hat oder ueber Fehler oder Uneindeutigkeiten in seiner FAQ reden - das bringt uns etwas.
Aber eine Loesung die Hume bereits ausdiskutiert hat als "ultra super mega cool" darzustellen ist schwachfug/
Leider ist diese Lösung nur sehr beschränkt einsetzbar. Sie hilft nur bei einem direkten Vergleich zweier Strings. Für zwei ungleiche Strings läßt sich damit aber nicht bestimmen, welcher der beiden Strings der "Kleinere" ist. Als Sortier- bzw. Vergleichskriterium (z.B. für einen assoziativen Container) im Zusammenhang mit der STL ist diese Variante ebenfalls nicht geeignet.
Die Lösung ist auch nicht sonderlich effizient. Da eine Vergleichsfunktion ihre Argumente niemals ändern sollte, hier aber eine Umwandlung der Buchstaben nötig ist, müssen von den zu vergleichenden Strings Kopien erstellt werden.
Betrachtet man den Code genauer, so stellt man fest, dass die Lösung strenggenommen nicht mal eine Antwort auf die Frage ist. Es wird schließlich nicht case-insensitiv verglichen. Die Eigenschaft "case-insensitiv" ist hier keine Eigenschaft der Vergleichsfunktion. Vielmehr werden einfach die beiden Strings so umgewandelt, dass Groß-/Kleinschreibung kein Thema mehr ist.
was muss man dazu noch sagen?
Auf deutsch: Boese Loesung, pfui pfui, Finger weg.
-
Vellas hat die Strings ja noch nicht mal per const referenz übergeben.
-
@Simon2: Siehe Shade Of Mine's Post ... Ich kann dem nur zustimmen
(das meinte ich 
).
-
lolol schrieb:
Vellas hat die Strings ja noch nicht mal per const referenz übergeben.
Dann guck mal genau hin, dann siehst du wieso, es würde nämlich keinen Sinn machen erst per const referenz zu übergeben und dann eine Kopie anzulegen, die ich sowieso braucht, dann kann ich auch direkt ne Kopie übergeben (weshalb Hume es in seinem Beispiel auch nicht getan hat).
Die Variante von Hume ist natürlich wesentlich besser. Ich sollte wohl auch öfter mal wieder auf seine HP gucken. Finde die stricmp.h auch sehr schön.
Greetz
-
Shade Of Mine schrieb:
Was ist los mit euch in letzter Zeit?
100 mal einen string kopieren verkauft ihr als gute Loesung...
Tja, was nur mit Euch los in letzter Zeit ?
Ich frage lediglich, wie jemand zur Einschätzung kommt, es sei zu unperformant (die Vorteile der anderen Lösung habe ich gar nicht abgestritten) ... und sofort stürzt sich ein Haufen "Nichtangesprochener" auf mich, als ob ich Leichenschändung begangen hätte.Ist schon der Versuch, sich rational mit dem reflexartigen Performanceargument auseinanderzusetzen, Grund genug, mich in den feurigen Pfuhl der Java- und VB-Programmierer zu werfen ?
Gruß,
Simon2.
P.S.: Bislang wurde übrigens meine Frage noch nicht beantwortet: Wieso findet "transformer" diese Lösung zu unperformant ?
-
bisse dumm junge?
-
kannst du die plattitüden auch einstellen und nicht einfach auf irgendne faq verweisen, die performanz anhand von stl konformität beurteilt?
die in post #2 vorgestellte lösung ist für das gestellte problem hervorragend geeignet. sie ist kurz, leicht nachvollziehbar und wenig fehleranfällig.
man sieht, dass strings kopiert werden (oh, hilfe!) und die lösung bietet keine von stl vergleichsoperatoren geforderte strikt-ordnung. aber war das gefordert? nö, wars nicht. jetzt kann man sich fragen, wofür die methode benötigt wird und im gesamtkonzept vergleichen, wie sehr sich das bisschen kopieren auf die performanz auswirkt.
ist toll, wie einige leute son zeug hoch optimieren und alle eventualitäten erschlagen, aber an anderer stelle hoch komplexe algorithmen aus unwissenheit so schlecht implementieren, dass sie das programm im vergleich zu solchen kleinen vergleichsoperationen um faktor 1000 verlangsamen.
angemessene optimierung.
-
Eine Lösung die funktioniert, verständlich ist, und ausreichend schnell ist, ist eine gute Lösung. Und ausreichend schnell kann die "tolower/toupper" Lösung in vielen Fällen sein. Meine Kritik an der "tolower/toupper" Lösung wäre vielleicht eher dass sie unnötig kompliziert ist - man braucht ein paar µs länger um zu verstehen was abgeht.
Ein echtes Problem wird es aber erst wenn man anstelle von einer 8 Bit Codepage anfängt mit Unicode zu arbeiten. Oder viele verschiedene Codepages unterstützen will/muss. Aber das ist ein Horror an den ich gleich garnicht denken will... und gottseidank ein anderes Thema
-
transformer schrieb:
bisse dumm junge?
OK,
ich ziehe meine Frage zurück. Bestimmte Leute sind es einfach nicht wert, sich mit ihnen zu beschäftigen.
-
OMG ich ziehe mein voriges Posting zurück! Die "tolower/toupper" Version ist 100x klarer und übersichtlicher und überhaupt.
Ich hatte an stricmp aus der clib gedacht, aber nicht bedacht dass hier strstr gefragt ist, und es leider kein stristr gibt.
Plotzenhotz, du Doofsack, lies erstmal die verlinkten Dokumente bevor du deinen Senf dazugibst!
Soviel dazu. Bitte um Entschuldigung!
-
Sorry, wenn ich hier auch meinen Senf dazugebe, aber: Magazin: Stringverarbeitung in C++ - Kapitel 5.