Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Sun, May 22, 2011 at 11:41:31AM +0200, Jacek Wolszczak wrote:
Hi,

I am sending links to patches uploaded to dropbox. I wasn't sure if 1MB
of attachments would be welcome here.

http://dl.dropbox.com/u/174726/patches/0001-Replace-DBG_-with-OSL_-in-calc-chart2.patch
http://dl.dropbox.com/u/174726/patches/0002-Replace-DBG_-with-OSL_-in-sc-source-core.patch
http://dl.dropbox.com/u/174726/patches/0003-Replace-DBG_-with-OSL_-in-sc-source-ui.patch
http://dl.dropbox.com/u/174726/patches/0004-Replace-DBG_-with-OSL_-in-sc-source-filter.patch
http://dl.dropbox.com/u/174726/patches/0005-Follow-up-of-DBG_-removal.patch

Libreoffice compiles with the above changes. 

I'm taking a mutex on this.


Probably a question for a side-thread but what should DBG_CHKTHIS,
DBG_CTOR and DBG_UNHANDLED_EXCEPTION be replaced with. I mean, are there
any OSL_ equivalents for them? Or should they be left as they are?

DBG_CHKTHIS and DBG_CHKOBJ does sanity check of the object, if a function
is passed. In many cases it is not, though--because I do not see any
reason for them in that case, I suppose they are just placeholders for
future extension. The function passed to them has signature
char const* (*)(void const*), where the argument is pointer to the
tested object and return value is 0 if there are no problems and
a (static) string describing the problem otherwise. I would change the
function's signature to bool (*)(whatever-type-is-appropriate) and then
replace DBG_CHKOBJ(object, Foo, func) by, e.g.,
OSL_ENSURE(func(object), "blah blah") (most cases I know of are used for
testing function preconditions, so I would actually use OSL_PRECOND
there). I would just remove those that pass 0 as function pointer.

DBG_CTOR is a bit more complicated--it does
1. sanity check if function is passed (just like DBG_CHKTHIS)
   I would use OSL_POSTCOND(func(*this), "blah blah") at the end of the
   constructor.
2. live instance counting
   The same effect can be achieved by deriving from osl::DebugBase
   template class (osl/diagnose.hxx), e.g.,
   class Foo : protected osl::DebugBase<Foo>
   {
   // ...
   };
   But I am not sure this is needed for every single class...
3. tracing (has anyone ever used that?)
   I would just ignore this...

After you have deleted all the DBG_ stuff from a class, you should
remove any DBG_NAME, DBG_NAMEEX and DBG_NAMEEX_VISIBILITY statements
related to it.

DBG_UNHANDLED_EXCEPTION is defined in tools/diagnose_ex.h, not the
(evil) tools/debug.hxx, so it's just fine to leave it as is.

D.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.