Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On Monday 14 of January 2013, Noel Grandin wrote:
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?

 You need to add overloads, for anything except signed/unsigned char/short:

On Friday 11 of January 2013, Lubos Lunak wrote:
 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). 

-- 
 Lubos Lunak
 l.lunak@suse.cz

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.