On Tue, Dec 19, 2000 at 09:25:47PM +0000, Nick Ing-Simmons wrote: > Nicholas Clark <nick@ccl4.org> writes: > >> > >> But I don't see where looks_like_number() lets things with ',' in through > >> to be converted ... > > > >I think that I was unclear. Jarkko was suggesting roll our own strtol > >(etc) for perl6. > >I was only thinking in terms of roll our own routine in 5.7 for sv_2[iun]v > >to call. > > So was I - looks_like_number is doing most of the work already, having it > tally up the digits into an UV as it goes makes a lot of sense to me. I'll be even happier if the arm backend optimiser likes the idea of *10 being total ||= total << 2; total = new_digit + total << 1; as that's 2 machine instructions, 2 clock cycles, whereas *10 is at least 4 IIRC. Just 1 more advantage of base being constant at compile time. I think can get the value out of looks_like_number pretty much for free. (and I think I know how to pre-empt overflow cheaply) > It is less clear that we want the hassle of the NV case. I wasn't thinking of the NV case. As I mailed Jarkko privately recenmtly, I don't like floting point numbers. I had 4 different versions of "500" once, but I only found out that this was the cause of my problem after 2 or 3 days of pain. Also, numconvert.t getting upset with 18446744073709551615 and 18446744073709551616 as they go too and from floating point (particulary long double - still not solved, not even sure it it's soluable) remind me that floating point is horrible. I would have said "I like chars. There are only 256 of them." But someone's removed that safe haven now. I was thinking something like int son_looks_like_number (SV * sv, UV *value); that returns flags about what it found out in the int, and the value in *value if the pointer is non null, and the value doesn't overflow. (flags include "minus", "erk we've overflowed the UV", "saw a decimal point" "saw e notation" and "infinity" as now; the UV would return the abs value) Nicholas ClarkThread Previous | Thread Next