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

V>тут

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

приводился пример, продублирую
V>

V>struct S { int i; };

V>S f()
V>{
V>  S s;

V>  s.i = 0; // гипотетическое UB тут

V>  return s; // NRVO
V>}

V>const S t = f(); // NRVO
V>

Брат по разуму что ли?
Если тут якобы есть UB, то как мы можем пронаблюдать это самое UB? Покажи развёрнутый пример, который выдаёт разный результат в дебаге и релизе.

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

σ>this указывает на константный объект, в чём ты можешь легко убедиться.

Ты хоть раз в жизни собирал и запускал программу, написанную тобой на С++?

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

BFE>Смотрите, функция buildMap() возвращает объект типа std::map<int, int>, а потом в выражении const std::map<int, int> someDictionary = buildMap(); этим ( полученным из функции buildMap() ) объектом инициализируется переменная someDictionary.

Да, сopy elision там возникает дважды — при возврате значения из ф-ии и при конструировании целевой переменной.


BFE>NRVO — это про то, что возвращает функция, а не про инициализацию константного объекта обозначенного именем someDictionary.

Семантически да, ф-ия возвращает безымянный неконстантный объект, который является аргументом конструктора копирования при инициализации константной переменной.


BFE>То, что потом случается сopy elision к самой функции отношения уже не имеет.

Но ф-ия могла бы возвращать сразу const std::map<int, int>, и все рассуждения выше по ветке были бы верны.

σ>>А если есть NRVO, то теперь переменная вне функции и внутри, вместо обозначения двух разных объектов, начинают обозначать один и тот же. Я выше кидал цитату про two different ways of referring to the same object.

S>Еще раз: переменной вне нет пока порождающая функция не завершилась. Место под переменную есть, переменной нет.

Какое ещё место под переменную? Ты случайно не путаешь переменные и объекты?

S>>>Так что UB будет только если мы попробуем поменять константный объект уже после завершения функции из которого мы объект вернули. Но не до того как.

σ>>И каким же образом объект вдруг поменяет свою константность?

S>Не поменяет, а приобретет.

Ладно, спрошу как тебе угодно: каким образом приобретёт.

S>Точно так же, как объект приобретает константность после завершения его инициализации.

Т.е. никак?

S>>>Ну и я был бы признателен, если бы вы объяснили несведующему, как так получается, что объект константный, но во время работы его конструктора у нас this указывает отнюдь не на константный объект

σ>>this во время конструкции константного объекта указаывает, внезапно, на константный объект.

S>А тот факт, что якобы константный объект можно менять, вам жить не мешает?

Нет. Возможно, у тебя при словах "константный объект" возникают какие-то необоснованные ассоциации/представления, то кто тебе виноват?

S>Или эмпирический опыт вы отвергаете как класс?

Байден пожимает невидимые руки рынка, а у тебя вместо этого эмпирический опыт константных объектов?

S>>>изменение состояния внутри конструктора через этот указатель никакое не UB.

σ>>Потому что так написано в стандарте https://timsong-cpp.github.io/cppwp/n4868/class.ctor.general#5

S>Ну так там же и написано, что const на время работы конструктора на объект не распространяется.

Написано, что const semantics не распространяется.

S>Т.е. пока инициализация не завершилась нет никакого константного объекта.

а что инициализируем тогда?

Хм, а, кстати, в упрощённом коде:

struct S { int i; };

S f()
{
  S s;

  s.i = 0;
}

const S t = f();

Если применяется NRVO, и тогда переменные s и t обозначают один и тот же объект, то по-твоему
1. Инициализация для этого объекта заканчивается в S s;?
2. Или заканчивается только после возвращения из функции, и значит внутри он — неинициализированный (и, следовательно, его lifetime ещё не начался, и, следовательно, обращаться к его членам — UB)?

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

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

V>>тут

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

приводился пример, продублирую
V>>

V>>struct S { int i; };

V>>S f()
V>>{
V>>  S s;

V>>  s.i = 0; // гипотетическое UB тут

V>>  return s; // NRVO
V>>}

V>>const S t = f(); // NRVO
V>>

TB>Брат по разуму что ли?
хамство лучше не надо применять, нет причин

TB>Если тут якобы есть UB, то как мы можем пронаблюдать это самое UB? Покажи развёрнутый пример, который выдаёт разный результат в дебаге и релизе.

