Вроде как блрками читать быстрее выйдет.

Кодить в 100500 раз быстрее если просто вычитать весь

Я тоже не уверен. Но вроде как все возможно.

Для потоковых операций отдельные сущности

Вроде как блрками читать быстрее выйдет.

с чего это

На самом деле, stream-режим это полностью отдельная тема

Эта штука возникает когда надо просто прочитать файл, и 146% его можно последовательно в память уложить

но зачем там бросать исключение если можно вернуть result? который 100% надо будет обработать

если ты уж так беспокоишься что его не обработают

Result<T,E> кодится за 15 минут с нуля если лень брать готовое

Я мимокрокодил, но есть же std::variant, он не подойдет?

неа

ну у меня на самом деле реализация через чтение мегабайтными блоками, но не суть

пользователю этой функции совершенно точно не нужен стрим-режим

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

но зачем там бросать исключение если можно вернуть result? который 100% надо будет обработать

наоборот, как правило исключение не обработают, потому что пустой файл - достаточная индикация ошибки уже

например, потом этот файл прочитают как utf-8 и пихнут в xml parser, который сообщит что инпут не xml

прости, я не понимаю что ты пишешь. слова по отдельности вроде бы понятные - а все вместе полная фигня

что значит исключение не обработают потому что файл пустой?

если файл пустой не будет исключения? или что?

прости, я не понимаю что ты пишешь. слова по отдельности вроде бы понятные - а все вместе полная фигня

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

тогда расскажи в каких именно случаях ты бросаешь исключения а в каких - нет

чтение пустого файла, очевидно, не ошибка

"как правило" означает, что не всегда

но с result это поведение легко сделать ошибкой

смотри

auto content = readFile("file_may_be_empty.txt").fail_on_empty("This file is empty");

я бы хотел, чтобы было auto content = readFile("file.bin"); static_assert(std::is_same<decltype(content), std::vector<uint8_t>>::value, "");

В компайл тайме файл прочитать?

В компайл тайме файл прочитать?

ну а почему нет

ну а почему нет

Ну это странно

нет, это пример, что не нужно заменять возвращаемое значение readFile

нет, это пример, что не нужно заменять возвращаемое значение readFile

xy-problem?

не вижу причины НЕ заменять возвращаемое значение readFile если так будет удобнее

ну а почему нет

Есть такой proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0373r0.pdf The content of datafile.txt: The quick brown fox jumps over the lazy dog. The content of main.cc: #include <iostream> int main() { std::cout << tF”datafile.txt”; } The program outputs: The quick brown fox jumps over the lazy dog.

Ну давай ещё в сокеты читать/писать в компайл тайме.

Ну давай ещё в сокеты читать/писать в компайл тайме.

ну а что, compile-time http server! запускаешь gcc и он реквесты обрабатывает

Во во

xy-problem?

Смотри. 90% пользователей считают, что пустой файл является ошибкой и обработают её в любом случае. И им совершенно не сдалось выяснять, что же на самом деле пошло не так у функции readFile

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

Смотри. 90% пользователей считают, что пустой файл является ошибкой и обработают её в любом случае. И им совершенно не сдалось выяснять, что же на самом деле пошло не так у функции readFile

опять какая-то выдуманная хрень

100% пользователей получат от readFile Result<T,E> и несколько функций как его обрабатывать: - похуй пляшем .unwrap() - дефолтно .expect("Failed to read") - непустое .fail_on_empty("File is empty - string may be optional")

Все эти функции либо возвращают T либо падают или бросают эксепшены разной степени тяжести

А нельзя проще readFile("name", error_code)

100% пользователей получат от readFile Result<T,E> и несколько функций как его обрабатывать: - похуй пляшем .unwrap() - дефолтно .expect("Failed to read") - непустое .fail_on_empty("File is empty - string may be optional")

То есть теперь все использования должны писать лишний вызов .unwrap() потому что 10% это действительно нужно?

А нельзя проще readFile("name", error_code)

а потом (void)error_code; чтобы не было варнинга про неиспользованную переменную ага

То есть теперь все использования должны писать лишний вызов .unwrap() потому что 10% это действительно нужно?

не умрут, напишут

не напишут - конпелятор напомнит

readFile(const string& name, ErrorCode& errcode)

не умрут, напишут

50 раз, из них 40 раз будет unwrap и игнорирование результата

50 раз, из них 40 раз будет unwrap и игнорирование результата

вообще дефолтный unwrap() делает PANIC("WOOPS") если в резалте пришел Err

вообще дефолтный unwrap() делает PANIC("WOOPS") если в резалте пришел Err

Еще хуже, надо было просто отдать пустой массив

назови правильно .ignore() или как-то так и сразу будет видно кто и где игнорирует

Еще хуже, надо было просто отдать пустой массив

не надо

ну окай, .ignore

с дизайном у тебя явно проблемы

?

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

Я не очень понял, а что код ошибки нельзя пробросить?

Можно бы(просто нету средств), почему нет ? Только работать это будет только там где компилировалось

int a[] = { #include array.txt.h }

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

Вот такой вопрос. Есть функция std::vector<uint8_t> readFile(filename, ???) которая читает файл полностью. Функция не хочет плевать просто так исключения (забудут обработать ;)) и поэтому хочется сделать, чтобы бросать исключение в качестве индикатора ошибки было явной частью вызова. Вот как в таких случаях передавать параметр "действие при ошибке"?

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

Я полагаю, что речь идет о возврате "значение либо исключение"

смотри, например, дальше будет вызов loadStringDecode() и поедет сигнатура loadString

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

Если я как раз хочу этого избежать :)

Я хочу кастомизировать поведение функции при ошибке (это нужно в 10% случаев)

Я хочу кастомизировать поведение функции при ошибке (это нужно в 10% случаев)

Покажи клиентский код

Покажи клиентский код

Все 100МБ?

Ээ

не парьтесь, он сам разберется

сделает хуевый велосипед и успокоится

зато все 100мб клиентов будут довольны

ну ладно, со 100 я перегнул, вроде) там что-то вроде 500к строк

не парьтесь, он сам разберется

Кстати, ты же ассемблерный код читаешь. Расскажи, switch за О(1) или за О(N) находит нужный case. https://godbolt.org/g/h7pnAK

ну и как ты думаешь, нужны нам все 500к строк? или работающего примера хватит?

сделает хуевый велосипед и успокоится

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

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

там не исключение если что

Какая разница? Условия-то надо всё равно все перебрать.