это не будет ломать, код, компилятор будет убирать new только когда это не будет создавать сайд-эффектов
Компиляторы прекрасно убирают в простых случаях
в общем это уже давно существует, для этого и вынесено выделение динамической памяти на уровень языка, а атрибут который я скинул говорит компилятору, что "эта функция такая же как malloc". Но есть более хитрые случаи, когда хочется компилятору доказать, что ничего в локальном скоупе не меняется после вызова и для этого, к сожалению, ничего нет, никаких атрибутов. Вероятно это гораздо сложнее реализовать
Вообще интересно конечно, в случае аллокации на стеке в той демке компилятор после инлайнинга смог проанализировать и убрать кучу промежуточных копирований и построение целого дерева и главное - он даже убрал рекурсивный проход по этому дереву Вот что мешает компилятору сделать то же самое для хип аллокаций? Почему компилятор не может трактовать такие new-аллокации (если мы пометим дополнительным аттрибутом) как те же аллокации на стеке только имеющие другие правила жизни (то есть объект не умирает после выхода из скоупа) и аналогичным образом после инлайнинга заоптимизировать в ноль все это построение и проход по дереву? Может есть фундаментальная проблема которая мешает компилятору С++ выдать такой же ассемблерный выхлоп для хип аллокаций как и для стековых аллокаций в том примере?
Проблема не в компиляторе, проблема в вашем коде, что-то в нем мешает компилятору соптимизировать ваши же странные решения. Выкидываете совершенно ненужные шаблоны и передачу кучу всего как отдельные аргументы ....
для этого не нужны вариадик шаблоны, просто берёшь и пишешь
Стикер
struct A { A* a; int i; int j; }; int main() { A { .a = new A {.i = 0, .j = 1}, .i = 2, .j = 3 }; }
а зачем здесь вызов функций то каких то я не понимаю
а как передать несколько вложенных объектов ? return new Rect{ .children = { new Rect{..}, new Rect{..}, ... } }
#include <vector> struct A { std::vector<A*> a; int i; int j; }; int main() { A { .a = {new A {.i = 0, .j = 1}, new A}, .i = 2, .j = 3 }; } Также
так это по сути и есть тот пример с хип-аллокациями в демке выше. Проблема в том что компилятор сейчас не может это заоптимизировать так же хорошо как в случае построения дерева на стеке где каждый узел будет иметь уникальный тип (а вложенные ноды будут храниться в std::tuple)
Что значит заоптимизировал в данном контексте? На стеке выделил память сразу для всего и там аллоцировал?
посмотри как компиляторы заоптимизировали построение дерева на стеке и его последующий обход здесь https://godbolt.org/z/E9d5xTfe8
Обсуждают сегодня