0

What the heck ? (real question in bold after thereafter quotation)

§ 20.7.2.2.1

template<class Y> explicit shared_ptr(const weak_ptr<Y>& r);
23 Requires: Y* shall be convertible to T*. 24 Effects: Constructs a shared_ptr object that shares ownership with r and stores a copy of the pointer stored in r.
25 Postconditions: use_count() == r.use_count().
26 Throws: bad_weak_ptr when r.expired().
 27 Exception safety: If an exception is thrown, the constructor has no effect.

This is not the boost behavior. A shared constructed from an expired weak gives an empty shared. And you can test it in boolean contexts.

Why did the comitee chose the way of exceptions ? For example google C++ guidelines banish exception usage altogether. How are projects with such guidelines, or even exceptions disabled at build time (on compilers that authorize disabling) will do ?

Lastly, cannot it be dangerously slow (for real time programs) if this is possibly happenning often (developer is relying in expired pointers detection as normal program flow) ? I remember an article mentionning two possible strategies to implement exceptions, and one was slowing everything down but not really when exceptions happend, the other was slow only when exceptions happened but did not impair the rest. I suppose this must still hold true to some extent.

Praetorian
  • 106,671
  • 19
  • 240
  • 328
v.oddou
  • 6,476
  • 3
  • 32
  • 63
  • 4
    If you don't want to use exceptions, ever, there's very little in the Standard Library available to you. You'll need to find another library. Luckily C++ is a great library development platform and I'm sure there are some. – Ben Voigt Dec 06 '13 at 01:57
  • 4
    `boost::shared_ptr` also throws an exception when constructing from an expired `weak_ptr`, just as `std::shared_ptr` does: http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/shared_ptr.htm#weak_ptr_constructor (`expired()` is equivalent to `use_count() == 0`). – Josh Townzen Dec 06 '13 at 02:02
  • @JoshTownzen: wasn't `use_count` a kind of boogie function we were not supposed to use ? I see it has made its way into officiality in the standard though. Anyway the invariant is understandable. Just one thing remains, is that use_count may be outdated (not thread safe). – v.oddou Dec 06 '13 at 02:11

1 Answers1

8

I'm ignoring the whole exceptions, purrformance & Google guidelines rant because that is just silly unless you have a use case where you can prove this is hurting you.

If you don't want to deal with exceptions, construct it as 

shared_ptr<T> p{r.lock()};

That will create an empty shared_ptr if r.expired() == true

Praetorian
  • 106,671
  • 19
  • 240
  • 328
  • On my, is that so ? Then I guess I totally confused getting a `shared_ptr` from `.lock()` method (which is the way I probably always used); and constructing the `shared_ptr` from the `weak_ptr`. Then I thought the standard changed my little comfort and got afraid, when it actually changed nothing. answer accepted. – v.oddou Dec 06 '13 at 02:13