convert int to string without using standard library (stdio.h)

[websnarf]

Its too short to be obfuscated. I didn't ram things on one line, and I
didn't use side-effects in unexpected ways, I didn't abuse the
preprocessor, and there is nothing mysterious in the algorithm used.

Ya reckon? "somestring"[var] is generally mysterious to newbies;

Its rare, but its not mysterious. Newbie or not, you can understand
what that very quickly. Do you know how many programming languages
support that, BTW?

For martians.

Its easy to throw stones, especially when you are setting your own bar
for what you can understand. So show me something that is both clearer
and still correct.

[...] and completely unsuitable for the OP's level
of understanding.

What do you know of the OP's level of understanding?

I can read his original post. Come on, be sensible.

He may not understand C or english, but its not clear to me which. It
turns out the question is actually slightly harder than it seems at
first blush. The other posters here are struggling with it, so perhaps
the OP is simply in the same boat as them, but is actually in pursuit
of a *good* answer.

Yeah, right, like the GTOR.

I don't think says as much about my solution as it does about you.

[...] It seems more grandstanding than helpful.

As opposed to one solution being incorrect, another broken down into a
half dozen sub-functions

Like I said, grandstanding. I gave you the benefit before, now I know.

Well, first of all, you gave me the benefit of nothing. And now you
are basically asserting that correctness and clarity are tantamount to
grandstanding.

You're amusing, in a weird sort of a way.

You are moronic in an explicit sort of way. Do you understand that
faithful conversion of floating point to a string is a *LOT* harder,
and basically a *DIFFERENT PROBLEM*? In fact I would be interested
(from just a "observe a car crash" sense of interest) in how you would
suggest one might convert a floating point to a string.

Wait a second -- remind me, are you the one that said empty strings are
illegal in C?

 

[ceeques]

Thanks all for replying once again.

Morris Dovey wrote:
The OP is involved in a situation involving a lot of

judgement calls to resolve trade-offs, as illustrated by the decision
to not use printf(). If this boundary value problem is significant in
his judgement, he will need to determine appropriate mods (use
unsigned types, promote to wider type within the function, etc); but
can use the code provided as a starting point.

I am actually dealing with unsigned integer and unsigned short. Does it
make the situtaion easier to deal with?. Also, if my integer is
represented in hex values does it change anything?..

