itoa'd you so?

Steve 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.
>
>                 --Levi
>
> /*
> 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 mailing list