Die RICHTIGE Art zu konvertieren

SG1

wob schrieb:

Printe schrieb:

Wieso? Genau dafür hat die Funktion den zweiten Parameter (idx), der wird dann nämlich auf die Position des ersten 'd' gesetzt.

Ok, da hast du recht und ich vergesse immer wieder, dass es diesem Parameter gibt. Meine Schuld. Nur warum wird dann bei einem Fehler "von links" eine Exception geworfen? Dann sollte man da stillschweigend 0 zurückgeben - du könntest ja von dann ebenfalls diesen 2. Parameter prüfen. Finde ich inkonsistent.

Ja, ist inkonsistent. Ich vermute(!), dass die Erfinder der stdlib einen Parser im Hinterkopf hatten. Du übergibst einen Zeiger auf den Punkt, an dem Dein Parser steht und bekommst im 2. Parameter zurück, wo Du weiterparsen musst.

wob

Ja, es ist konsistent mit iostreams.

Es ist auch völlig ok, wenn man sowas machen will. Nur MUSS man, um das zu testen, ein Nicht-nullptr 2. Argument übergeben. Daher denke ich, dass genau dieser Fall, also KEIN 2. Argument angegeben, zu einem sichtbaren Fehler hätte führen sollen. Wenn jemand das 2. Argument ausliest, ist es völlig ok, dann bis dahin zu konvertieren.

Aber egal, der Standard ist nun einmal wie er ist - und ich benutze eben mein eigenes stoi, das sich eben anders verhält.

Jedenfalls muss man immer dran denken, dass stoi("42 ein string, sonst kein weiterer parameter") keinen Fehler wirft. Sofern ich das Bewusstsein dafür erhöht habe, bin ich ja auch schon glücklich

Bizarreofnature

Das gesamte Projekt ist jetzt auf String umgestellt.

Danke nochmal an alle. Es ist wirklich besser als C-Strings.

Und mehr oder weniger gearbeitet habe ich ja jetzt mit char. Also ist das wohl auch abgehakt.

Printe

wob schrieb:

Es ist auch völlig ok, wenn man sowas machen will. Nur MUSS man, um das zu testen, ein Nicht-nullptr 2. Argument übergeben. Daher denke ich, dass genau dieser Fall, also KEIN 2. Argument angegeben, zu einem sichtbaren Fehler hätte führen sollen.

Warum denn? Das Verhalten ist doch ausführlichstens dokumentiert für jeden, der lesen kann.

Man kann von einem Programmierer erwarten, dass er eine Funktion, die er erstmals verwendet, mal kurz in der Doku nachliest. Und dass drei Parameter, von denen zwei optional sind, zumindest mal Interesse wecken. Oder dass man sich selbst die Frage stellt "was macht die Funktion eigentlich, wenn sie einen String nicht konvertieren kann?"

Wem das alles egal ist, wer einfach nur blind Code kopiert, den er im Internet gefunden hat, der muss halt selbst die Erfahrungen machen.

wob

Printe schrieb:

Warum denn? Das Verhalten ist doch ausführlichstens dokumentiert für jeden, der lesen kann.

Das ist ein nutzloses Totschlagargument.

Das Verhalten sollte so sein, dass es möglichst nützlich für den gemittelten Benutzer ist und weder Inkonsistenzen noch sonstige Überraschungen bietet.

Wer schaut schon in die Dokumentation?! (Zumal bei 3rd party libraries gerne mal die Doku völlig veraltet ist!)

Printe

wob schrieb:

Das ist ein nutzloses Totschlagargument.

Von mir aus. Aber es ist wahr.

Das Verhalten sollte so sein, dass es möglichst nützlich für den gemittelten Benutzer ist ...

Das kann für spezialisierte Anwenderfunktionen gelten. Für Funktionen in Standardbibliotheken gilt, dass sie ihre Aufgabe möglichst umfassend erfüllen sollen. Den spezialisierten Wrapper kann sich dann jeder Anwender selber bauen, wenn er das für nötig hält.

Wer schaut schon in die Dokumentation?! (Zumal bei 3rd party libraries gerne mal die Doku völlig veraltet ist!)

DAS ist ein Totschlagargument. Und die Doku auf cppreference.com ist alles andere als veraltet.

Schlangenmensch

Ich muss mich wob mit seiner Kritik an stoi zumindest zum Teil anschließen.
Wenn ich selber entwickel, werde ich wahrscheinlich in die Doku schauen, da ich Fehler in der Eingabe behandeln muss. Anders sieht es aus, wenn ich Code von anderen lese. Da erwarte ich, dass die Funktionen das machen, was ich vom Namen her erwarte. Vor allem, wenn sie aus der Standard Bibliothek stammen.
Mal als Beispiel:

try
{
   auto result = std::stoi(irgendeinEingabeString);
}
catch(...)
{
   LOG_ERROR("DAU ist zu blöd eine ganze Zahl einzugeben");
}

Wenn ich das lese, gehe ich davon aus, dass der Entwickler sich gedanken um die Fehlerbehandlung gemacht hat. Das aber nur ein Teil der möglichen Eingabefehler behandelt werden, geht daraus nicht vor. Das ist meiner Meinung nach unschön.

Printe schrieb:

Wer schaut schon in die Dokumentation?! (Zumal bei 3rd party libraries gerne mal die Doku völlig veraltet ist!)

DAS ist ein Totschlagargument.

Von mir aus. Aber es ist wahr.