Wie kann ich ein std::string-Objekt nach einem ganzen String durchsuchen, ohne, dass dabei auf Groß und kleinschreibung geachtet wird?

std::string tolowerString(std::string str) {
	transform(str.begin(), str.end(), str.begin(), tolower);
	return str;
}

std::string toupperString(std::string str) {
	transform(str.begin(), str.end(), str.begin(), toupper);
	return str;
}

int main() {
  cout << tolowerString("Hallo, heute ist EIn toLLeR Tag").find(tolowerString("ein toller tag")) << endl;
}

Sollte 17 ausgeben.

Greetz

das ist doch zu unperformant

Macht nix, dein Beitrag ist es auch nicht (und produktiv ebensowenig)

@Knuddlbaer: thx

@Knuddlbaer: El perfecto, genau das!

thX @ All.

@...Methode war mir eben zu langsam...

Wie hast Du das denn festgestellt und welche Auswirkungen hatte das ?

Gruß,

Simon2.

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

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

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?!

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.

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.

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

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 ?

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.

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

bisse dumm junge?

OK,

ich ziehe meine Frage zurück. Bestimmte Leute sind es einfach nicht wert, sich mit ihnen zu beschäftigen.

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!