Re: [boost] Borland C++ 5.5.1 problem with the new shared_ptr tests

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-11-19 13:41:24

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Tuesday, November 19, 2002 3:04 PM
Subject: Re: [boost] Borland C++ 5.5.1 problem with the new shared_ptr tests

> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
> > > Borland C++ 5.5.1 fails the following test:
> > >
> > > struct X
> > > {
> > >     X(): next() {}
> > >     boost::shared_ptr<X> next;
> > > };
> > >
> > > void test()
> > > {
> > >     boost::shared_ptr<X> p(new X);
> > >     p->next = boost::shared_ptr<X>(new X);
> > >     BOOST_TEST(!p->next->next);
> > >     p = p->next;
> > >     BOOST_TEST(!p->next); // here
> > > }
> > >
> > The problem is here;
> >
> >    p = p->next;
> >
> > This assignment is slicing. It is directly calling
> >
> >     shared_count & operator= (shared_count const & r) // nothrow
> >
> > on the lvalue (p). The pointee (p.px)  is destroyed during
> "pi_->release();"
> > but is not re-assigned.
> >
> > If the intention was that the assignment use:
> >
> >     template<typename Y>
> >     shared_ptr & operator=(shared_ptr<Y> const & r) // never throws
> >
> > then Borland doesn't use it.
>
> No. The intent is to use the automatically generated copy assignment
> operator. By default, it should do memberwise assignment, and the end
result
> should be exactly
>
> >     shared_ptr & operator=(shared_ptr const & r) // never throws
> >     {
> >         px = r.px;
> >         pn = r.pn; // shared_count::op= doesn't throw
> >         return *this;
> >     }
>
> that.
>

I see.
So bcc5.5.1 fails to generate (or use in this context?) the default
assignment op...
How do you plan to fix this...
defining it just for bcc,
or for all compilers? that is, can be any problem in defining operator=
always?

Fernando Cacciola