Во первых, не вижу необходимости кому либо что то демонстрироать. Обрати внимание, я называю сабжевое UB "гипотетическим", "подозреваемым".
Во вторых, это так не работает. Наличие UB не гарантирует наличие аномалий, лишь только делает их возможными, то есть, из наличия UB не следует обязательное наличие аномалий.
В третьих, приведенная мной трактовка носит исключительно теоретический характер на текущий момент. Я просто сопостовляю положения стандарта, и из такого сопоставления вытекает возможность UB

BFE>>>NRVO — это про то, что возвращает функция, а не про инициализацию константного объекта обозначенного именем someDictionary. То, что потом случается сopy elision к самой функции отношения уже не имеет.
σ>>В C++17 уже нет copy elision, ну да ладно, не суть важно.
BFE>Да, я знаю, что после C++17 всё это сильно запутали. Стало хуже.
Смотря в чём. Концептуально стало значительно проще, а значит — лучше. То, что появились некоторые… дефекты. Ну, бывает.

σ>>Давай я тебе помогу выдать ответ на мой исходный вопрос.
BFE>Лучше скажите, вот в этом коде:
BFE>

struct A
{
  int m{}; 
  A() { m = 1; }
}

const A a;

BFE>константный объект a меняется во время своей инициализации.

Здесь вообще нет модификации a.

BFE> А ведь это UB — константный объект менять нельзя!

Про период конструкции и константные объекты я уже давал цитату.

σ>>Задам два вопроса (речь про C++17+):
σ>>1. При NRVO, переменная result внутри функции и someDictionary вне — обозначают один и тот же объект?
σ>>2. Если ответ на предыдущий вопрос утвердительный, то тогда: этот объект константный или нет? (Объяснить почему)

BFE>Давайте я вам подсказку дам, где вы ошибаетесь. Вот она: lifetime

И что «lifetime»? Он начинается внутри функции, после инициализации result.

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

σ>1. При NRVO, переменная result внутри функции и someDictionary вне — обозначают один и тот же объект?

Не одновременно, и этого достаточно.

Ты бы оперировал полностью подробностями:
— на вызываемой стороне подготавливается область памяти для будущего объекта;
— ссылка на эту область передаётся для RVO в виде неявного аргумента;
— типы конструируемого и целевого объекта связаны весьма опосредовано — эти типы могут отличаться не только в константности;
— "внешняя" ссылка становится валидной строго после того, как "внутренняя" ссылка станет невалидной.


σ>2. Если ответ на предыдущий вопрос утвердительный

Отрицательный в такой постановке, бо ты исключаешь из вопроса время жизни переменных.


σ>то тогда: этот объект константный или нет? (Объяснить почему)

Потому что тебе уже говорили по кругу много раз, а до тебя не доходит. ))

Объект в конструкторе еще "никакой", его еще не существует.
Рассматривать целевую область памяти как объект можно только по завершении инициализации.

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

V>хамство лучше не надо применять, нет причин

Почему? Вижу балабола — хамлю.

V>Во вторых, это так не работает. Наличие UB не гарантирует наличие аномалий, лишь только делает их возможными, то есть, из наличия UB не следует обязательное наличие аномалий.

Тогда назови гипотетическую осмысленную оптимизацию, которая может быть возможно благодаря этому UB

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

σ>this указывает на константный объект, в чём ты можешь легко убедиться.

#include <stdio.h>
#include <stdlib.h>

class T {
    public: 
    void foo() { printf("foo()\n"); }
    void foo() const { printf("foo() const\n"); }
    T() {
        foo();
    }
};

int main() {
    const T t{};
    t.foo();
    return 0;
}

Угадай, что выведет?
Чтоб ИДЕ не открывать, я вот тут запустил: https://cplayground.com/?p=snail-mallard-tarsier

foo()
foo() const

Внутри конструктора зис — не конст. Понимаешь, вот это — пруф, а не твоё балабольство и размахивание руками.

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

σ>>>И во время конструирования в твоём примере объект тоже константный.
V>>Каким образом? ))
σ>По определению, которое я линканул.

Ты на вопрос не ответил.


σ>Его ты, видимо, тоже не смог понять

Так нечего понимать — ты не даёшь строгих определений, не спрашиваешь точные вопросы.


V>>Конструктор объекта не имеет понятия — создаёт ли он константный объект или мутабельный.
σ>И? Константный объект или нет зависит от его типа.

От модификатора переменной/выражения.
У тебя нет возможности описать константный пользовательский тип. ))


