Сообщение Re[8]: Правомерно ли такое от 18.08.2020 17:39
Изменено 18.08.2020 17:45 rg45
Re[8]: Правомерно ли такое
Здравствуйте, T4r4sB, Вы писали:
TB>Скажем так, ссылка ведёт на объект, находящийся на стеке в вызывающей функции. То есть формально она не битая. И если бы у объекта не было деструктора, то ссылка бы вообще делала вид, что всё ништяк.
Давай по порядочку.
Во-первых, деструктор формально есть у любого типа данных, даже у int. И его даже можно явно позвать: http://coliru.stacked-crooked.com/a/8360b8eef0155e2c. Просто деструктор такая хитрая штука, что он может быть определен пользователем, а может быть сгенерирован компилятором. Деструктор может быть тривиальным и нетривиальным. Но он есть всегда. И время жизни объекта, согласно стандарту, закачивается, ПРИ ВХОДЕ, в деструктор (даже если он формальный — в этом случае просто где вход, там и выход).
Во-вторых, сразу же после инициализации auto&& i = test(IntWrapper(0)); время жизни объекта IntWrapper сразу же заканчивается. От него остается только область памяти, которой компилятор может распоряжаться по своему усмотрению. Например, он может разместить в ней объект(ы) какого-нибудь типа, массивы, вообще все, что угодно. Если ты начнешь постепенно усложнять свой пример, ты в этом убедишься рано или поздно. Поэтому любое использование объекта после окончания его времени жизни ведет к UB — согласно стандарту, ессно. Несмотря на то, что ссылка указывает на валидную область памяти, ее объекта в этой области уже нет и пользоваться такой ссылкой нельзя. Вот такие ссылки, которые пережили свои объекты и которыми нельзя пользоваться я и называю "битыми".
TB>Скажем так, ссылка ведёт на объект, находящийся на стеке в вызывающей функции. То есть формально она не битая. И если бы у объекта не было деструктора, то ссылка бы вообще делала вид, что всё ништяк.
Давай по порядочку.
Во-первых, деструктор формально есть у любого типа данных, даже у int. И его даже можно явно позвать: http://coliru.stacked-crooked.com/a/8360b8eef0155e2c. Просто деструктор такая хитрая штука, что он может быть определен пользователем, а может быть сгенерирован компилятором. Деструктор может быть тривиальным и нетривиальным. Но он есть всегда. И время жизни объекта, согласно стандарту, закачивается, ПРИ ВХОДЕ, в деструктор (даже если он формальный — в этом случае просто где вход, там и выход).
Во-вторых, сразу же после инициализации auto&& i = test(IntWrapper(0)); время жизни объекта IntWrapper сразу же заканчивается. От него остается только область памяти, которой компилятор может распоряжаться по своему усмотрению. Например, он может разместить в ней объект(ы) какого-нибудь типа, массивы, вообще все, что угодно. Если ты начнешь постепенно усложнять свой пример, ты в этом убедишься рано или поздно. Поэтому любое использование объекта после окончания его времени жизни ведет к UB — согласно стандарту, ессно. Несмотря на то, что ссылка указывает на валидную область памяти, ее объекта в этой области уже нет и пользоваться такой ссылкой нельзя. Вот такие ссылки, которые пережили свои объекты и которыми нельзя пользоваться я и называю "битыми".
Re[8]: Правомерно ли такое
Здравствуйте, T4r4sB, Вы писали:
TB>Скажем так, ссылка ведёт на объект, находящийся на стеке в вызывающей функции. То есть формально она не битая. И если бы у объекта не было деструктора, то ссылка бы вообще делала вид, что всё ништяк.
Давай по порядочку.
Во-первых, деструктор формально есть у любого типа данных, даже у int. И его даже можно явно позвать: http://coliru.stacked-crooked.com/a/8360b8eef0155e2c. Просто деструктор такая хитрая штука, что он может быть определен пользователем, а может быть сгенерирован компилятором. Деструктор может быть тривиальным и нетривиальным. Но он есть всегда. И время жизни объекта, согласно стандарту, закачивается, ПРИ ВХОДЕ, в деструктор (даже если он формальный — в этом случае просто где вход, там и выход).
Во-вторых, сразу же после инициализации auto&& i = test(IntWrapper(0)); время жизни объекта IntWrapper сразу же заканчивается. От него остается только область памяти, которой компилятор может распоряжаться по своему усмотрению. Например, он может разместить в ней объект(ы) какого-нибудь типа, массивы, вообще все, что угодно. Если ты начнешь постепенно усложнять свой пример, ты в этом убедишься рано или поздно. Поэтому любое использование объекта после окончания его времени жизни ведет к UB — согласно стандарту, ессно. Несмотря на то, что ссылка указывает на валидную область памяти, ее объекта в этой области уже нет и пользоваться такой ссылкой нельзя. Вот такие ссылки, которые пережили свои объекты и которыми нельзя пользоваться, я и называю "битыми".
TB>Скажем так, ссылка ведёт на объект, находящийся на стеке в вызывающей функции. То есть формально она не битая. И если бы у объекта не было деструктора, то ссылка бы вообще делала вид, что всё ништяк.
Давай по порядочку.
Во-первых, деструктор формально есть у любого типа данных, даже у int. И его даже можно явно позвать: http://coliru.stacked-crooked.com/a/8360b8eef0155e2c. Просто деструктор такая хитрая штука, что он может быть определен пользователем, а может быть сгенерирован компилятором. Деструктор может быть тривиальным и нетривиальным. Но он есть всегда. И время жизни объекта, согласно стандарту, закачивается, ПРИ ВХОДЕ, в деструктор (даже если он формальный — в этом случае просто где вход, там и выход).
Во-вторых, сразу же после инициализации auto&& i = test(IntWrapper(0)); время жизни объекта IntWrapper сразу же заканчивается. От него остается только область памяти, которой компилятор может распоряжаться по своему усмотрению. Например, он может разместить в ней объект(ы) какого-нибудь типа, массивы, вообще все, что угодно. Если ты начнешь постепенно усложнять свой пример, ты в этом убедишься рано или поздно. Поэтому любое использование объекта после окончания его времени жизни ведет к UB — согласно стандарту, ессно. Несмотря на то, что ссылка указывает на валидную область памяти, ее объекта в этой области уже нет и пользоваться такой ссылкой нельзя. Вот такие ссылки, которые пережили свои объекты и которыми нельзя пользоваться, я и называю "битыми".