Re: stack-allocated Window subclasses

Oh, I just saw this email.

I recently posted a gerrit change for review around FontCharMap, you can
find it here:

https://gerrit.libreoffice.org/#/c/11565/

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.

Am I correct in my understanding?

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?

Chris

On Wed, Sep 24, 2014 at 2:19 AM, Michael Meeks <michael.meeks@collabora.com>
wrote:

> Hi Noel,
>
> On Tue, 2014-09-23 at 14:52 +0200, Noel Grandin wrote:
> > Otherwise we should just standardise on boost::intrusive_ptr and remove
> SvRef.
>
>         Yep - my concern is only that boost::intrusive_ptr< Window > - is
> some
> horribly long horror =) and that having some semi-standard means of
> having widget refs that are not so grim might be nicer:
>
>         WindowRef xRef;
> vs.     boost::intrusive_ptr< Window > xRef;
> vs.     vcl::ref< Window > xRef;
>
>         etc. but would love to hear other people's views; in general, I
> think
> fewer tokens for the mind to swallow when reading the bulk of the code
> is a good thing.
>
> > This should be fixable if it doesn't already work - myself and sberg
> > already did this for rtl::Reference.
>
>         Nice =)
>
> > Mostly I guess we need to figure out where and when to destroy them -
> > is it in the destructor, or in some other method specific to this task?
>
>         Of course, the ideal is to migrate these stuff incrementally. To do
> that, I'd suggest we use the new intrusive_ptr and destroy the Window in
> the normal way at the end; but that we slowly migrate all explicit
> 'delete' calls to be virtual dispose calls, and split out reference
> releasing / cyclic references later.
>
>         My hope is that all these non-heap Window's are leafs in the
> hierarchy
> anyhow and/or that we can clean them up without worrying about a proper
> 'dispose' mechanism just now.
>
>         Does that make sense ?
>
>         ATB,
>
>                 Michael.
>
> --
>  michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot