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

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 )
?

 Yes, I know I used static_cast<>, but that's because of my undying love for 
all these integer problems, so I wanted to have a little fun as a 
compensation :). And I'd like to get rid of all this one day.

> > and we can document in one place why it's necessary.

 So that other people don't have to search: According to my reading of the 
standard (mainly 13.3.3.1.1 and 13.3.3.2 [*]), this is because when choosing 
which conversion for overloaded functions is better, the standard treats all 
integer conversions[**] the same. I'm a bit confused by "the rank of S1 is 
better than the rank of S2," in 13.3.3.2, since reading also 4.13 I would say 
that long and long long have different rank, therefore int->long should be 
prefered to int->long long, but a test with all GCC, Clang and MSVC shows 
that having f( long ) and f( long long ) makes f( 0 ) ambiguous :(. Makes me 
wonder if there is some obscure reason for this or if just the person coming 
up with this was having a bad day.

[*] The draft at 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf .
[**] With the exception of promotion of types smaller than int to (unsigned) 
int.

>       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.

> 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).

[***] That meaning language integer types, not the SAL stuff. Overloading on 
the latter would not change anything.

-- 
 Lubos Lunak
 l.lunak@suse.cz