Re[2]: Почему нет принудительного TCO?
От: cppguard  
Дата: 11.02.22 08:51
Оценка:
Здравствуйте, Alexander G, Вы писали:

AG>Легальность и в некоторых случая обязательность return value optimization и не-привествование std::move на return value уже даёт некоторую почву -- много где оно уже работает, пусть и без требования.


Я говорю про то, что можно гарантировать, типа copy-ellision (хотя, не совсем верный пример). То,что разные оптимизации существуют, это хорошо. Но рекурсивные алгоритмы без гарантии TCO гарантированно взорвут стек.

AG>Есть некоторая сложность с тем, что стандарт не говорит про то, что вообще обязательно есть stack, даже несмотря на stack unwinding при исключениях и std::stacktrace из C++23, но дело поправимое.


Вот за это люблю С++: на одном ресурсе обсуждаешь что-то из стандарта, и тебе говорят про необязательное существование стека (я бы очень хотел взглянуть на эти платформы), обсуждаешь на другом, и там тебе говорят, что proposal оптимизирован для x86-64, чтобы всё весело влезало в свободные регистры. Истина, как всегда, is out there.

AG>Видимо на самом деле не так уж оно и нужно, если такого пропозла не было.


А джаваскриптопитонячий std::any прям вот всем позарез нужен? Или это для тех, кто написал первую версию на питоне и потом такой: "сейчас перепишем на С++, всё летать будет!". Я, кстати, прямо сейчас работаю над проектом, который с Java на С++ именно с такой мотивацией переписали Или другой пример: в Java есть Map::computeIfAbsent, который очень удобен для написания branch-less кода, а в С++ можно соснуть петушок на палочке, но зато есть emplace, insert, try_insert, try_emplace — на любой вкус и лад =) Как я уже написал, я считаю, что большинство членов коммитета тащат в стандарт то, что нужно их компаниям, а не то, что нужно среднему программисту по палате.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.