replacing OUString::valueOf(static_cast<sal_Int32>) ??

[Lubos Lunak]

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
 l.lunak at suse.cz