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/

[Victor Bazarov]

Steven T. Hatton wrote:

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.

sprintf

V
--
Please remove capital As from my address when replying by mail

[mlimber]

Steven T. Hatton wrote:

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.

The example Stroustrup gives is the best way. Compare:

http://www.parashift.com/c++-faq-lit....html#faq-39.2
http://www.parashift.com/c++-faq-lit....html#faq-39.3

As the FAQ notes, you could use C facilities rather than C++, but the
latter should be preferred.

See also Boost's lexical_cast.

Cheers! --M

[Pete Becker]

mlimber wrote:

As the FAQ notes, you could use C facilities rather than C++, but the
latter should be preferred.

However, it doesn't say why the "C++" approach should be preferred.
(Yes, I'm aware that it's possible to pass too small an output buffer to
the C functions. Don't do that.)

C provides perfectly good conversion functions. The "C++" approach,
creating a stringstream object which you then throw away, is extremely
expensive. I would never use it.

--

Pete Becker
Roundhouse Consulting, Ltd.

[Steven T. Hatton]

mlimber wrote:

The example Stroustrup gives is the best way. Compare:

http://www.parashift.com/c++-faq-lit....html#faq-39.2
http://www.parashift.com/c++-faq-lit....html#faq-39.3

As the FAQ notes, you could use C facilities rather than C++, but the
latter should be preferred.

See also Boost's lexical_cast.

Cheers! --M

The whole idea is to have one little call such as itos there when you need
it. I usually want to do it in a situation such as :

virtual const char* what() const throw() {
std::string message(_myName );
message+="\n\t" ;
message+=""!=_n amespaceName? _namespaceName+ "::":"";
message+=""!=_c lassName ? _className +"::":"";

message+=""!=_f ile?" File: "+_file :"";
message+= 0!=_line?" Line: "+itos(_line):" ";

message+=_messa ge;

return message.toStdSt ring().c_str();
}
Note that I have not yet tested this with std::string. I am converting code
that used Qt QString, which provides a QString::setNum (int).
--
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/

[Dietmar Kuehl]

Pete Becker wrote:

C provides perfectly good conversion functions.
.... which are harder to use than might seem. Both the buffer size
and the conversion specifiers are potential stumbling blocks. Of
course, any experienced C programmers knows these.
The "C++" approach,
creating a stringstream object which you then throw away, is extremely
expensive. I would never use it.

It is actually a shame that there is no simple and efficient method
addressing this issue. Of course, what actually qualifies as simple
and/or efficient depends on the user's view. I would use something
like the code below:

#include <algorithm>
#include <limits>

template <typename V, typename OutIt>
OutIt convert(V v, OutIt to)
{
enum { bsize = std::numeric_li mits<V>::digits 10 + 2 };
bool neg = v < 0;

char buffer[bsize], *tmp = buffer + bsize;
*--tmp = "0123456789 "[(neg? -(v + (v < -10? 10: 0)): v) % 10];
v /= 10;

if (neg)
v = -v;

for (; v > 0; v /= 10)
*--tmp = "0123456789 "[v % 10];

if (neg)
*--tmp = '-';
return std::copy(tmp, buffer + bsize, to);
}

Of course, when used with an inappropriate iterator it also gives
the potential of a buffer overrun. ... but it also allows for
perfectly save use e.g. when using 'std::back_inse rter()' together
with an 'std::string' as the destination.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

[Daniel T.]

In article <5N************ *************** ***@speakeasy.n et>,
"Steven T. Hatton" <ch********@ger mania.sup> wrote:

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.

How could it be any more convenient?

template < typename T, typename U >
T lexical_cast( const U& u ) {
std::stringstre am ss;
T t;
if ( !( ss << u && ss >> t ) ) throw std::bad_cast() ;
return t;
}

The above can be used exactly like any of the other casting operators
that C++ provides. Boost provides a much more optimized version if you
find it necessary.

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

[Daniel T.]

In article <ps************ ********@gigane ws.com>,
Pete Becker <pe********@acm .org> wrote:

mlimber wrote:

As the FAQ notes, you could use C facilities rather than C++, but the
latter should be preferred.

However, it doesn't say why the "C++" approach should be preferred.
(Yes, I'm aware that it's possible to pass too small an output buffer to
the C functions. Don't do that.)

Passing a too small buffer, and type safety are the two reasons I can
think of off hand, there may be more.

When it comes down to it, the C++ approach has less undefined behavior.
In order to "just don't do that" one must know all the things that one
shouldn't do. Obviously, the fewer things there are, the easer it will
be to not do them.

C provides perfectly good conversion functions.
"perfectly" ? I think "adequate" would be a more appropriate adjective,
as in "barely sufficient or satisfactory". But that's just me, YMMV.

The "C++" approach,
creating a stringstream object which you then throw away, is extremely
expensive. I would never use it.

I use stringstreams for this purpose all over my code and I've never had
a user complain that it's too slow because of it. Yes, I've written code
that's "too slow", that's part of the nature of writing games, but
profiling showed other parts of the code that were far more expensive
than stringstreams.
--
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.

[Bo Persson]

"Steven T. Hatton" <ch********@ger mania.sup> skrev i meddelandet
news:b6******** *************** *******@speakea sy.net...

mlimber wrote:

The example Stroustrup gives is the best way. Compare:

http://www.parashift.com/c++-faq-lit....html#faq-39.2
http://www.parashift.com/c++-faq-lit....html#faq-39.3

As the FAQ notes, you could use C facilities rather than C++, but
the
latter should be preferred.

See also Boost's lexical_cast.

Cheers! --M

The whole idea is to have one little call such as itos there when
you need
it. I usually want to do it in a situation such as :

virtual const char* what() const throw() {
std::string message(_myName );
message+="\n\t" ;
message+=""!=_n amespaceName? _namespaceName+ "::":"";
message+=""!=_c lassName ? _className +"::":"";

message+=""!=_f ile?" File: "+_file :"";
message+= 0!=_line?" Line: "+itos(_line):" ";

message+=_messa ge;

return message.toStdSt ring().c_str();
}
Note that I have not yet tested this with std::string.

No, obviously! :-)

This is exactly why using C style char pointers are so dangerous. As
soon as the function returns, the message goes out of scope, and is
destroyed.

Guess what happens to the pointer?
(You also cannot say that what() doesn't throw, when any of the string
operations might throw a bad_alloc.)
Bo Persson

[Pete Becker]

Daniel T. wrote:

In article <ps************ ********@gigane ws.com>,
Pete Becker <pe********@acm .org> wrote:

mlimber wrote:

As the FAQ notes, you could use C facilities rather than C++, but the
latter should be preferred.

However, it doesn't say why the "C++" approach should be preferred.
(Yes, I'm aware that it's possible to pass too small an output buffer to
the C functions. Don't do that.)

Passing a too small buffer,

Yup. You have to know something about conversions to get conversions right.
and type safety are the two reasons I can
think of off hand,
We're talking about converting an int. Write it once, get it right, end
of discussion.
there may be more.
There may not be. Doesn't affect this discussion.

When it comes down to it, the C++ approach has less undefined behavior.
Nope. Write it once, get it right. No undefined behavior.

Oh, you meant "less opportunity to screw up if you're careless". Well,
that's true. Programming isn't a job for careless people.
In order to "just don't do that" one must know all the things that one
shouldn't do. Obviously, the fewer things there are, the easer it will
be to not do them.
Easier isn't the only goal, especially when any competent programmer
ought to be able to convert an int to a string with very little effort.

The "C++" approach,
creating a stringstream object which you then throw away, is extremely
expensive. I would never use it.

I use stringstreams for this purpose all over my code and I've never had
a user complain that it's too slow because of it. Yes, I've written code
that's "too slow", that's part of the nature of writing games, but
profiling showed other parts of the code that were far more expensive
than stringstreams.

Gratuitously slow code isn't good design. The reasons for using a
stringstream simply aren't compelling, and the cost is high. If you
don't put the slow stuff in, you won't have to take it out later.

--

Pete Becker
Roundhouse Consulting, Ltd.