Convert an integer to a string? Plan B?

[Steven T. Hatton]

http://public.research.att.com/~bs/b...#int-to-string

Is there no C library function that will take an int and convert it to its
ascii representation? The example Bjarne shows in his faq is not extremely
convenient.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[andy]

Roland Pibinger wrote:

On Sat, 11 Mar 2006 11:11:57 -0500, Pete Becker <pe********@acm .org>
wrote:

Daniel T. wrote:

So, what is the "appropriat e test" to ensure that a buffer is not
overrun?

Here's a proposal for a simple, efficient, and safe conversion
function:

#include <stdio.h>
#include <string>

inline std::string& itostr (int i, std::string& out) {
std::string::va lue_type buf[128];
int len = snprintf(buf, sizeof(buf), "%d", i);

if (len > 0 && size_t (len) < sizeof (buf)) {
out.assign(buf, std::string::si ze_type (len));
} else {
out.clear();
}
return out;
}

Seems good to me. I reckon you could maybe improve on the buffer size
could you as below? Whether the function should assert or throw an
exception on failure is another debate too of course, and whether to
check for the terminator etc :

#include <cstdio>
#include <limits>
#include <string>
#include <stdexcept>

struct itostr_error : public std::exception{
itostr_error(){ }
const char* what(){ return "bad itostr";}
};
inline
std::string& itostr (int i, std::string& out)
{
std::string::va lue_type buf[std::numeric_li mits<int>::digi ts10 +
3];
int len = std::sprintf(bu f, "%d", i); //slightly quicker
if (len > 0 && size_t (len) < sizeof (buf)
&& (buf[std::numeric_li mits<int>::digi ts10 + 2]=='\0')) {
out.assign(buf, std::string::si ze_type (len));
return out;
} else {
throw itostr_error();
}
}

#include <iostream>
int main()
{
try{
std::string str;
itostr(INT_MIN, str);
std::cout << str <<'\n';
}
catch( itostr_error & e){
std::cout << e.what() <<'\n';
}
}

regards
Andy Little

[Pete Becker]

an**@servocomm. freeserve.co.uk wrote:

Whether the function should assert or throw an
exception on failure is another debate too

No, it's not. <g> It's a matter of looking at the design of the
application it's going to be used in.

But in general, low level functions should report errors in-channel,
because once you've added the overhead of throwing exceptions you can't
get rid of it. Applications that don't use exceptions shouldn't have to
pay for them. So this sort of thing ought to be written in two layers,
one to do the formatting and report errors, and one that calls it and
translates errors into exceptions.

char *itoc(char *buf, size_t size_if_you_ins ist, int val)
{
format val into buf
if successful, return next position in buf, otherwise return 0
}

string itostr(int val)
{
char buf[whatever];
if (itoc(buf, whatever, val))
return string(buf);
throw error;
}

--

Pete Becker
Roundhouse Consulting, Ltd.

[andy]

an**@servocomm. freeserve.co.uk wrote:

[...]

