Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


On 2014-09-23 02:40 PM, 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.

SvRef (include/tools/ref.hxx) is the rough equivalent of boost::intrusive_ptr, so that would be my 
suggestion.
It use no atomics and has only one extra virtual call(other than the actual destructor) but removing that is straightforward, I just haven't got around to it.
Otherwise we should just standardise on boost::intrusive_ptr and remove SvRef.

I'd also love to avoid 'orrible casts everywhere when converting to references to parent types [ perhaps I just do this wrong myself ;-]

This should be fixable if it doesn't already work - myself and sberg already did this for 
rtl::Reference.

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 ? Michael.

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?




Disclaimer: http://www.peralex.com/disclaimer.html



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.