On Wednesday 09 of January 2013, Michael Stahl wrote: > On 09/01/13 17:02, Lubos Lunak wrote: > > 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?
You mean having just one overload taking the highest (signed) integer we support? I don't see a problem with that in practice. > > 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). The explicit cast will also always be the same way on all platforms. > > 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. Right, using a different name for the function would be even better. But while we're at it, I think it'd be better to not go the somewhat cryptic way and call it e.g. OUString::number() or similar. > 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? But there's not a problem with it, is there? -- Lubos Lunak [email protected] _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
