On 09/01/13 17:02, Lubos Lunak wrote: > On Wednesday 09 of January 2013, Michael Meeks wrote: >> On Wed, 2013-01-09 at 16:10 +0200, Noel Grandin wrote: >>> maybe we need >>> OUString::valueOfInt32(sal_Int32) >>> that does the cast for us? >>> >>> At least it'll be less noisy, > > Is there really such a big difference between > OUString::valueOf( sal_Int32( 0 )) > and > OUString::valueOfInt32( 0 )
it has the advantage of being explicit in what type it expects; however i actually think that is quite irrelevant for a Integer-to-String conversion (as opposed to a -to-binary conversion); are there any use cases where converting to a "too big" integer type would mess up the result? so it would probably be an improvement, but a small one. >> Looks less error prone to me; doesn't suffer from odd side-effects of >> un-related type changes as badly either; > > What makes you think so? Having the type directly in the function name is > almost the same like the explicit cast. If you cast incorrectly, you'll just > as well get incorrect implicit cast when calling the function renamed > function. but you'll at least implicitly cast the same way on all platforms (since the sal types don't map to arbitrary types, but to types of a particular size). >> hopefully fixes the perennial >> 64bit vs. 32bit issues. Can be in-lined to produce ~identical code, we >> could deprecated the old valueOf() methods just to beef up the idea that >> we're continuing to evolve the sal API ;-) >> >> Any profound objections ? [ not that I've time to do it myself of >> course ]. > > Uhm, but we already have more than enough Hungarian notation all over the > place. If the API is to evolve, it should not do so by going backwards :(. > > What I think would work better would be having overloads for each > integer[***]/float type (or a template), all of them still named valueOf(). > That means one wouldn't need to bother with what the type actually is and the > functions would just do the right thing (well, as long as the type is not > sal_uInt8 or sal_uInt16, since, SAL types madness striking again, those are > actually sal_Bool resp. sal_Unicode). i don't like that idea, actually because there are already valueOf overloads for integral types sal_Bool and sal_Unicode that do something other than produce a string representation of an integer value, which seems wrong to me to begin with. better to add a new overloaded function, say valueOfInt, and have overloads for all possible C++ integral types, all of which produce strings with numbers. using that consistently would also solve the problem of accidentally calling valueOf(a_sal_uInt16) and getting surprising results. only question is what to do about the "radix" parameter which is supported by sal_Int32 and sal_Int64 parameters currently... likely it's not needed often? _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
