On 17/09/12 16:52, Stephan Bergmann wrote: > On 09/17/2012 11:32 AM, Norbert Thiebaud wrote: >> On Mon, Sep 17, 2012 at 3:27 AM, Stephan Bergmann <sberg...@redhat.com> >> wrote:
>>>> for instance >>>> sal/inc/osl/thread.hxx:#include <cassert> >>>> sal/inc/rtl/strbuf.hxx:#include <cassert> >>>> sal/inc/rtl/string.hxx:#include <cassert> >>>> sal/inc/rtl/ustrbuf.hxx:#include <cassert> >>>> sal/inc/rtl/ustring.hxx:#include <cassert> >>>> sal/textenc/unichars.hxx:#include <cassert> >>>> >>>> and, see above, these guys are included _a lot_ so assert.h get >>>> defined/un-defined/redefined a lot too (just with the 6 include above >>>> we are talking about 85K times. or somewhere liek 4 times per >>>> source... >>>> by centralyzing it at some choke point (sal/config.h if you want) and >>>> hunting down random include of assert.h we actually improve things... > Anyway, even if reducing the number of #include <cassert> in the code > gives a slight compilation speedup, I see no reason why this one > specific case, cassert, should be addressed by replacing all those > individual #includes with a single one in some strategic header, while > many other cases (cstddef, cstring, ...) would not. i think Norbert wants to special case it because, unlike other headers, it does not have the usual include guard macros, but can actually be included multiple times; ordinary headers are only actually opened once by contemporary compilers because they implement an include guard optimization, which of course doesn't work in the assert.h case. i don't really think the performance benefit is that important; but including it in a central place would give a consistency benefit in whether assert is enabled, which sounds good to me... _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
