On Thursday 15 of December 2011, Stephan Bergmann wrote:
On 12/15/2011 02:57 PM, Lubos Lunak wrote:
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?
No. I mean that 'foo( "bar" << "baz" )' is incorrect C++, unless foo is a
macro that does some hidden magic behind the scenes that changes the meaning.
And not only it's incorrect, it's also not obvious.
Of course, one can learn this case, and add it to the hundreds of other cases
that we already have where one either knows it or bumps into it and has to
start digging around. When was the last time somebody has run e.g. into UNO's
= operator (and that one actually is somewhat more obvious that this)?
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.
I was talking about the strings on the input of the log call. If the syntax
is SAL_INFO( "area", "File ", file, " not found." ), then "File " and " not
found." can be converted automatically using utf-8, because it's just a log
message, so it's very likely only English anyway, and it's a perfectly fine
way of avoiding the truly horrible SAL_INFO( "area",
RTL_CONSTASCII_USTRINGPARAM( "File " ), file, RTL_CONSTASCII_USTRINGPARAM( "
not found." )). At the same time, it does not introduce this automatic
conversion anywhere else, as the ostream-based operator<< can.
--
Lubos Lunak
l.lunak@suse.cz
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.