String auf Ziffern prüfen

[wob]

@CppConst sagte in String auf Ziffern prüfen:

Wie man mit modernem C++ einen String in eine Zahl(nehmen wir hier mal int an) umwandelt, oder noch verrückter eine Zahl aus einem String parst.

Mit std::stoi (string to int) bzw. std::to_string. Oder from/to_chars. Oder nach string umwandeln mit libfmt (mit fmt::format).

Wenn du aber direkt etwas liest/schreibst, ist oft gar kein Umweg über string nötig, wenn du direkt aus streams liest (in s. schreibst).

[SeppJ]

@CppConst sagte in String auf Ziffern prüfen:

Die Einstiegsfrage des Threaserstelllers kam mir da ganz recht um auf den Zug auf zuspringen. Ist meine Intention etwas klarer geworden?

Die Frage ist schon klar, aber du verstehst die Antwort nicht. Nochmal in ganz klaren Worten: Dieses low-level Geraffel brauchst du nie! Also ist es auch müßig sich zu wundern, dass dieses low-level Geraffel unerwartet schwer ist!

Du musst niemals wissen, ob ein String nur aus Zahlen besteht, du musst niemals selber etwas schreiben, um einen String in eine Zahl umzuwandeln. Du solltest sogar gar nicht in der Verlegenheit sein, eine Zahl als String vorliegen zu haben.

[wob]

@SeppJ sagte in String auf Ziffern prüfen:

Du solltest sogar gar nicht in der Verlegenheit sein, eine Zahl als String vorliegen zu haben.

Du hast noch nie mit Kundendaten gearbeitet, schließe ich daraus (oder du hast Kunden, die kompetent in IT sind*). Man bekommt json (oder csv oder irgendwas ähnliches), hofft, dass alles gut & wie spezifiziert ist, und dann hat man doch wieder Gemisch in Strings. Und ja, auch unterschiedliche Formate für dieselbe Art Daten. Es ist sehr häufig am einfachsten, anhand spezifischer Merkmale wie "ist das 3. Zeichen im String eine Ziffer" festzustellen, welches Format man nun parsen will. Diesen Usecase habe ich sehr häufig.

* mir ist manchmal absolut schleierhaft, wie unsere Kunden es schaffen, diese merkwürdigen Formate zu produzieren.

[SeppJ]

@wob sagte in String auf Ziffern prüfen:

@SeppJ sagte in String auf Ziffern prüfen:

Du solltest sogar gar nicht in der Verlegenheit sein, eine Zahl als String vorliegen zu haben.

Du hast noch nie mit Kundendaten gearbeitet, schließe ich daraus (oder du hast Kunden, die kompetent in IT sind*).

Falsche Schlussfolgerung. (Leider, wenn es um den Punkt aus der Klammer geht). Auch du kapierst leider nicht die Antwort, obwohl sie klar wie nie gegeben ist. Du bekommst eine Datei, da stehen Zahlen drin, natürlich in irgendeiner Form von Zeichenkette codiert. An welcher Stelle meinst du, Strings auf Ziffern prüfen zu müssen, selber Zahlen parsen zu müssen, oder ähnlichen Quatsch? Warum liest du nicht einfach Zahlen mit den Standardfunktionen? Oder noch besser: Nimmst einen fertigen JSON-Parser und sagst dem, dass da in dem Feld eine Zahl steht?

Ich habe dauernd solchen Datenquatsch und ist kein Problem.

Aber im Gegenteil würde ich einen Kollegen schwer rügen, wenn der seine Arbeitszeit mit solchem NIH-Quark verschwendet.

[DocShoe]

@SeppJ sagte in String auf Ziffern prüfen:

@wob sagte in String auf Ziffern prüfen:

@SeppJ sagte in String auf Ziffern prüfen:

Du solltest sogar gar nicht in der Verlegenheit sein, eine Zahl als String vorliegen zu haben.

Du hast noch nie mit Kundendaten gearbeitet, schließe ich daraus (oder du hast Kunden, die kompetent in IT sind*).

