В чем смысл owner_less, если истекший weak_ptr даст поведение undefined?

Ответ 1

Один пункт разъяснения. Истекшие слабые_ptr не являются UB при использовании owner_less. Из стандартного

в соответствии с отношением эквивалентности, определяемым оператором(),! operator() (a, б) & &! operator() (b, a), два экземпляра shared_ptr или weak_ptr эквивалент тогда и только тогда, когда они разделяют право собственности или оба являются пустыми.

Одна вещь, которую следует помнить, состоит в том, что пустой weak_ptr - это тот, которому никогда не назначался допустимый shared_ptr, или тот, которому был назначен пустой shared_ptr/weak_ptr. Истекший weak_ptr не является пустым слабой_ptr.

Изменить:

Определение, приведенное выше, зависит от того, что означает "пустой" слабый_ptr. Итак, давайте посмотрим на стандартный

• constexpr weak_ptr() noexcept;

  Эффекты: Создает пустой объект weak_ptr.
   Постусловия: use_count() == 0.

• weak_ptr (const weak_ptr & r) noexcept;
• template weak_ptr (const weak_ptr & r) noexcept;

• template weak_ptr (const shared_ptr & r) noexcept;

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

  Эффекты: если r пуст, создается пустой объект weak_ptr; в противном случае создается объект weak_ptr, который разделяет владение с помощью r и сохраняет копию указателя, хранящегося в r.

  Постусловия: use_count() == r.use_count().

Обмен просто обменивает содержимое, а назначение определяется как указанные выше конструкторы плюс своп.

Чтобы создать пустой weak_ptr, вы используете конструктор по умолчанию или передаете ему empty_ptr или shared_ptr, который пуст. Теперь вы заметите, что срок действия не означает, что weak_ptr станет пустым. Он просто заставляет его иметь use_count() от нуля и expired(), чтобы вернуть true. Это связано с тем, что базовый счетчик ссылок не может быть освобожден до тех пор, пока не будут освобождены все слабые указатели, разделяющие объект.

Ответ 2

Вот минимальный пример, демонстрирующий ту же проблему:

struct Character
{
    char ch;
};

bool globalCaseSensitive = true;

bool operator< (const Character& l, const Character& r)
{
    if (globalCaseSensitive)
        return l.ch < r.ch;
    else
        return std::tolower(l.ch) < std::tolower(r.ch);
}

int main()
{
    std::set<Character> set = { {'a'}, {'B'} };

    globalCaseSensitive = false; // change set ordering => undefined behaviour
}

map и set требуют, чтобы их ключевой компаратор реализовал строгую слабое упорядочивающее отношение по типу ключа. Это означает, что, помимо прочего, если x меньше y, то x всегда меньше y. Если программа не гарантирует этого, программа демонстрирует поведение undefined.

Мы можем исправить этот пример, предоставив пользовательский компаратор, который игнорирует переключатель чувствительности к регистру:

struct Compare
{
    bool operator() (const Character& l, const Character& r)
    {
        return l.ch < r.ch;
    }
};

int main()
{
    std::set<Character, Compare> set = { {'a'}, {'B'} };

    globalCaseSensitive = false; // set ordering is unaffected => safe
}

Если a weak_ptr истекает, то weak_ptr впоследствии будет по-другому сравнивать с другими из-за того, что он является нулевым и больше не может гарантировать строгое отношение слабого порядка. В этом случае исправление остается неизменным: используйте пользовательский компаратор, который невосприимчив к изменениям в общем состоянии; owner_less является одним из таких компараторов.

Как undefined это поведение?

Undefined - undefined. Нет континуума.

Если одна реализация [...], когда поведение становится undefined?

Как только содержащиеся элементы перестанут иметь четкое строгую слабое упорядочивающее соотношение.

Если одна реализация [...] является поведением еще undefined? Другими словами, find начнет возвращать неправильный ключ?

Undefined поведение не ограничивается просто возвратом неправильного ключа. Он может сделать что угодно.

Это похоже на [...], нет проблем, потому что значения ссылаются на ключ не по порядку.

Без упорядочения ключи не имеют встроенной способности ссылаться на значения.

Ответ 3

std::sort требует упорядочения. owner_less на нем может быть полезно.

В map или set меньше - положив a weak_ptr в качестве ключа к тому, чтобы ухаживать за undefined. Так как вам все равно придется синхронизировать время жизни контейнера и указателя вручную, вы можете также использовать необработанный указатель (или ручной, не владеющий интеллектуальным указателем, который каким-то образом справляется с проблемой истечения срока действия), чтобы сделать это более понятным.