First of all: I see this has been already committed, after giving people only
slightly more than the weekend and the day after it to react, which I
consider too short for something with as large scope as this. Some of us
don't work on the weekends and have a backlog when they come back on Monday.
On Friday 18 of November 2011, Stephan Bergmann wrote:
...
- The implementation is somewhat careful to produce as little code as
possible at the call-site of the new macros, and to keep the code path
for suppressed logs as short as possible. However, the C++-stream-style
macros will potentially always be more expensive than the
C-printf-format-style ones.
Does it really matter, when it is used only in debug builds anyway? Debug
builds are slower already anyway, and if the cost of generating the output is
considered expensive, what about the cost of wherever the output will end up?
One open question is which set of macros (the C-printf-format-style ones
or the C++-stream-style ones) to give the "natural" names without
additional suffix.
IMO that is a rather simpler decision: The natural names should be used by
the only set that exists, for a number of reasons:
- the C variants don't work with C++ strings (or other non-trivial data),
which makes them next to useless
- this is debug code, so the slight performance cost is negligible
- where do we have non-C++ code that has actually needs to use this
functionality and cannot just have the filename extension changed?
- people will mix the two sets randomly, with all the consequences (mess,
wondering when to use which one)
- the _S suffix is ugly and it is the variant that'll eventually be used more
- if there are any (real) problems with the C++ variant, perhaps they should
be simply rather fixed/improved
- WTH should we intentionally have two sets of one functionality again?
--
Lubos Lunak
l.lunak@suse.cz
Context
- Re: [Libreoffice] Assertions and Logging (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.