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 <[EMAIL PROTECTED]> wrote: > Steve <[EMAIL PROTECTED]> 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. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