struct itostr_error : public std::exception{
itostr_error(){ }
const char* what(){ return "bad itostr";}
};
inline
std::string& itostr (int i, std::string& out)
{
std::string::va lue_type buf[std::numeric_li mits<int>::digi ts10 +
3];
int len = std::sprintf(bu f, "%d", i); //slightly quicker
if (len > 0 && size_t (len) < sizeof (buf)
&& (buf[std::numeric_li mits<int>::digi ts10 + 2]=='\0')) {

BTW The last line above now looks decidedly dodgy, but I dont know the
spec well enough to know if its a potential error, though it slightly
surprisingly doesnt seem to throw an exception on input of e.g 1 on
two systems. Might be best to change it to: &&(buf[len]=='\0')){

regards
Andy Little

[andy]

Pete Becker wrote:

an**@servocomm. freeserve.co.uk wrote:

Whether the function should assert or throw an
exception on failure is another debate too
No, it's not. <g> It's a matter of looking at the design of the
application it's going to be used in.

But in general, low level functions should report errors in-channel,
because once you've added the overhead of throwing exceptions you can't
get rid of it. Applications that don't use exceptions shouldn't have to
pay for them.

I put them in because I do use them. If an empty string is returned
that is an error and must be acknowledged as such rather than ignored,
which is what happens IMO all to often if it can be ignored.
Embarassing as it is is users must be informed when output is invalid
even if in worst case the application shuts down to indicate its
mangled their data.

(The same is true in critical embedded systems AFAIK except that the
error must be dealt with in place or the alarm sounds and everybody
runs for it, nevertheless in all cases it must be made impossible to
ignore corrupted data)

So this sort of thing ought to be written in two layers, one to do the formatting and report errors, and one that calls it and
translates errors into exceptions.

char *itoc(char *buf, size_t size_if_you_ins ist, int val)
{
format val into buf
if successful, return next position in buf, otherwise return 0

^^^^^^^^^^^^^^^ ^^^^^^^^^^

What are we doing here? ... iterating char by char ... seems a little
slow, hardly inlinable surely? ... hmm what about using a stringstream
?

;-)

regards
Andy Little

[Roland Pibinger]

On 11 Mar 2006 14:19:21 -0800, an**@servocomm. freeserve.co.uk wrote:

Pete Becker wrote:

But in general, low level functions should report errors in-channel,
because once you've added the overhead of throwing exceptions you can't
get rid of it. Applications that don't use exceptions shouldn't have to
pay for them.

I put them in because I do use them. If an empty string is returned
that is an error and must be acknowledged as such rather than ignored,
which is what happens IMO all to often if it can be ignored.

Actually, the conversion from int to string cannot fail because all
bit combinations in an int result in a valid value. The only
'exception' is an out-of-memory condition but that's a different
question (you cannot handle OOM with exceptions). The error handling
code is only included to acknowledge the return value of snprintf.
BTW, the conversion functions are of course not symmetric (string to
int can fail).

Best wishes,
Roland Pibinger

[Roland Pibinger]

On 11 Mar 2006 13:03:33 -0800, an**@servocomm. freeserve.co.uk wrote:

inline
std::string& itostr (int i, std::string& out)
{
std::string::va lue_type buf[std::numeric_li mits<int>::digi ts10 +
3];
int len = std::sprintf(bu f, "%d", i); //slightly quicker
if (len > 0 && size_t (len) < sizeof (buf)
&& (buf[std::numeric_li mits<int>::digi ts10 + 2]=='\0')) {

What means std::numeric_li mits<int>::digi ts10 and why is it 9 on a 32
bit system?

Roland Pibinger

[Pete Becker]

an**@servocomm. freeserve.co.uk wrote:

char *itoc(char *buf, size_t size_if_you_ins ist, int val)
{
format val into buf
if successful, return next position in buf, otherwise return 0

^^^^^^^^^^^^^^^ ^^^^^^^^^^

What are we doing here? ... iterating char by char

No, formatting the text into a buffer and returning the _next_ position
in the buffer, i.e. the one after the formatted text. That makes it easy
to continue to append to the buffer.

--

Pete Becker
Roundhouse Consulting, Ltd.

[andy]

Roland Pibinger wrote:

On 11 Mar 2006 13:03:33 -0800, an**@servocomm. freeserve.co.uk wrote:

inline
std::string& itostr (int i, std::string& out)
{
std::string::va lue_type buf[std::numeric_li mits<int>::digi ts10 +
3];
int len = std::sprintf(bu f, "%d", i); //slightly quicker
if (len > 0 && size_t (len) < sizeof (buf)
&& (buf[std::numeric_li mits<int>::digi ts10 + 2]=='\0')) {

What means std::numeric_li mits<int>::digi ts10 and why is it 9 on a 32
bit system?

It means that you will get a maximum of digits10 + 1 digits for the
type. Don't ask me why its +1. Try this program to make it clearer.
Just count the number of digits shown by each number and compare that
with digits10 value + 1
#include <limits>
#include <iostream>

template <typename T>
void func()
{
std::cout << std::numeric_li mits<T>::digits 10 << '\n';
std::cout << std::numeric_li mits<T>::max() << '\n';
}

int main()
{

func<short>();
func<unsigned short>();
func<int>();
func<unsigned int>();
func<long>();
func<unsigned long>();
func<long long>();
func<unsigned long long>();
}

regards
Andy Little

[andy]

Roland Pibinger wrote:

On 11 Mar 2006 14:19:21 -0800, an**@servocomm. freeserve.co.uk wrote:

Pete Becker wrote:

But in general, low level functions should report errors in-channel,
because once you've added the overhead of throwing exceptions you can't
get rid of it. Applications that don't use exceptions shouldn't have to
pay for them.
I put them in because I do use them. If an empty string is returned
that is an error and must be acknowledged as such rather than ignored,
which is what happens IMO all to often if it can be ignored.

Actually, the conversion from int to string cannot fail because all
bit combinations in an int result in a valid value. The only
'exception' is an out-of-memory condition but that's a different
question (you cannot handle OOM with exceptions). The error handling
code is only included to acknowledge the return value of snprintf.

In that case things are much simpler. Now I added a traits class for
the format string so potentially extending the useage to other integer
types, though it seems sprintf is a bit limited to signed and unsigned
int only..whatever. ..

#include <cstdio>
#include <limits>
#include <string>
#include <boost/utility/enable_if.hpp>
#include <boost/type_traits/is_integral.hpp >

template <typename IntegerType>
struct format;

template <>
struct format<int>{
static const char* specifier(){ret urn "%d";}
};
template <>
struct format<unsigned int>{
static const char* specifier(){ret urn "%u";}
};

template <typename IntegerType>
inline
typename boost::enable_i f<
boost::is_integ ral<IntegerType >,
std::string&::type

itostr (IntegerType i, std::string& out)
{
std::string::va lue_type buf[
std::numeric_li mits<IntegerTyp e>::digits10 + 3
];
std::string::si ze_type len
= std::sprintf(bu f, format<IntegerT ype>::specifier (), i);
out.assign(buf, len);
return out;
}

#include <iostream>
int main()
{
std::string str;
itostr(-1,str);
std::cout << str <<'\n';
itostr(1U,str);
std::cout << str <<'\n';
}

regards
Andy Little

[Daniel T.]

In article <44************ **@news.utanet. at>,
rp*****@yahoo.c om (Roland Pibinger) wrote:

On Sat, 11 Mar 2006 11:11:57 -0500, Pete Becker <pe********@acm .org>
wrote:

Daniel T. wrote:

So, what is the "appropriat e test" to ensure that a buffer is not
overrun?

Here's a proposal for a simple, efficient, and safe conversion
function:

#include <stdio.h>
#include <string>

inline std::string& itostr (int i, std::string& out) {
std::string::va lue_type buf[128];
int len = snprintf(buf, sizeof(buf), "%d", i);

if (len > 0 && size_t (len) < sizeof (buf)) {
out.assign(buf, std::string::si ze_type (len));
} else {
out.clear();
}
return out;
}

Why put a 128 char buffer on the stack when string already has one
imbedded in it...

string& itostr( int i, string& result )
{
result.clear();
if ( i == INT_MIN ) {
result += "-2147483648";
}
else if ( i == 0 ) {
result = '0';
}
else {
string::size_ty pe pos = 0;
if ( i < 0 ) {
result = '-';
i = -i;
pos = 1;
}
while ( i > 0 ) {
result.insert( pos, 1, char( '0' + i % 10 ) );
i /= 10;
}
}
return result;
}

string itostr( int i ) {
string result;
itostr( i, result );
return result;
}
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.