Re: [reSIProcate] VS2005 crashing with DUM
oops - yes.
david
On 10/24/07, Derek MacDonald <derek@xxxxxxxxxxxxxxx> wrote:
> Pehaps david meant that auto_ptr can cause problems when pointed to a base
> class w/ non-virtual destructors, and left a word out?
>
> PS - adam, you can climb down from the watchtower.
>
>
> On 10/24/07, Adam Roach <adam@xxxxxxxxxxx> wrote:
> >
> > On 10/23/07 11:00 PM, Adam Roach wrote:
> > > david Butcher wrote:
> > >
> > >> auto_ptr is not compatible with virtual destructors. that may be the
> odd bit.
> > >>
> > >>
> > >
> > > What?
> > >
> > >
> >
> > Let me be more explicit.
> >
> > Stroustrup [1] doesn't mention anything about this in his treatment of
> > auto_ptr. In fact, his examples include putting the base class of
> > polymorphic objects into auto_ptrs -- which is going to lead to improper
> > release of resources without virtual destructors.
> >
> > Also, extensive searches on Google failed to turn anything up that might
> > be interpreted as a general prohibition against using auto_ptr with
> > objects that have virtual destructors.
> >
> > In fact, the only thing I turned up has to do with a really obscure bug
> > in Visual C++ 8.0, apparently having to do with errant coercion paths
> > [2]; it sound like it impacts all virtual methods, not just destructors.
> > It should be noted that the code that causes these problems shouldn't
> > compile under real C++ compilers (although I suppose there's a chance
> > that this coercion path is preferred by the compiler over another
> > implicit path that other compilers use for the specific code in question
> > -- meaning it would compile in both environments, but trigger the
> > "virtual methods crash" bug described in the article I cite).
> >
> > Finally, I've demonstrated to myself that things work just fine with
> > auto_ptr and virtual destructors under g++ in the trivial case with a
> > tiny program:
> >
> > #include <iostream>
> > #include <memory>
> >
> > class A
> > {
> > public:
> > A(){}
> > virtual ~A();
> > };
> >
> > A::~A()
> > {
> > std::cout << "A is going away" << std::endl;
> > }
> >
> > class B : public A
> > {
> > public:
> > B(){}
> > virtual ~B();
> > };
> >
> > B::~B()
> > {
> > std::cout << "B is going away" << std::endl;
> > }
> >
> > int main(int argc, char **argv)
> > {
> > std::auto_ptr<A> ptr(new B());
> > ptr.reset ();
> > return 0;
> > }
> >
> >
> > So, david: could you please clarify what you mean? It's not clear to me,
> > and I've had a number of developers send me private mail asking, "is
> > this right?"
> >
> > /a
> >
> > ---
> > [1] Soustrup, Bjarne, "The C++ Programming Language", 3rd Edition,
> > Addison Wesley, 1997
> >
> > [2] Bottom of page:
> > <
> http://www.codeproject.com/Feature/SubtleBugs.asp?select=2053685&df=100&forumid=343280&exp=0&fr=183.5>
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxx
> >
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
>
>