String auf Ziffern prüfen

Genau, wenn ich dieses Aufgabe der Ziffernerkennung habe, dann möchte ich gern wissen wie man das im modernen C++ macht und nicht mit C-Methoden.

Ist das daher keine legitime und logische Frage?
@SeppJ sagte in String auf Ziffern prüfen:

@CppConst sagte in String auf Ziffern prüfen:

Wie würde man denn heute im modernen C++ einzelne Zeichen eines Strings darauf testen ob sie eine Ziffer sind oder nicht?

Die Frage ist nicht wie, sondern warum. Warum denkst du das in modernem C++ zu brauchen?

Keine Ahnung ich lese eine Textdatei ein und will wissen ob da Zahlen mit drin sind zum Beispiel. Oder ich lese von einem Textfeld einer GUI was ein und will wissen ob da ne Zahl mit drin ist. Gibt doch sicher viele Beispiele wo es interessant wird zu wissen ob da ne Zahl oder mehrere drin sind.

Columbo

@CppConst sagte in String auf Ziffern prüfen:

Keine Ahnung ich lese eine Textdatei ein und will wissen ob da Zahlen mit drin sind zum Beispiel. Oder ich lese von einem Textfeld einer GUI was ein und will wissen ob da ne Zahl mit drin ist. Gibt doch sicher viele Beispiele wo es interessant wird zu wissen ob da ne Zahl oder mehrere drin sind.

In der Praxis haben Eingabefelder einen bestimmten Zweck, d.h. sie sollen eine Zahl enthalten (und nicht enthalten können). Im Code würdest Du dann eine Funktion aufrufen, die diese Zahl auslesen soll. Im Falle eines Fehlers signalisiert die Funktion das entsprechend. D.h. nicht

if (!isnumber(field)) {
    bark
} else {
   n = readnum(field);
   ...
}

schreiben, sondern

int n
if (!readnum(field, &n)) {
    bark
}
...

Wenn Du readnum selbst implementieren möchtest, nur zu, aber ich habe noch nie eine Funktion gebraucht/gesehen, die einen String auf eine Zahl nur prüft, anstatt sie gleichsam zu extrahieren.

@Columbo sagte in String auf Ziffern prüfen:

readnum

Ich möchte nichts implementieren was schon da ist: readnum gehört zum Standard C++?

Columbo

@CppConst "readnum" ist gleich std::cin >> n

hustbaer

Wenn's darum geht Ziffern zu erkennen...

Man kann z.B. https://en.cppreference.com/w/cpp/locale/ctype_char verwenden.
Wenn's locale-abhängig funktionieren soll kann man auch die ctype facet der aktuellen locale verwenden: https://en.cppreference.com/w/cpp/locale/ctype

Wenn's OK ist sich auf Zeichensätze festzulegen bei denen die Codes von 0...9 fortlaufend sind (was OK sein sollte), kann man auch nach wie vor ch >= '0' && ch <= '9' schreiben.
Wenn's etwas schneller sein soll kann man auch size_t(ch) - size_t('0') <= 9 schreiben.

hustbaer

@Columbo sagte in String auf Ziffern prüfen:

@CppConst "readnum" ist gleich std::cin >> n

Oder from_chars: https://en.cppreference.com/w/cpp/utility/from_chars
(Oft besser wenn der Code auch schnell sein soll und der Input nicht sowieso schon in einem Stream steht.)

Columbo

@hustbaer Ups. Klar, wenn man einen String hat. Ich dachte irgendwie unbewusst an stdin.

Vielen Dank, was es nicht alles gibt und man wenig findet wenn man danach sucht. Modernes C++ lernen ist echt nicht einfach.

SeppJ

@CppConst sagte in String auf Ziffern prüfen:

Vielen Dank, was es nicht alles gibt und man wenig findet wenn man danach sucht. Modernes C++ lernen ist echt nicht einfach.

Das ist ja nicht einmal modern, sondern auch schon 1979 auf ca. Seite 2 jedes Lehrbuchs unter "Benutzereingaben". Und auch in C gibt's das seit der ersten Version. Und in allen Vorläufern von C. Was ist hier los mit all den Leuten, die selber Zahlen parsen wollen?

Ok, ich versuche es zu erklären.

Ich bin gerade dabei mein C++ Wissen aufzufrischen und zu erweitern, zuvor hatte ich in Python, Java, PHP und ein wenig C programmiert. Eine Eingabe, die meist als String vorliegt auf eine Zahl zu testen(z.B. durch einen eingebaute Funktion der Standardslibs oder zur Not auch mal als Exception bei einer Typumwandlung) gehört zu vielen Übungsaufgaben um sich einfach mal mit einer Programmiersprache vertraut zu machen.

Wenn man heute C++ lernt ist mir aufgefallen, dass man versucht die Leute zu modernem C++ (alles ab C++11) zu bewegen.

Aus diesen beiden Umständen zeugt meine verrückte Frage: 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. Da hilft es mir wenig wenn das auf Seite 2 vom einen C-Buch aus dem Jahre 1979 steht.

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

Zumal ist 2021 Jahr des Parsens^^

DirkB

@hustbaer sagte in String auf Ziffern prüfen:

Wenn's OK ist sich auf Zeichensätze festzulegen bei denen die Codes von 0...9 fortlaufend sind

Was so vom C-Standard verlangt wird.
Ja, hier ist C++ - aber nicht anders.

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.