Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Kluev, Вы писали:

K>>есть ли в std аналог File.ReadAllBytes()?

R>Тут нашлись такие, кто докопался до эффективности. Ну так вот, если важно быстродействие, то можно использовать чуть более длинную версию — аж целых 4 строчки

R>

R>std::vector<uint8_t> read_all_bytes(const std::string& path)
R>{
R>   std::basic_ifstream<uint8_t> input(path.c_str(), std::ios_base::binary);
R>   std::vector<uint8_t> bytes(std::filesystem::file_size(path));
R>   input.read(bytes.data(), bytes.size());
R>   return bytes;
R>}
R>

Нечитаемая мелкобуква с триллионом подводных багов.
Страуструп со Степановым не просто внедрили наихудшие решения в язык и стандартную библиотеку (iostream и stl), но и навязали неокрепшим умам кошмарный нечитаемый мелкобуквенный стиль программирования.
По хорошему комитет давно пора разгонять. От того что они там что-то рожают раз в десятилетие никакой пользы нет.

Здравствуйте, Kluev, Вы писали:

R>>

R>>std::vector<uint8_t> read_all_bytes(const std::string& path)
R>>{
R>>   std::basic_ifstream<uint8_t> input(path.c_str(), std::ios_base::binary);
R>>   std::vector<uint8_t> bytes(std::filesystem::file_size(path));
R>>   input.read(bytes.data(), bytes.size());
R>>   return bytes;
R>>}
R>>

K>Нечитаемая мелкобуква

Ну, это субъективно. Я, например, думаю по-другому.

Ну и главное — это пишется один раз, в использовании же это не сложнее, чем File.ReadAllBytes. И даже чуть проще, потому что "File." писать не нужно:

const auto bytes = read_all_bytes("my_file.bin");

K>с триллионом подводных багов.

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

Здравствуйте, Kluev, Вы писали:

K>Нечитаемая мелкобуква с триллионом подводных багов.

Это про snake_case? Оказывается изучали и такое: https://github.com/hwayne/awesome-cold-showers#an-eye-tracking-study-on-camelcase-and-under_score-identifier-styles-pdf

An Eye Tracking Study on camelCase and under_score Identifier Styles (PDF)

Hype: camelCase is easier to read than under_score. So it is a best practice to use camelCase in variable names, function names, and other identifiers.

Shower: Several research papers have been done. But when eye-tracking software was used to test the claim, two conclusions emerged: (1) developers are equally accurate regardless of style, but (2) the under_score style can be processed faster and easier.

Caveats: The study's sample size was small (15 people), and "Subjects were historically trained mostly in the underscore identifier style and were all programmers." In the study, subjects were presented terms in isolation (not in blocks of code). Thus, as the study notes, there could be variance due to context.

Notes: "The interaction of Experience with Style indicates that novices benefit twice as much with respect to time, with the underscore style. "This paper purports to remedy difficulties in an earlier paper entitled To CamelCase or Under_score, which concluded that with training, camelCase is more accurately processed. Finally, neither paper seems to have analyzed whether native language comes into play (e.g. whether it is easier for non-native English speakers to understand camelCase versus under_score).

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Kluev, Вы писали:

R>>>

R>>>std::vector<uint8_t> read_all_bytes(const std::string& path)
R>>>{
R>>>   std::basic_ifstream<uint8_t> input(path.c_str(), std::ios_base::binary);
R>>>   std::vector<uint8_t> bytes(std::filesystem::file_size(path));
R>>>   input.read(bytes.data(), bytes.size());
R>>>   return bytes;
R>>>}
R>>>

K>>Нечитаемая мелкобуква

R>Ну, это субъективно. Я, например, думаю по-другому.

В этой лапше одна часть библиотеки не знает о существовании другой, через костыль c_str работает. О какой вообще читаемости может идти речь?
Здесь, же черт, возьми живого места нет. Зачем к uint8 _t? в basic_ifstream, зачем этот basic, там что advanced есть? ifstream — это от оператора if или от чего? почему лишнее basic_ важнее input и file, что на него аж 5 букв, а на файл инпут по одной в if? Почему basic через сепаратор _, а i и f нет? зачем здесь при file_size(path) filesystem, что есть какой-то другой file_size не в файловой системе, а в солнечной?
Все это кошмарная халтура за которую комитет давно пора разогнать.


