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 [email protected] _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
