foo();
int main() {}
где теперь будем хранить?
ок, я понял, этот механизм будет работать только внутри одного translation unit, с раздельной компиляцией он работать не будет
с другой стороны я и так планирую собирать проект одним translation unit (как минимум потому что у компилятора будет больше информации и он будет лучше оптимизировать код)
Кстати мне нравится идея самособираемых проектов - когда в репозитории проекта хранится все необходимое для сборки этого проекта. Более того я считаю что компилятор вообще можно рассматривать как пользовательскую библиотеку (среди множества других используемых в проекте) - например есть главная точка входа - функция main а рядом будет лежать файлик типа build.cpp который инклудит компилятор например ligclang и собирает проект (и бинарник следующуей версии себя)
Вы предлагаете внести это изменение в язык из-за проекта, который вы хотите собирать одним TU? Поправьте, если я ошибаюсь.
Никаких изменений в язык добавляться не будет - по стандарту dangling references это UB а я всего лишь хочу настроить этот ub внутри компилятора так чтобы оно работало чуть по другому. Да, для того чтобы оно работало через несколько translation units нужно будет менять abi но вроде как abi не является частью стандарта языка (поправьте если я ошибаюсь)
А как именно менять ABI?))
Вместо того, чтобы пытаться менять компилятор, лучше бы понять, почему такой код писать не надо.
А как сейчас в abi работает copy elision? Раньше это была внутренняя оптимизация компилятора но в стандарте с++17 появилось требование не вызвать конструктор и деструктор для промежуточных объектов в случае RVO и RNVO. Что происходит если эти функции находтся в нескольких traslation units? Наверняка в abi для этого добавили какие-то дополнительные слоты для скрытых указателей по которым создаются объекты (и передаются без копирования) иначе тогда компиляторы не смогли бы поддерживать этот стандарт
Как и раньше для передачи объектов, которые не умещаются в GPR: через неявный указатель в RCX/RDI
Обсуждают сегодня