[Libreoffice] signed/unsigned comparison (was: [PATCH] Replace SvULongs with vector and code clean up part 1)
stephan.bergmann.secondary at googlemail.com
Wed Aug 17 03:03:22 PDT 2011
On Aug 11, 2011, at 12:22 PM, Lubos Lunak wrote:
> On Wednesday 10 of August 2011, Stephan Bergmann wrote:
>> On Aug 10, 2011, at 12:31 PM, Lubos Lunak wrote:
>>> On Tuesday 09 of August 2011, Stephan Bergmann wrote:
>>>> Technically, lostd::list is no longer a container, as it violates the
>>>> requirement that the return type of size() is size_type. (And if you
>>>> redefine size_type as int, as you should do anyway in the above sketch,
>>>> it violates the requirement that size_type is an unsigned integral
>>> Do you realize that as long as the list does not contain 2E9 items, which
>>> it does not, this does not matter at all?
>> That's not my point. My point is that such an IMO hacky solution that
>> tries to outsmart the language is probably not worth it. (Imagine a
>> compiler that emits a warning if a class that does not meet the container
>> requirements is used with one of the standard algorithms…)
> This scores really very very low on my scale of hackiness. Can you come up
> with an example that would be broken by this that would not be more hacky on
> its own?
> And actually, there is even nothing wrong with it technically. If you use the
> class with anything that requires size_t to be unsigned, you use the class as
> std::vector, and there size_t is unsigned. It's only the wrapper that is
> BTW, Qt has been doing this since at least Qt4.0 (see
> http://doc.qt.nokia.com/4.7/qvector.html#size_type-typedef) and apparently
> has been getting away with it nicely. There used to be exactly the same
> annoyances with older Qt and probably most people by now even don't even know
> there could be a problem with anything.
I see. I'm still not convinced, though. For one, there are more uses of unsigned in the C/C++ ecosystem than std::vector::size_type, so there are potentially many more places in the code where you have to be aware of and be prepared to properly handle issues of signed/unsigned mismatch. For another, replacing standard functionality with its own invention (even if its only a wrapper) is something the OOo code base has often been criticized for (and often rightly so, IMO).
But, sure, YMMV.
More information about the LibreOffice