У меня есть принципиально три пути

ну как альтернатива optional

но в optional не написано почему не получилось

Я могу её вернуть, могу передать параметр обработки и могу бросить исключение, если файла нет

Путь (2) замечательный, если по жизни пустой файл уже ошибка

Вопрос в том, что путь 3 ужасен

Если задуматься, то нет никакой валидации, что я проверяю, что функция вообще умеет бросать это исключение

Да, а теперь представьте ситуацию когда у вас очень сложная система и исключение происходит глубоко по call стеку от потребителя

И что?

Тогда чтобы меньше колотить удобно использовать исключения

Хотя это и порождает проблемы с энфорсом try

Но это же все равно, что вернуть std::any из функции

Но это же все равно, что вернуть std::any из функции

Почему any? получаете ту же пару значение/эксепшн, только не явно

Ну т.е. функция все еще может возвращать объект любого типа!

У вас нет информации о её возврате

ты хочешь такую проверку встроенную в язык?

да, в этом месте хотелось бы сделать какой-нибудь checked exception

да, в этом месте хотелось бы сделать какой-нибудь checked exception

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

да, недостатки известны и везде уже отказались от них

ты хочешь такую проверку встроенную в язык?

я хочу operator try :)

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

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

Так а в чем проблема с expected вы не написали

Так а в чем проблема с expected вы не написали

Я не знаю как дела в 20м, но в 17м приходится писать неприятные буквы в части a + b

Т.е. нельзя auto a = try try_get_a(); а надо auto try_a = try_get_a(); if (is_fail(try_a)) return bypass_fail(std::move(try_a)); auto a = /**/(std::move(try_a));

как проще всего unicode строку перевести в cp1251?

как проще всего unicode строку перевести в cp1251?

libicu

Т.е. нельзя auto a = try try_get_a(); а надо auto try_a = try_get_a(); if (is_fail(try_a)) return bypass_fail(std::move(try_a)); auto a = /**/(std::move(try_a));

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

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

Полный аналог второго выражения

нагуглил варианты, но как-то странно работают, то переводят, то нет

return должен произойти, как в случае выброшенного исключения

А, ну вот expected именно оно и есть

Так это функциональный возврат и есть

Вот так (вроде ) будете писать: auto a = * try_get_a();

Там же не исключение бросить, а вернуть

Там же не исключение бросить, а вернуть

не понял

как проще всего unicode строку перевести в cp1251?

WideCharToMultibyteChar / ICU

как вы хотите описать то что должно произойти

не понял

operator try примененный к expected должен проверить, что случай ОК, в противном случае вернуть (return) ошибку из функции

да как угодно

если что, под windows

operator try примененный к expected должен проверить, что случай ОК, в противном случае вернуть (return) ошибку из функции

хм, мне казалось такое там тоже есть (указать что вернуть если unexpected ) в общем я только презентацию александреску видел пару месяцев назад, надо почитать

хм, мне казалось такое там тоже есть (указать что вернуть если unexpected ) в общем я только презентацию александреску видел пару месяцев назад, надо почитать

я слышал такое умеют делать за счет корутиновских операторов

но это ОБС (или ОАС?)

а дальше там идет реализация "почти variant" типа expected<OkType, type_base_set<PossibleExceptions>>

и все идеальнейше работает

WideCharToMultibyteChar / ICU

можно пример, пожалуйста?

хм, мне казалось такое там тоже есть (указать что вернуть если unexpected ) в общем я только презентацию александреску видел пару месяцев назад, надо почитать

Вообще в качестве примера на подумать load_string вполне может принять параметром инпута vector<byte> и тогда FileNotFound обрабатывать немножко смешно

Вообще в качестве примера на подумать load_string вполне может принять параметром инпута vector<byte> и тогда FileNotFound обрабатывать немножко смешно

Не понял

и вероятность в итоге так высока, а контеншен за контрольный блок так велик, что это идет на равне с сисколлом?

Без move есть вероятность что не только владение но и lifetime закончится в вызывающем потоке. А это уже скажется на работе с аллокатором. Который может всякими tls пользоваться. Move более детерминирован.

Не понял

load_string имеет конвенцию (<источник>, <теги>) -> string где источник это поток byte-ов

возможные ошибки это ошибки источника и ошибки перекодировщика

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

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

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

не сталкивался с острой практической необходимостью делать такие обобщения

не сталкивался с острой практической необходимостью делать такие обобщения

а почему синтаксически должна отличаться загрузка строки из файла и из массива?

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

load_string(file) или load_string(vector) это буквально русский язык

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

если же захочу, то думаю какой-нибудь optional с enum кода ошибки вместо bool меня бы устроил

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

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

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

если получив utf8-xml-ку с сервера вы не можете её декодировать, вы шлете /report серверу WTF он отправил если разорвалось соединение, вы повторяете запрос

ну вот получается что load_file и load_vector сильно различаются семантически

не вижу

load_string это метод буквально следующего вида auto data = try load_data(источник) return decode(data, теги)

не нужен

Почти не использую

и преподу скажи, что никому метод show не нужен

Ну гугл кодстайл убил эксепшоны в C++, за это спасибо

я всё жду когда нормальные эксепшоны сделают

Чем вам текущие не нравятся

Чем вам текущие не нравятся

нужны exception как аналоги эррор кодов, с таким же "легковесным" выбрасыванием

ибо эррор коды не удобно использовать

exception func() { return exception("wat"); }

получается какой-то rust

Или C/Go

А чем вам expected тогда не по нраву? Это ж как раз оно и есть

А чем вам expected тогда не по нраву? Это ж как раз оно и есть

каждый раз проверять надо или костылить цепочку вызовов

а с исключениями засунул в try всё и в catch ловишь

хотя там ещё у Александреску было интересное выступление по поводу SCOPE_*, но оно по сути тоже на исключениях, просто без try-catch https://www.youtube.com/watch?v=WjTrfoiB0MQ

да все ок с эксепшенами в цхх. Все вроде логично, кроме некоторых редких вещей.

Expected такой же ресурсоемкий как эксепшон. Если я правильно понимаю.

expected норм, за исключением синтаксиса

@supapro

Жди

Если задуматься, то нет никакой валидации, что я проверяю, что функция вообще умеет бросать это исключение

попахивает checked exceptions из Java)))

попахивает checked exceptions из Java)))

им и является

нужны exception как аналоги эррор кодов, с таким же "легковесным" выбрасыванием

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

я как раз это читаю, только r1

Т.е. нельзя auto a = try try_get_a(); а надо auto try_a = try_get_a(); if (is_fail(try_a)) return bypass_fail(std::move(try_a)); auto a = /**/(std::move(try_a));

переизобретение исключений какое-то получается

но это ОБС (или ОАС?)

как нагуглить эти аббревиатуры?

как нагуглить эти аббревиатуры?

ОБС одна бабка сказала

переизобретение исключений какое-то получается

разница в том, что это - тип возвращаемого значения