Указатели и контейнеры

Расположение упаковки и байт, как описано в C FAQ здесь :

Это для выравнивания. Многие процессоры не могут получить доступ к 2- и 4-байтным количествам (например, ints и long ints), если они переполнены каждым способом.

Предположим, что у вас есть эта структура:

struct {
    char a[3];
    short int b;
    long int c;
    char d[3];
};

Теперь вы можете подумать, что это возможно, чтобы упаковать эту структуру в память следующим образом:

+-------+-------+-------+-------+
|           a           |   b   |
+-------+-------+-------+-------+
|   b   |           c           |
+-------+-------+-------+-------+
|   c   |           d           |
+-------+-------+-------+-------+

Но на процессоре намного проще, если компилятор упорядочивает его как это:

+-------+-------+-------+
|           a           |
+-------+-------+-------+
|       b       |
+-------+-------+-------+-------+
|               c               |
+-------+-------+-------+-------+
|           d           |
+-------+-------+-------+

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

+-------+-------+-------+-------+
|           a           | pad1  |
+-------+-------+-------+-------+
|       b       |     pad2      |
+-------+-------+-------+-------+
|               c               |
+-------+-------+-------+-------+
|           d           | pad3  |
+-------+-------+-------+-------+
blockquote>

11
задан Martin York 22 September 2008 в 16:44
поделиться

3 ответа

Контейнеры указателя повышения имеют строгое владение по ресурсам, которые они содержат. Станд.:: вектор <повышение:: shared_ptr <X>> совместно использовал владение. Существуют причины, почему это может быть необходимо, но в случае, если это не, я принял бы значение по умолчанию для повышения:: ptr_vector <X>. YMMV.

13
ответ дан 3 December 2019 в 06:49
поделиться

Устойчивый на: интеллектуальные указатели являются очень хорошим методом обработки управления ресурсами, но не единственного. Я соглашаюсь, что Вы будете видеть очень немного необработанных указателей в правильно написанном коде C++, но по моему опыту Вы не видите что много интеллектуальных указателей также. Существует много совершенно безопасных от исключения классов, реализованных с помощью контейнеров необработанных указателей.

3
ответ дан 3 December 2019 в 06:49
поделиться

Ну, наверху один случай.

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

Требует, чтобы профилирование гарантировало, что контейнерные операции являются узким местом хотя :)

2
ответ дан 3 December 2019 в 06:49
поделиться
Другие вопросы по тегам:

Похожие вопросы: