Сообщение Re[24]: Когда это наконец станет defined behavior? от 29.04.2023 16:47
Изменено 29.04.2023 16:54 rg45
Re[24]: Когда это наконец станет defined behavior?
Здравствуйте, netch80, Вы писали:
N>Но я, кажется, вижу, какие могут быть грабли. Пусть moo() тут сохранит эту ссылку куда-то ещё в долгосрочное хранилище, откуда его берёт какой-то другой код... можно ли компилятору предположить, что объект по ссылке не меняется, например, всё время жизни программы? Где-то надо провести границу, или давать это явно сделать кодеру.
ИМХО, подобные хотелки здорово оторваны от реальности.
N>Но я, кажется, вижу, какие могут быть грабли. Пусть moo() тут сохранит эту ссылку куда-то ещё в долгосрочное хранилище, откуда его берёт какой-то другой код... можно ли компилятору предположить, что объект по ссылке не меняется, например, всё время жизни программы? Где-то надо провести границу, или давать это явно сделать кодеру.
ИМХО, подобные хотелки здорово оторваны от реальности.
Re[24]: Когда это наконец станет defined behavior?
Здравствуйте, netch80, Вы писали:
N>Но я, кажется, вижу, какие могут быть грабли. Пусть moo() тут сохранит эту ссылку куда-то ещё в долгосрочное хранилище, откуда его берёт какой-то другой код... можно ли компилятору предположить, что объект по ссылке не меняется, например, всё время жизни программы? Где-то надо провести границу, или давать это явно сделать кодеру.
ИМХО, подобные хотелки здорово оторваны от реальности. Более реальный вариант — писать простой код, понятный как человеку, так и компилятору с оптимизатором.
N>Но я, кажется, вижу, какие могут быть грабли. Пусть moo() тут сохранит эту ссылку куда-то ещё в долгосрочное хранилище, откуда его берёт какой-то другой код... можно ли компилятору предположить, что объект по ссылке не меняется, например, всё время жизни программы? Где-то надо провести границу, или давать это явно сделать кодеру.
ИМХО, подобные хотелки здорово оторваны от реальности. Более реальный вариант — писать простой код, понятный как человеку, так и компилятору с оптимизатором.