σ>А не от того, что там понимает конструктор.

Это согласно твоим забавным представлениям, где у тебя объект почему-то уже существует, когда его еще не существует.

Согласно определениям, принятым в С++, "объект" — это экземпляр "класса".
Пока нет готового экземпляра, нет объекта, ферштейн?

До тебя эту примитивщину не могут донести уже пол-сотни постов.


σ>Объект вообще может не конструктором инициализироваться.

Тогда он не лежит в своей объектной переменной и рассуждения о его первородной константности идут лесом.

Чего тут смешного — ты предлагаешь создавать объекты через UB, чтобы "доказать" другое UB.
Идиотизм на марше.


σ>Ты очень много пишешь всяких утверждений, которые вообще непонятно на что влияют.

Да тебе много чего не понятно.
Суть твоего торможения была понятна сразу — ты рассуждал о двух ссылках как о якобы пересекающихся по времени жизни.
Я сразу обратил на эту ошибку рассуждений твоё внимание.
Но ты облажался, не поняв сие важное замечание (или просто не обратив достаточное внимание).
Ну и всё.
После этого ты уже классический мальчик для битья, извини. ))
Сам напросился.


σ>Ты просто любишь своими наблюдениями делиться?

Да просто упоротых не жалко от слова совсем.
Вы выходите за границы разумного.

Вовсе не является недостатком незнание или непонимание чего либо, особенно при наличии желания узнать/понять.
Недостатком является лень ума и присущая этой лени упоротость.

Это как протест двоечников против невыученных уроков. ))
Неконструктив там целенаправленный, а не случайный.

Т.е. именно из-за намеренности созданного неконструктива упоротых можно и нужно тщательно пинать.
Вживую если — можно даже ногами по лицу. ))

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

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

V>>представленная развертка существенно не эквивалентна исходнику

V>Эквивалентна


V>>в исходном варианте имя someDictionary означает объект, и тип этого объекта const std::map<int, int>

V>Верно.


V>>в развертке же это имя означает ссылку

V>Да, можно было другое имя для ссылки взять. ))
V>

V>const std::map<int, int> someDictionary = buildMap();
V>const std::map<int, int> & someDictionaryRef = someDictionary;

V>Если затем ссылаться на map только через someDictionaryRef — получим полную идентичность до совпадений даже имён (если уж к именам придрался).

вот тут внимательно посмотри
в исходном примере имеем const std::map<int, int> someDictionary = buildMap();
в развертке же ссылка

без эмоций подумай эту разницу. Конкретнее — в исходном случае получаем NRVO, а следовательно получаем и ситуацию с двумя декларациями одного и того же объекта, одну внутри функции вторую снаружи. И одна из них делает объект константным. Один и тот же объект. Внимательно присмотрись, без предубеждений

σ>>1. При NRVO, переменная result внутри функции и someDictionary вне — обозначают один и тот же объект?

V>Не одновременно, и этого достаточно.

Чё ты цепляешься за это "не одновременно" как за соломинку? "Не одновременно" это ты про то, что инициализируемая константная переменная вне области видимости тела функции? Тоже мне, проблема:

struct S { int i; };

S f();

const S t = f();

S f()
{
  S s;

  s.i = 0;

  return s;
}

V>Ты бы оперировал полностью подробностями:

Ты подробностями называешь детали реализации? Нахер ими вообще оперировать, рассуждая о семантике C++, можешь объяснить сперва? Семантика C++ не зависит от того, подготавливается там область памяти, или область хуямяти, или программа с бумажкой и карандашом интерпретируется.

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

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

V>>представленная развертка существенно не эквивалентна исходнику

V>Эквивалентна


V>>в исходном варианте имя someDictionary означает объект, и тип этого объекта const std::map<int, int>

V>Верно.


V>>в развертке же это имя означает ссылку

V>Да, можно было другое имя для ссылки взять. ))
V>

V>const std::map<int, int> someDictionary = buildMap();
V>const std::map<int, int> & someDictionaryRef = someDictionary;

V>Если затем ссылаться на map только через someDictionaryRef — получим полную идентичность до совпадений даже имён (если уж к именам придрался).


V>>и применяемый тип относится к ссылке но не к объекту

V>Ссылка на объект может быть интерпретирована как неотличимая от объекта — это почему компилятор не обязан заводить переменную-ссылку в памяти, если он "видит" её инициализацию, и это прямо по стандарту.

