Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Warum kein itoa()?

33 views
Skip to first unread message

Gregor Szaktilla

unread,
Oct 20, 2011, 5:34:12 PM10/20/11
to
Hallo zusammen!

Eine Frage die mich schon lange beschäftigt und die ich immer noch nicht
beantworten kann: Wieso gibt es ein atoi() aber kein itoa()? Eigentlich ist
doch alles da, was man braucht.

ASCII ist definiert, wie eine Zahl aussieht auch, also muss man doch nur
formulieren, wie aus einem int oder long eine Folge von Ziffern wird.

Was habe ich übersehen? Man schafft man es doch auch, eine beliebige Zahl
in irgendeinem Zahlensystem auf dem Bildschirm auszugeben(?!).

TIA+Gruß

Gregor

--
Google is watching you.

Daniel Krügler

unread,
Oct 21, 2011, 1:23:28 PM10/21/11
to
Ich denke, das ist eine gute Frage, aber man sollte sie wahrscheinlich
besser in einer C-Themengruppe stellen. Wenn ich raten würde, würde
ich
sagen, dass man sich bei der Lokalisierung nicht einigen konnte, aber
das ist auch nicht wirklich überzeugend, da offenbar der umgekehrte
Weg string -> integer-Typ wohldefiniert ist für all Basen zwischen 2
und 36. Aus mir unerfindlichen Gründen hat man sich bei dem Weg
integer -> string auf die Basen 8, 10 und 16 beschränkt.

Ich gehe davon aus, dass der C++-Standard dies nicht ohne Kooperation
mit dem C-Kommittee lösen wird.

Besten Gruss aus Bremen,

Daniel Krügler

Gerald Breuer

unread,
Oct 21, 2011, 3:08:48 PM10/21/11
to
Vielleicht meinte man, dass sprintf reicht.

Stefan Reuther

unread,
Oct 21, 2011, 3:10:43 PM10/21/11
to
Gregor Szaktilla wrote:
> Eine Frage die mich schon lange beschäftigt und die ich immer noch nicht
> beantworten kann: Wieso gibt es ein atoi() aber kein itoa()? Eigentlich
> ist doch alles da, was man braucht.

atoi kommt aus der C-Standardbibliothek. Angenommen, es gäbe nun eine
Funktion 'char* itoa(int n)'. Wo kommt der Speicher her, den diese
Funktion zurückgibt? Das eine Bibliotheksfunktion implizit 'malloc'
aufruft, war wohl früher nicht so gerne gesehen, und das ganze mit
statischem Speicher ist auch nicht so der Brüller. Also muss der Nutzer
Speicher zur Verfügung stellen. Außerdem wäre natürlich noch schön, wenn
er Dinge wie die Zahlenbasis wählten könnte. Und da sind wir in
Nullkommanix bei 'sprintf': ein Parameter mit dem Speicher, einer mit
der Konfiguration, einer mit der Zahl.

In C++ gibt's nun stringstreams, und da packt man sich den Dreizeiler
mit der heute gewünschten Konfiguration zur Not selbst in eine Funktion.

> Was habe ich übersehen? Man schafft man es doch auch, eine beliebige
> Zahl in irgendeinem Zahlensystem auf dem Bildschirm auszugeben(?!).

Auf die gleiche Weise bekommt man doch auch einen String.

C: printf <-> sprintf
C++: cout <-> stringstream-Objekt


Stefan

Paul Brettschneider

unread,
Oct 21, 2011, 11:42:27 PM10/21/11
to

Gregor Szaktilla wrote:

> beantworten kann: Wieso gibt es ein atoi() aber kein itoa()? Eigentlich
übrigens bevorzugt std::string statt "C-style" Strings.

Daniel Krügler

unread,
Oct 22, 2011, 3:04:02 PM10/22/11
to
On 21 Okt., 21:10, Stefan Reuther <stefan.n...@arcor.de> wrote:
> Gregor Szaktilla wrote:
> > Eine Frage die mich schon lange beschäftigt und die ich immer noch nicht
> > beantworten kann: Wieso gibt es ein atoi() aber kein itoa()? Eigentlich
> > ist doch alles da, was man braucht.
>
> atoi kommt aus der C-Standardbibliothek. Angenommen, es gäbe nun eine
> Funktion 'char* itoa(int n)'. Wo kommt der Speicher her, den diese
> Funktion zurückgibt? Das eine Bibliotheksfunktion implizit 'malloc'
> aufruft, war wohl früher nicht so gerne gesehen, und das ganze mit
> statischem Speicher ist auch nicht so der Brüller.

