не обязательно функций. Это могут функторы и лямбды. Можешь сделать иерархию функторов какую-нибудь

немного наркомания получается

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

кроме коллбэка ты тут ничего не придумаешь. Я серьёзно. Если нужно действие ВНУТРИ функции, которое ты можешь передать извне, то не выдумывай ничего, что уже до тебя придумано

у меня кроме одной функции еще иерархия

Читается полностью

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

Но могу и соврать. У hdd тоже кеш есть.

немного наркомания получается

не сказал бы. Зато защита есть, которую ты хочешь)

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

ох я бы не был так уверен, что будет быстрее.

кроме коллбэка ты тут ничего не придумаешь. Я серьёзно. Если нужно действие ВНУТРИ функции, которое ты можешь передать извне, то не выдумывай ничего, что уже до тебя придумано

Мне нужно грубо говоря variant<enum, callback>, но у меня нет variant)

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

Кодить в 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() или как-то так и сразу будет видно кто и где игнорирует

ERROR: S client not available

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

не надо

ну окай, .ignore

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

?

ну так если пользователь спецаильно игнорит, то ССЗБ

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

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

сразу всё сделать в компайл-тайм ???

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

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

потому что вместо занятий хернёй нужно заниматься правильными вещами. Надо уметь расставлять приоритеты правильно

а всякие странные фичи пусть пилят где-нибудь в другом месте

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

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

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

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

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

?

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

ты вообще знаком, что такое Result<T,V>?

ты вообще знаком, что такое Result<T,V>?

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

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

Так точно

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

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

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

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

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

так, ещё раз. Какого ты хочешь добиться результат в итоге?

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

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

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

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

Все 100МБ?

Ээ

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

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

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

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