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

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