Почему boost::optional еще не в стандартной библиотеке?

На самом деле плохо представляю, как вообще кодить без boost::optional и boost::variant. Разве что вместо второго городить везде классы и наследование.

Пиши на Java, возвращай null (от ArrayList<String>), размягчай свои волосы.

Мне надо на C++, тестовое задание чтобы работу найти. И вроде даже в Java это уже считается моветоном среди не ретроградов. Помню, что даже там уже Optional придумали.

Что же мне теперь делать, тянуть буст в зависимостях?

Наркоман?

// bla-bla
// .... 

// nothing found
return {};

Это не тру. Это что-то уровня когда возвращаешь -1, если не нашел, а точнее даже хуже.

Хм, я учил Java тогда, когда ещё 7-ка была. Увы, новее знаю плохо, ибо на самообучении при _очень_ редком применении.

Хотя да, нашёл Optional в javadoc'ах 8-ки.

Это что-то уровня когда возвращаешь -1

И что в этом плохого?

Видимо остается городить свой класс, как re.match в бидоне, который будет делать

auto found = sdelay_iz_muhi_slona(dictionary, startWord, endWord);
if found.nashel() {
    std::cout << "Ura, nashol put', vot on: " << found.path_as_string() << std::endl;
}
else {
    std::cerr << "Ne nashel :{" << std::endl;
}

Смотря какой компилятор в наличии. В experimental есть optional. В GCC 4.9.3-5.2.0, например, уже завезли.

Попробуй тоньше.

Хипстеры, сэр.

Ты смотри, даже меня уже ретроградом в мои то 20, назвали.

может что-то еще более наркоманское

Возвращай тупл литералом и разворачивай его через std::tie , будет почти как в go.

То, что некрасиво, нет такого, что как Optional - сразу понятно из сигнатуры, что оно возвращает и когда, и всё такое.

Я ничего не понял, гоуланг не знаю.

Ну так можно 0 вернуть

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

http://en.cppreference.com/w/cpp/utility/tuple/tie

http://blog.golang.org/error-handling-and-go

Предлагаешь возвращать либо мусорный вектор и значение enum class'а, означающее провал, либо хороший вектор и значение enum class'а, означающее удачу?

Java, говоришь? http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html

Любые указатели (хоть unique_ptr/shared_ptr в С++, хоть «ссылки» в Java) - ни разу не адекватная замена optional, ибо

• Как узнать, что оно может быть null? Комментарий - не надёжно.
• accidental data structures
• быстродействие (в C++ заворачивание в optional может быть на порядок быстрее, чем выделение динамической памяти)

Первые два пункта касаются Java в той же мере, что и С++.

Тебе предлагают возвращать флаг успешного завершения и объект, который может иметь пустое значение в случае неуспеха. Не тупи.

И что это за объект такой?

Строка или вектор нулевой длины.

Любые указатели (хоть unique_ptr/shared_ptr в С++, хоть «ссылки» в Java) - ни разу не адекватная замена optional, ибо

Как узнать, что оно может быть null? Комментарий - не надёжно.

Не отрицая полезности optional, к любому *_ptr следует относиться так, будто он может быть nullptr.

А если внезапно мне надо не вектор возвращать, а свой собственный класс, у которого не бывает пустого значения?

return std::make_pair(true, result); // Нашёл
return std::make_pair(false, {}); // Не нашёл

Говно конечно, но примерно того же сорта, что и твой вариант.

А если внезапно мне надо не вектор возвращать, а свой собственный класс, у которого не бывает пустого значения?

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

А вообще, тебе предлагают решение, а ты капризничаешь «а вот сичас у миня ни палучицца!!!11».

Больше литералов же, покажем что мы могем как в питоне:

return {true, res};
return {false, {}};

«Параноидальный» подход к ptr порождает 100500 лишних if (not null), else-ветка которых далеко не всегда тривиальна.

Учитывая, что вариант с нехваткой памяти можно исключить из рассмотрения (один фиг new умеет throw bad_alloc), остаётся преднамеренный возврат null. Возможный преднамеренный возврат null - это сколько процентов от возвратов указателей вообще? Допустим, 30%. Остальные 70% if будут мертвым кодом.

не бывает пустого значения

И чем здесь optional будет от тупла отличаться?

А что создавать, если пустого значения у объекта, который иногда хотим возвращать, не бывает?

boost::optional<Date> begin, end;
boost::tie(begin, end) = getPeriod();

It works because inside boost::tie a move-assignment from T is invoked on optional<T>, which internally calls a move-constructor of T.

Бустокислота же, неудивительно что ее в stdlib не приняли.

пустого значения у объекта, который иногда хотим возвращать, не бывает

Плохой, негодный объект. Сделай placement new в aligned storage и возвращай этот storage. А когда тебя придут бить клавиатурами коллеги - скажи что ты так аллокаций избегаешь.

Бустокислота же, неудивительно что ее в stdlib не приняли.

Ее собираются принять. Не совсем бустовый вариант, правда.

Тред не читал, никто ещё не предложил обмазаться экспериментальным разделом 14ого стандарта?

Вообще свой optional(у мну на проекте как раз свой закостылен, ибо в интерфейсах таскается) дело ну пары часов с тестами медитацией и перервывом на просмотр порно.

Можно позаимствовать из cxxomfort

возвращай shared_ptr

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

Спасибо - не знал.

Плохой, негодный объект

Отличный объект. Default-конструкторы - в общем случае отстой. Как раз optional отлично сочетается с отказом от default-конструкторов.

А как это работает в boost::optional без пойнтеров?

Я хотел посмотреть, открыл optional.hpp и перехотел. Размер возвращаемого объекта из функции фиксируется в компайлтайме же. Они возвращают struct {bool = false} для None и struct {myclass = result} для Some, выбираемые темплейтной магией?

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

А как это работает в boost::optional без пойнтеров?

Не знаю. У меня нет ни Boost, ни C++14.

Мальчик, иди разберись для начала, сколько байт занимает std::vector.

http://en.cppreference.com/w/cpp/experimental/optional

Но в твоем случае я бы не выпендривался и вернул пустую строку, т.к. по смыслу задачи это знаечние никогда не будет валидным

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

Бывают объекты размером не больше указателя, их как раз нужно возвращать по значению

Бывают объекты

Бывают, лол, все контейнеры, все виды строк и все PIMPL'ы (т.е. все Qt). Интересно как раз в каком случае НЕ нужно по значению возвращать.

Да даже если объект в несколько раз больше указателя - возврат по значению будет намного быстрее, чем работа с динамической памятью. Вобщем-то достаточно типовая ситуация: объект представляет из себя набор из пары-тройки указателей плюс какой-нибудь size_t. RVO и move semantics делают возврат по значению выгодным, ибо данные, на которые ссылаются внутренние указатели объекта, не копируются.

Бывают, лол, все контейнеры

Не все

, все виды строк

не вск

и все PIMPL'ы (т.е. все Qt).

Далеко не все классы в Qt используют PIMPL, особенно те из них, которые не наслудуются от QObject

Принимается, но в таких слуаях лучше поглядеть на получившийся асм или попрофилировать

RVO

Полагаться на RVO для корректности программы? O_o

С добрым утром. Вообще-то RVO теперь прописано в стандарте.