Ну берёшь значение a со стека и пихаешь его в регистр проца, а на стеке удаляешь. Может у нас там Main корроткий, и мы знаем, что можно занять регистр спокойно.
Ну, окей, это оптимизация, соглашусь, такое может быть.
Если эскейп анализ показывает что переменные никуда не уходят наружу из метода, компилятор имеет право пихать ее куда угодно, даже если предполагается что обычно переменная в куче. Можно разбить класс/структуру на филды и распознать по регистрам Конкретно здесь компилятор мог и на регичтр не класть - все равно это никто не читает, а значит и создавать не обязательно
Гм. Ну, тут да. Тут согласен, но я рассматриваю worst-case обычно.
Думаю, не мог. Вдруг в Add сайд-эффекты.
Ну мы тут в теорию играем
переменаая - просто адрес, даже если объект меняется в add, это не отменяет того, что переменную можно удалить со стека
Я про то, что компилятор мог не создавать.
Такую мелочь грех не заинлайнить (включая EnsureCapacity)
Это про то что если в Add был бы какой Console.WriteLine, то написанное мной про целиковый выброс кода было бы некорректно
Вот не согласен. EnsureCapacity на холодном пути лежит и очень дорогой внутри, так что нет. А вот остальное можно и заинлайнить.
Так это сайд-эффект же ж.
А речь о чем-то другом?
Ну, просто в стандартных методах контейнеров странно их ожидать.🤷♂
EnsureCapacity как раз не надо - это ж редкий кейс
А потом ты читаешь кодген для throw и "да ну нахер, буду проституткой"
Я делаю проще. Я не читаю 😎😎😎
Обсуждают сегодня