Какого черта ? (настоящий вопрос выделен жирным шрифтом после цитаты)
§ 20.7.2.2.1
template<class Y> explicit shared_ptr(const weak_ptr<Y>& r);
23 Требуется:Y*
должно быть конвертировано вT*
. 24 Эффекты: Создает объект shared_ptr, который разделяет владение с r и сохраняет копию указателя, хранящегося в r.
25 Постусловия:use_count() == r.use_count()
.
26 Выдает:bad_weak_ptr
когдаr.expired()
.
27 Безопасность исключений. Если возникает исключение, конструктор не действует.
Это не поведение повышения. Общий ресурс, созданный из слабого объекта с истекшим сроком действия, дает пустой общий ресурс. И вы можете проверить это в логических контекстах.
Почему комитет пошел по пути исключений? Например, рекомендации Google C++ полностью исключают использование исключений. Как будут работать проекты с такими рекомендациями или даже исключениями, отключенными во время сборки (в компиляторах, которые разрешают отключение)?
Наконец, не может ли он быть опасно медленным (для программ реального времени), если это, возможно, происходит часто (разработчик полагается на обнаружение указателей с истекшим сроком действия как на нормальный поток программы)? Я помню статью, в которой упоминались две возможные стратегии реализации исключений: одна замедляла все, но не когда происходили исключения, другая замедляла только тогда, когда происходили исключения, но не мешала остальным. Я предполагаю, что в какой-то степени это все еще верно.
shared_ptr
из.lock()
(который я, вероятно, всегда использовал); и созданиеshared_ptr
изweak_ptr
. Потом я подумал, что стандарт изменил мой маленький комфорт и испугался, когда на самом деле ничего не изменилось. ответ принят. 06.12.2013