Hi,
On Tue, Mar 07, 2017 at 04:05:40PM +0100, Stephan Bergmann wrote:
> So if you want to make such instrumentation of VclPtr ctor, it's not much
> hassle to add that instrumentation also to the from-raw-ptr
> VclPtr::operator=?
__LINE__ and __FILE__ only work at the position of the assignment,
On 03/07/2017 03:07 PM, Bjoern Michaelsen wrote:
On Tue, Mar 07, 2017 at 02:58:31PM +0200, Noel Grandin wrote:
I can't see how that would flush out any bugs.
E.g. In a local debug build I added metadata on where a VclPtr was created (via
__FILE__, __LINE__) so that I could learn where they
Hi,
On Tue, Mar 07, 2017 at 02:58:31PM +0200, Noel Grandin wrote:
> I can't see how that would flush out any bugs.
E.g. In a local debug build I added metadata on where a VclPtr was created (via
__FILE__, __LINE__) so that I could learn where they were leaked from without
hunting them down
Hi Bjoern,
On 07/03/17 11:58, Bjoern Michaelsen wrote:
> so while poking around for tdf#99352, I created a local branch where most
> contructions of VclPtr<> from a raw pointer have been replaced with an
> explicit
> construction of a VclPtr<>. I havent used anything fancy (clang rewriter),
>
On 2017/03/07 1:58 PM, Bjoern Michaelsen wrote:
FWIW: the changes are along the lines of:
-mpPage = pPage;
+mpPage = VclPtr(pPage);
with mpPage being a VclPtr<> and pPage being a raw pointer.
I can't see how that would flush out any bugs. How could it go wrong? Whether it is null
/README.lifecycle, "what
remains to be done" part)
=> +1 for me as QA + dev but not expert (at all!)
Julien
--
View this message in context:
http://nabble.documentfoundation.org/tdf-99352-explicit-ctoring-of-VclPtrs-tp4209616p4209623.html
Sent from the Dev mailing list archive
Hi all,
so while poking around for tdf#99352, I created a local branch where most
contructions of VclPtr<> from a raw pointer have been replaced with an explicit
construction of a VclPtr<>. I havent used anything fancy (clang rewriter), just
some vim macros. I didnt catch all, but the majority of
