Есть ли ошибка в GCC 4.7.2 реализации shared_ptr (templated) оператора присваивания?

Мой вопрос касается реализации шаблона оператора назначения shared_ptr в GCC 4.7.2, который, как я подозреваю, содержит ошибку.

ПОМЕЩЕНИЕ 1: С++ 11 СТАНДАРТ

Вот подпись шаблона оператора присваивания, о котором я говорю:

template<class Y> shared_ptr& operator=(const shared_ptr<Y>& r) noexcept;

Из стандарта С++ 11 (20.7.2.2.3):

"Эквивалентно shared_ptr(r).swap(*this)."

Другими словами, шаблон оператора присваивания определяется в терминах шаблона конструктора. Подпись шаблона конструктора выглядит следующим образом:

template<class Y> shared_ptr(const shared_ptr<Y>& r) noexcept;

Из стандарта С++ 11 (20.7.2.2.1):

"Требуется: конструктор [...] не должен участвовать в разрешении перегрузки, если Y * неявно конвертируется в T *."

ПОМЕЩЕНИЕ 2: GCC 4.7.2 ОСУЩЕСТВЛЕНИЕ:

Теперь реализация шаблона конструктора GCC 4.7.2 кажется мне верной (std::__shared_ptr - базовый класс std::shared_ptr):

template<typename _Tp1, typename = 
typename std::enable_if<std::is_convertible<_Tp1*, _Tp*>::value>::type>
__shared_ptr(__shared_ptr<_Tp1, _Lp>&& __r) noexcept
    : 
    _M_ptr(__r._M_ptr), 
    _M_refcount()
{
    _M_refcount._M_swap(__r._M_refcount);
    __r._M_ptr = 0;
}

Однако реализация GCC 4.7.2 шаблона оператора присваивания такова:

template<typename _Tp1>
__shared_ptr& operator=(const __shared_ptr<_Tp1, _Lp>& __r) noexcept
{
    _M_ptr = __r._M_ptr;
    _M_refcount = __r._M_refcount; // __shared_count::op= doesn't throw
    return *this;
}

Что меня поражает, так это то, что эта операция не определена в терминах шаблона конструктора или swap(). В частности, простое присваивание _M_ptr = __r._M_ptr не дает такого же результата, как если типы _Tp1* и _Tp* явно проверяются на конвертируемость через std::is_convertible (который может быть специализированным).

ПОМЕЩЕНИЕ 3: РЕАЛИЗАЦИЯ VC10

Я заметил, что VC10 имеет более подходящую реализацию в этом отношении, которую я считаю правильным и ведет себя так, как я ожидал в своих тестовых случаях (в то время как GCC не делает):

template<class _Ty2>
_Myt& operator=(const shared_ptr<_Ty2>& _Right)
{
    // assign shared ownership of resource owned by _Right
    shared_ptr(_Right).swap(*this);
    return (*this);
}

ВОПРОС:

Есть ли ошибка в реализации GCC 4.7.2 shared_ptr? Я не мог найти отчет об ошибке для этой проблемы.

POST SCRIPTUM:

Если вы хотите спросить меня, что такое мои тестовые примеры, почему я забочусь об этой, казалось бы, несущественной детали, и почему я, кажется, подразумеваю, что мне нужно специализироваться на std::is_convertible, пожалуйста, сделайте это в чате. Это долгая история, и нет способа суммировать ее, не будучи неправильно понятой (со всеми ее неприятными последствиями). Заранее благодарю вас.

Ответ 1

Что меня поражает, так это то, что эта операция не определена в терминах шаблона конструктора или swap().

Это не обязательно, он должен вести себя так, как если бы он был определен в этих терминах.

В частности, простое присваивание _M_ptr = __r._M_ptr не дает того же результата, что и в случае, когда типы _Tp1* и _Tp* явно проверяются на конвертируемость через std::is_convertible (который может быть специализированным).

Я не согласен: [meta.type.synop]/1 Поведение программы, которая добавляет специализации для любого из шаблонов классов, определенных в этом подпункте, это undefined, если не указано иное.

Таким образом, вы не можете изменить значение is_convertible<Y*, T*>, и если Y* можно конвертировать в T*, тогда назначение будет работать, и поскольку оба назначения (указателя и объекта refcount) равны noexcept, конец результат эквивалентен свопу. Если указатели не конвертируемы, то присваивание не будет скомпилировано, но это будет shared_ptr(r).swap(*this), поэтому оно все равно эквивалентно.

Если я ошибаюсь, напишите отчет об ошибке, и я исправлю его, но я не думаю, что соответствующая программа может обнаружить разницу между реализацией libstdС++ и требованиями стандарта. Тем не менее, у меня не было бы никаких возражений по поводу его изменения в рамках swap. Текущая реализация возникла прямо из shared_ptr в Boost 1.32, я не знаю, будет ли Boost по-прежнему делать то же самое или использовать shared_ptr(r).swap(*this) сейчас.

[Полное раскрытие, я являюсь сторонником libstdС++ и в основном отвечаю за код shared_ptr, который изначально был пожертвован авторами boost::shared_ptr, а затем был изменен мной с тех пор.]

Ответ 2

Реализация в GCC соответствует требованиям стандарта. Когда стандарт определяет, что поведение одной функции эквивалентно другому набору функций, это означает, что эффект первого эквивалентен эффекту последних функций, определенных в стандарте (а не как реализованному).

Стандарт не требует использования std::is_convertible для этого конструктора. Для конструктора требуется SFINAE, но для оператора присваивания не требуется SFINAE. Требование о том, чтобы типы конвертируемых были помещены в программу, а не на реализацию std::shared_ptr, и это ваша ответственность. Если типы, переданные внутри, не являются конвертируемыми, то это ошибка в вашей программе. Если они тогда, реализация должна принять код, даже если вы хотите отключить использование, специализируясь на шаблоне is_convertible.

Опять же, специализация is_convertible для ограничения преобразований указателей - это поведение undefined, поскольку вы изменяете семантику базового шаблона, который явно запрещен в стандарте.

Это приводит к исходному вопросу, на который вы не хотите отвечать: какой прецедент заставил вас задуматься над этим решением. Или сказал иначе: почему люди продолжают спрашивать о решениях, а не о реальных проблемах, которые они хотят решить?