Das sollte kein Problem sein. Typische Implementierungen von itoa
habe sehr grosse Ähnlichkeit zu sprintf, siehe z.B.

http://www.cplusplus.com/reference/clibrary/cstdlib/itoa/

Sprich: Hier wird kein Speicher alloziiert, sondern in übergebenden
Speicher geschrieben. Auch sprintf ist inzwischen in C11 erweitert
worden um sprintf, wo man noch eine Längeninformation über den
übergebenden Puffer angibt, d.h. ähnlich könnte man ein itoa_s
definieren.

> Also muss der Nutzer
> Speicher zur Verfügung stellen. Außerdem wäre natürlich noch schön, wenn
> er Dinge wie die Zahlenbasis wählten könnte.

Ich denke, dass das Zahlenbasis-Argument ein wesentlicher Beweggrund
dieses Beitrags war - zumindest habe ich das soverstanden.

> Und da sind wir in
> Nullkommanix bei 'sprintf': ein Parameter mit dem Speicher, einer mit
> der Konfiguration, einer mit der Zahl.

Ich gebe zu, dass ich nichts dagegen hätte, wenn sprintf so erweitert
würde, dass man beliebige Zahlenbasen angeben könnte.

> In C++ gibt's nun stringstreams, und da packt man sich den Dreizeiler
> mit der heute gewünschten Konfiguration zur Not selbst in eine Funktion.

Abgesehen von der Zahlenbasis, ja.

> > Was habe ich übersehen? Man schafft man es doch auch, eine beliebige
> > Zahl in irgendeinem Zahlensystem auf dem Bildschirm auszugeben(?!).
>
> Auf die gleiche Weise bekommt man doch auch einen String.

Diese Antwort habe ich nicht verstanden.

> C: printf <-> sprintf
> C++: cout <-> stringstream-Objekt

Das Problem ist, dass die wesentlichen C++-Spezifikationen von Streams
und string <-> Konvertierungen auf eine entsrpechende Semantik in C
zurückgeführt werden. Da es in C bisher keine Möglichkeit gibt, einen
integralen Typ in einer beliebigen Basis in eine Stringform zu
überführen,
fehlt leider auch diese Möglichkeit bei den C++-Strings bzw. den neuen
Hilfsfunktionen in C++11, wie to_string.

Daniel Krügler

unread,
Oct 22, 2011, 3:10:12 PM10/22/11
to
On 22 Okt., 05:42, Paul Brettschneider <paul.brettschnei...@yahoo.fr>
wrote:
> Gregor Szaktilla wrote:
> > beantworten kann: Wieso gibt es ein atoi() aber kein itoa()? Eigentlich
>
> übrigens bevorzugt std::string statt "C-style" Strings.

Korrekt, aber das Argument von Gregor sticht, da alle Stream-
und String-Konvertierungsfunktionen in C++ letztendlich auf
entsprechende C-Spezifikationen zurückzuführen sind. Dies
ist auch der Grund, warum die neuen C++11-Hilfsfunktionen
von std::string (to_string und to_wstring) nicht die Möglichkeit
bieten, eine beliebige Basis anzugeben - obwohl es aber in die
Gegenrichtung möglich ist, weil eben strtol et. al. diese
Option bieten.

Paul Brettschneider

unread,
Oct 23, 2011, 7:47:32 AM10/23/11
to

Daniel Krügler wrote:

> On 22 Okt., 05:42, Paul Brettschneider <paul.brettschnei...@yahoo.fr>
> wrote:
>> Gregor Szaktilla wrote:
>> > beantworten kann: Wieso gibt es ein atoi() aber kein itoa()? Eigentlich
>> übrigens bevorzugt std::string statt "C-style" Strings.
> von std::string (to_string und to_wstring) nicht die Möglichkeit
eigentlich auch auf das flexiblere snprintf() hinweisen und die std::string
Klasse nur nebenbei erwähnen.

