< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] VS2005 crashing with DUM


Nice spot
A

-----Original Message-----
From: "david Butcher" <davidlbutcher@xxxxxxxxx>
Date: Tue, 23 Oct 2007 20:49:41 
To:"Alan Hawrylyshen" <alan@xxxxxxxxxxxx>
Cc:"Nilay Tripathi" <nilay.linux@xxxxxxxxx>,       resiprocate-devel 
<resiprocate-devel@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: [reSIProcate] VS2005 crashing with DUM

auto_ptr is not compatible with virtual destructors. that may be the odd bit.
david

On 10/23/07, Alan Hawrylyshen <alan@xxxxxxxxxxxx> wrote:
>
>
> On 23-Oct-07, at 04:30 , Nilay Tripathi wrote:
> The auto_ptr instance that we create has everything fine, but as soon as we
> assign it to mClientAuthManager, vfptr goes for a toss. Something creepy in
> operator=() of auto_ptr.
>
> Is it safe to assume that the 'creepy' part of auto_ptr is something other
> than the 'assignment transfers ownership' semantics of auto_ptr.
>
> Given a class, A, and a pair of auto_ptr's p1 and p2, the following is
> roughly true:
>  A* p;
>  auto_ptr<A> p1(p = new A);
>  // p1 'points' to the 'new A' (the same place that 'p' points)
>  // of course 'p' is dangerous and merely here for pedagogical purposes.
>  auto_ptr<A> p2(p1);
>
>  // p2 now 'points' at the same place as 'p' and
>  // p1 is pointing at nothing.
>
>  auto_ptr<A> p3 = p2 ; // usually disallowed, but has same effect, only p3
>  // refers to the same A that p does.
>
>  Using auto_ptr<>::release() and auto_ptr<>::get() can put you in trouble
> too...
>
> Or was it something else really 'odd'?
>
>
>
>
> Alan Hawrylyshen
> a l a n a t p o l y p h a s e d o t c a
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>