V>То бишь, хотя в примере выше у нас две переменные, на стеке будет выделено место только для первой из них, а ссылка someDictionaryRef будет использоваться сугубо как алиас имени someDictionary.

V>(то же самое касается ссылок, инициализированных другими ссылками — они часто "схлопываются" в один алиас времени компиляции)


V>>при этом сам объект (созданный в __buildMap над __buildMap_result) — уже не константный

V>Не "уже не константный", а "еще не константный"

Имено "уже не константный". В исходном примере он был константный, а потом ув. so5team его развернул и объект стал не костантным.

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

S>>, но когда вы в исходном коде видите:
S>>

S>>const std::map<int, int> someName;
S>>

S>>то кто вам гарантирует, что идентификатор someName означает что-то кроме ссылки после прохода оптимизатора?

V>похоже, мы разговариваем на разных языках.. Причем тут оптимизатор — категорически не понимаю.

Просто при том, что изначальный вопрос возник о том, что будет в результате применения оптимизации, конкретно NRVO.
Т.е., если мы изначально допускаем, что оптимизатор может пустить вдоль побочные эффекты конструкторов/деструкторов, то нелогично как-то требовать что someName после оптимизации означает тоже самое что и до.

V>почему тут подозревается UB:

Я, например, не понимаю, почему подозревается UB. Выглядит все это так: "мне кажется, что здесь UB, а вы мне покажите цитата из стандарта, чтобы мне казалось еще сильнее".

S>>А еще было бы круто если бы кто-нибудь из почитателей святой буквы стандарта

V>зачем ерничать?

Затем, что если бы мне сразу ответили на этот вопрос, то мы бы не ушли от тех самых контекстов, в которых объект то константа, то нет. Эта ложка оказалась бы к обеду.

V>ув. σ выше по теме приводил норму для этого случая, лень искать. Вкратце простыми словами — конструктору в этом случае дадено исключительное право сцецифическим образом плевать на константность.

Почему тоже самое не дано NRVO оптимизации? Если оно уже в одном месте так работает.

S>>А ответить на простые вопросы так "покажите мне текст стандарта".
V>и судя по всему это правильно. Именно стандарт и определяет все эти аспекты поведения, с него и надо начинать

Повторю еще раз: стандарт написан для специфической аудитории специфическим языком. То, что язык делает и как должно просто и понятно описываться другими словами для простых разработчиков. Поэтому если кому-то удобно оперировать термином implicitly creates, то это отрадно, но сомнительно что эта терминология будет удобна для большинства.

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

V>>Не "уже не константный", а "еще не константный"

V>Имено "уже не константный". В исходном примере он был константный, а потом ув. so5team его развернул и объект стал не костантным.

А вы докажите, что он не константный, т.к. единственный способ работы с ним -- это через константную ссылку. С которой константность снять вам никто не даст.

σ>>>>И во время конструирования в твоём примере объект тоже константный.
V>>>Каким образом? ))
σ>>По определению, которое я линканул.

V>Ты на вопрос не ответил.

Конструируя объект типа const T, конструируем константный объект, т.к. по определению объект типа const T это константный объект (const object). Вот определение: https://timsong-cpp.github.io/cppwp/n4868/basic.type.qualifier#def:object,const.
Могу даже скопировать определение сюда
> A const object is an object of type const T

Охренеть как сложно, да?

σ>>Его ты, видимо, тоже не смог понять

V>Так нечего понимать — ты не даёшь строгих определений

Вот определение, даю в третий, если не больше, раз: https://timsong-cpp.github.io/cppwp/n4868/basic.type.qualifier#def:object,const. Строже него нет.

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

S>>Еще раз: переменной вне нет пока порождающая функция не завершилась. Место под переменную есть, переменной нет.

σ>Какое ещё место под переменную? Ты случайно не путаешь переменные и объекты?

Ok, очепятался. Место под объект есть, объекта нет.

S>>>>Так что UB будет только если мы попробуем поменять константный объект уже после завершения функции из которого мы объект вернули. Но не до того как.

σ>>>И каким же образом объект вдруг поменяет свою константность?

S>>Не поменяет, а приобретет.

σ>Ладно, спрошу как тебе угодно: каким образом приобретёт.

Автоматически после завершения работы конструктора.

S>>Точно так же, как объект приобретает константность после завершения его инициализации.

σ>Т.е. никак?

Автоматически после завершения работы конструктора.