Daniel Krügler

unread,
Oct 22, 2011, 4:19:12 PM10/22/11
to
On 22 Okt., 21:04, Daniel Krügler <daniel.krueg...@googlemail.com>
wrote:
> Auch sprintf ist inzwischen in C11 erweitert
> worden um sprintf, wo man noch eine Längeninformation über den
> übergebenden Puffer angibt, d.h. ähnlich könnte man ein itoa_s
> definieren.

Oops, das sollte eigentlich heissen:

"[..] in C11 erweitert worden um sprintf_s [..]"

Stefan Reuther

unread,
Oct 22, 2011, 6:02:54 PM10/22/11
to
Daniel Krügler wrote:
> On 21 Okt., 21:10, Stefan Reuther <stefan.n...@arcor.de> wrote:
>>Gregor Szaktilla wrote:
>>>Eine Frage die mich schon lange beschäftigt und die ich immer noch nicht
>>>beantworten kann: Wieso gibt es ein atoi() aber kein itoa()? Eigentlich
>>>ist doch alles da, was man braucht.
>>
>>atoi kommt aus der C-Standardbibliothek. Angenommen, es gäbe nun eine
>>Funktion 'char* itoa(int n)'. Wo kommt der Speicher her, den diese
>>Funktion zurückgibt? Das eine Bibliotheksfunktion implizit 'malloc'
>>aufruft, war wohl früher nicht so gerne gesehen, und das ganze mit
>>statischem Speicher ist auch nicht so der Brüller.
>
> Das sollte kein Problem sein. Typische Implementierungen von itoa
> habe sehr grosse Ähnlichkeit zu sprintf, siehe z.B.

Genau darauf wollte ich hinaus: man braucht kein itoa, wenn man ein
sprintf hat.

>>Also muss der Nutzer
>>Speicher zur Verfügung stellen. Außerdem wäre natürlich noch schön, wenn
>>er Dinge wie die Zahlenbasis wählten könnte.
>
> Ich denke, dass das Zahlenbasis-Argument ein wesentlicher Beweggrund
> dieses Beitrags war - zumindest habe ich das soverstanden.

"beliebige Zahlenbasis" hab ich aus dem OP nicht herausgelesen, auf den
Bildschirm kann man doch auch nur oct/dec/hex ausgeben.

>>>Was habe ich übersehen? Man schafft man es doch auch, eine beliebige
>>>Zahl in irgendeinem Zahlensystem auf dem Bildschirm auszugeben(?!).
>>
>>Auf die gleiche Weise bekommt man doch auch einen String.
>
> Diese Antwort habe ich nicht verstanden.

Sollte heißen: die Bibliotheken (C-Standardbibliothek, C++-Standard
bibliothek) haben zu dem Anwendungsfall "beliebige Zahl [...] auf dem
Bildschirm ausgeben" immer noch eine parallele, äquivalente Möglichkeit,
einen String zu erzeugen.


Stefan

Daniel Krügler

unread,
Oct 24, 2011, 12:55:18 PM10/24/11
to
On 23 Okt., 13:47, Paul Brettschneider <paul.brettschnei...@yahoo.fr>
wrote:
Für den C++-Standard spielt es keine Rolle, ob man bezogen
auf sprintf oder snprintf spezifiziert, da die Spezifikation einen
genügend grossen Buffer voraussetzt. Eine reale Implementierung
kann es so oder so machen, aber essentiell ist, dass die
Semantik wohldefiniert ist.

Daniel Krügler

