Кто со мной?

[_Bers]

Сообщение от Сtrl

_Bers, вы не правы. Смотрите пункт 3.6.2/1 стандарта C++. Там написано:

Я на самом деле не совсем понимаю, как в действительности правильно трактовать данный пункт стандарта.

Лично я понимаю это так: все не инициализированные явно статические переменные должны хранить значение ноль.

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

А теперь смотрим в сторону статический области памяти.

Что это такое?

Это область памяти, выделяемая процессу при создании (есть и другие разновидности памяти, например - стек, но это уже из другой оперы).

О том, сколько этой памяти должно быть выделено процессу, и какие значения должны хранить ячейки этой памяти - все это хардкорно зашивается в сам формат exe файла.

Если данная ячейка памяти не имеет явного значения, значит она - ноль.
Вся статическая память по дефолту заполнена нулями!

Так как все глобальные переменные живут по одним и тем же адресам, и их значения заранее известны - можно при создании процесса проинициализировать эти значения данными из ехе файла.
Вся остальная память - нули.

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

Если же вы создадите неинициализированный глобальный массив из 1024 элементов типа int, то в ехе файл запишится только указивка - сколько нужно выделить памяти под эти элементы (естейственно, сами значения не будут записаны в ехе файл из экономии места. И потом, нафига это нужно, если известно что они все по дефолту все равно нули? Будит записано только количество)

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

Однако при этом, никаких особых конструкторов, которые умеют определять глобальна ли переменная, и специально для глобальных записывать нули - нет.

у простых типов данных, например у int дефолтный конструктор вообще ничего не делает.

/зы если же вы создадите в глобальной области крупный массив явно-инициализированных данных, ваш ехе файл рискует многократно увеличится в размерах.

[Пепел Феникса]

Если данная ячейка памяти не имеет явного значения, значит она - ноль.
Вся статическая память по дефолту заполнена нулями!

это по стандарту С++ так должно быть, и есть.
но на практике в винде может быть и иначе.

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

Это область памяти, выделяемая процессу при создании (есть и другие разновидности памяти, например - стек, но это уже из другой оперы).

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

[_Bers]

Сообщение от Пепел Феникса

это по стандарту С++ так должно быть, и есть.
но на практике в винде может быть и иначе.

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

Однако же, компилятор сам не подсовывает явную инициализацию вместо каждой неинициализированной глобальной переменой.
Ехе файл не содержит код для не_явной инициализации статиков.

И уж точно никаких таких конструкторов, которые по дефолту инициализируют глобальную переменную нулём так же не существует.

Сообщение от Пепел Феникса

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

Только эту часть памяти винда сама выделяет каждому процессу в дополнение к статической. И она не заполняется нулями при старте. Соответственно, стековые переменные по дефолту смотрят на мусор.

[Пепел Феникса]

олько эту часть памяти винда сама выделяет каждому процессу в дополнение к статической. И она не заполняется нулями при старте. Соответственно, стековые переменные по дефолту смотрят на мусор.

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

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

обычно нет, это уже роль линкера.

Ехе файл не содержит код для не_явной инициализации статиков.

эту роль играет .bss секция.

[_Bers]

Сообщение от Пепел Феникса

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

А почему тогда там мусор постоянно всякий валяеццо?

[Пепел Феникса]

А почему тогда там мусор постоянно всякий валяеццо?

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

а мусор потом изза скачков по стеку.

[_Bers]

Сообщение от Пепел Феникса

а мусор потом изза скачков по стеку.

Не понял. Почему-почему?) Я просто плохо себе представляю сам принцип действия.

[Пепел Феникса]

обьясню попроще:

void foo(int n)
{
    char x[1024];
    //чтото с ним делает.
    if(n>0)foo(n-1);
}

в итоге при

foo(4)

будет использовано минимум (1024+4+4)*4=4192байта стека, мы его так сказать подпачкали, память так и останется грязной.
а потом выйдя из процедуры, другая процедура вновь использует эту область стека, а грязь то так и остается, вот и мусор.

условно показаны скачки по стеку на рисунке(локальные переменные, вызовы функций)
ось Х это время(слева направо)
ось У положение esp(или обьем использования стека, без разницы)
в итоге видно, что одна и таже область стека может использоваться разными процедурами не один раз.

[_Bers]

Аааа... то есть, получается, что винда выделяет девственно чистую статик память + стек (как часть этой статик памяти, но под юрисдикцией оси, а не ехе).

Однако, прежде чем стек предоставится в распоряжение функции main, его уже что-то там скрытое от программиста с++ успевает поюзать?

Типа, main свои переменные локальные располагает уже в б/у ? ))

Ну то есть, я правильно понял: винда ещё при загрузке приложения уже вовсю эксплуатирует память этого самого приложения?

[Пепел Феникса]

Однако, прежде чем стек предоставится в распоряжение функции main, его уже что-то там скрытое от программиста с++ успевает поюзать?

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

Ну то есть, я правильно понял: винда ещё при загрузке приложения уже вовсю эксплуатирует память этого самого приложения?

ну да, она грузит это самое приложение, и это гораздо проще сделать находясь "внутри" него.

Типа, main свои переменные локальные располагает уже в б/у ? ))

да.