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

[Noel Grandin]

On 2013-01-11 15:32, Lubos Lunak wrote:
>>>   
>>>   Following this, what the developer really wants is to create a string from a
>>> number. So OUString::fromNumber() seems like the obvious name for it. And it
>>> should take numbers of any kind, as it doesn't really matter, in the common
>>> case "give me this number as a string" is conceptually the same whether the
>>> number is a long or float. So that should be the optimal API for the
>>> functionality.
>>>
>>>   Now some real-world issues may enter into play, e.g. when the number is
>>> integer, it may be useful to specify the radix, which doesn't make much sense
>>> with floats; valueOf() has a default argument there, so it can be handled the
>>> same way. Another thing, since valueOf() is often used when constructing
>>> strings, OUString::fromNumber() may be considered a bit too long and it may
>>> be acceptable trade-off to shorten it to OUString::number(). Anything less,
>>> such as leaking irrelevant implementation details and forcing the developer
>>> to explicitly specify the underlying type, is settling on sub-optimal API
>>> that moves part of the implementation burden on the user of the library.
>>>
>>>   So, based on this, the best solution to the problem that I can see is
>>> creating fromNumber() or number() , overloaded for all signed/unsigned
>>> int/long/long long types and all floats because of the lame language
>>> ambiguity. The original valueOf() can be wrapped inside #ifndef
>>> LIBO_INTERNAL_ONLY after LO is moved away from this problematic function to
>>> keep it only for external backwards compatibility, while LO itself will no
>>> longer "have" it. So rather than bitting us in small ways every now and then,
>>> the (possibly smaller in the end, if it wasn't for this discussion) effort is
>>> spent now, and the effort is not that big (all the duplicates can be only 6
>>> lines, 2 for doxygen @overload @since, 4 for code forwarding to the overload
>>> taking the largest type). Win/win. And if this is still not convincing
>>> enough, then I give up.
>>>


OK, so I tried modifying my patch so that we have
   number(sal_Int64)
   number(float)
   number(double)

At which point my unit tests fail when passing a 32-bit value in because 
the compiler does not
know which overload to use - this is on 64-bit Ubuntu using gcc 4.7.2

I can't add a sal_Int32 variant because I suspect that will make the 
original problem come back, which was where
we started, with all the "static_cast<sal_Int32>" stuff.

Any ideas?





Disclaimer: http://www.peralex.com/disclaimer.html