<div dir="ltr">Oh, I just saw this email. <div><br></div><div>I recently posted a gerrit change for review around FontCharMap, you can find it here:</div><div><br></div><div><a href="https://gerrit.libreoffice.org/#/c/11565/">https://gerrit.libreoffice.org/#/c/11565/</a><br></div><div><br></div><div>I've never looked at what Reference actually does, but now that I do it seems that it relies on a class that exposes an acquire() and release() function - and a set function that I *think* is the equivalent of swap(). Seems very similar to what intrusive_ptr does. </div><div><br></div><div>Am I correct in my understanding?</div><div><br></div><div>Out of interest, what do smart pointers do, if anything, to polymorphism? If I have an intrusive_ptr to vcl::Window, then can I cast this to SystemWindow?</div><div><br></div><div>Chris</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 24, 2014 at 2:19 AM, Michael Meeks <span dir="ltr"><<a href="mailto:michael.meeks@collabora.com" target="_blank">michael.meeks@collabora.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Noel,<br>
<span class=""><br>
On Tue, 2014-09-23 at 14:52 +0200, Noel Grandin wrote:<br>
> Otherwise we should just standardise on boost::intrusive_ptr and remove SvRef.<br>
<br>
</span>        Yep - my concern is only that boost::intrusive_ptr< Window > - is some<br>
horribly long horror =) and that having some semi-standard means of<br>
having widget refs that are not so grim might be nicer:<br>
<br>
        WindowRef xRef;<br>
vs.     boost::intrusive_ptr< Window > xRef;<br>
vs.     vcl::ref< Window > xRef;<br>
<br>
        etc. but would love to hear other people's views; in general, I think<br>
fewer tokens for the mind to swallow when reading the bulk of the code<br>
is a good thing.<br>
<span class=""><br>
> This should be fixable if it doesn't already work - myself and sberg<br>
> already did this for rtl::Reference.<br>
<br>
</span>        Nice =)<br>
<span class=""><br>
> Mostly I guess we need to figure out where and when to destroy them -<br>
> is it in the destructor, or in some other method specific to this task?<br>
<br>
</span>        Of course, the ideal is to migrate these stuff incrementally. To do<br>
that, I'd suggest we use the new intrusive_ptr and destroy the Window in<br>
the normal way at the end; but that we slowly migrate all explicit<br>
'delete' calls to be virtual dispose calls, and split out reference<br>
releasing / cyclic references later.<br>
<br>
        My hope is that all these non-heap Window's are leafs in the hierarchy<br>
anyhow and/or that we can clean them up without worrying about a proper<br>
'dispose' mechanism just now.<br>
<br>
        Does that make sense ?<br>
<br>
        ATB,<br>
<div class="HOEnZb"><div class="h5"><br>
                Michael.<br>
<br>
--<br>
 <a href="mailto:michael.meeks@collabora.com">michael.meeks@collabora.com</a>  <><, Pseudo Engineer, itinerant idiot<br>
<br>
</div></div></blockquote></div><br></div>