Re: sal/config.g sal/types.h and sal/osl/rtl includes in general

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 <sbergman@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...