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


On Fri, Apr 13, 2012 at 08:21:35AM +0200, Stephan Bergmann wrote:
On 04/12/2012 03:59 PM, Lubos Lunak wrote:
 would somebody see a problem with this?

sal/inc/rtl/ustring.hxx :
+#ifdef RTL_AUTOMATIC_USING
+using ::rtl::OUString;
+using ::rtl::OStringToOUString;
+using ::rtl::OUStringToOString;
+#endif

I am not too excited about this.

For one, we need to ensure that none of the URE published interface
implicitly relies on -DRTL_AUTOMATIC_USING.  (And it is not clear to
me that compiling the sal library with -URTL_AUTOMATIC_USING could
even catch all problems in sal headers.)

For another, it increases accidental complexity (an ifdef block; yet
another -D always passed in) for IMO little gain.

And for a third, it introduces a magic special case (certain names
from the rtl namespace can be used without qualification; without
this being evident from the C++ source code itself, as it relies on
.mk file behavior; but there is an exception, that this special case
must not be used in certain headers).

I tend to agree on all points. If something like that is essential, we could
have something like a:
salhelper/inc/rtl/stringhelper.hxx:
#include <rtl/ustring.hxx>
using ::rtl::OUString;
using ::rtl::OStringToOUString;
using ::rtl::OUStringToOString;

and allow that to be used in .cxx only but not in .hxx. Then again the gain is
limited by that and its not automatically checkable without some ugly extra
scripting (right?).

Best,

Bjoern

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.