вектор stl против массива

Question

Как указано в ответе на мой вопрос , я буду использовать векторы только для изменения размера до N, чтения и записи n-го элемента, где n

PS Изменение размера и копирование блоков будет необходимо редко.

РЕДАКТИРОВАТЬ: Как требовал Дэвид Родригес - dribeas, это программа технического анализа.Исторические цены на акции хранятся в виде баров OHLC в векторах.Поэтому мне действительно нужно хранить элементы в векторах.Также есть некоторые другие классы калькуляции, называемые индикаторами, которые делают вычисления, основанные на ценах акций.Когда через tcp поступила новая цена, вначале акция обновляет свои бары и немедленно вызывает все методы расчета связанных индикаторов, говоря: «Хорошо, ребята, мой n-й бар был обновлен в это особое время. Идите сами».Все операции основаны на задачах, то есть акция никогда не обновляет себя до завершения последнего обновления, и аналогичным образом индикатор никогда не выполняет вычисления, пока идет последняя.Одна задача за раз.И если новые обновления продолжают поступать слишком быстро, их можно кэшировать как задачи.Таким образом, акция может дождаться окончания своего последнего обновления, и индикатор может аналогичным образом сохранять свои задачи, пока он рассчитан, НО акция не должна ждать окончания работы своих индикаторов.Вот где начинается проблема.Если приходит обновление, запас сначала просматривает размер вектора бара и проверяет, нужно ли изменить его размер.При необходимости он изменяет размеры своих векторов, в то время как некоторые предыдущие индикаторы могут работать до предыдущего обновления.Индикатор может достичь своих данных о запасах, поскольку данные могут быть изменены.До сих пор у меня не было никаких проблем, потому что вычисления индикатора были сделаны очень очень быстро.Но я обеспокоен.В качестве решения акция может сгенерировать второй больший вектор бара и сообщить своим индикаторам, что они могут достичь второго вектора для будущих расчетов.В конце концов, через пару секунд весь доступ к первому вектору пропадает, и его можно аккуратно удалить.

Answer 1

Похоже, что структура, которую вы действительно хотите, это std::deque, которая может быть добавлена ​​в амортизированном постоянном времени.

На самом деле, стратегия изменения размера - это та, которая уже используется std::vector.Фактически, точная стратегия, которую он использует, означает, что эта операция по существу является O (1), но только с точки зрения множества добавлений в течение длительного периода времени.Во всяком случае, кажется, нет никаких причин, чтобы изобретать колесо на этом.просто используйте std::vector.push_back() или std::queue.push_back()

Answer 2

1. Почему вы просто не изменили размеры существующих вектор?
2. Если вы не можете изменить размер существующего вектора, тогда вы можете использовать массив для него. Я не вижу никаких плюсов для использования std:vector в этом случае, для копирования вы можете использовать memcopy
3. Вы можете использовать массив и изменить его размер с помощью realloc.

Answer 3

Я бы сказал, что в вашем случае, в худшем случае, вектор будет не лучше, чем динамически размещенный необработанный массив.Возможно, это будет удобнее.

Что касается вашей дилеммы, это звучит как нечто, что было бы намного проще с неявным управлением памятью.Вы можете хранить свои входящие данные в общих указателях.Затем индикаторы получают общий указатель на данные, которые им нужны, когда они начинают вычислять.Если поступают новые данные, которые требуют признания недействительными старых данных, просто замените общий указатель на складе, содержащем старые данные, на общий указатель, содержащий новые данные.Любой индикатор, все еще использующий старые данные, может продолжать использовать его, потому что у него все еще есть общий указатель на старые данные (предотвращающий очистку старых данных), и старые данные будут очищены, когда все индикаторы, использующие данные, завершатсбросить их общие указатели.

Answer 4

Я прочитал оригинальный вопрос и думаю, что, возможно, стоило бы справиться с многопоточностью, чтобы у вас была гарантия, что ни одна нить не получит доступ к контейнеру при его расширении.

По конкретному рассматриваемому вопросу, если нет веской причины не делать этого, я бы всегда использовал std::vector для массива, если бы ни по какой другой причине только потому, что многие операции уже выполненывам не нужно вручную управлять памятью.

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