R>Ну и главное — это пишется один раз, в использовании же это не сложнее, чем File.ReadAllBytes. И даже чуть проще, потому что "File." писать не нужно:

Хде оно пишется один раз? Разве что в посте на rsdn и забывается как страшный сон. А в реальной жизни под это дело надо где-то создать хедер, подключить каталог к каждому проекту. Это повезло, что исходника нет, иначе обеспечены танцы с бубном с библиотеками. Ведь поддержки библиотек в с++ нет. Есть только бесконечный зоопарк костылей.
В С++ нет такого места где можно написать один раз. Наш добрый гений старуструп еще не в курсе что существуют такие технологии.

R>

R>const auto bytes = read_all_bytes("my_file.bin");
R>

K>>с триллионом подводных багов.

R>А вот с этого момента поподробнее, пожалуйста. Можно хотя бы один из триллиона озвучить?
Да легко. В input.read размер streamsize — знаковый, а vector.size() который туда передается беззнаковый. на 32 бит платформе тип возвращаемый file_size и размер в конструкторе вектора имеют разную размерность. Т.е. данный говнокод может легко рыгнуть уже на целочисленном переполнении, не говоря уже о других проблемах озвученных другими собеседниками выше.

Здравствуйте, Kluev, Вы писали:

R>>>>

R>>>>std::vector<uint8_t> read_all_bytes(const std::string& path)
R>>>>{
R>>>>   std::basic_ifstream<uint8_t> input(path.c_str(), std::ios_base::binary);
R>>>>   std::vector<uint8_t> bytes(std::filesystem::file_size(path));
R>>>>   input.read(bytes.data(), bytes.size());
R>>>>   return bytes;
R>>>>}
R>>>>

K>В этой лапше одна часть библиотеки не знает о существовании другой, через костыль c_str работает. О какой вообще читаемости может идти речь?

Ну это не так. Начиная с C++11 c_str можно не писать. Я это написал просто по привычке. Даже не предполагал, что это может кого-то напрячь. Тоже мне беда, написал несколько лишних букв, какая, нафиг, разница, что там внутри, ты внутрь File.ReadAllBytes часто заглядываешь?

K>Здесь, же черт, возьми живого места нет. Зачем к uint8 _t? в basic_ifstream, зачем этот basic, там что advanced есть?

Ну просто потому что я хотел подчеркнуть, что для описания массива байт можно использовать беззнаковый тип, только и всего. Пожалуйста, можно с тем же успехом работать и с обычным char (который используется по умолчанию). И тогда вместо std::basic_ifstream<uint8_t> можно написать просто std::ifstream. Я же не знаю требований программы, поэтому демонстрировал возможности. Хотел как лучше, получилось как всегда.

K>ifstream — это от оператора if или от чего? почему лишнее basic_ важнее input и file, что на него аж 5 букв, а на файл инпут по одной в if? Почему basic через сепаратор _, а i и f нет?

Ну, во-первых потому, что было рассчитано, что чаще будет использоваться алиас типа std::ifstream. А basic_istream — это имя шаблона класса, предполагалось, что он будет использоваться сравнительно редко, по мере необходимости. А во-вторых, это просто придирки к именам. Тут на вкус и цвет все фломастеры разные и, наверное, в любом языке можно докопаться до столба. Меня, например, очень раздражают вебрблюжьи горбы в C#, так что теперь — всех расстрелять, потом разогнать?

K>зачем здесь при file_size(path) filesystem, что есть какой-то другой file_size не в файловой системе, а в солнечной?

Ну ты сейчас обсуждаешь мой личный стиль и мои личные предпочтения, а не особенности языка С++. Да, я не вижу никакой трагедии в использовании полно-квалифицированных имен. Но если для кого-то это так важно, пожалуйста — в C++, так же как и в C# есть using директивы. А еще есть и using — объявления и алиасы пространств имен — пожалуйста, делайте себе синтаксический сахар сколько влезет.

K>Все это кошмарная халтура за которую комитет давно пора разогнать.

