stack-allocated Window subclasses

Lubos Lunak l.lunak at
Wed Sep 24 08:00:39 PDT 2014

On Tuesday 23 of September 2014, Michael Meeks wrote:
> 	The question is; what should we replace it with. Personally I'm more of
> a fan of intrusive reference counting for VCL - we don't want lots of
> atomics, so that the optimizer can rid us of size inefficiency - and at
> least for now we can't ref-count those guys anyway I think.
> 	Then again rtl::Reference<Foo> lost its nasty virtual methods recently
> (IIRC), so - perhaps we could use that - but for the fact that it's
> unpleasantly long to type. I'd also love to avoid 'orrible casts
> everywhere when converting to references to parent types [ perhaps I
> just do this wrong myself ;-]
> 	So - possibly having a ButtonRef xFoo; type class that is (underneath)
> an rtl::Reference<Button> - and yet can easily be implicitly co-erced to
> a WindowRef etc. might fly ?
> 	I guess we need to have a plan in-place there before shunting all those
> widgets off onto the heap where we can lifecycle manage them sensibly =)
> 	Thoughts ?

 I must have missed it, where can I read what problems led to requiring a 
solution like this instead of the primitive&working way of having parents 
responsible for cleaning up their children on destruction? Stack-allocated 
objects is probably the most sensible C++ lifecycle management ever, so if it 
doesn't work with vcl, vcl has got to be seriously broken in that regard.

 Lubos Lunak
 l.lunak at

More information about the LibreOffice mailing list