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.lu...@collabora.com _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