Falsche Schlussfolgerung. (Leider, wenn es um den Punkt aus der Klammer geht). Auch du kapierst leider nicht die Antwort, obwohl sie klar wie nie gegeben ist. Du bekommst eine Datei, da stehen Zahlen drin, natürlich in irgendeiner Form von Zeichenkette codiert. An welcher Stelle meinst du, Strings auf Ziffern prüfen zu müssen, selber Zahlen parsen zu müssen, oder ähnlichen Quatsch? Warum liest du nicht einfach Zahlen mit den Standardfunktionen? Oder noch besser: Nimmst einen fertigen JSON-Parser und sagst dem, dass da in dem Feld eine Zahl steht?

Ich habe dauernd solchen Datenquatsch und ist kein Problem.

Aber im Gegenteil würde ich einen Kollegen schwer rügen, wenn der seine Arbeitszeit mit solchem NIH-Quark verschwendet.

Das klappt auch nur dann, wenn auf Kundenseite auch eine passende Bibliothek zum Erzeugen des (JSON/XML/wasauchimmer) Dokuments benutzt wird. Wenn die auch alles selbst basteln kann´s durchaus vorkommen, dass man zB einen XML-Dialekt bekommt, der auf den ersten Blick valide aussieht, sich aber trotzdem nicht parsen lässt. Dann muss man doch wieder selbst parsen.

[SeppJ]

@DocShoe sagte in String auf Ziffern prüfen:

@SeppJ sagte in String auf Ziffern prüfen:

@wob sagte in String auf Ziffern prüfen:

@SeppJ sagte in String auf Ziffern prüfen:

Du solltest sogar gar nicht in der Verlegenheit sein, eine Zahl als String vorliegen zu haben.

Du hast noch nie mit Kundendaten gearbeitet, schließe ich daraus (oder du hast Kunden, die kompetent in IT sind*).

Falsche Schlussfolgerung. (Leider, wenn es um den Punkt aus der Klammer geht). Auch du kapierst leider nicht die Antwort, obwohl sie klar wie nie gegeben ist. Du bekommst eine Datei, da stehen Zahlen drin, natürlich in irgendeiner Form von Zeichenkette codiert. An welcher Stelle meinst du, Strings auf Ziffern prüfen zu müssen, selber Zahlen parsen zu müssen, oder ähnlichen Quatsch? Warum liest du nicht einfach Zahlen mit den Standardfunktionen? Oder noch besser: Nimmst einen fertigen JSON-Parser und sagst dem, dass da in dem Feld eine Zahl steht?

Ich habe dauernd solchen Datenquatsch und ist kein Problem.

Aber im Gegenteil würde ich einen Kollegen schwer rügen, wenn der seine Arbeitszeit mit solchem NIH-Quark verschwendet.

Das klappt auch nur dann, wenn auf Kundenseite auch eine passende Bibliothek zum Erzeugen des (JSON/XML/wasauchimmer) Dokuments benutzt wird. Wenn die auch alles selbst basteln kann´s durchaus vorkommen, dass man zB einen XML-Dialekt bekommt, der auf den ersten Blick valide aussieht, sich aber trotzdem nicht parsen lässt. Dann muss man doch wieder selbst parsen.

@SeppJ sagte in String auf Ziffern prüfen:

Ich habe dauernd solchen Datenquatsch und ist kein Problem.

[DocShoe]

@SeppJ sagte in String auf Ziffern prüfen:

Ich habe dauernd solchen Datenquatsch und ist kein Problem.

Dann hast du wohl anderen Datenquatsch als wir.

[SeppJ]

@DocShoe sagte in String auf Ziffern prüfen:

@SeppJ sagte in String auf Ziffern prüfen:

Ich habe dauernd solchen Datenquatsch und ist kein Problem.

Dann hast du wohl anderen Datenquatsch als wir.

Nein, ich denke nicht, denn mein Datenquatsch ist schon ziemlich übel. Aber wenn du wirklich selber Zahlen zerlegst oder ähnliches, dann spreche ich euch Kompetenz ab. Dann seid ihr vermutlich sogar eine der Ursachen für Datenquatsch: "Wir sollen Zahlen an die Technik schicken, aber die können keine negativen Zahlen verstehen. Den Parser dort hat so ein Flickschuster selber geschrieben, der kommt damit nicht zurecht!"

[wob]

@SeppJ sagte in String auf Ziffern prüfen:

