Re: stack-allocated Window subclasses

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@collabora.com