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…)
Really, I would not try to outsmart the specification---even if the
specification is far from beautiful.
Right, doing things properly, for whatever definition of 'properly', is more
important than anything else. That's how OOo has always been developed and
that's why we now have a clean, easy to understand and elegant codebase. Oh,
wait.
I hope my post did not come across as demanding a sarcastic reply.
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.
You can never do without signed types, so as long as there's a single
unsigned type, there always will be mixing.
Yes, we appear to agree that there is some mixing. I just argued that I do not consider the
(infrequent) mixing a problem worth a more hacky and less straightforward solution than inserting
an explicit cast. (And that if there is high-frequency mixing then probably something else is bad
about the code, and fixing that root cause will also remove the high-frequency mixing.)
-Stephan
Context
- [Libreoffice] [PATCH] Use STL find() in SvxNumberFormatShell (continued)
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.