S>>>>Ну и я был бы признателен, если бы вы объяснили несведующему, как так получается, что объект константный, но во время работы его конструктора у нас this указывает отнюдь не на константный объект

σ>>>this во время конструкции константного объекта указаывает, внезапно, на константный объект.

S>>А тот факт, что якобы константный объект можно менять, вам жить не мешает?

σ>Нет. Возможно, у тебя при словах "константный объект" возникают какие-то необоснованные ассоциации/представления, то кто тебе виноват?

У меня простая ассоциация: константный объект менять нельзя. Это совпадает с тем, что я вижу в языке.
Соответственно, если объект можно менять, значит он неконстантный.

S>>Или эмпирический опыт вы отвергаете как класс?

σ>Байден пожимает невидимые руки рынка, а у тебя вместо этого эмпирический опыт константных объектов?

Да, несколько десятилетий пользуюсь ими. Есть опыт того, что с ними можно делать, а что нельзя. Менять, например, нельзя. mutable оставляем за бортом разговора.

S>>Ну так там же и написано, что const на время работы конструктора на объект не распространяется.

σ>Написано, что const semantics не распространяется.

И чтобы это могло значить? Ну, кроме того, что объект не константен.

S>>Т.е. пока инициализация не завершилась нет никакого константного объекта.

σ> а что инициализируем тогда?

Объект. Который затем станет константой.

σ>Если применяется NRVO, и тогда переменные s и t обозначают один и тот же объект, то по-твоему
σ>1. Инициализация для этого объекта заканчивается в S s;?
σ>2. Или заканчивается только после возвращения из функции, и значит внутри он — неинициализированный (и, следовательно, его lifetime ещё не начался, и, следовательно, обращаться к его членам — UB)?

По моему, здесь следует видеть два объекта:

* s внутри f() неконстантный;
* t вне f() константный.

Поскольку одновременно они не сущуствуют и использоваться одновременно не могут, то тот факт, что они являются одним объектом с точки зрения одной конкретной оптимизации -- это просто мелкая деталь реализации, не более того. Знать про которую разработчику нужно лишь для того, чтобы понять, куда подевались побочные эффекты из конструктора/деструктора.

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

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

S>>>, но когда вы в исходном коде видите:
S>>>

S>>>const std::map<int, int> someName;
S>>>

S>>>то кто вам гарантирует, что идентификатор someName означает что-то кроме ссылки после прохода оптимизатора?

V>>похоже, мы разговариваем на разных языках.. Причем тут оптимизатор — категорически не понимаю.

S>Просто при том, что изначальный вопрос возник о том, что будет в результате применения оптимизации, конкретно NRVO.

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

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

S>Т.е., если мы изначально допускаем, что оптимизатор может пустить вдоль побочные эффекты конструкторов/деструкторов, то нелогично как-то требовать что someName после оптимизации означает тоже самое что и до.

V>>почему тут подозревается UB:

S>Я, например, не понимаю, почему подозревается UB. Выглядит все это так: "мне кажется, что здесь UB, а вы мне покажите цитата из стандарта, чтобы мне казалось еще сильнее".

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

S>>>А еще было бы круто если бы кто-нибудь из почитателей святой буквы стандарта

V>>зачем ерничать?

S>Затем, что если бы мне сразу ответили на этот вопрос, то мы бы не ушли от тех самых контекстов, в которых объект то константа, то нет. Эта ложка оказалась бы к обеду.

Ерничание как штатный инструмент ведения беседы — это жесть. Я стараюсь отвечать на все заданные мне вопросы. Не припомню чтобы в твою сторону что то осталось без ответа.

V>>ув. σ выше по теме приводил норму для этого случая, лень искать. Вкратце простыми словами — конструктору в этом случае дадено исключительное право сцецифическим образом плевать на константность.

S>Почему тоже самое не дано NRVO оптимизации? Если оно уже в одном месте так работает.

Хороший вопрос, вряд ли я на него смогу ответить. Вероятно, это недоработка языка. Примерно такая же, что и привела к сабжевому гипотетическому UB — стандарт определил:
1. что тип объекта определяется его декларацией
2. модифицировать константный объект — UB
3. и тут добавили положение про NRVO, которое сделало возможным один и тот же объект задекларировать два раза, причем по разному (с константностью и без). И вот этот третий пункт с учетом предыдущих двух формирует всю обсуждаемую в текущей подветке котовасию