unread,
Oct 24, 2011, 1:05:31 PM10/24/11
to
On 23 Okt., 00:02, Stefan Reuther <stefan.n...@arcor.de> wrote:
> Daniel Krügler wrote:
> > On 21 Okt., 21:10, Stefan Reuther <stefan.n...@arcor.de> wrote:
> >>Gregor Szaktilla wrote:
> >>>Eine Frage die mich schon lange beschäftigt und die ich immer noch nicht
> >>>beantworten kann: Wieso gibt es ein atoi() aber kein itoa()? Eigentlich
> >>>ist doch alles da, was man braucht.
>
> >>atoi kommt aus der C-Standardbibliothek. Angenommen, es gäbe nun eine
> >>Funktion 'char* itoa(int n)'. Wo kommt der Speicher her, den diese
> >>Funktion zurückgibt? Das eine Bibliotheksfunktion implizit 'malloc'
> >>aufruft, war wohl früher nicht so gerne gesehen, und das ganze mit
> >>statischem Speicher ist auch nicht so der Brüller.
>
> > Das sollte kein Problem sein. Typische Implementierungen von itoa
> > habe sehr grosse Ähnlichkeit zu sprintf, siehe z.B.
>
> Genau darauf wollte ich hinaus: man braucht kein itoa, wenn man ein
> sprintf hat.

Leider bietet sprintf nicht die notwendigen Multi-Basen-Support,
lediglich
8, 10 und 16 werden unterstützt. Im Gegensatz dazu unterstützt die
andere Richtung *alle* Basen von 2 bis 36. Es gibt aus meiner Sicht
keinen Grund, warum sprintf nicht den gleichen Bereich abdeckt.

> >>Also muss der Nutzer
> >>Speicher zur Verfügung stellen. Außerdem wäre natürlich noch schön, wenn
> >>er Dinge wie die Zahlenbasis wählten könnte.
>
> > Ich denke, dass das Zahlenbasis-Argument ein wesentlicher Beweggrund
> > dieses Beitrags war - zumindest habe ich das soverstanden.
>
> "beliebige Zahlenbasis" hab ich aus dem OP nicht herausgelesen,

Ich beziehe mich hier auf den Punkt:

"Man schafft man es doch auch, eine beliebige Zahl in irgendeinem
Zahlensystem auf dem Bildschirm auszugeben(?!)"

> auf den
> Bildschirm kann man doch auch nur oct/dec/hex ausgeben.

Ich vermute, dass du dich hier auf eine Ausgabe mit Präfix beziehst,
denn es ist ist klar, dass alle Basen von 2-36 realisiert werden
können: Wie gesagt, die C-Library bietet die Möglichkeit, jede
String-Representation im Base-Bereich 2-36 in einen integralen
Wert zu konvertieren, siehe strtol und Co.

> >>>Was habe ich übersehen? Man schafft man es doch auch, eine beliebige
> >>>Zahl in irgendeinem Zahlensystem auf dem Bildschirm auszugeben(?!).
>
> >>Auf die gleiche Weise bekommt man doch auch einen String.
>
> > Diese Antwort habe ich nicht verstanden.
>
> Sollte heißen: die Bibliotheken (C-Standardbibliothek, C++-Standard
> bibliothek) haben zu dem Anwendungsfall "beliebige Zahl [...] auf dem
> Bildschirm ausgeben" immer noch eine parallele, äquivalente Möglichkeit,
> einen String zu erzeugen.

Das ist richtig, aber es überlässt damit dem Programmierer die
Aufgabe,
die String-Konvertierung durchzuführen. Ich denke, die C-Library
sollte diese Funktionalität von sich aus bereitstellen, bevor man
jeder
seine eigene to_string-Funktion neu schreibt.

Gregor Szaktilla

unread,
Nov 6, 2011, 12:59:22 PM11/6/11
to
Hallo Stefan,

Stefan Reuther schrieb:
> ... Angenommen, es gäbe nun eine
> Funktion 'char* itoa(int n)'. Wo kommt der Speicher her, den diese
> Funktion zurückgibt? ...

das Argument mit dem Speicher ist aus meiner Sicht nicht stichhaltig. Mit
Einführung von Strings hätte man eine itos()-Funktion sehr gut in <string>
„nachliefern“ können und hätte via c_str() auch ein itoa() gegeben. Zudem
ist die Rückgabe *irgendeines* Typs doch immer daran gebunden, dass diese
Rückgabe irgendwo stehen muss, oder nicht?

Gruß

Gregor

--
Ich sehe ja ein, dass es auf unserer komischen Kugel wenigstens einen geben
muss, der normal ist. Aber warum ausgerechnet ich?!

