Зачем использовать boost:: optional, когда я могу вернуть указатель

Преимущество возвращаемого типа optional<Student&> здесь заключается в том, что семантика использования очевидна для всех пользователей, знакомых с optional (и станет очевидной, как только они ознакомятся с ним). Эти семантики:

• Вызывающий не владеет Student и не отвечает за управление памятью. Вызывающий просто получает ссылку на существующий объект.
• Понятно, что эта функция может дать сбой. Вы может быть получаете ценность, но может быть ничего не получаете. Понятно, что вызывающему нужно так или иначе проверить результат.

optional<T> самодокументируется в отличие от T*. Более того, у него есть и другие преимущества: он может работать в тех случаях, когда вы хотите вернуть объект любого типа без необходимости выделения памяти. Что, если вам нужно вернуть int, double или SomePOD?

optional<T&> был удален из стандартизации C++, потому что его использование сомнительно: он ведет себя почти идентично не владеющему T* с немного другой (и до путаницы отличной от optional<T> и T*) семантикой.

optional<T&> в основном не владеющий T* красиво и несколько странно завернутый.

Теперь optional<T> другой зверь.

Я использовал optional<Iterator> в своих алгоритмах поиска на основе контейнеров. Вместо того, чтобы возвращать end(), я возвращаю пустой необязательный параметр. Это позволяет пользователям определить без сравнения, не удалось ли им найти элемент, и позволяет использовать код, подобный следующему:

if(linear_search_for( vec, item))

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

Указатели на элементы не дают вам информации о местоположении, которая может вам понадобиться, за исключением смежных контейнеров.

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

Следующее использование фактически возвращает значение. Предположим, у вас есть функция, которая вычисляет прямоугольник.

Rect GetRect();

теперь это здорово. Но что, если вопрос может быть бессмысленным? Что ж, один из подходов состоит в том, чтобы вернуть пустой прямоугольник или другое значение «флаг».

Необязательный позволяет вам сообщить, что он может вернуть прямоугольник или ничего, и не использовать пустой прямоугольник для состояния «ничего». Это делает возвращаемое значение обнуляемым.

int GetValue();

является лучшим примером. Недопустимое значение может использовать состояние флага int, скажем, -1, но это заставляет каждого пользователя вашей функции искать и отслеживать состояние флага, а не случайно рассматривать его как нормальное состояние.

Вместо этого optional<int> GetValue() ясно дает понять, что может произойти сбой, и что означает сбой. Если он заполнен, вы знаете, что это реальное значение, а не значение флага.

В обоих этих случаях возврат указателя, не являющегося владельцем, нецелесообразен, потому что кому принадлежит хранилище? Возврат указателя-владельца обходится дорого, потому что бессмысленное выделение кучи бессмысленно.

Необязательные типы — это типы значений, допускающие значение NULL. Когда вы хотите управлять ресурсами локально, и вам все еще нужно пустое состояние, они ясно дают понять.

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

optional<T&> действительно может быть заменен на T*, но T* не имеет четкой семантики (право собственности?).

Но optional<T> нельзя заменить на T*. Например:

optional<Interval> ComputeOverlap(const Interval&, const Interval&);

Если нет перекрытия, нет проблем с T* (nullptr) или optional<T>. Но если есть перекрытие, нам нужно создать новый интервал. В этом случае мы можем вернуть smart_pointer или опционально.

Предположим, у вас есть std::map<IndexType, ValueType>, где вы пытаетесь что-то найти (Примечание: то же самое относится и к другим контейнерам, это просто пример). У вас есть следующие варианты:

• Вы возвращаете ValueType&: пользователь может изменить содержимое вашей карты, и ему не нужно думать о выделении/освобождении памяти. Но если вы ничего не найдете на своей карте, вам нужно создать исключение или что-то подобное.
• Вы возвращаете ValueType*: пользователь может изменить содержимое вашей карты, и вы можете вернуть nullptr, если ничего не найдете. Но пользователь может вызвать удаление для этого указателя, и вы все равно должны указать, должен он это делать или нет.
• Вы возвращаете смарт-указатель на ValueType: пользователю не нужно беспокоиться об удалении или отказе от удаления, и он может изменять содержимое вашей карты в зависимости от типа смарт-указателя. Вы также можете вернуть nullptr. Но это в значительной степени требует, чтобы вы имели дело с smart_pointers на вашей карте, что слишком сложно, если ValueType будет, например. просто int в противном случае.
• Вы возвращаете простое ValueType: пользователь не может изменять содержимое вашей карты и ему не нужно думать о выделении/освобождении памяти. Но если вы ничего не нашли на своей карте, вам нужно вернуть какой-то специальный ValueType, который сообщает пользователю, что вы ничего не нашли. Если ваш ValueType, например. int, какой из них вы бы вернули, чтобы было ясно, что "целое не найдено".
• Вы возвращаете boost::Optional, который наиболее близок к простому возврату ValueType по значению с дополнительной опцией «не возвращать ValueType»