On 09/18/2012 12:43 PM, Norbert Thiebaud wrote:
On Tue, Sep 18, 2012 at 3:38 AM, Stephan Bergmann <[email protected]> wrote:
It turns out that one drawback of this is with header files that are careful
to only declare the incomplete type via
namespace rtl { class OUString; }
(instead of including rtl/ustring.hxx) if that is all they need. They would
either need to continue using "rtl::OUString" (instead of just "OUString"),
or need to duplicate the using declaration (which could be considered
breaking of encapsulation), or include rtl/ustring.hxx instead.
here is (see bottom of the message) a list of cxx file that do
_not_include ustring.hxx (linux build... so there may be a handfull of
platform specific others)
excluding sal and autodoc, that is 236 files... out of 8013 files...
so 97% of the cxx file of the project already include ustring.hxx (and
therefore due to the inclusion chaine also include at a minimum:
* sal/types.h
* sal/config.h
* sal/macros.h
* sal/detail/log.h
* sal/log.hxx
* rtl/ustring.h
* osl/interlck.h
* rtl/string.h
* rtl/textcvt.h
* rtl/textenc.h
* rtl/string.hxx
* osl/diagnose.h
* rtl/memory.h
* rtl/stringutils.hxx
so... out of the 163 header ( git grep -l "namespace rtl *{ *class
OU" | grep -v OUStringBuffer | wc -l ) that use that namespace rtl {
class OUString; } construct... most of the time they are trying to
avoid a #include that happen anyway.
But the relevant data would rather be how many of those cxx files that
do include rtl/ustring.hxx do so unnecessarily (and are thus needlessly
recompiled when rtl/ustring.hxx changes -- which it happens to do a lot
these days).
Granted, the entities declared in rtl/ustring.hxx are used so widely
that the number of cxx files that do not need to include it is probably
rather small. Still, I consider it good practice in general to use the
idiom of only declaring incomplete types in headers where appropriate.
(And blame not following that practice as one reason for needlessly long
rebuild times.)
Stephan
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
