String auf Ziffern prüfen


  • Mod

    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.



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


  • Mod

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



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



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


  • Mod

    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.


  • Mod

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



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


  • Mod

    @CppConst sagte in String auf Ziffern prüfen:

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

    Monoliths "Unstrung"



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


Log in to reply