Да прям уж. Какая, нафиг, разница, что там внутри функции, главное же, чтоб работала правильно. Тебе часто приходится заглядывать внутрь File.ReadAllBytes?

R>>Ну и главное — это пишется один раз, в использовании же это не сложнее, чем File.ReadAllBytes. И даже чуть проще, потому что "File." писать не нужно:

K>Хде оно пишется один раз? Разве что в посте на rsdn и забывается как страшный сон. А в реальной жизни под это дело надо где-то создать хедер, подключить каталог к каждому проекту. Это повезло, что исходника нет, иначе обеспечены танцы с бубном с библиотеками. Ведь поддержки библиотек в с++ нет. Есть только бесконечный зоопарк костылей.
K>В С++ нет такого места где можно написать один раз. Наш добрый гений старуструп еще не в курсе что существуют такие технологии.

А в чем проблемы-то? Всю жизнь писали и пишем общие библиотеки на самых разных уровнях. И при чем тут Страуструп?

K>Да легко. В input.read размер streamsize — знаковый, а vector.size() который туда передается беззнаковый. на 32 бит платформе тип возвращаемый file_size и размер в конструкторе вектора имеют разную размерность. Т.е. данный говнокод может легко рыгнуть уже на целочисленном переполнении, не говоря уже о других проблемах озвученных другими собеседниками выше.

Ну это опять же сугубо мой косяк, который я там дальше по ходу обсуждения и поправил: http://rsdn.org/forum/cpp/8662776.1

Автор: rg45
Дата: 06.01 01:24

.

А с учетом сказанного выше по тексту, можно сделать еще и покомпактнее:

std::vector<char> read_all_bytes(const std::string& path)
{
   std::ifstream input(path, std::ios_base::binary | std::ios_base::ate);
   std::vector<char> bytes(input.tellg());
   input.seekg(0);
   input.read(bytes.data(), bytes.size());
   return bytes;
}

Здесь, конечно же, vector.size() беззнаковый, но размер вектора инициализируется по значению, возвращаемому tellg(), которое имеет тип std::streamsize и переполнение невозможно.

Ну, один косяк исправили. Да и косяк-то, положа руку на сердце, весьма условный — чтоб налететь на это на 64-битной платформе, размер файла должен перевалить за 2.3 экса-байт (2.3 миллиона терабайт). Вы серьезно собираетесь загрузить такой файл в оперативную память?

Что-то еще? Ты там про триллион багов говорил.

Здравствуйте, Kluev, Вы писали:

K>Т.е. данный говнокод может легко рыгнуть уже на целочисленном переполнении, не говоря уже о других проблемах озвученных другими собеседниками выше.

