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

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

V>>аа.. я ориентировался на это

Автор: σ
Дата: 16.08.23

V>>Выше приводил конкретные 5 пунктов, даже с косвенной отсылкой на стандарт, посредством которых мною допускается гипотеза сабжевого UB. То есть, те 5 пунктов объясняют, каким образом допускается гипотеза про UB. Я не просил никаких ссылок на стандарт, наоборот, готов предоставить их явно для обоснования тех или иных своих тезисов. На счет того что "мне кажется" — тут да, мне действительно кажется что здесь может быть оттрактовано UB, и приведенные выше 5 пунктов объясняют каким именно образом.

R>Смотри, какая штука получается, давай еще раз посмотрим на этот абзац в стандарте:

R>https://timsong-cpp.github.io/cppwp/class.copy.elision#1

R>

R>When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the constructor selected for the copy/move operation and/or the destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object. If the first parameter of the selected constructor is an rvalue reference to the object's type, the destruction of that object occurs when the target would have been destroyed; otherwise, the destruction occurs at the later of the times when the two objects would have been destroyed without the optimization.

R>Object-то the same, но вот ways are different и это ключевой момент, который покрывает сразу и разницу времен жизни, и разницу в константности.

Время жизни является свойством объекта а не пути к нему. Время жизни определяется исходя из манипкляций с объектом, причем не важно сквозь какой путь. Поэтому, количество этих путей не важно. Объект один — lifetime один.

R> А еще хочу заострить внимание на вот этой фразе: "an implementation is allowed...". То есть, не говорится, что компилятор обязан так сделать — ему это разрешается. И как именно он поступит, так или эдак, программист даже знать не обязан. В итоге программист имеет полное право считать, что в данном случае создаются два (или даже три) объекта, с разными временами жизни и разной константностью.

Стандарт говорит по другому, ты сам чуть выше привел цитату про the same object. На практике это, например, будет проявляться в том что у программиста во внутреннем объекте и во внешнем — то ли одинаковый this (если случилось RVO) то ли разные (если оно не случилось). Так же, к примеру, побочные эффекты в выдавленных конструкторах поскипаются в случае RVO, а без него они останутся. Другими словами, программист не имеет права считать что бъекта будет два/три, он обязан считать что ему будет обстоятельствами непреодолимой силы (an implementation is allowed...) дадено либо два объекта либо один.

R>И правильно тут рядом сказали: NRVO — это разновидность оптимизации, как ни крути.

Ну.. Окей. Утверждение на любителя как по мне. По такой логике можно говорить что Zero-overhead principle, inline — это тоже разновидности оптимизации. Ну и что. Как это можно применить к сабжу?