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

нужно ли пустое состояние объекта std::variant

И до сих пор не решили? Надеюсь, всё-таки решат, что пустое значение тоже нужно.

Надеюсь, всё-таки решат, что пустое значение тоже нужно.

Но ведь оно не нужно.

эмм... работу на жабе найти проще. это я по предложениям на сайтах работы вижу, причём не один год. да и жаба попроще будет, нежели плюсы.
что касается буста, то его не надо особо «тащить». он легко линкуется статически, многие библиотеки вообще header-only. буст поставляется в сборках под все основные системы, поддерживает сборку основными распространёнными копиляторами. с ним проблемы возникают как раз только тогда, когда вдруг какая-то часть переходит из буста в стандарт. посему рекомендую заранее переопределить либо макросами, либо ещё как, использование областей видимости буста и везде их проставлять. чтобы потом просто переопределить в std и не мучиться. каша из буста и новых стандартов не всегда живёт хорошо. поэтому нужно писать всё аккуратно.

Мне менее интересно то, что пишут на джаве, кроме разве что хадупа. Плюс я уже лучше знаю C++.

И например в репах убунты 15.10 есть только буст 1.58, а 1.60 нету. Я из-за этого немножко приуныл, потому что хотел boost::test использовать, а там интерфейс поменяли за эти версии.

И например в репах убунты 15.10 есть только буст 1.58, а 1.60 нету

Дроч на последние версии - плохая привычка для реальной работы.

собери статически и не парься. у буста есть такая хрень как BCP (http://www.boost.org/doc/libs/1_60_0/tools/bcp/doc/html/index.html), которая позволяет вытаскивать только ту часть буста, которая реально используется в твоём коде, чтобы потом компилить и линковать только то, что тебе нужно.

это точно. потому что обычно у работодателей куплен какой-нить древний редхат и на нём стоит софт позапрошлого века и компилятор, которым ещё наши деды фашистов убивали :)

Ты готов уродовать обьекты костылями только бы не использовать optional?

У тебя неправильные понятия о костылях. Многие объекты и так имеют естественные нулевые состояния (указатель, std::string...) и почти всегда они возникают как только нужно иметь дефолтный констуктор. Инога нули требует семантика объекта или вообще не работают с объектом по значению. В остатке получается мизерное кол-во сценариев где бы optioanl мог бы быть полезным в плюсах.

Но ведь оно не нужно.

Почему? Заворачивать variant в optional - увеличит размер.

Но ведь оно не нужно.

Почему?

Потому что я не хочу постоянно проверять variant на пустоту; потому что variant - это sum type, и в него должны входить только те типы, которые я явно указал; потому что если я захочу пустое значение в variant, я добавлю туда struct empty {} или что-то такое.

Заворачивать variant в optional

O_o

Соответственно хочу вернуть или std::vector<std::string>, если путь найден, или ничего не возвращать.

Пустой вектор вполне подходит в качестве «ничего».

Каким образом из типа результата становится понятно, что вектор нулевой длины - валидный результат, означающий «объект не найден»?

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

К примеру, если список файлов в директории пуст, то это результат поиска в пустой директории, или поиск вообще ещё не стартовал?

Если он может не стартовать, то зачем вообще возвращать вектор?

Какое нулевое значение выбрать для идентификатора, 0, -1 или некая константа?

Это другой случай.

Или результат ошибочен?

Для ошибок есть исключения.

Что функция поиска маршрута вернула вектор нулевой длины в результате ошибки.

С тем же успехом она сможет вернуть «пустой» optional в результате ошибки.

Особое значение векторов нулевой длины тоже усложняет код.

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

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

Не знаю. Вот лично я понимаю optional и использую его в разных языках. Но для списков не вижу никакого смысла в нем. Писал бы на haskell, например, не стал бы запихивать [] в Maybe

Почему? Заворачивать variant в optional - увеличит размер.

Потому, что пустое состояние программист может задать для своего variant сам.

Дроч на последние версии - плохая привычка для реальной работы.

Ну у нас «на реальной работе» 1.59 версия сейчас. Причём на 1.60 даже переходили, но из-за чего-то откатились. Не везде такие сложности и проблемы с обновлением.

Многие объекты и так имеют естественные нулевые состояния (указатель, std::string...)

Хорошо, как на случай более сложных объектов? Хотя бы структуры из тех нескольких строк/векторов.

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

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

Ну-ну. У меня несколько другой опыт и случаев когда пустая строка или ноль являются отличным от «отсутствующего» значения хватает. Кстати, тебя не смущает, что optional, в том или ином виде, много где есть. Чем плюсы тут уникальны?

Не везде такие сложности и проблемы с обновлением.

С тем же успехом можно сказать «не везде так просто с обновлениями». Поэтому привычка плохая.

O_o

Я просто тебя не понял. Если говорить о boost::optional, то там автоматический никакой пустой тип не запихивается. Хотя из коробки и имеется специальный тип под это дело, чтобы каждый не городил свой empty. Подумал, что ты как раз против этого.

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

Банальный возврат списка файлов в директории подойдёт? Пустой вектор может означать как отсутствие файлов, так и некорректность пути. «Иногда» эти ситуации лучше разделять.

Потому, что пустое состояние программист может задать для своего variant сам.

Да, это просто было недопонимание. Хотя я бы всё-таки предпочёл чтобы «из коробки» имелся специальный тип под это дело вместе с удобными функциями проверки.

Для ошибок есть исключения.

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

Поэтому привычка плохая.

И что же в ней плохого? Ну попадёт «привыкший» на работу где обновиться не получится. Будет подстраиваться или уйдёт оттуда.

Если ты намекаешь на потенциальные баги/регрессии в свежих версиях, то это, во многом, организационные проблемы.

И что же в ней плохого? Ну попадёт «привыкший» на работу где обновиться не получится.

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

Будет подстраиваться или уйдёт оттуда.

Ни то, ни другое не бесплатно.

Собственно вернуть пустой вектор - нормально. Ты буквально ничего не нашел и верни вот это ничего. А ты на ровном месте создаешь «специальный случай». Еще было бы понятно если «найти ничего» и «не смог попытаться найти» имело разный смысл, но тогда почему бы не попробовать Exception или вернуть какой-то статус. А может даже возвращать bool, а вектор передавать по ссылке

Ни то, ни другое не бесплатно.

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

Ну если у вас человек может втихаря протащить что угодно

Конкретно у нас - нет, но где-то - вполне может.

то «привычка к последним версиям» далеко не главная проблема.

Смотря для кого. Для того, кто не сдал работу - таки главная %)

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

Очень даже универсальный. Для обработки ошибок. Если же неуспех той или иной операции является не ошибкой, а штатной ситуацией, то да, можно заюзать Maybe или, в более сложном случае, Either. Но если мы просто возвращаем список результатов, то пустой вектор итак вполне хорошо справляется с представлением «пустого» результата.

Очень даже универсальный. Для обработки ошибок.

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

Если же неуспех той или иной операции является не ошибкой, а штатной ситуацией

Дык, это не всегда очевидно, тем более для библиотечного кода.

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

Согласен.

Дык, это не всегда очевидно, тем более для библиотечного кода.

И именно поэтому

стандартная библиотека и буст (в меньшей степени) предоставляют выбор, а не используют исключения везде

=)