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

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?