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

Не знаю, какие там optimizations у них get implicitly performed through compiler optimizations, но я тут наклепал на коленке vector с расширением через realloc и получил довольно существенный выигрыш на простом тесте: https://gist.github.com/loskutov/8c10e34845c71db5177947a0d15ec55f.

Понятно, что в реальном мире вряд ли кому-то нужны частые релокации, но тем не менее, STL оказался медленнее аналога, сваянного за несколько минут на коленке, что отчасти подтверждает утверждение о медленном STL.

что отчасти подтверждает утверждение о медленном STL.

Это подтверждает только (очевидную) мысль, что обобщённая реализация не может быть лучше во всех «особых случаях».

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

деточка, иди свои кулстори 1С никам рассказывай. В 2016 то году рассказывать про 03 стандарт...ну не знаю, давай еще вспомним времена, когда namespace не было и будем без них писать. Сейчас кто-то бросится на борланд с++ тесты компилировать.

И кстати. ссылку на STL, где было по другому в студию.

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

Знатный слив. молодца.

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

У тебя реально мозг отсутствует или просто сегодня тупишь?

В большинстве реализаций STL у std::vector тоже есть специализации для тривиально копируемых типов.

Понятно, что в реальном мире вряд ли кому-то нужны частые релокации, но тем не менее,

В реальном мире память кучи скорее всего будет сильно фрагментирована после некоторого времени работы и дешёвых realloc'ов будет значительно меньше на размерах до MMAP_THRESHOLD.

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

И что вы предлагаете?

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

А кто гарантирует? Или вы сегодня вместо КО?

Устал повторять, есть для этого resize и reserve.

а fstream как же?

А fstream крайне не удобен, когда дело касается кодировок. Под офтопиком - вдвойне (имена фалов - UTF-16)

Не у vector а у std::copy

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

если я верно понял это видео https://www.youtube.com/watch?v=nXaxk27zwlk (50я минута)
то push_back также быстр, как и reserve

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

Но это работает только с массивами заранее известной длины.

для regular files мультиплексирование не используют

А я не устал и повторюсь: понятно, что в реальном мире вряд ли кому-то нужны частые релокации.

Но как быть с неблокирующим чтением.

poll и read, естественно. Или, если ты автор драйвера и у тебя странные потребности, mmap вместо read.

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

конструкция asm volatile(«» : : «g»(p) : «memory») применялась для отключения оптимизации, она подходит и для gcc
тогда тесты становились корректны (оптимизация не вырезает лишнего)

то push_back также быстр, как и reserve

Поскольку он тоже делает reserve, но заранее зарезервировать нужное количество памяти будет разумнее.

А я не устал и повторюсь: понятно, что в реальном мире вряд ли кому-то нужны частые релокации.

Ну так если релокаций не будет, то vector по скорости тот же type[size].

Спасибо, капитан.

Спасибо, капитан.

Рад, что помог вам постичь азы.

Понятно, что в реальном мире вряд ли кому-то нужны частые релокации, но тем не менее, STL оказался медленнее аналога, сваянного за несколько минут на коленке, что отчасти подтверждает утверждение о медленном STL.

Если говорить о векторе, то в среднем каждый элемент вектора перемещается не более одного раза. Так что, наличие или отсутствие realloc особо не влияет на скорость вектора.

И как тут заметили, случается фрагментация. Это, вообще, бич для низкоуровневых языков, где нет хитроумного GC.

Во всяком случае, у realloc нет причин работать медленнее, чем malloc+memcpy, а быстрее он всё же иногда работает. В общем, ИМХО, довольно странным решением было не включать в аллокаторы аналог realloc.

Это, конечно, не значит, что скорость расширения вектора является перформанс-проблемой плюсов, но всё же.

Это не важно. Реалок не копирует память, даже если возвращает другой указатель.

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

Нельзя. Интерфейс не позволяет.

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

Это просто выделение памяти - это станет понятно, после того, как станет понятно отличается оператора new и ключевого слова new. Для понимания этого нужно воспользоваться гуглом.

Реалок не копирует память, даже если возвращает другой указатель.

Спору нет, реалок не копирует. Это ложится на плечи разработчика.

И это то же, но дело не в этом. Если реалок возвращает другой адрес - все данные находятся там же, где и находились - т.е. их не надо копировать.

Сколько же вам можно азы разжевывать. http://blog.httrack.com/blog/2014/04/05/a-story-of-realloc-and-laziness/

buffer = realloc(buffer, capa);

Отличные азы.

А дальше там говорят о частном случае glibc. Но там же говорят и об общем случае allocnew/copy/freeold.

Хорошо, когда вы можете полагаться на конкретную реализацию realloc на целевой платформе. Но утверждать, что она такая на всех платформа несколько опрометчиво.

Дядя, ты от жизни отстал лет так на 15. Единственный случай под линуксом, когда в какой-нибудь недо-libc уместно использовать явное копирование — embedded без MMU.

Дядя, ты от жизни отстал лет так на 15. Единственный случай под линуксом, когда в какой-нибудь недо-libc уместно использовать явное копирование — embedded без MMU.

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