NekZMasterZivЕщё раз, ваш чисто теоретический спор лишён всякого смысла, поскольку все вызовы всего кода создания чего-то на стеке и потом вызова констуктора инлайнятся.
Абсолютно по барабану, как это всё происходит.
Я об этом ниже написал, переходя от голой теории к конкретике.Если переходить к конкретике, то в твоём примере никакой экземпляр класса вообще не создается - нигде, а компилятор на -O3 заменяет метод объекта и его член-переменную функциональным эквивалентом, т.е., просто фигачит jmp на rand() из main.

MasterZivНу и?
Топик закрываю?В общем-то, перетёрли уже всё, что только можно было перетереть и "в" и "около". Закрывай, коль надоела эта байда.

NekZХе-хе, так в том-то и была суть всего, что я тебе талдычу уже третью страницу топика.
Да даже на -O1 останется лишь jmp.Told'ычить-то ты, конечно, told'ычишь, но объекта как не было, так и нет, а мы говорим именно об объектах.

MasterZiv0) placement new не переопределяется.
1) код placement new -- это вызов констуктора с указанным placement-у указателем на память в виде this .
2) соответственно, код placement new всегда инлайнится. Это собственно один вызов функции.Да брось! Всё прекрасно переопределяется:

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

NekZИ именно такие вот оптимизации, выкидывающие вообще всякие там упоминания о твоём классе и его мемберах из итогового ассемблера, демонстрируют тебе, что нет никаких фаз выделения памяти на стеке и вызова placement new , они существуют только в твоём сознании.Да что ты говоришь? Попробуй-ка при при максимальной оптимизации добавить квалификатор volatile к объявлению метода MyClass::f*(), к объявлению экземпляра класса собери и удивись "силе моего сознания".

NekZНет, это пушится адрес возврата для последующей инструкции callЛеонид абсолютно прав!
"push rax" расширяет стек вниз на 8 байт, сохраняя там значение из "rax", что равносильно (в нотации Intel):

Обычно, компилятор примерно так и делает, но в данном, конкретном случае, расширение кадра невелико и компилятор, почему-то, выбрал "push rax" с инициализацией памяти на стеке из регистра "rax", вместо "sub rsp, 8" без инициализации.
Далее, по соглашению __cdecl, результат функции rand() помещается в регистр "eax" и мнемоника "mov dword ptr [rsp + 4], eax" указывает нам на то, что значение из регистра "eax" помещается, в старшее двойное слово расширенной части кадра стека. Сие нам говорит о том, что компилятор разместил код, расширяющий кадр стека с выравниванием на четверное слово, но, при этом, используется только старшее двойное слово - "MyClass::x", а мнемоника "mov eax, dword ptr [rsp + 4]" говорит нам о том, что в clang квалификатор volatile напрочь отключает оптимизацию, как таковую, чего не происходит, например, в гнусе.

NekZ, только мне непонятно зачем делать push/pop, когда после любой операции модификации "rsp" для выравнивания вполне достаточно сделать "and rsp, -16".

Anatoly Moskovsky, если я правильно понимаю написанное, парни предлагают различать то, через что осуществляется доступ к членам/методам экземпляра класса (объекта) - через lvalue-ссылку или же через rvalue-ссылку с учётом cv-квалификаторов, а также использовать "this" в объявлении параметров метода в качестве ключевого слова для указания того, что дедукция шаблона должна осуществляться по типу lvalue/rvalue ссылки, через которую осуществляется доступ и, опять же, с учётом cv-квалификаторов.

Похоже, я не одинок в своих хотелках!