itoa'd you so?
smorrey at gmail.com
Wed Sep 19 16:06:40 MDT 2007
So actually it looks like I misunderstood the original question.
Rather than some fundamental flaw in what I'm doing.
#2 was a serious screw up on my part I should have known better.
But I think #1 was still an elegant answer, although maybe in an
embedded situation it was less than optimal.
I'll keep searching for a better solution, but my thinking was < code
== less things to go wrong.
On 9/19/07, Levi Pearson <levi at cold.org> wrote:
> Steve <smorrey at gmail.com> writes:
> > Ok now this has got me stumped what was unsafe about #2?
> > Taking advantage of the type safety features in the standard lib, is
> > what I was trying to show, and I have a lot of code running using
> > both. If thats unsafe, I have some patchin' to do.
> OK, I reread your description of the problem, and I guess they didn't
> forbid using standard libraries as I thought they did. Using C++
> streams is still serious overkill. Anyway, your emphasis here on
> 'type safety' is misplaced. The type of your function is int ->
> string, and solving the problem doesn't require any typecasting at
> all. As far as type theory goes, you're setting up a map (i.e., a
> function) from integers to their corresponding string representations.
> Maybe you could explain better what your type safety concerns were?
> Clearly, they wanted to see if you knew how to algorithmically
> translate an integer to a string. You totally punted on that problem.
> See several other examples in the thread for what I imagine they were
> looking for.
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
More information about the PLUG