Double check that you don't have sprintf in your system libraries
(even if perhaps you don't have the header for it). Also, look for
'itoa' in your system libraries.

If not, download a public domain implementation of sprintf.

As I said before I don't have a standard library - so i can not use
printf or sprintf. I have one function which can print string to the
embedded system output. so I am trying to convert all unsigned int /
unsigned short to a string.


THANKS!
cQ

 

[Morris Dovey]

ceeques (in (e-mail address removed))
said:

| I am actually dealing with unsigned integer and unsigned short.
| Does it make the situtaion easier to deal with?. Also, if my
| integer is represented in hex values does it change anything?..

Using unsigned types does make it easier. As Eric pointed out, the
function I posted has a problem with the largest negative number -
and by using only unsigned integer types you avoid that problem (and
eliminate the need to deal with taking the absolute value, output of
the sign character, and need for another pointer to char. The code can
be shortened to:

char *itos(char *s,unsigned i)
{ unsigned t = i;
do ++s; while (t /= 10);
*s = '\0';
do *--s = '0' + i % 10; while (i /= 10);
return s;
}

The conversion to hexadecimal digits is slightly different; since you
can use >> and & operations instead of / and % operations; and use the
digit values to retrieve digit characters from an array of 16 chars.
Since it's common to display leading zeros with hex numbers, you may
elect to eliminate the first do{}while loop.

The suggestion to download a public domain version of sprintf() is not
a bad idea. On one embedded project, we started with a public domain
version and removed all the features/formats we didn't want to
minimize the memory footprint.

 

[websnarf]

Thanks all for replying once again.
Morris Dovey wrote:
The OP is involved in a situation involving a lot of

I am actually dealing with unsigned integer and unsigned short. Does it
make the situtaion easier to deal with?.

Yes it does. You can drop all the negation checking logic.

[...] Also, if my integer is
represented in hex values does it change anything?..

You can exchange division and modulo with a shift and mask. You can't
use the '0'+lastDigit trick for hexadecimal, of course (this does not
affect my proposed solution.) I would not say that it was technically
*easier*.

As I said before I don't have a standard library - so i can not use
printf or sprintf.

Well his point was to go find the source code for sprintf, and just rip
out the part that you need. Unfortunately, its a pretty ignorant
comment, since such code is usually unusually complicated and targetted
towards a different parametrization (you usually pass the field width,
0-extension padding, signedness, right-justification mode, etc
parameters along with your conversion). Its hard to believe that was
given as a serious answer.

I gave you a 12-line solution written way faster than I could mutate
any sprintf source into a correct solution (I wonder how fast you, as a
self-admitted novice, would be able to do the sprintf-source solution).
For just the unsigned cases, Morris Dovey's solution works (though,
his signed int solution is wrong), so you can use that (though I
personally, would generate the string in reverse, then reverse the
string, rather than pay twice the penalty for all the divides and
modulos).

[...] I have one function which can print string to the
embedded system output. so I am trying to convert all unsigned int /
unsigned short to a string.

Right -- so being that you are on an embedded system, do you suppose
that the conciseness of the solution is important?

 

[Mark McIntyre]

Ya reckon? "somestring"[var] is generally mysterious to newbies;

Its rare, but its not mysterious. Newbie or not, you can understand
what that very quickly.

Hmm, theres probably a reason why its a FAQ.

Its easy to throw stones, especially when you are setting your own bar
for what you can understand. So show me something that is both clearer
and still correct.

*shrug*. I already gave the poster a reasonable suggestion that was
both clear and correct.

He may not understand C or english, but its not clear to me which.

Lets be clear: the OP wanted to know how to output numbers without
using printf. This isn't particularly hard, your fairly confusing
example notwithstanding.

Well, first of all, you gave me the benefit of nothing.
Incorrect

And now you
are basically asserting that correctness and clarity are tantamount to
grandstanding.

No, I'm asserting that posturing and showing off are tantamount to
grandstanding.

You are moronic in an explicit sort of way.

And you're neither the front nor the rear of a donkey.

Do you understand that
faithful conversion of floating point to a string is a *LOT* harder,
and basically a *DIFFERENT PROBLEM*?

I disagree.

In fact I would be interested
(from just a "observe a car crash" sense of interest) in how you would
suggest one might convert a floating point to a string.

I'm sure you would. Here's a hint: printf has a default precision.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[websnarf]

Ya reckon? "somestring"[var] is generally mysterious to newbies;

Its rare, but its not mysterious. Newbie or not, you can understand
what that very quickly.

Hmm, theres probably a reason why its a FAQ.

Probably so that newbies could learn it and understand it very quickly.
Although its clearly geared at a very particular kind of newbie --
i.e., one that has not used other languages that also support that
feature.

*shrug*. I already gave the poster a reasonable suggestion that was
both clear and correct.

You didn't explain how to extract the digits. Nor did you explain the
problem with negative numbers. How can you be either clear or correct
if you don't describe a complete algorithm?

Lets be clear: the OP wanted to know how to output numbers without
using printf. This isn't particularly hard, your fairly confusing
example notwithstanding.

Its confusing to you and Old Wolfe, because in a very real sense you
two do not understand the problem. Any complexity that is in my
solution corresponds exactly with the required complexity for solving
the problem. Morris Dovey, for example, was the only one to post a
clearer/simpler solution -- but of course, his initial solution was
wrong (as Eric Sosman also points out.) pete's solution may be correct
(I didn't bother to check it, but I can see what he's *trying* to do)
but it is insanely hard to see that it is correct (I noticed you didn't
make any comment about his solution.) My solution has the benefit of
being correct while being easy to see *why* it is correct.

No, I'm asserting that posturing and showing off are tantamount to
grandstanding.

But these attributes are all inside *your* mind. If the problem is so
easy, as you claim, then how is it possible to show off by solving such
an easy problem? The fact is that the problem, as originally stated,
is *slightly* complicated, and was not really satisfactorily answered
by anyone else's post (you could argue that pete's might be ok, but I
still cannot *see* why it works; I would have to run it under a
debugger I think).

I disagree.

Well you're consistent anyways. Since you haven't even presented a
solution to the original problem, I can see how you are going to easily
subterfuge your way out of this one ...

I'm sure you would. Here's a hint: printf has a default precision.

Well here's a hint for you: for a large enough floating point number f
and integer x the value of (f mod 10^x) is not representable with full
precision in any predetermined length finite data type (similarly for f
* 10^x, for large enough x). So you can try doing it the same way as
you do it for integers, but as typically is the case with you, you will
get an incorrect answer. Your move.

 

[Mark McIntyre]

Mark McIntyre wrote:
Ya reckon? "somestring"[var] is generally mysterious to newbies;

Its rare, but its not mysterious. Newbie or not, you can understand
what that very quickly.

