А как в c++ файл прочитать

А какая ОС поддерживает адекватный неблокирующий IO для файлов?

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

Единственное, что я вижу, так это напрямую использовать open(mydevice, RD_ONLY | O_NONBLOCK)

Будто что-то плохое

Больше c++ way вариантов нет?

asio?

Или правильный путь это вариации select/poll + блокирующее чтение?

Так ведь select/poll нужен и для неблокирующего, разве нет?

Именно С++-way нет. Но можно посмотреть asio или порты libev/libevent для C++.

Но они все основаны как раз на poll / select / платформозависимых аналогах.

Так в stdc++ нету file io. Поэтому или дергать C или ждать C++17 с filesystem. Хотя сомневаюсь, что там будет что-то толковое.

а fstream как же?

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

Сам не пользовался. FILE и QFile достаточно. Но читал о нём только плохое. Ибо тормозит, как и весь std.

в 11-х плюсах std вполне себе годен.

красивый бенчмарк

там афтар просто упорот. читает файл с флагом «rb» в строку, причём типа string. дальше даже читать неохота.

А какая ОС поддерживает адекватный неблокирующий IO для файлов?

Windows? Да и в Mac OS X вроде добавили асинхронный ввод-вывод POSIX.

читает файл с флагом «rb» в строку, причём типа string. дальше даже читать неохота.

иии?

Поддержу анонима тут..

Ибо тормозит, как и весь std.

И как же тормозит, скажем, std::vector? Или std::sort. Или ещё лучше - какой-нибудь std::is_integral.

Ибо тормозит, как и весь std.

А в чем заключаются тормоза std::vector<> к примеру?

std::vector<> к примеру

Отсутствие реаллок?

https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md#object-r...

На моих задачах QVector работал быстрее. В детали не вникал.

https://www.reddit.com/r/programming/comments/2ezy59/facebooks_stdvector_opti...

This article authoritatively declares that using 2 is one of the worst possible factors, however, no one is able to reproduce their findings. The GCC and Clang team have extensively benchmarked many alternative constant factors and have found that, in fact, using 1.5 is slower than using 2.

This issue can be found here:

https://gcc.gnu.org/ml/libstdc /2013-03/msg00058.html

Facebook's submission is lacking any actual benchmarks or anything that we can use to justify their position objectively other than just claims that their implementation is noticeably faster. From people who have benchmarked it, it's sometimes faster for some stuff, sometimes slower for other stuff, and mostly it's just the same. Much of the optimizations that they explicitly perform in their implementation get implicitly performed by std::vector through compiler optimizations and the use of intrinsics.

Отсутствие реаллок?

Что отсутствие realloc? Или анонимус не знает про resize() и reserve()?

https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md#object-r...

А resize() и realloc() вам ничего не говорят?

This article authoritatively declares that using 2 is one of the worst possible factors, however, no one is able to reproduce their findings. The GCC and Clang team have extensively benchmarked many alternative constant factors and have found that, in fact, using 1.5 is slower than using 2.

Вообще мимо. Ты бы хоть посмотрел, на какую именно часть я сослался. Там о том, что из-за того, что «C++ values [...] are all conservatively considered non- relocatable», std::vector делает не realloc и даже не new + memcpy + delete, а копирование/перемещение плюсовых объектов. В C++ вообще не завезли аналога realloc для памяти, выделенной new.

На моих задачах QVector работал быстрее.

Без конкретного примера этот ответ ни о чем.

В детали не вникал.

Это многое объясняет.

Вот это позор.

http://www.cplusplus.com/reference/cstdlib/realloc/

А как часто в Си realloc() возвращает тот же указатель, что переданный ему?

http://www.cplusplus.com/reference/cstdlib/realloc/

Зачем вы мне это написали?

http://en.cppreference.com/w/c/memory/realloc

The reallocation is done by either: a) expanding or contracting the existing area pointed to by ptr, if possible. The contents of the area remain unchanged up to the lesser of the new and old sizes. If the area is expanded, the contents of the new part of the array are undefined. b) allocating a new memory block of size new_size bytes, copying memory area with size equal the lesser of the new and the old sizes, and freeing the old block.

Я так понимаю, что если повезёт, то попадёшь в (a). Нет, так в (b) и будет тоже самое, что и вектор делает.

в Си

в Си

в Си

Это зависит от аллокатора, очевидно же.

Это зависит от аллокатора, очевидно же.

По делу вы скажете хоть что-либо?

Потому что «вы» спросили «Что отсутствие realloc?». Я подумал, что вы не знаете, что есть такая сишная функция и подумали, что он думает, что std::vector не может изменять размер. Вот.

Я так понимаю, что если повезёт, то попадёшь в (a).

Ты правильно понимаешь.

Нет, так в (b) и будет тоже самое, что и вектор делает.

Не уверен. Если компилятор очень умный и развернёт это в вызов memcpy — да.