Oder noch besser: Nimmst einen fertigen JSON-Parser und sagst dem, dass da in dem Feld eine Zahl steht?

Du hast mich nicht verstanden. Ich nehme einen fertigen JSON-Parser. Selbstverständlich kodiert der Kunde manche Zahlen als Strings. Manchmal. Es können auch Buchstaben oder komische Zeichen IN Zahlen vorkommen, die da eigentlich nicht hingehören. Oder Zahlentupel in Strings vorkommen, d.h. der String ist sowas wie "W12-17" oder einfach "17-12". Oder gar "1712". Und ich brauche aber z.B. die beiden Zahlen. Wenn du jetzt "1712" in stoi packst, kommt 1712 heraus und nicht ein Tupel (17, 12). Oder sonstwie. Dann checkt man hat einfach irgendwelche Charakteristiken des Strings (z.B. ist die Länge 4? Dann zwei zweiziffrige Zahlen einlesen. Ist die Länge 5 und in der Mitte ein '-', dann eben entsprechend anders parsen. Usw. Und selbstversändlich ist der Inhalt in so einer Datei NICHT konsistent. Problematisch wird es immer dann, wenn die Daten mehrere Interpretationen zulassen. Zum Beispiel wenn auch "1712" -> (171, 2) möglich wäre. Dann hat man ein Problem. Wenn Kunde zu blöd ist, das korrekt hinzubekommen, muss man ggf. sogar vorher einen Fit machen, um zu gucken, welche Interpretation hier nun wahrscheinlich richtig ist.

[Columbo]

Aber dann würdest Du immer noch keine Zahlen selber parsen, sondern die Zahlen aus entsprechend herausgeschnittenen Strings lesen. Abgesehen davon hoert sich das schon ziemlich an den Haaren herbeigezogen an. 1712 soll ein Tupel sein...? Wer schickt denn so einen Müll?

Edit: Also ich meinte spezifisch, e.g. W17-12 wird geparsed indem man den ersten char herausliest, prueft, ggf. putback'ed, dann die erste Zahl einliest, usw. du wuerdest nicht tatsaechlich eine Schleife schreiben welche sukzessiv Ziffern mit Potenzen von Zehn multipliziert und aufaddiert.

[hustbaer]

@Columbo
Ich glaube es ging hauptsächlich um das:

@SeppJ sagte in String auf Ziffern prüfen:

Du solltest sogar gar nicht in der Verlegenheit sein, eine Zahl als String vorliegen zu haben.

Und das passiert mMn. halt doch oft. Da reicht's schon wenn man Commandline Arguments bekommt wo Zahlen dabei sind. Und ich würde auch viele andere Dinge nicht direkt über Streams machen wollen. Also Strings haben wo Zahlen drin sind ist IMO schon ein Fall den man oft hat, und wo nicht immer die beste Lösung ist mit Streams oder fertigen Parsern draufzuhauen.

Was nett wäre, wäre etwas ähnliches wie libfmt nur für Eingabe. Also quasi ein moderner sscanf Ersatz.

Wenigstens gibt es jetzt from_chars mit dem man Sub-Ranges von Strings parsen kann ohne sinnlos einen temporären String erstellen zu müssen.

Und ich denke es kommt auch oft drauf an wie viel Aufwand es ist eine zusätzliche Third-Party Library zu verwenden. Wenn da ein riesen Genehmigungsprozess dran hängt, dann lässt man es lieber wenn man das selbe auch in 5-10 Zeilen Code selbst schreiben kann.

[SeppJ]

@hustbaer sagte in String auf Ziffern prüfen:

@Columbo
Ich glaube es ging hauptsächlich um das:

@SeppJ sagte in String auf Ziffern prüfen:

Du solltest sogar gar nicht in der Verlegenheit sein, eine Zahl als String vorliegen zu haben.

Und das passiert mMn. halt doch oft. Da reicht's schon wenn man Commandline Arguments bekommt wo Zahlen dabei sind.

Das ist doch ein Paradebeispiel für etwas, was man (außerhalb simpelster Scripts für den Eigengebrauch, wo man gar nichts auf Fehler testet) niemals selber machen sollte, sondern immer ein Framework benutzt, das einem eine "Standard"-unixartige Commandline macht, wo man nur Parametername, Typ, evtl. Defaultwerte, und Hilfetext definiert und das Framework liefert einem dann das fertige Endergebnis und das auch komplett richtig ohne die vielen möglichen Fehler, die man dabei machen kann. GNU getopt ist 40 Jahre alt, Boost program options wird bald 20. Es gibt keinen Grund, wieso heute jemand diese Frameworks nochmal schlecht nachprogrammieren sollte.

Neu Erfinden kommt da nur in Frage, wenn man wirklich vor hat, das neue, verbesserte Parameterframework für die Welt zu schreiben. Dann brauch man eventuell auch Prüfungen, welche Arten von Zeichen genau in einem String stehen. Aber bitte nicht für jedes dahergelaufene Kommandozeilenprogramm neu erfinden.

[Ein ehemaliger Benutzer]

Ich denke mal die Antwort mit dem from_chars ist die beste hier. Da es die modernste Art ist mit solchen Probleme umzugehen.

Jede Kundeneingabe kommt erst mal als String an, egal ob ich die in der Konsole oder per grafischer Benutzeroberfläche aus einem Textfeld hole.

Ich kann gar nicht zählen wie oft ich schon die Aufgabe bekommen habe, testen sie ob der Kunde eine Zahl eingegeben hat.

[Ein ehemaliger Benutzer]

@SeppJ sagte in String auf Ziffern prüfen:

Du musst niemals wissen, ob ein String nur aus Zahlen besteht, du musst niemals selber etwas schreiben, um einen String in eine Zahl umzuwandeln. Du solltest sogar gar nicht in der Verlegenheit sein, eine Zahl als String vorliegen zu haben.

Und will gar nichts selber schreiben. Nochmal, ich will wissen welche schon fertige Funktionen ich im modernen C++ für solche Aufgaben nutzen kann.

[SeppJ]

Wie soll man das beantworten? Die Antwort ist ja schließlich: Indem du die passende Funktionalität/Framework nimmst, in dem sich die Frage nach den Details zur Umwandlung String->Zahl gar nicht erst stellt. Aber welche das ist, hängt halt davon ab, was du machst. Du liest formatierte Daten? Macht dein Parser, aber welcher das ist hängt von dir und vom Format ab. Du liest Benutzereingaben? Macht deine UI, aber welche das ist hängt von dir ab. Du interpretierst Kommandozeilen? Macht dein Komandozeileninterpreter, aber welcher das ist, hängt von dir ab. Du musst aus welchen Gründen auch immer tatsächlich Strings selber in Zahlen umwandeln? Tausend Antworten hier, aber keine der guten Antworten empfiehlt, selber die Zahl Zeichen für Zeichen zu entziffern.

[Columbo]

@hustbaer sagte in String auf Ziffern prüfen:

@Columbo
Ich glaube es ging hauptsächlich um das:

@SeppJ sagte in String auf Ziffern prüfen:

Du solltest sogar gar nicht in der Verlegenheit sein, eine Zahl als String vorliegen zu haben.

Das mag vielleicht fuer das (an den Haaren herbeigezogene) Beispiel des TEs nicht gelten, in dem man tatsächlich from_chars braucht (und laengst kein eigenes Zahlen Parsen!). Aber in der Praxis stimme ich zu, dass man Zahlen in seinem eigenen Code nicht explizit in Strings speichern brauchen sollte. Qt, Iostreams, JSON parser, etc. haben doch alle "toInt()" Funktionen. Das ist alles internalisiert.

@hustbaer sagte in String auf Ziffern prüfen:

Da reicht's schon wenn man Commandline Arguments bekommt wo Zahlen dabei sind.

Also unsere in-house cmd parsing lib hat da ebenfalls CmdFlag<int> thisFlag in Petto.

[Ein ehemaliger Benutzer]

Dachte auch std::string hat einfach eine toInt Funktion. Na immerhin gibt es ja noch std::stoi

[Columbo]

@CppConst sagte in String auf Ziffern prüfen:

Dachte auch std::string hat einfach eine toInt Funktion.

Monoliths "Unstrung"

[Ein ehemaliger Benutzer]

Ok, vom dem Standpunkt aus eine verständliche Designentscheidung.