<div dir="ltr">Hey,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 23, 2014 at 1:24 PM, Eike Rathke <span dir="ltr"><<a href="mailto:erack@redhat.com" target="_blank">erack@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Markus,<br>
<div class=""><br>
On Friday, 2014-05-23 03:14:30 +0200, Markus Mohrhard wrote:<br>
<br>
> so by going through Lsan reports I noted that we have a few classes in<br>
> formula that are marked with SAL_NO_VTABLE and therefore have no virtual<br>
> protected destructors, This prevents us from deleting some of these<br>
> instances and it looks like people just leaked them in the past.<br>
<br>
</div>What actually leaks, given that these classes have no member variables<br>
and only define interfaces as pure abstract base classes one derives<br>
from?<br></blockquote><div><br></div><div>There is code in formula which generates objects from sc but can of course only use the abstract interfaces. Instead of deleting the objects we just leak them after use because the d'tor is protected.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
> Is there any reason not to remove the SAL_NO_VTABLE and make the destructor<br>
> virtual and public. I"m talking especially about<br>
> include/formula/IFunctionDescription.hxx where the use of SAL_NO_VTABLE<br>
> looks like premature optimization to me.<br>
<br>
</div>This appears to me as exactly what the comment on SAL_NO_VTABLE in<br>
include/sal/types.h talks about.<br></blockquote><div><br></div><div>The main question is if it really makes a difference. I understand that it makes a difference for objects where we create thousands or more but these classes seem to generate just a few objects.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But no, if we really leak because of SAL_NO_VTABLE (this is on Windows,<br>
isn't it? because it's defined empty for other platforms) then I don't<br>
object to remove it, but then we should also remove the SAL_NO_VTABLE<br>
define.<br>
<br>
However, is it a prerequisite to have a non-virtual dtor when using<br>
SAL_NO_VTABLE? Or wouldn't adding a virtual to the dtor already solve<br>
the problem and not make Lsan stumble about?<br></blockquote><div><br></div><div>How can you use a virtual destructor when you don't have a v-table? As far as my understanding goes the destructors are protected and non-virtual because you can't have a virtual destructor and should not be able to delete the objects through the base class. So the question from my point of view is more if it there is really a good reason to save these few bytes per object? Personally I would not worry about the space a v-table allocates until I'm really desperate and don't have any other place to optimize.<br>
<br></div><div>Regards,<br>Markus<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
  Eike<br>
<br>
--<br>
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.<br>
GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A<br>
Support the FSFE, care about Free Software! <a href="https://fsfe.org/support/?erack" target="_blank">https://fsfe.org/support/?erack</a><br>
</font></span></blockquote></div><br></div></div>