Re: 'StylePoolImpl::createIterator': function does not take 0 arguments

> As it happens, in LibreOffice code, "#ifdef DEBUG" is 1:1 equivalent to "#if (OSL_DEBUG_LEVEL >= 
> 2)", and the thought was that perhaps all instances of "#ifdef DEBUG" should be changed to that 
> instead, to make it more clear that it is a rather rare way to build, that code inside "#ifdef 
> DEBUG" is *not* compiled in a normal --enable-debug or --enable-dbgutil build, but one needs the 
> much more rare case of increasing the dbglevel thing.
>
> It has even been suggested in the past we should get rid of those dbglevel, or OSL_DEBUG_LEVEL, 
> things, to make the configuration space smaller. It is quite enough (in my opinion) to have 
> --enable-debug, --enable-dbgutil, --enable-symbols, --enable-assert-always-abort, and 
> --enable-sal-log, that all have related but different meanings. Also --enable-release-build could 
> be interpreted as being related. And I probably forgot some...

Having fallen into this pitfall a couple of times and got a headache understanding why the code was 
not executed, I highly favor to at least change to OSL_DEBUG_LEVEL >= 2.

I am one of those who would like to remove the debug levels, but lately (spending far too much time 
in the internal UNO workings), I am a little afraid that we have a lot of bit rotten code waiting 
to become a problem. So doing this change in a branch would be wise.

rgds
jan I
> Currently, when somebody loosely talks about "debug mode" vs "release mode" (as is common for 
> people coming from a background of Visual Studio projects, for instance), it is fairly unclear 
> what they actually mean. We should strive to make it clearer.
>
> What you say "make my own DEBUG build", what do you mean exactly?
>
> --tml
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice