On 12/15/2011 02:57 PM, Lubos Lunak wrote:
On Thursday 15 of December 2011, Stephan Bergmann wrote:
On 12/13/2011 07:56 PM, Lubos Lunak wrote:
But it might the moment you realize you're trading away things like
SAL_INFO( "foo", 1<< 2 ) or SAL_INFO( "foo", "bar"<< "baz" ).
Trading away the former, having to parenthesize (1<< 2) instead, is a
std C++ trade-off. Granted, omission of the leading "ostream<<" in the
macro call makes this somewhat non-obvious. What is traded away in the
latter case?
The "bar"<< "baz", which, at first glance, is nonsense. Code is not only
written, it is also read, and many more times.
Still don't get what you mean. You mean, "bar" << "baz" should be
forbidden by the compiler, making sure one writes "barbaz" instead?
Anyway, bikeshedding about surface syntax is rather pointless.
Well, I did say that longer exposure to this codebase makes people oblivious
to bad API, didn't I? This is not bikesheding. This is adding yet one more
case of ugly API to the codebase, and while it's not tragically fugly and
neither are most of the other, it simply all adds up and the result is a
fugly codebase where even adding two strings together is an exercise. And it
will not get better if such stuff will keep getting added because surface
syntax, the thing developers deal with most of the time, is supposedly rather
pointless.
I still think neither approach is more beautiful than the other. But
that's subjective, of course.
Well, that's another advantage of the format approach then. It's an
inconvenience to have to explicitly say the format string is utf-8 (and
arguments probably as well), but then this conversion can be again
limited just to logging and not to every std::ostream operation.
Yes, having the message in UTF-16 is an advantage here. For the
ostream-based approach, we need to wait for general availability of
C++11's char16_t.
They are log messages. They are written in English.
Erm, are we talking past each other here? The fully composed log
message, with string arguments placed into it, somehow needs to handle
the UTF-16 string arguments placed into it. All I wanted to say is that
your approach, building up the fully composed message as
rtl::OUStringBuffer, shields client code from having to specify how to
translate any rtl::OUString arguments into the proper format.
Stephan
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
