C++11 standard decision "shared_ptr(const weak_ptr<Y>& r) Throws bad_weak_ptr"

Question

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.

Answer 1

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