Обеспечение строгой гарантии безопасности

#cpp #исключения #cpp14

Прохожу курс по C++ и пытаюсь ответить на такой вопрос:

Если у класса, объекты которого хранятся в стеке, есть небросающие перемещающие методы,
то можно реализовать такой возвращающий pop со строгой гарантией безопасности исключений
(отметьте все верные утверждения)


Обеспечить строгую гарантию безопасности для метода pop, который
возвращает выталкиваемый элемент, не получается из-за возможного
исключения при копировании возвращаемого объекта.
Если у класса, объекты которого хранятся в стеке, есть перемещающий
конструктор, то исходная реализация (см. степ 10) обеспечивает
строгую гарантию безопасности исключений.
Если у класса, объекты которого хранятся в стеке, есть небросающий
перемещающий конструктор, то исходная реализация (см. степ 10)
обеспечивает строгую гарантию безопасности исключений.
Если у класса, объекты которого хранятся в стеке, есть небросающий
перемещающий конструктор, то исходная реализация (см. степ 10) не
обеспечивает строгую гарантию безопасности исключений, но этого можно
добиться добавив std::move в строке с return.
Проблема обеспечения строгой гарантии безопасности возвращающего
метода pop возникает только для стеков, которые реализованы на
массиве.
Проблема обеспечения строгой гарантии безопасности возвращающего
метода pop актуальна для произвольных контейнеров.


Исходная реализация вот такая:

template  struct Stack 
{
    void Push(const T& t)
    {
        data_.push_back(t)
    }

    T pop()
    {
        T tmp = data_.back();
        data_.pop_back();
        return tmp;
    }

    std::vector data_; 
};


Как мне кажется, если в return добавить std::move, то мы явно вызовем перемещающий
метод и все будет хорошо. Ну и проблема обеспечения СГБ вполне актуальна не только
для стеков на массиве, не вижу тут совсем никакой связи с массивом, т.к. проблема в
гарантии возникает из за возможной ошибки при копировании, потому что объект возвращается
по значению. Поэтому отвечаю 1, 4 и 6, но это неверно. Подскажите пожалуйста где ошибка
в моем мышлении?

UPD

Правильно: 1, 3, 6. Объяснение см. в комментариях к правильному ответу на вопрос
ну и сам правильный ответ :)
    

Ответы

Ответ 1

Как мне кажется, если в return добавить std::move, то мы явно вызовем перемещающий
метод и все будет хорошо.


Так как после изменения контейнера у нас идет только return, то необходимо, чтобы
этот участок был безопасен относительно исключений, всё что было до изменения контейнера
нам не важно. Также примем за правду тот факт, что деструктор T не выбрасывает исключений,
в ином случае обеспечить строгую гарантию нельзя. Поэтому для начала разберемся с копированием
возвращаемого значения. Компилятор постарается применить оптимизации RVO/NRVO, чтобы
избежать как копирования, так и перемещения возвращаемого значения. В случае, если
такая оптимизация не удастся, то в return по-возможности будет перемещение tmp, а не
его копирование, согласно стандарту:


  When the criteria for elision of a copy/move operation are met, but not for an
exception-declaration , and the object to be copied is designated by an lvalue, or
when the expression in a return statement is a (possibly parenthesized) id-expression
that names an object with automatic storage duration declared in the body or parameter-declaration-clause
of the innermost enclosing function or lambda-expression, overload resolution to select
the constructor for the copy is first performed as if the object were designated by
an rvalue. If the first overload resolution fails or was not performed, or if the type
of the first parameter of the selected constructor is not an rvalue reference to the
object’s type (possibly cv-qualified), overload resolution is performed again, considering
the object as an lvalue.


.


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


Объект по-возможности будет перемещен, так что этот пункт отпадает, ведь у нас явно
задано в условии, что объект может перемещаться не выбрасывая исключений. Если же объект
может выбросить исключение при перемещении, или если перемещение невозможно и при копировании
может вылететь исключение, то строгую безопасность такой pop не обеспечивает.


  Если у класса, объекты которого хранятся в стеке, есть перемещающий конструктор,
то исходная реализация (см. степ 10) обеспечивает строгую гарантию безопасности исключений.


Нет, ведь перемещающий конструктор может бросить исключение, а объект из стека уже
удален.


  Если у класса, объекты которого хранятся в стеке, есть небросающий перемещающий
конструктор, то исходная реализация (см. степ 10) обеспечивает строгую гарантию безопасности
исключений.


Это верно.


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


Нет, исходная реализация уже обеспечивает такую гарантию. Как сказано выше, сначала
компилятор захочет вообще убрать, и копирование, и перемещение. Если не удастся, то
tmp будет рассматриваться как rvalue. А вот если применить std::move, то это может
поломать компилятору возможность сделать RVO/NRVO, т.е. лучше оно не сделает, но может
сделать хуже в плане оптимизаций.


  Проблема обеспечения строгой гарантии безопасности возвращающего метода pop возникает
только для стеков, которые реализованы на массиве.


Имеется ввиду просто массив вида T[N] или любой контейнер, представляющий структуру
данных массив?
В первом случае удаление из массива одного элемента невозможно, разве что вручную
управлять временем жизни объектов, но тогда массив должен быть не T[N], а, например,
char[N * sizeof(T)] с соответствующим выравниванием. При таком подходе вся безопасность
ложиться на обертку, которая управляет этим массивом.
Во втором же, всё должно быть в порядке, если сам pop_back не бросает исключений.
Поэтому в общем случае, с массивом будет всё нормально.


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


Разве что произвольный контейнер сам по себе не обеспечивает эту безопасность при
удалении последнего элемента, поэтому всё будет зависеть от реализации контейнера.

Возможно, я в чем-то не прав и меня поправят.


Ответ 2

Сложный вопрос, я вижу только жёсткий bug, в pop. Там не проверяется состояние вектора
на пустоту. В данном массиве реализация компиляторами расчитана только на скорость
без проверок. Что приведёт к неопределённому поведению, потому-что компиляторы одни
не будут проверять ничего, и будет порча состояния стэка, а в других процессорах вполне
может быть простой флаг ошибки памяти.


При копировании tmp в новый объект, могут быть проблемы с памятью, а стэк уже испортили. Ok.
Перемещающий конструктор есть, но его не вызывали. Опять bad.
Тоже bad. Стек испорчен.
return std::move(tmp) очень поможет так как не будет никаких конструкторов и перемещений.
Если удалили элемент, то дальше хода нет - ответ : нет не только в массивах.
ok