Opened 11 years ago

Closed 11 years ago

#712 closed request (wontfix)

deprecate SmartPtr

Reported by: Peter Owned by: Peter
Priority: minor Milestone:
Component: utility Version: trunk
Keywords: Cc:

Description

SmartPtr? was introduced when yat didn't use boost. It is most likely better to use shared_ptr in boost, and we should at least point users to that class.

Change History (5)

comment:1 Changed 11 years ago by Peter

(In [2779]) record r2778 in NEWS, refs #712

comment:2 Changed 11 years ago by Peter

(In [2861]) avoid using SmartPtr?; prefer using boost::shared_ptr. refs #712

comment:3 Changed 11 years ago by Peter

(In [2862]) prefer boost::shared_ptr. refs #712

comment:4 Changed 11 years ago by Peter

(In [2863]) prefer boost::shared_ptr. refs #712

comment:5 Changed 11 years ago by Peter

Milestone: yat 0.10
Resolution: wontfix
Status: newclosed

SmartPtr is now only used in one place: in class utility::Index, which holds a SmartPtr as private member. In contrast to the other places however (see r2861 r2862 r2863) it is not obvious how to best replace SmartPtr here. The problem is that SmartPtr is exposed to the API via a constructor

Index(const SmartPtr<...);

Unless we want to break the API, we need to keep this constructor. Doing that while changing the member to a boost::shraed_ptr is not straightforward. It is trivial to create a boost shared_ptr from a SmartPtr but it is probably not a good idea because who should own the pointee. We could let the SmartPtr own the pointee but that means that shraed_ptr and thereby the Index is undefined in case the SmartPtr? goes out of scope. The other idea is to transfer ownership from SmartPtr to shared_ptr but that means the SmartPtr is undefined in case the shared_ptr goes out of scope. That leaves the middle alternative, which is to create a shared_ptr that points to a new copy of SmartPtr's pointee. That solves the problem above but it changes the behaviour in the sense that if someone is modifying the orginal pointee (in SmartPtr) after teh shared_ptr is created, the pointee in shared_ptr will not be effected. Therefore, I think we should keep the Index as is, which implies we also keep the SmartPtr as is without deprecation.

Note: See TracTickets for help on using tickets.