N
В плюсах гцц ещё индексы не научился отдавать наружу?
Size: a a a
2020 September 30
SE
есть простой способ заставить BOOST_ASSERT печатать стектрейс перед вызовом terminate?
AS
в частности в чате @pro_prog
AS
AT
реально ли сделать кастомный аллокатор для
std::vector, который бы использовал преимущества возможности работы с витруальной памятью как здесь (речь про аналогичный механизм, предположительно доступный на CPU, конечно)?OZ
реально ли сделать кастомный аллокатор для
std::vector, который бы использовал преимущества возможности работы с витруальной памятью как здесь (речь про аналогичный механизм, предположительно доступный на CPU, конечно)?я не читал до конца, но есть такая вещь как pinned memory, там можно реализовать двухстороннее общение которое будет выглядеть нормально, но со стороны хоста чтение будет медленное. Кажется называется mirrored memory или что то такое
AT
то, что в
std::vector гвоздями прибито и не отдано на откуп аллокатору — это стратегия роста (типа удвоения или x1.5 при достижении capacity) — ведь это будет мешать правильному использованию такой фичи?V
реально ли сделать кастомный аллокатор для
std::vector, который бы использовал преимущества возможности работы с витруальной памятью как здесь (речь про аналогичный механизм, предположительно доступный на CPU, конечно)?Вы хотите изобрести device_vector?
https://docs.nvidia.com/cuda/thrust/index.html
https://docs.nvidia.com/cuda/thrust/index.html
AT
я не читал до конца, но есть такая вещь как pinned memory, там можно реализовать двухстороннее общение которое будет выглядеть нормально, но со стороны хоста чтение будет медленное. Кажется называется mirrored memory или что то такое
речь про то, что можно сделать так, чтобы вектор рос вообще без перемещений и перекопирований содержимого в моменты реаллокации
I
то, что в
std::vector гвоздями прибито и не отдано на откуп аллокатору — это стратегия роста (типа удвоения или x1.5 при достижении capacity) — ведь это будет мешать правильному использованию такой фичи?Ну, у тебюя будет запрос размера памяти идти же, а какую отдавать и сколько - это тебе решать.
AT
речь про то, что можно сделать так, чтобы вектор рос вообще без перемещений и перекопирований содержимого в моменты реаллокации
не про это речь
OZ
речь про то, что можно сделать так, чтобы вектор рос вообще без перемещений и перекопирований содержимого в моменты реаллокации
я точно не помню, но сам аллокатор решает уничтожить или нет. Не обязательно уничтожать объект если произошло увеличение буфера. Ща поищу более точную инфу
AT
Ну, у тебюя будет запрос размера памяти идти же, а какую отдавать и сколько - это тебе решать.
нет. Я не могу отдать меньше, чем запросили
V
речь про то, что можно сделать так, чтобы вектор рос вообще без перемещений и перекопирований содержимого в моменты реаллокации
Идея хороша но только для очень больших векторов. А для них можно и reserve позвать, а если много удалений, то отказаться от вектора и использовать list
OZ
я точно не помню, но сам аллокатор решает уничтожить или нет. Не обязательно уничтожать объект если произошло увеличение буфера. Ща поищу более точную инфу
в третьей таблице в самом низу: https://en.cppreference.com/w/cpp/named_req/Allocator . Насколько я понял можно схитрить. Но вопрос в том как отличить расширение от вызова деструктора самого вектора ...
AT
Идея хороша но только для очень больших векторов. А для них можно и reserve позвать, а если много удалений, то отказаться от вектора и использовать list
тогда уж deque