Что тут ещё сказать-то? Ну замерь.

ы бы хоть посмотрел, на какую именно часть я сослался. Там о том, что из-за того, что «C++ values [...] are all conservatively considered non- relocatable», std::vector делает не realloc и даже не new + memcpy + delete, а копирование/перемещение плюсовых объектов. В C++ вообще не завезли аналога realloc для памяти, выделенной new.

Это чушь, реализации STL используют memmove и memcpy для std::is_trivially_copyable объектов. Вектор должно быть не может использовать realloc из-за отсутствия такого метода в концепте плюсового аллокатора. Хотя при особом желании можно сделать realloc хотя бы для дефолтного аллокатора.

Я подумал, что вы не знаете, что есть такая сишная функция и подумали, что он думает, что std::vector не может изменять размер.

Речь шла о якобы медленном vector из stl.

vector v;
for(i : range)
{
  v.push_back(i);
}

vector v;
v.reserve(range);
for(i : range)
{
  v.push_back(i);
}

vector v;
v.resize(range);
for(i : range)
{
  v[i] = i;
}

Очевидно, что первый способ будет далеко не самый быстрый.

Что тут ещё сказать-то?

Скажите что-либо по делу.

Ну замерь.

Что вы предлагаете мне измерить?

Что вы предлагаете мне измерить?

Измерь член, покажи замеры анонимусу, пусть завидует/незавидует

Что вы предлагаете мне измерить?

Как часто в Си realloc() возвращает тот же указатель, что переданный ему, очевидно же.

QVector

А там реаллок есть, кстати.

А как часто в Си realloc() возвращает тот же указатель, что переданный ему?

Часто. В крестах реаллок не используется потому что объект может хранить ссылки на себя, например. И это ок, но с массивами чисел, например, или простых структур с несколькими полями и без указателей лучше использовать реаллок.

Как часто в Си realloc() возвращает тот же указатель, что переданный ему, очевидно же.

Это будет зависеть от хардварной конфигурации, ОС и ее настройки, характера использования памяти приложением.

Часто.

Отличный пруф. Так держать.

В крестах реаллок не используется потому что объект может хранить ссылки на себя, например.

И?

И это ок, но с массивами чисел, например, или простых структур с несколькими полями

Вы о POD?

и без указателей лучше использовать реаллок.

Такое ощущение, что вы не понимаете, о чем говорите.

1. до С++11 буфер string не был декларирован, как обязательно непрерывный
2. зачем использовать лишние сущности, которые не вносят никакого смысла, для обычного динамического выделения памяти?
3. зачем передавать через стек огромный объект, который при выходе из функции (вместе с содержимым файла) будет честно копироваться?
а потом эти люди какие-то бенчмарки пишут.

Это будет зависеть от хардварной конфигурации, ОС и ее настройки, характера использования памяти приложением.

Зачем тогда ты у меня это спросил?

1. до С++11 буфер string не был декларирован, как обязательно непрерывный

шел 2016 год. ок. Кстати название реализации STL, где было иначе ДО 11 стандарта в студию.

2. зачем использовать лишние сущности, которые не вносят никакого смысла, для обычного динамического выделения памяти?

проще и нагляднее.

3. зачем передавать через стек огромный объект, который при выходе из функции (вместе с содержимым файла) будет честно копироваться?

это к 1 вопросу и move-семантики. Кстати даже ДО move семантики объект копировался бы только в дебажных сборках.

И

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

Вы о POD

В том числе, но ссылку на себя может хранить и простая структура, так что POD не гарантирует, что можно использовать memmove.

Нормально работает.

Первая же ссылка: https://stackoverflow.com/questions/12997131/stdfstream-buffering-vs-manual-b...

В C++ вообще не завезли аналога realloc для памяти, выделенной new.

зачем же так радикально? в плюсовых контейнерах есть аллокаторы. переписываешь аллокатор - и всё. естессна, аллокатор должен знать всё о специфике объекта.

вообще, new для не-POD объектов - не просто выделение памяти, я ещё и вызов конструктора. так что сравнивать его с аллокацией в С нельзя. но перегружать его никто не запрещал.

шел 2016 год. ок. Кстати название реализации STL, где было иначе ДО 11 стандарта в студию.

детка, стандарт есть стандарт. несмотря на годы и реализации. если ты пишешь про С++ вообще, то надо понимать, где границы.

проще и нагляднее

основы динамической работы с памятью для самых маленьких: http://www.cplusplus.com/reference/cstdlib/malloc

это к 1 вопросу и move-семантики. Кстати даже ДО move семантики объект копировался бы только в дебажных сборках.

да ну? ну и зачем было тогда внеднять move, интересно? сидели себе дядьки в комитете, от скуки фигнёй страдали. и как-то не сразу эту семантику всем компиляторам удалось внедрить, надо заметить.