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

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

_NN>>Пожалуйста:
_NN>>Перед тем как положить объект в куче, Rust обязан сначала создать его на стеке, а потом скопировать в кучу.

FR>В релизной сборке stack overflow не будет, так как все соптимизируется.
FR>Тут проблема в том, что в отладочной без оптимизаций все делается тупо с созданием на стеке так как Box::new по сути самая обычная функция, а тут все-таки уже нужно ключевое слово, которое (box) даже есть в нестабильных сборках компилятора, но которое почему-то стабилизировать не хотят.
Это был просто пример кода где Rust есть стек, а C++ нет.
Я не спорю, что есть оптимизация, которую компилятор проводит.
Получается, что есть вероятность где невозможно будет применить отладочную сборку из-за этого эфекта, например при сборке модуля ядра.

FR>Но на замеры именно в сабже это багофича повлиять не должна, так-как прекрасно оптимизируется (надеюсь тестировали не отладочную сборку).
Это уже вопросы к замерам, чем там меряются

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

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

_NN>>Пожалуйста:
_NN>>Перед тем как положить объект в куче, Rust обязан сначала создать его на стеке, а потом скопировать в кучу.

FR>В релизной сборке stack overflow не будет, так как все соптимизируется.
FR>Тут проблема в том, что в отладочной без оптимизаций все делается тупо с созданием на стеке так как Box::new по сути самая обычная функция, а тут все-таки уже нужно ключевое слово, которое (box) даже есть в нестабильных сборках компилятора, но которое почему-то стабилизировать не хотят.
Это был просто пример кода где Rust ест стек, а C++ нет.
Я не спорю, что есть оптимизация, которую компилятор проводит.
Получается, что есть вероятность где невозможно будет применить отладочную сборку из-за этого эфекта, например при сборке модуля ядра.

FR>Но на замеры именно в сабже это багофича повлиять не должна, так-как прекрасно оптимизируется (надеюсь тестировали не отладочную сборку).
Это уже вопросы к замерам, чем там меряются