<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED --- - replace tools/solar.h macros with osl versions"
href="https://bugs.freedesktop.org/show_bug.cgi?id=63154#c32">Comment # 32</a>
on <a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED --- - replace tools/solar.h macros with osl versions"
href="https://bugs.freedesktop.org/show_bug.cgi?id=63154">bug 63154</a>
from <span class="vcard"><a class="email" href="mailto:michael.meeks@collabora.com" title="Michael Meeks <michael.meeks@collabora.com>"> <span class="fn">Michael Meeks</span></a>
</span></b>
<pre>There are 600 or so hits of DELETEZ, in each case we'd need to work out whether
the memory could be re-used inadvertently and I guess add a manual NULL as/when
we think it could be; that my be somewhat hard to verify of course.
I'm not against that, clearly any usage of DELETEZ of a member in a destructor
is bogus eg.
accessibility/source/extended/accessibletabbarbase.cxx-
AccessibleTabBarBase::~AccessibleTabBarBase()
{
ClearTabBarPointer();
DELETEZ( m_pExternalLock );
}
or
cui/source/tabpages/macroass.cxx
_SfxMacroTabPage::~_SfxMacroTabPage()
{
DELETEZ( mpImpl );
}
And those can be removed safely. I guess we should consult some C++ guru - who
(no doubt) would recommend one of the bewildering array of templatized smart
pointers of varying efficiency that can magically do something similar :-)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>