On Friday 13 of April 2012, 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.)
I think you are right about -URTL_AUTOMATIC_USING for sal not being a very good idea, it'd be better to just have one check .cxx that'd include everything in sal (and another one for URE, and whenever else needed), without having the #define in effect. That'd make sure no problem slips through if the file was automatically made to include inc/*.hxx , and a failure only in the one .cxx would make it more obvious why it fails. > For another, it increases accidental complexity (an ifdef block; yet > another -D always passed in) for IMO little gain. No, you see it backwards :). It reduces code annoyances for IMO very little price. > And for a third, it introduces a magic special case (certain names from > the rtl namespace can be used without qualification; Strings already kind of are a magic special case. They are the one non-builtin type that is by far the most used one, close to the builtin ones (which is part of the reason why many programming languages do have strings as a builtin type). So I see nothing wrong with trying to get them as conveniently usable as possible, as ::any::little::annoynance::there AddsUpNumerousTimesL BECAUSE_THE_THING_IS_USED_SO_OFTEN. I understand that this argument probably doesn't work that well with people who have already gotten used to all kind of quirks of a codebase that has managed to get even int and bool types complicated, since we simply have to get the work done somehow (and I said 'we', because I can already watch myself getting used to things I'd prefer not to), but that doesn't mean everybody has to suck it up until the end of time. As the strings are already namespaced by the name itself, I'd be open to alternate solutions such as moving them out of the namespace, but that'd break binary compatibility and the (probably only hypothetical) case of some other code using the name for something else. -- Lubos Lunak l.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
