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

On Aug 9, 2011, at 5:15 PM, Lubos Lunak wrote:
> On Tuesday 09 of August 2011, Stephan Bergmann wrote:
> > On Aug 9, 2011, at 3:02 PM, Lubos Lunak wrote:
> > > Too bad usage of STL drags in these problems, but that's not a problem
> > > that couldn't be solved.
> >
> > How?
>
> namespace lostd // or just no namespace at all, any other 'list' class is 
> unlikely
> {
> template< ... >
> class list : public ::std::list< ... >
> {
> ...
> int size() const { return ::std::list< ... >::size(); } // plus possibly 
> checks here, but somehow doubt there are many cases, if any, where one would 
> have a list with more than 2E9 items
> ...
> };
>
> This class is technically still also std::list, so it should be a drop-in 
> replacement for all cases. And IMO a much nicer solution than 
> people "randomly" adding casts all over the codebase.

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.)  Really, I 
would not try to outsmart the specification---even if the specification is far from beautiful.

From my experience, I consider the problem of "randomly added casts" as not that severe, anyway.  
The best fix for the code in question would probably be if "indexing types" like the type of nEntry 
were std::size_t to begin with.  Then, explicit casts would probably only be needed at the 
interfaces to external representations (like file formats)---places where explicit range checks are 
typically already needed, anyway.

-Stephan