Hmm, theres probably a reason why its a FAQ.

Probably so that newbies could learn it and understand it very quickly.

Er no. A FAQ is a Frequently ASKED question. That is to say, its
something that people often find confusing....

Although its clearly geared at a very particular kind of newbie --

Yup, ones who are new to C.

You didn't explain how to extract the digits. Nor did you explain the
problem with negative numbers. How can you be either clear or correct
if you don't describe a complete algorithm?

Firstly, completeness is nothing to do with clarity and correctness.
You know this, but are being awkward.

Secondly, we have a tradition in CLC of giving people enough
iformation to work out the rest themselves. You know this, and are
being disingenuous.

Its confusing to you and Old Wolfe, because in a very real sense you
two do not understand the problem.

Pompous git. You really are a complete birk aren't you?

Well here's a hint for you: for a large enough floating point number f
and integer x the value of (f mod 10^x) is not representable with full
precision in any predetermined length finite data type

Apparently you don't understand the problem or the solution after all.

(similarly for f
* 10^x, for large enough x). So you can try doing it the same way as
you do it for integers, but as typically is the case with you, you will
get an incorrect answer. Your move.

I'm not interested in playing "my dick is bigger than yours" thanks.


--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[websnarf]

On 18 Jul 2006 15:32:37 -0700, in comp.lang.c , (e-mail address removed)
wrote:
Mark McIntyre wrote:
Ya reckon? "somestring"[var] is generally mysterious to newbies;

Its rare, but its not mysterious. Newbie or not, you can understand
what that very quickly.

Hmm, theres probably a reason why its a FAQ.

Probably so that newbies could learn it and understand it very quickly.

Er no. A FAQ is a Frequently ASKED question.

That's what the letters stand for, but that's not what it is. Why
doesn't the C FAQ supply an answer for splitting strings by characters,
since that's asked here over and over. It doesn't even discuss strtok
at all (I've answered questions about this function itself a half dozen
times here in the last year.) In fact I am not aware of any FAQ in
existence which is actually a collection of frequently asked questions.
Its just a moniker.

Anyone who isn't completely new to the internet ought to know this
(BTW, this is not "an internet", its a news message, and no it did not
arrive through a series of tubes).

[...] That is to say, its
something that people often find confusing....

So you think Steve Summit did the research to actually find out what
people find confusing? Do you think he maintains counts on the number
of times any particular kind of question is asked?

Yup, ones who are new to C.

That's simply not so. An experienced Java, Python or Lua programmer,
who was learning C for the first time would not even notice anything

Firstly, completeness is nothing to do with clarity and correctness.

So you occupy a position that is simultaneously clear, correct and yet
ambiguous and incomplete? You have not demonstrated that your approach
*will* work. For example, it *DOESN'T* work with floating point
numbers. That's like describing some attributes about how a perpetual
motion machine might function without giving the details of how to
build one.

You know this, but are being awkward.

No, I'm asserting that pretending that you are clear or correct is
meaningless when talking about something that isn't well defined. In
this case your proposed answer.

Secondly, we have a tradition in CLC of giving people enough
iformation to work out the rest themselves. You know this, and are
being disingenuous.

Yeah, sieg heil! Anyways, *I* have a tradition of removing ambiguity
and trying to provide *REAL* clarity. And I point out mistakes,
especially if they appear hidden or have any reasonable chance of being
misleading (such as this case). I really don't care what the rest of
you sheep do in CLC, except where it clearly acts against this.

Your solution isn't a solution at all, so I just treated it as line
noise (which has a similar degree of clarity and correctness), as I am
sure the OP did as well. Its the other solutions that posed the
problem, because they are close to correct (or difficult to verify as
correct), and the OP could easily have been lead astray. My solution,
in a sense, simultaneously demonstrates why all the other "solutions"
have problems.

So if you have a problem with my approach to posting here, I am going
to suggest that its your problem, as I have no intention of modifying
the way I do things.

 

[Richard Heathfield]

(e-mail address removed) said:

Yeah, sieg heil!

Right up until that point, you had my sympathy.

 

[Keith Thompson]

Mark McIntyre wrote: [...]

Secondly, we have a tradition in CLC of giving people enough
iformation to work out the rest themselves. You know this, and are
being disingenuous.

Yeah, sieg heil!

Shove it, Paul.

 

[Default User]

So if you have a problem with my approach to posting here, I am going
to suggest that its your problem, as I have no intention of modifying
the way I do things.

Fortunately, that can be remedied from my standpoint.

*plonk*




Brian