Чому я вважаю за краще використовувати вектор замість deque

Оскільки

1. вони обидва є суміжними контейнерами пам'яті;
2. особливо мудро, деке має майже все, що має вектор, але більше, оскільки його ефективніше вставляти спереду.

Чому хтось вважає std::vectorза краще std::deque?

Елементи в dequeє НЕ суміжними в пам'яті; vectorелементи гарантовано будуть. Отже, якщо вам потрібно взаємодіяти з простою бібліотекою C, яка потребує суміжних масивів, або якщо ви (багато) дбаєте про просторову місцевість, то, можливо, ви віддасте перевагу vector. Крім того, оскільки існує додаткове ведення бухгалтерії, інші операційні послуги, ймовірно, (трохи) дорожчі, ніж їх еквівалентні vectorоперації. З іншого боку, використання багатьох / великих екземплярів vectorможе призвести до непотрібної фрагментації купи (уповільнення викликів до new).

Крім того, як зазначалося в інших місцях на StackOverflow , тут є більше обговорень: http://www.gotw.ca/gotw/054.htm .

Щоб знати різницю, слід знати, як dequeце взагалі реалізується. Пам'ять виділяється в блоки однакових розмірів, і вони зв'язані між собою (як масив або, можливо, вектор).

Отже, щоб знайти n-й елемент, ви знайдете відповідний блок, а потім отримаєте доступ до елемента всередині нього. Це постійний час, оскільки це завжди рівно 2 пошуки, але це все одно більше, ніж вектор.

vectorтакож добре працює з API, які хочуть суміжний буфер, оскільки вони є або API C, або є більш універсальними, оскільки можуть приймати покажчик і довжину. (Таким чином, ви можете мати вектор знизу або звичайний масив і викликати API з вашого блоку пам'яті).

Де dequeє його найбільші переваги:

1. При вирощуванні або скороченні колекції з обох кінців
2. Коли ви маєте справу з дуже великими розмірами колекції.
3. Коли ви маєте справу з булами, вам дуже потрібні були, а не бітсет.

Другий з них менш відомий, але для дуже великих розмірів колекції:

1. Вартість перерозподілу велика
2. Накладні витрати на пошук суміжного блоку пам'яті є обмежувальними, тому ви можете швидше закінчити пам’ять.

Коли я мав справу з великими колекціями в минулому і переходив від суміжної моделі до блочної, ми змогли зберігати приблизно в 5 разів більшу колекцію, перш ніж у нас закінчилася пам'ять у 32-бітовій системі. Це частково тому, що при перерозподілі йому фактично потрібно було зберегти як старий, так і новий блок, перш ніж копіювати елементи.

Сказавши все це, ви можете зіткнутися з проблемами std::dequeв системах, які використовують "оптимістичний" розподіл пам'яті. Хоча спроби запитати великий розмір буфера для перерозподілу vectorзаповіту в певний момент отримають відмову з a bad_alloc, оптимістичний характер розподільника, швидше за все, завжди задовольняє запит на менший буфер, запитуваний a, dequeщо, ймовірно, може спричинити операційна система, щоб убити процес, щоб спробувати отримати трохи пам'яті. Який би з них він не вибрав, може бути не надто приємним.

Вирішення проблем у такому випадку - це встановлення прапорів системного рівня, щоб замінити оптимістичне розподіл (не завжди можливо), або управління пам’яттю дещо ручніше, наприклад, за допомогою власного розподільника, який перевіряє використання пам’яті тощо. Очевидно, не ідеально. (Що може відповісти на ваше запитання щодо переваги вектору ...)

Я реалізовував як вектор, так і deque кілька разів. deque набагато складніший з точки зору реалізації. Це ускладнення перетворюється на більше коду та більш складний код. Отже, ви зазвичай бачите розмір коду, коли ви вибираєте deque замість вектора. Ви також можете відчути невелику швидкість удару, якщо ваш код використовує лише те, у чому перевершує вектор (тобто push_back).

Якщо вам потрібна черга з подвійним кінцем, deque є безперечним переможцем. Але якщо ви робите більшість своїх вставок і стирань ззаду, вектор буде безперечним переможцем. Коли ви не впевнені, оголосіть свій контейнер typedef (щоб його було легко перемикати вперед-назад) і виміряйте.

std::dequeне має гарантованої безперервної пам’яті - і це часто дещо повільніше для індексованого доступу. Деке зазвичай реалізується як "список вектора".

Відповідно до http://www.cplusplus.com/reference/stl/deque/ , "на відміну від векторів, декам не гарантовано мати всі його елементи в сусідніх місцях зберігання, усуваючи таким чином можливість безпечного доступу через арифметику покажчиків".

Декети дещо складніші, частково тому, що вони не обов'язково мають суміжний макет пам'яті. Якщо вам потрібна ця функція, не слід використовувати деке.

(Раніше моя відповідь спричинила відсутність стандартизації (з того самого джерела, що і вище, "деко можуть бути реалізовані конкретними бібліотеками по-різному"), але це насправді стосується майже будь-якого стандартного типу даних бібліотеки.)

Deque - це контейнер послідовностей, який дозволяє довільний доступ до його елементів, але не гарантовано мати суміжне сховище.

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

Я віддав би перевагу, std::dequeніж std::vectorу більшості випадків.

Ви не віддаєте перевагу вектору, аніж декому відповідно до цих результатів тесту (із джерелом).

Звичайно, ви повинні протестувати у своєму додатку / середовищі, але коротко:

• push_back в основному однаковий для всіх
• вставка, стирання в deque набагато швидше, ніж список, і незначно швидше, ніж вектор

Ще трохи роздумів та примітка, яку слід розглянути circular_buffer.

З одного боку, вектор досить часто просто швидший, ніж deque. Якщо вам насправді не потрібні всі функції deque, використовуйте вектор.

З іншого боку, іноді ви робите функції потрібно , який вектор не дає вам, в цьому випадку ви повинні використовувати Deque. Наприклад, я кидаю виклик кожному, хто намагається переписати цей код , не використовуючи деке і не змінюючи алгоритму.

Зверніть увагу, що векторна пам’ять перерозподіляється в міру зростання масиву. Якщо у вас є вказівники на векторні елементи, вони стануть недійсними.

Крім того, якщо стерти елемент, ітератори стають недійсними (але не "для (авто ...)").

Редагувати: змінено "deque" на "vector"