Stefan Reuther

unread,
Nov 7, 2011, 12:51:54 PM11/7/11
to
Gregor Szaktilla wrote:
> Stefan Reuther schrieb:
>> ... Angenommen, es gäbe nun eine
>> Funktion 'char* itoa(int n)'. Wo kommt der Speicher her, den diese
>> Funktion zurückgibt? ...
>
> das Argument mit dem Speicher ist aus meiner Sicht nicht stichhaltig.
> Mit Einführung von Strings hätte man eine itos()-Funktion sehr gut in
> <string> „nachliefern“ können und hätte via c_str() auch ein itoa()
> gegeben. Zudem ist die Rückgabe *irgendeines* Typs doch immer daran
> gebunden, dass diese Rückgabe irgendwo stehen muss, oder nicht?

Mein Argument bezog sich darauf, warum es in der C-Standardbibliothek
kein 'itoa' gibt.

Wenn du unbedingt eine fertige Lösung haben willst anstatt den
Dreizeiler selber zu schreiben, gibt es boost::lexical_cast
<http://www.boost.org/doc/libs/1_47_0/libs/conversion/lexical_cast.htm>.
Das wäre zumindest am ehesten im Stile der C++-Bibliothek. Eine nackte
Funktion 'std::string itoa(int)' würde da einfach nicht reinpassen.


Stefan

David Seppi

unread,
Nov 7, 2011, 3:56:34 PM11/7/11
to
Gregor Szaktilla schrieb:

> Zudem ist die Rückgabe *irgendeines* Typs doch immer daran
> gebunden, dass diese Rückgabe irgendwo stehen muss, oder nicht?

Ja schon, nur muß in Deinem Fall nicht die Rückgabe (der Zeiger
auf char) irgendwo stehen, sondern das Array, auf dessen erstes Element
der Zeiger zeigt. Wo soll denn dieses Array angelegt werden?
Am Stack, wo es nach Verlassen der jeweiligen Funktion verschwände?
Oder am Heap, was einen impliziten Aufruf von malloc benötigt?

--
David Seppi
1220 Wien

Gregor Szaktilla

unread,
Nov 8, 2011, 8:43:48 AM11/8/11
to
Hallo Stefan,

Stefan Reuther schrieb:
> Mein Argument bezog sich darauf, warum es in der C-Standardbibliothek
> kein 'itoa' gibt.

dann verstehe ich das wahrscheinlich noch nicht, weil ich die
C-Standardbibliothek noch nicht gut genug kenne.

> Wenn du unbedingt eine fertige Lösung haben willst ...

Darum ging es mir nicht. Ich wollte nur verstehen, woran es liegt, dass es
diese Funktion nicht gibt.

Gruß

Gregor

--
Urlaub: Liegen bleiben, bis es weh tut.

Gregor Szaktilla

unread,
Nov 8, 2011, 5:51:37 PM11/8/11
to
Hallo David,

David Seppi schrieb:
oh, jetzt hab’ ich’s kapiert. Danke!

Gruß

Gregor



--
Die Fantasie ist dem Menschen gegeben worden als Entschädigung für das, was
er nicht ist - und der Humor als Trost für das, was er ist. (Mark Twain)

Michael Karcher

unread,
Nov 8, 2011, 7:05:52 PM11/8/11
to
David Seppi <dse...@a1.net> wrote:
> > Zudem ist die Rückgabe *irgendeines* Typs doch immer daran
> > gebunden, dass diese Rückgabe irgendwo stehen muss, oder nicht?
> Am Stack, wo es nach Verlassen der jeweiligen Funktion verschwände?
> Oder am Heap, was einen impliziten Aufruf von malloc benötigt?
Borland hatte in Turbo C / Turbo C++ / Borland C++ schon lange ein
itoa als Bibliothekserweiterung. Der Puffer wurde vom Aufrufer
bereitgestellt, in dessen Verantwortung es dann auch lag, genug Platz
für die zu formatierende Zahl zur Verfügung zu stellen. Siehe z.B.

http://www.cplusplus.com/reference/clibrary/cstdlib/itoa/

Gruß,
Michael Karcher
0 new messages