On 31 August 2016 at 11:16, Jim Apple <[email protected]> wrote: > Why should we reduce our boost dependency? >
Boost will sometimes break subtly (or unsubtly by changing APIs) between versions, is often not as well tested as stdlib implementations and does not have a standard. If there are reasonable std:: implementations of boost:: primitives, experience has shown it's usually a good idea to opt for the std > > Do you think there are places where scoped_ptr is used now where you > would want to keep it indefinitely if it were part of the standard and > not part of boost? > No, but I can't say I've audited every location. For our typical uses, I don't see a disadvantage to unique_ptr. > > On Wed, Aug 31, 2016 at 10:47 AM, Henry Robinson <[email protected]> wrote: > > We use boost::scoped_ptr everywhere to handle scope-owned heap-allocated > > objects. C++11 has std::unique_ptr for this. I'd like to get a decision > on > > whether we should start standardising on unique_ptr. This is particularly > > relevant for new code - should I call it out in code review? > > > > The most significant difference is that unique_ptr is moveable, which > means > > it can be used in collections (good!). It also means that badly written > > code can allow scope-owned objects to escape their scope: > > > > private: > > unique_ptr<Foo> foo_; > > > > public: > > unique_ptr<Foo> get_foo() { return move(foo_); } > > > > or worse: > > > > Foo* get_foo() { return foo_.release(); } > > > > In both cases you have to be quite explicit about the decision to yield > > ownership of the owned object, and it seems to me that we should catch > this > > in code review. > > > > Since using unique_ptr in collections is so useful, and reducing our > boost > > dependency is generally worthwhile, I'm very much in favour of moving to > > unique_ptr for future code, and at some point porting all the current > > scoped_ptr to unique_ptr. > > > > What do you think? > > > > Henry > -- Henry Robinson Software Engineer Cloudera 415-994-6679
