[Libreoffice] signed/unsigned comparison (was: [PATCH] Replace SvULongs with vector and code clean up part 1)

[Stephan Bergmann]

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

-Stephan