Почему нет кучи для базовой ссылки?

Question

Из Страуструпа * Основы C ++ , он предлагает чистый объектно-ориентированный язык (на стр. 4).

class complex { double re, im; /* … */ };
complex a[ ] = { {1,2}, {3,4} };

Он предполагает a в чистом объектно-ориентированном языке выделяется в куче , а структура памяти a выглядит следующим образом:

вероятный размер 3 * sizeof (ссылка) + 3 * sizeof (heap_overhead) + 4 * sizeof (double) .Предполагая, что ссылка - это одно слово, а объем кучи - два слова, мы получаем вероятный размер в 19 слов для сравнения с 8 словами в C ++.Эти накладные расходы памяти связаны с накладными расходами во время выполнения от выделения и косвенного доступа к элементам.Этот косвенный доступ к памяти обычно вызывает проблемы с использованием кэша и ограничивает возможности использования ПЗУ.

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

Я полагаю, что это явление общее, а не заданное для языка примеров на чистом ОО.

Но я не могу найти никакой ссылки (я признаю, что это не дружественный для поисковых систем вопрос).

Обновление

Спасибо за ваши ответы.Однако я забыл опубликовать свое первоначальное предположение.( Извините, это моя ошибка. )

На самом деле, я также подумал, что само по себе a может быть размещено в стеке или где-то еще, у него самих кучи не будет.Но позже я заметил, что BS также говорит:

Сравните это с более типичным макетом из «чисто объектно-ориентированного языка», где each user-defined object is allocated separately on the heap и доступ через ссылку...

на стр. 4.

Итак, я думаю, что он ограничил реализацию только кучей (или стеком).

(Ofконечно, возможно я читаю слишком много в этом предложении.)

Answer 1

complex a[ ] = { {1,2}, {3,4} };

Давайте разберемся с этим - подход снизу вверх.

1. У вас есть два complex объекта, которые инициализированы списком : Complex{1,2} и Complex{3,4}.

Complex {double, double}

Каждый объект complex имеет адрес кучи (белый) и пространство, занимаемое (синим) объектомdouble значения.

Далее следует внешняя скобка {, которая должна инициализировать список и array из Complex объектов.

array {Complex1, Complex2}

У него есть адрес объекта array (белый) и две ссылки (синие) на два Complex объекта.

Наконец, для complex a нет накладных расходов, поскольку это просто локальная переменная, которая находится в стеке.

Answer 2

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

На самом деле, я также подумал, потому что a можетраспределяться по стеку или как-либо еще, поэтому сам по себе не будет иметь кучи служебных данных.Но позже я заметил, что BS также говорит:

Сравните это с более типичным макетом из «чисто объектно-ориентированного языка», где each user-defined object is allocated separately on the heap и доступ через ссылку...

на стр. 4.

Итак, я думаю, что он ограничил реализацию только кучей (или стеком).

(OfКонечно, может быть, я слишком много читаю в этом предложении)

Я думаю, что вы слишком много в него читаете.Реальные языки, на которые ссылается Stroustroup (например, Python, Java или C # - если мы ограничиваемся коробочными типами), имеют «обычный» стек, содержащий простой массив ссылок.

Answer 3

Ссылка верхнего уровня живет везде, где живет.Вот несколько вариантов:

1. Он может жить в стеке.a в коде можно представить следующим образом.
2. Он встроен в существующий объект.
3. Память выделяется только для удержания ручки.В этом случае он будет иметь дополнительную нагрузку на память.
4. Он живет как глобальная сущность.
5. Ссылка может находиться в регистре.a в коде также можно представить так, как будто в этом случае он не имеет ни служебной памяти, ни служебной памяти: вместо этого он «только» требует использования регистра.

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

Другие объекты являются объектами:

• Класс complex используется для создания объекта, который фактически внедряетк нечетным double «объектам», которые также являются значениями, а не фактическими объектами.
• a - это объект массива в этой модели, ссылающийся на два complex объекта.

Answer 4

Вы получаете кучу накладных расходов, когда сохраняете что-то в куче.Два значения complex хранятся в куче, поэтому они получают служебные данные.Массив ссылок также хранится в куче, поэтому он получает служебные данные.

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