Сколько выделяется памяти под массив в C++?

Question

[DVoropaev]

Если я напишу так:

unsigned int a[] = {1, 2, 4, 8, 16, 32, 64, 128, 512, 256};

то сколько выделится памяти под массив? Зависит от компилятора?
Я предполагаю, что выделится ровно столько, сколько элементов перечислено в списке (т. е. sizeof(тип) * количество элементов в списке).

Answer 1

[Максим Мосейчук]

Я предполагаю, что выделится ровно столько, сколько элементов перечислено в списке

Совершенно верно за одним исключением. Памяти может выделятся чуть больше из-за выравнивания. Доступ к памяти по выровненным адресам намного быстрее происходит, из-за чего эффективнее например выделить дополнительный байт в начале (что бы адрес массива стал кратным 2/4/8/16 (смотря какое выравнивание в архитектуре используется).

Comments

[DVoropaev]

а можно ли как-то узнать, сколько байтов выделяется дополнительно?

[Максим Мосейчук]

dableproger: с ходу не скажу, но почитать вам это стоит https://ru.stackoverflow.com/questions/435726/%D0%...

[Максим Мосейчук]

dableproger: возможно попробовать перед массивом объявить переменную и вычислить разность адреса массива и адреса переменной и ещё отнять размер переменной. Получите размер неиспользуемого места перед массивом.

Вот только я не уверен, гарантирует ли компилятор определённый порядок переменных. В структурах гарантирует точно.

[SolidMinus]

fshp: гарантирует. В обеих случаях. И на стеке и на куче.

Вот только в случае со стеком - они будут в обратном порядке. Стек растет в сторону уменьшения адресов, то есть более "поздняя" переменная выделится в стеке "выше", т.е по адресам она будет раньше.

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

[Максим Мосейчук]

SolidMinus: на куче точно не гарантирует, т.к. память может быть фрагментирована. И если первое выделение не помещается в первый фрагмент, а второе помещается - то адреса будут в обратном порядке.

А со стеком верное замечание, да.

[SolidMinus]

fshp: хм, про фрагментацию забыл. Вы правы.

[MiiNiPaa]

SolidMinus: При оптимизации ничего не гарантируется вообще. Может поменять местами переменные: coliru.stacked-crooked.com/a/e15e0295e1036c37

Может удалить переменные: coliru.stacked-crooked.com/a/c4dfbedceede9f71 , https://godbolt.org/g/ihDLZD

Пытаться гадать о внутреннем строении компилятора по адресам локальных переменных менее эффективно, чем делать то же на кофейной гуще.

[SolidMinus]

MiiNiPaa: переменные на которые есть reference в коде удалить он не может, он может их оптимизировать в использование регистрами, в примере он их удалил потому что дабл нигде не используется, але)))

Но если в коде будет оператор & перед именем переменной - в регистр он ее не запихнет, т.к у регистров нет адреса в памяти.

Изменение порядка такое связано с тем, что double занимает памяти больше чем int, поэтому сначала пушится инт, потом дабл. Имелось ввиду переменные одного типа.

Ты лучше не адреса выводи через принтф, а дизассемблируй мейн функцию и смотри как что меняется там...

[MiiNiPaa]

Ты лучше[...] дизассемблируй мейн функцию

A ссылка на годболт во втором случае для кого была?

Вот примеры для переменных одного типа. И х и z перемещаются до массива.
coliru.stacked-crooked.com/a/291040364186f84c
https://godbolt.org/g/e9jiQP

Answer 2

[SolidMinus]

sizeof(type) * N, где type - тип, а N - количество элементов, плюс к этому числу добавляется количество байт до такого числа, чтобы оно было кратно выравниванию, как сказали выше.

Проще говоря, занимает столько, сколько занимает N таких элементов ( для int - 4N байт ) и это число округляется в верхнюю сторону до числа, чтобы было кратным некоторому числу K. Это число K и есть выравнивание, задается в настройках компилятора.

Нужно выравнивание, чтобы процессору проще вычислять было. Он гораздо проще работает с числами кратными степени двойки.