Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, _smit, Вы писали:

_>>...действует в рамках вызова функций. Gcc поступает также, т.н. "Calling Convention".

PD>Calling convention — это другое. Это правила передачи параметров функции (слева направо(сейчас нет уже, было в Win16) или справа налево, через стек и/или регистры, кто очищает стек при выходе (вызывающая или вызываемая). К отведению места в стеке под локальные переменные функции это отношения не имеет.

верно, посмотрел определение "Calling Convention", так и есть. Изучал организацию стека MIPS по документам, подобным "MIPS Calling Convention" (https://acm.sjtu.edu.cn/w/images/d/db/MIPSCallingConventionsSummary.pdf) и др. (http://people.ee.duke.edu/~sorin/ece152/lectures/2.4-isa.pdf, http://www.cs.ucsb.edu/~franklin/154/Fall07/lectures/Lec5_handout.pdf), плюс требования к SSP, поэтому отложилось в голове, что размещение локальных переменных являлось частью соглашения о вызовах.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, uzhas, Вы писали:

U>>то есть компилятор может реюзать стековую память для других переменных, если время жизни предыдущих закончилось

PD>Думаю, что не может, а обязан.
в примере выше он может, но не обязан. тебе лишь бы поспорить ?

PD>Иначе объем памяти может возрасти в N раз без всякого смысла.
фраза без всякого смысла. мне тут испугаться числа N?

Здравствуйте, uzhas, Вы писали:

PD>>Думаю, что не может, а обязан.
U>в примере выше он может, но не обязан. тебе лишь бы поспорить ?

Да нет, просто тут стековый механизм выделения, а это его следствие.

PD>>Иначе объем памяти может возрасти в N раз без всякого смысла.
U>фраза без всякого смысла. мне тут испугаться числа N?

При достаточно большом размере локальных переменных и приличном N получить на ровном месте stack overflow там , где можно без него обойтись — пугаться бы я не стал, но высказался бы об авторах кода нелестно.

Здравствуйте, Pavel Dvorkin, Вы писали:

U>>в примере выше он может, но не обязан. тебе лишь бы поспорить ?

PD>Да нет, просто тут стековый механизм выделения, а это его следствие.

никакого следствия тут нет
смотрим сюда: http://rextester.com/WVP96955
clang не стал склеивать две стековые переменные и это его право
подобную оптимизацию компиляторы реализуют в силу своих возможностей

Здравствуйте, uzhas, Вы писали:

U>clang не стал склеивать две стековые переменные и это его право

Ты прав, а он неправ

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, uzhas, Вы писали:

U>>clang не стал склеивать две стековые переменные и это его право

PD>Ты прав, а он неправ

Ничего неправильного тут нет. Укладка p2 туда же, где p1, потребовала бы лишних телодвижений, в первую очередь, на зачистку стека после первого printf(). Лишняя команда манипуляции %esp стоила бы дороже, чем те 4 байта. Вот если бы их было 4000, скорее всего, сделали бы такую зачистку.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Думаю, что не может, а обязан.
U>>в примере выше он может, но не обязан. тебе лишь бы поспорить ?

PD>Да нет, просто тут стековый механизм выделения, а это его следствие.

PD>>>Иначе объем памяти может возрасти в N раз без всякого смысла.
U>>фраза без всякого смысла. мне тут испугаться числа N?

PD>При достаточно большом размере локальных переменных и приличном N получить на ровном месте stack overflow там , где можно без него обойтись — пугаться бы я не стал, но высказался бы об авторах кода нелестно.

Меряют, скорее всего, не "в N раз", не разбираясь, что умножают на это N — а _на сколько_ возросла затрата.

Здравствуйте, Kingofastellarwar, Вы писали:

K>т.е. все операторы new вызванные в методах этого объекта

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

Здравствуйте, Kingofastellarwar, Вы писали:

K>фича для компилятора:
K>вот например передаем мы чтото или создаем локальную переменую, а почему бы если нет особых указаний, то все что будет динамически выделено этим и производными объектами не выделять тоже в стеке?
K>т.е. все операторы new вызванные в методах этого объекта, если нет особых указаний, будут аллокейтить в стеке
K>например при передаче строк, можно вообще тогда обойтись без обращения к куче

потому что

std::string h() { return std::string('a',1000); }
std::string g() { char x[10]; return h(); }
std::string f() { g(); char x[5000]; }

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

You will always get what you always got
  If you always do  what you always did