[Libreoffice] Assertions and Logging

[Stephan Bergmann]

On 11/22/2011 06:53 PM, Lubos Lunak wrote:
> On Tuesday 22 of November 2011, Stephan Bergmann wrote:
>> On 11/22/2011 05:17 PM, Lubos Lunak wrote:
>>>    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?
>>
>> While the macros are currently only enabled in debug builds, I see no
>> reason that should always be so.  A production build from which one can
>> extract such logging information would be quite useful, I think.  So I
>> designed the macros with that in mind.
>
>   I still don't think that changes much. If the output is already generated, it
> will end up somewhere, and that's either /dev/null, in which case the
> generation should not be enabled at all, or it's some terminal, where the
> cost of scrolling, displaying, etc. is much higher than just some string
> creation, or it's some log file, which involves system buffers, writing to
> disk, etc. and that is again more expensive. We could probably make each of
> the output calls solve a random sudoku just for the fun of it and it wouldn't
> make a noticeable difference :). This usage would need at least the part for
> deciding whether to generate any output to be cheap though.

I was more concerned about call-site code size than run time.  Should 
have made that more clear.

>> The only problem with the S variants is the call-site bloat of creating
>> a std::ostringstream and piping into it, etc.  I don't see how that can
>> elegantly be avoided, though.
>
>   If the std::stream stuff is really that heavy, then we don't necessarily need
> to use it (although I admit that this may not fit the above requirement if
> doing the work of using something else is considered not elegant). The stream
> <<  foo style does not mandate using std::stream, e.g. QDebug [*] uses this
> style too. And this could be done later, if it actually is needed. I think
> it's better to start with good API and possibly fix the performance later
> rather than start with good performance and fix the API later.

Yes, replacing std::ostringstream with something else would remain an 
option if need be.

>   As for the plain string case being fast, maybe that could be achieved using
> an overload (or template) with std::stream and const char*.

I achieved it with some compile-time template programming now, see my 
other mail.

Stephan