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

[Michael Stahl]

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?