S>>>А ответить на простые вопросы так "покажите мне текст стандарта".
V>>и судя по всему это правильно. Именно стандарт и определяет все эти аспекты поведения, с него и надо начинать

S>Повторю еще раз: стандарт написан для специфической аудитории специфическим языком. То, что язык делает и как должно просто и понятно описываться другими словами для простых разработчиков. Поэтому если кому-то удобно оперировать термином implicitly creates, то это отрадно, но сомнительно что эта терминология будет удобна для большинства.

Это дело вкуса. Для меня, например, стандарт — это правила игры в язык C++. Если кто то хочет играть в игру на основе собственного понимания правил — пожалуйста, но стандарт — это источник первичного смысла в ней. Аналогично можно было бы сказать, что законы написаны для юристов, а потом недоумевать, почему мне штрафы сыпятся и почему меня в тюрьму сажают.

S>>>>>Так что UB будет только если мы попробуем поменять константный объект уже после завершения функции из которого мы объект вернули. Но не до того как.

σ>>>>И каким же образом объект вдруг поменяет свою константность?

S>>>Не поменяет, а приобретет.

σ>>Ладно, спрошу как тебе угодно: каким образом приобретёт.

S>Автоматически после завершения работы конструктора.

Т.е при завершении работы конструктора меняется тип объекта?

S>>>>>Ну и я был бы признателен, если бы вы объяснили несведующему, как так получается, что объект константный, но во время работы его конструктора у нас this указывает отнюдь не на константный объект

σ>>>>this во время конструкции константного объекта указаывает, внезапно, на константный объект.

S>>>А тот факт, что якобы константный объект можно менять, вам жить не мешает?

σ>>Нет. Возможно, у тебя при словах "константный объект" возникают какие-то необоснованные ассоциации/представления, то кто тебе виноват?

S>У меня простая ассоциация: константный объект менять нельзя. Это совпадает с тем, что я вижу в языке.
S>Соответственно, если объект можно менять, значит он неконстантный.

Ладно. Я думал это понятно, но, видимо, придётся проговорить явно. Когда я спрашиваю про поведение программы на цепепе, меня интересуют определения стандарта, а не твои. Твои не интересуют.

S>>>Ну так там же и написано, что const на время работы конструктора на объект не распространяется.

σ>>Написано, что const semantics не распространяется.

S>И чтобы это могло значить? Ну, кроме того, что объект не константен.

То, что константен, но модифицировать его (и даже его подобъекты) не UB.

	Скрытый текст
	Вообще, идея, что это ещё и на агрегатную инициализацию распространяется, а не только на инициализацию конструктором, но этот дефект на тему обсуждения константности+NRVO не влияет

S>>>Т.е. пока инициализация не завершилась нет никакого константного объекта.

σ>> а что инициализируем тогда?

S>Объект. Который затем станет константой.

Может покажешь в стандарте про смену типа объекта при возврате из конструктора?

σ>>Если применяется NRVO, и тогда переменные s и t обозначают один и тот же объект, то по-твоему
σ>>1. Инициализация для этого объекта заканчивается в S s;?
σ>>2. Или заканчивается только после возвращения из функции, и значит внутри он — неинициализированный (и, следовательно, его lifetime ещё не начался, и, следовательно, обращаться к его членам — UB)?

S>По моему, здесь следует видеть два объекта:

S>* s внутри f() неконстантный;
S>* t вне f() константный.

S>Поскольку одновременно они не сущуствуют и использоваться одновременно не могут

Если ты про область видимости переменных s и t,

struct S { int i; };

S f();

const S t = f();

S f()
{
  S s;

  s.i = 0;

  return s;
}

то вот, внутри функции s и t доступны "одновременно".

S> то тот факт, что они являются одним объектом с точки зрения одной конкретной оптимизации -- это просто мелкая деталь реализации, не более того.

Оно, конечно, деталь реализации в том смысле, что какие-то реализации могут делать, а какие-то нет, но вообще это происходит на уровне абстрактной машины C++ (примерно как то, что размер int это "деталь реализации"). И (не)применение NRVO отличимо в смысле наблюдаемого поведения этой машины (так же, как размер int).

В отличие от чего-нибуть типа будет ли под int i = 0; выделяться место, или будет только в регистре, или вообще i не использовалось и было выкинуто.

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

σ>>>Если по семантике C++ это один и тот же объект
V>>Нет никаких "если".
V>>Не считает.
σ>Очередной беспруфный вскукарек засчитан

На это уже отвечалось — пруфом является сам код.