On 2019/05/07 1:06 PM, Luboš Luňák wrote:
If you're going to already handle the problems, why not handle the awfulness
by fixing it, instead of patching it up? The class is broken, and it'll be
broken even after you tweak one consequence of the base problem. If the base
problem gets fixed, the consequence goes away too.
That would ideal, but this class is used __extensively__ by code that
already implements various workarounds and has lots of it's own issues.
What I'm doing here is making its behaviour in the empty case more reasonable,
and adding asserts that will flush out some of the existing dodgy code.
Note I say __some__, there are only a certain amount of regressions we are willing
to tolerate in the pursuit of better code :-)
The class can't be both, internally it stores just one value, and there are
functions such as the Size ctor or operator<< that do take a side (although
in line with the general stupidity, different functions take a different
side). And while the class gets used extensively, the usage can be fixed
mechanically.
I'd be happy to be proven wrong, but I'm not aware of any mechanical fixes.
And I would not be surprised to find code that calls both getWidth() and GetWidth()
on the same object.
Context
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.