I have been looking at the shared_ptr class, and I have made a change to include an assignment from a standard pointer. I have done this so that I don't have to create a new shared_ptr just to reassign an existing shared_ptr. // Assignment to a 'normal' pointer. shared_ptr & operator=(T * r) { this_type(r).swap(*this); return *this; } I have a few questions. 1) Is this necessary? 2) Does this do the job? 3) Is there any reason this wasn't included in the first place? I welcome any comments. Regards, IanM
I have been looking at the shared_ptr class, and I have made a change to include an assignment from a standard pointer. I have done this so that I don't have to create a new shared_ptr just to reassign an existing shared_ptr.
1) Is this necessary?
Necessary if you don't want to manually create a temp. ;)
2) Does this do the job?
Sure seems to.
3) Is there any reason this wasn't included in the first place?
Although I don't tend to do this, you could run into troubles if you allocate some memory, have a "bare" pointer to it, and then assign it to a parameter that is a shared pointer. If you were planning on managing the memory yourself in this case, you'd have trouble when the shared pointer went out of scope. This change wouldn't have a negative impact on *me*, but I'm certainly a babe in the Boost world myself having only sufficiently figured out the smart pointers myself. :) However, this is probably the kind of thing the authors were trying to protect against happening accidentally... -tom! -- Tom Plunket Sony Computer Entertainment America tplunket@scea.com Bend, Oregon, USA 3D Studio geek PlayStation junkie
On Monday, August 19, 2002, at 02:48 PM, Ian Mold wrote:
I have been looking at the shared_ptr class, and I have made a change to include an assignment from a standard pointer. I have done this so that I don't have to create a new shared_ptr just to reassign an existing shared_ptr.
You can use the reset() member function to do this. You don't need to change the class. Using a named member function (reset) is less error prone because the transfer of ownership is clearer; that's why we don't provide an operator= that "adopts" the passed pointer. -- Darin
participants (3)
-
Darin Adler -
Ian Mold -
Tom Plunket