Да ты говнокода не видел, походу. Хочешь увидеть говнокод — загляни в реализацию File.ReadAllBytes. Вот где индусятина буйным цветом.

	File.ReadAllBytes (C#)
	public static byte[] ReadAllBytes(string path) { if (1 == 0) { } FileOptions options = FileOptions.SequentialScan; using SafeFileHandle safeFileHandle = OpenHandle(path, FileMode.Open, FileAccess.Read, FileShare.Read, options, 0L); long num = 0L; if (safeFileHandle.CanSeek && (num = safeFileHandle.GetFileLength()) > 2147483591) { throw new IOException(SR.IO_FileTooLong2GB); } if (num == 0L) { return ReadAllBytesUnknownLength(safeFileHandle); } int num2 = 0; int num3 = (int)num; byte[] array = new byte[num3]; while (num3 > 0) { int num4 = RandomAccess.ReadAtOffset(safeFileHandle, array.AsSpan(num2, num3), num2); if (num4 == 0) { ThrowHelper.ThrowEndOfFileException(); } num2 += num4; num3 -= num4; } return array; } private static byte[] ReadAllBytesUnknownLength(SafeFileHandle sfh) { byte[] array = null; Span<byte> span = stackalloc byte[512]; try { int num = 0; while (true) { if (num == span.Length) { uint num2 = (uint)(span.Length * 2); if ((long)num2 > 2147483591L) { num2 = (uint)Math.Max(2147483591, span.Length + 1); } byte[] array2 = ArrayPool<byte>.Shared.Rent((int)num2); span.CopyTo(array2); byte[] array3 = array; span = (array = array2); if (array3 != null) { ArrayPool<byte>.Shared.Return(array3); } } int num3 = RandomAccess.ReadAtOffset(sfh, span.Slice(num), num); if (num3 == 0) { break; } num += num3; } return span.Slice(0, num).ToArray(); } finally { if (array != null) { ArrayPool<byte>.Shared.Return(array); } } }

Классная работа ученика школы информационных технологий для умственно отсталых. Зато всё большими буквами, ага.


И кстати, мой "говнокод" спокойно загружает файлы размером свыше 2ГБ, а у вашей чудесной File.ReadAllBytes слетает кабина:

Unhandled exception. System.IO.IOException: The file is too long. This operation is currently limited to supporting files less than 2 gigabytes in size.
   at System.IO.File.ReadAllBytes(String path)
   at ConsoleApp1.Program.Main(String[] args) in E:\Development\VS2022\ConsoleApp1\Program.cs:line 8

E:\Development\VS2022\ConsoleApp1\bin\Release\net8.0\ConsoleApp1.exe (process 644) exited with code -532462766.
Press any key to close this window . . .

Это просто гениально, тупо размер файла ограничили и все! И никаких проблем с преобразованием знаковых-беззнаковых, класс!


Тебя все еще удивляет, почему в std нет аналога File.ReadAllBytes? Отвечаю: потому что нафиг мне не упало в std такое счастье.

Здравствуйте, rg45, Вы писали:
r> Да ты говнокода не видел, походу. Хочешь увидеть говнокод — загляни в реализацию File.ReadAllBytes. Вот где индусятина буйным цветом.
Это больше похоже на результат декомпиляции байткода.

Здравствуйте, ·, Вы писали:

·>Это больше похоже на результат декомпиляции байткода.

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

Здравствуйте, rg45, Вы писали:

r> ·>Это больше похоже на результат декомпиляции байткода.
r> Да, вероятно. Об этом я не подумал. Но, как бы то ни было, такое жесткое ограничение на размер загружаемого файла для функции общего применения — это странно — очень-очень мягко говоря, не правда ли? Я считаю, лучше вообще не делать, чем делать кое-как.
Это ограничение платформы. Массивы в шарпе индексируются 32-битным знаковым интом. Т.е. byte[] в принципе не может быть больше 2гб.

Здравствуйте, ·, Вы писали:

·>Это ограничение платформы. Массивы в шарпе индексируются 32-битным знаковым интом. Т.е. byte[] в принципе не может быть больше 2гб.

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

Автор: rg45
Дата: 02.01 16:14

, в две строчки который, делает ReadAllBytes по полезности, как арифмометр счеты.

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, ·, Вы писали:

R>·>Это ограничение платформы. Массивы в шарпе индексируются 32-битным знаковым интом. Т.е. byte[] в принципе не может быть больше 2гб.

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

Автор: rg45
Дата: 02.01 16:14

, в две строчки который, делает ReadAllBytes по полезности, как арифмометр счеты.

хм. несуществующий велосипед "победил" стандартное решение. самому не смешно?

Здравствуйте, rg45, Вы писали:

K>>зачем здесь при file_size(path) filesystem, что есть какой-то другой file_size не в файловой системе, а в солнечной?

R>Ну ты сейчас обсуждаешь мой личный стиль и мои личные предпочтения, а не особенности языка С++. Да, я не вижу никакой трагедии в использовании полно-квалифицированных имен. Но если для кого-то это так важно, пожалуйста — в C++, так же как и в C# есть using директивы. А еще есть и using — объявления и алиасы пространств имен — пожалуйста, делайте себе синтаксический сахар сколько влезет.

Уточню. Сам namespace filesystem не нужен. Вполне достаточно пространства имен std. Там нет столько функциональности чтобы выделять в отдельное пространство имен. Что же касается директив using то и тут в комитете ухитрились поднасрать пользователям с именами функций типа absolute. Без полной квалификации тут происходит полный разрыв с контекстом.

K>>Все это кошмарная халтура за которую комитет давно пора разогнать.

R>Да прям уж. Какая, нафиг, разница, что там внутри функции, главное же, чтоб работала правильно. Тебе часто приходится заглядывать внутрь File.ReadAllBytes?

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

R>А в чем проблемы-то? Всю жизнь писали и пишем общие библиотеки на самых разных уровнях. И при чем тут Страуструп?

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

K>>Да легко. В input.read размер streamsize — знаковый, а vector.size() который туда передается беззнаковый. на 32 бит платформе тип возвращаемый file_size и размер в конструкторе вектора имеют разную размерность. Т.е. данный говнокод может легко рыгнуть уже на целочисленном переполнении, не говоря уже о других проблемах озвученных другими собеседниками выше.

R>Ну, один косяк исправили. Да и косяк-то, положа руку на сердце, весьма условный — чтоб налететь на это на 64-битной платформе, размер файла должен перевалить за 2.3 экса-байт (2.3 миллиона терабайт). Вы серьезно собираетесь загрузить такой файл в оперативную память?

Это не одиночный косяк, а система. В std целый зоопарк различных типов размеров с постоянными проблемам signed/unsigned

R>Что-то еще? Ты там про триллион багов говорил.

А тебе мало что ли? В с++ функцию из трех букв нельзя написать не сделав три ошибки. Что говорит о том что дизайн языка и библиотеки — мусор.

Здравствуйте, ·, Вы писали:

·>Именно. Поэтому я считаю, что это вполне возможно и достаточно оправдано сделать универсальное и надёжное решение в стандартной библиотеке. Т.к. частное решение в две строчки может иметь очень тонкие баги.

Разве в общем случае эта задача имеет решение?

Здравствуйте, ·, Вы писали:

·>Тем более это — аргумент в пользу того, что это должно быть в стандартной либе, чтобы хоть как-то более менее согласовано было. И если обнаруживают баги, то они правятся централизовано, а не каждый правит свой двухстрочник.

Каким образом имплементация операционной системы может оказаться в стандарте языка? Даже тот же std::filesystem::file_size(not_a_regular_file) — уже implementation-defined, а значит не стандартизовано.

Здравствуйте, Kluev, Вы писали:

K>стандарт С++ не знает что такое библиотека, проект и другие "ненужные" вещи. в итоге чтобы собрать некоторые проекты нужно качать питон, какие-то левые скрипты и т.п. миллион костылей.
Это не проблемы языка, а наоборот преимущество: каждый может организовать работу так, как считает нужным.

Здравствуйте, Kluev, Вы писали:

K>хм. несуществующий велосипед "победил" стандартное решение. самому не смешно?
В том-то и дело, что смешно, так как без кавычек.

Здравствуйте, rg45, Вы писали:

R> if (safeFileHandle.CanSeek && (num = safeFileHandle.GetFileLength()) > 2147483591)

Это просто позор. Куда делись 56 байтов?

Здравствуйте, B0FEE664, Вы писали:

R>> if (safeFileHandle.CanSeek && (num = safeFileHandle.GetFileLength()) > 2147483591)

BFE>Это просто позор. Куда делись 56 байтов?

Это налог на содержание "платформы"

Здравствуйте, B0FEE664, Вы писали:

BFE>·>Тем более это — аргумент в пользу того, что это должно быть в стандартной либе, чтобы хоть как-то более менее согласовано было. И если обнаруживают баги, то они правятся централизовано, а не каждый правит свой двухстрочник.
BFE>Каким образом имплементация операционной системы может оказаться в стандарте языка?
Как и всё остальное. В стандарте же есть, например, std::thread, а ведь имплементация тредов в операционках везде очень разная.

BFE>Даже тот же std::filesystem::file_size(not_a_regular_file) — уже implementation-defined, а значит не стандартизовано.
Верно. Поэтому предложенный тут код выше — не годится. file_size не должен задавать точный размер массива, а только hint. Наиболее вменяемая имплементация есть в jdk, и в две строчки не укладывается, потому что не так уж это всё и тривиально.

Здравствуйте, Kluev, Вы писали:

K>хм. несуществующий велосипед "победил" стандартное решение. самому не смешно?

Ты ухватился за второстепенную мысль, а главную пропустил. А главная мысль была не про то, кто кого победил, а вот про это:

Тебя все еще удивляет, почему в std нет аналога File.ReadAllBytes? Отвечаю: потому что нафиг мне не упало в std такое счастье.