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

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

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

Готового нету, но можно написать самому (исправлено

Автор: Voivoid
Дата: 02.01 16:58

):

#include <fstream>
#include <vector>
#include <string>
#include <cstdint>
#include <algorithm>

std::vector<uint8_t> read_all_bytes(const std::string& path)
{
   std::basic_ifstream<uint8_t> input(path, std::ios_base::binary);
   return { std::istreambuf_iterator<uint8_t>(input), {} };
}

void save_all_bytes(const std::vector<uint8_t>& bytes, const std::string& path)
{
   std::basic_ofstream<uint8_t> output(path.c_str(), std::ios_base::binary);
   std::copy(bytes.begin(), bytes.end(), std::ostreambuf_iterator<uint8_t>(output));
}

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

я бы ещё вызвал

bytes.reserve(std::filesystem::file_size(path));

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

SP>я бы ещё вызвал

SP>

SP>bytes.reserve(std::filesystem::file_size(path));
SP>

Да, поддерживаю. Я сознательно не использовал std::filesystem, чтоб не создавать зависимость от стандарта языка.

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

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

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

R>Готового нету, но можно написать самому:

R> std::copy(
R> std::istreambuf_iterator<uint8_t>(input),
R> std::istreambuf_iterator<uint8_t>(),
R> std::back_inserter(bytes)
R> );

Да можно ж и без copy

std::vector<uint8_t> bytes( std::istreambuf_iterator<uint8_t>(input), std::istreambuf_iterator<uint8_t>() );

Или если предварительно делать reserve, то какой-нибудь assign например можно заюзать:

bytes.assign(std::istreambuf_iterator<uint8_t>(input), td::istreambuf_iterator<uint8_t>())

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

V>Да можно ж и без copy

std::vector<uint8_t> bytes( std::istreambuf_iterator<uint8_t>(input), std::istreambuf_iterator<uint8_t>() );

А, блин, точно. Че-то тупанул я. Исправил

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

.

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

std::string read_whole_file( const std::string& fname )
{
    std::fstream f( fname, std::ios_base::in );
    std::stringstream ss;
    ss << f.rdbuf();
    return ss.str();
}

Почитал ответы, задумался. А чем, простите, занимался комитет все эти 20 лет?

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

K>Почитал ответы, задумался. А чем, простите, занимался комитет все эти 20 лет?

Прямо по твоему вопросу: https://youtu.be/g2iyNH2Gh1k?t=244 (3 минуты видео)

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

K>Почитал ответы, задумался. А чем, простите, занимался комитет все эти 20 лет?

О, C++ развивается в эту сторону: потоки, filesystem — вот этого всего очень не хватало.
Чтение файла целиком в память — если это самая большая проблема стандартной библиотеки, то язык, считай, идеален. Я не говорю, что эта штука не нужна (особенно для кода на коленке), но проблем с ней в продакшене будет ещё больше, чем с текущей реализацией. Всё равно придется проверять предварительно размер файла, стоит ли целиком выделять под него память, потом проверять, смогли ли мы её выделить и т.д. обработка ошибок на много строчек.

P.S. Чего бы я хотел с большим удовольствием, так это работу с memory mapped files. Сейчас прямо не знаю на счёт кроссплатформенный решений, но раньше приходилось как следует закапываться в тот же WinAPI.

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

N>...
N>P.S. Чего бы я хотел с большим удовольствием, так это работу с memory mapped files. Сейчас прямо не знаю на счёт кроссплатформенный решений, но раньше приходилось как следует закапываться в тот же WinAPI.

Откройте для себя буст. Там много интересного есть. И многие вещи со временем переезжают в стандарт.

с std::regexp чет у них так и не получилось высокая производительность
причем во всех имплементациях
были еще примеры, забыл

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

R>с std::regexp чет у них так и не получилось высокая производительность

Ну, они старались

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

R>с std::regexp чет у них так и не получилось высокая производительность
R>причем во всех имплементациях

Да, даже у экспертов иногда лажа получается. Слава богу есть альтернативные реализации.

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

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

K>>Почитал ответы, задумался. А чем, простите, занимался комитет все эти 20 лет?

AD>Прямо по твоему вопросу: https://youtu.be/g2iyNH2Gh1k?t=244 (3 минуты видео)

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

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

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

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

K>Почитал ответы, задумался. А чем, простите, занимался комитет все эти 20 лет?

Вы не о том думаете. Подумайте лучше, что придёт школьник-проказник и подсунет вам вместо вашего маленького файла конфигурации, который вы читаете в ReadAllBytes(), тот же самый файл добавив в начало >4294967298 пробелов. Как долго ваша функция будет читать такой файл и как именно вы обрабатываете исключение по нехватки памяти? А что если кто-то использует эту функцию на серверном приложении?
Вы всё ещё уверены, что такая функция имеет право на добавление в стандарт?

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

BFE>Вы не о том думаете. Подумайте лучше, что придёт школьник-проказник и подсунет вам вместо вашего маленького файла конфигурации, который вы читаете в ReadAllBytes(), тот же самый файл добавив в начало >4294967298 пробелов.

Мне сомнительно, что ReadAllBytes будет использоваться для чтения текстовых файлов, для этого в .NET есть более подходящий метод — ReadAllText(). Вряд ли какой-нибудь проказник станет вручную править бинарный файл.

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

BFE>>Вы не о том думаете. Подумайте лучше, что придёт школьник-проказник и подсунет вам вместо вашего маленького файла конфигурации, который вы читаете в ReadAllBytes(), тот же самый файл добавив в начало >4294967298 пробелов.
R>Мне сомнительно, что ReadAllBytes будет использоваться для чтения текстовых файлов, для этого в .NET есть более подходящий метод — ReadAllText().
Для Json файлов это обычное дело.

R>Вряд ли какой-нибудь проказник станет вручную править бинарный файл.
Зачем вручную?

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

BFE> K>Почитал ответы, задумался. А чем, простите, занимался комитет все эти 20 лет?
BFE> Вы не о том думаете. Подумайте лучше, что придёт школьник-проказник и подсунет вам вместо вашего маленького файла конфигурации, который вы читаете в ReadAllBytes(), тот же самый файл добавив в начало >4294967298 пробелов. Как долго ваша функция будет читать такой файл и как именно вы обрабатываете исключение по нехватки памяти? А что если кто-то использует эту функцию на серверном приложении?
BFE> Вы всё ещё уверены, что такая функция имеет право на добавление в стандарт?
А чем, простите, занимался комитет все эти 20 лет? Надёжную обработку ошибок так и не сделали.