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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
