Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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.