Re[72]: Когда это наконец станет defined behavior? - C/C++

S>>>Вот когда мы делаем const T * p = new T(); мы же создаем объект и получаем его в неком нормальном начальном состоянии. Вызвав только new, ничего
S>>>больше не делая. А в случае start_lifetime_as мы типа создали, но если до этого пару-тройку обязательных приседаний не сделали, то никакого создания у нас не произойдет.

σ>>Я не понимаю, что ты называешь приседаниями.

S>Выделение памяти.
S>Присваивание значения.

S>Это происходит автоматически при использовании new или при размещении объекта на стеке (или при включения его внутрь другого объекта).

Это типа критерии создания объекта?

S>Ничего этого нет для start_lifetime_as.

S>>>Еще раз вам намекаю: то, что написано в стандарте, написано для разработчиков компилятора, анализаторов и стандартной библиотеки.

σ>>Нет, написано для доярок и сталеваров.

S>OK, которые специализируются на штудировании стандата для пиления компиляторов, анализаторов и стандартной библиотеки.

σ>>Предполагаю, что даже на этом форуме найдутся те, кто скажет что «Это софистика для стандарта. Я всю жизнь так поступал и ничо мне за это не было, так что можно»

S>Если эти люди простыми словами объяснят что можно делать и почему нужно так, то здорово. А вот отсылки на фразы типа "implicitly creates..." таким описанием, к сожалению, не являются.

Вполне являются.

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

TB>>Ну и где тут наблюдаемое уб?

σ>Я вполне отчётливо наблюдаю уб в том сценарии, который описал. Конкретное место и причину

σ>А какая тут ожидаемая логика?

Опять под дурачка косишь? Мальчик, ты балабол.

BFE>>>А ничего, что возвращаемый функцией buildMap() тип отличается от типа объекта someDictionary? Не смущает?

σ>>Сделай глубойкий вдох, убедись, что отличаешь переменные от объектов (и, следовательно, тип переменной от типа объекта), и попробуй сказать, какой же тип у объекта в случае NRVO, т.е. когда переменные result и someDictionary обозначают один и тот же объект.

S>Да блин, возьмите исходный пример:
S>

std::map<int, int> buildMap() {
    std::map<int, int> result;

    result.insert(42, 43); 
    ...
    return result;
}

void useMap() {
    const std::map<int, int> someDictionary = buildMap();
    ...
}

S>И разверните его вот таким образом:

А почему таким, а не таким:

void useMap() { return; }

S>Какие проблемы с UB?

Да может и никаких, я не знаю, я просто спрашиваю, каким будет объект при NRVO — константным или нет.

TB>>>Ну и где тут наблюдаемое уб?

σ>>Я вполне отчётливо наблюдаю уб в том сценарии, который описал. Конкретное место и причину

σ>>А какая тут ожидаемая логика?

TB>Опять под дурачка косишь? Мальчик, ты балабол.

В чём дело? Ты не можешь описать ожидаемую логику? А как ты тогда определяешь, меняет её оптимизатор или нет

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

σ>В чём дело? Ты не можешь описать ожидаемую логику? А как ты тогда определяешь, меняет её оптимизатор или нет

Обдристался — признай, не будь чмошником

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

σ>>>Я не понимаю, что ты называешь приседаниями.

S>>Выделение памяти.
S>>Присваивание значения.

S>>Это происходит автоматически при использовании new или при размещении объекта на стеке (или при включения его внутрь другого объекта).

σ>Это типа критерии создания объекта?

Это типа обязательные действия для того, чтобы объект был создан.

σ>Вполне являются.

Перед вами человек, для которого не является. Вопрос в том, один ли я такой.

σ>>В чём дело? Ты не можешь описать ожидаемую логику? А как ты тогда определяешь, меняет её оптимизатор или нет

TB>Обдристался — признай, не будь чмошником

Дядя, с головой в порядке? Я вообще-то вопрос задавал (https://rsdn.org/forum/cpp/8581729.1), как я в принципе мог, как вы выражаетесь, «обдристаться»?
Или вы перепутали кто из нас не осилил описать «ожидаему логику»?

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

S>>И разверните его вот таким образом:

σ>А почему таким, а не таким:
σ>

void useMap() { return; }

Потому что в случае с "таким" нет предмета для разговора.

S>>Какие проблемы с UB?

σ>Да может и никаких, я не знаю, я просто спрашиваю, каким будет объект при NRVO — константным или нет.

Внутри функции не константным. Снаружи константным. Выше показано как такое возможно. Если при этом есть какие-то нарушения стандарта, то хотелось бы об этом услышать.

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

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

BFE>>>А ничего, что возвращаемый функцией buildMap() тип отличается от типа объекта someDictionary? Не смущает?

σ>>Сделай глубойкий вдох, убедись, что отличаешь переменные от объектов (и, следовательно, тип переменной от типа объекта), и попробуй сказать, какой же тип у объекта в случае NRVO, т.е. когда переменные result и someDictionary обозначают один и тот же объект.

S>Да блин, возьмите исходный пример:
S>

S>std::map<int, int> buildMap() {
S>    std::map<int, int> result;

S>    result.insert(42, 43); 
S>    ...
S>    return result;
S>}

S>void useMap() {
S>    const std::map<int, int> someDictionary = buildMap();
S>    ...
S>}
S>

S>И разверните его вот таким образом:
S>

S>void __buildMap(std::byte * __result_buffer) {
S>  auto * __result = new(__result_buffer) std::map<int, int>();
S>  __result->insert(42, 43);
S>}

S>void __useMap() {
S>  alignas(std::map<int, int>) std::byte __buildMap_result[sizeof(std::map<int, int>)];
S>  __buildMap(__buildMap_result);
S>  const auto & someDictionary = std::start_lifetime_as<const std::map<int, int>>(__buildMap_result);
S>  ...
S>}
S>

S>И?

представленная развертка существенно не эквивалентна исходнику, в исходном варианте имя someDictionary означает объект, и тип этого объекта const std::map<int, int>
в развертке же это имя означает ссылку, и применяемый тип относится к ссылке но не к объекту, при этом сам объект (созданный в __buildMap над __buildMap_result) — уже не константный
таким образом, гипотетическое UB из исходника никак не возможно в развертке так как объект перестал быть константным

σ>>>>Я не понимаю, что ты называешь приседаниями.

S>>>Выделение памяти.
S>>>Присваивание значения.

S>>>Это происходит автоматически при использовании new или при размещении объекта на стеке (или при включения его внутрь другого объекта).

σ>>Это типа критерии создания объекта?

S>Это типа обязательные действия для того, чтобы объект был создан.

А можно ссылку на стандарт, плес?

σ>>Вполне являются.

S>Перед вами человек, для которого не является. Вопрос в том, один ли я такой.

Да может не один, только вот описание того, что делает start_lifetime_as, или про что там мы говорили, от числа (не)понимающих не зависит.

S>>>Какие проблемы с UB?

σ>>Да может и никаких, я не знаю, я просто спрашиваю, каким будет объект при NRVO — константным или нет.

S>Внутри функции не константным. Снаружи константным. Выше показано как такое возможно.

Выше показано два куска кода про которые утверждается что у них эквивалентное поведение.
Ток вот хорошо бы сначала поиметь описания поведения оригинального (или аналогичного упрощённого, как в https://rsdn.org/forum/cpp/8585034.1) кода. (В ситуации NRVO, без NRVO вопросов нет).

S>Если при этом есть какие-то нарушения стандарта, то хотелось бы об этом услышать.

В свою очередь, хотелось бы увидеть описание поведения (с т.з. стандарта, естественно)

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

V>представленная развертка существенно не эквивалентна исходнику, в исходном варианте имя someDictionary означает объект, и тип этого объекта const std::map<int, int>
V>в развертке же это имя означает ссылку, и применяемый тип относится к ссылке но не к объекту, при этом сам объект (созданный в __buildMap над __buildMap_result) — уже не константный

Простите за грубость, но когда вы в исходном коде видите:

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

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

V>таким образом, гипотетическое UB из исходника никак не возможно в развертке так как объект перестал быть константным

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

А еще было бы круто если бы кто-нибудь из почитателей святой буквы стандарта наконец-то объяснил простую штуку:

class demo {
  int i_;
public:
  demo() {
    i_ = f();
  }
  int f() { return rand(); }
};

const demo d;

работает конструктор константного объекта, но сам объект в это время нифига не константа.

А то доказывать, что термин "implicitly creates" понятен всем и каждому, вот прям горазды. А ответить на простые вопросы так "покажите мне текст стандарта".

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

S>>Это типа обязательные действия для того, чтобы объект был создан.

σ>А можно ссылку на стандарт, плес?

Нет, я не знаток стандарта. Но эмпирический опыт говорит именно об этом.

Если вы знаете, как создать объект без выполнения этих действий, то покажите как.

σ>Да может не один, только вот описание того, что делает start_lifetime_as, или про что там мы говорили, от числа (не)понимающих не зависит.

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

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

σ>Выше показано два куска кода про которые утверждается что у них эквивалентное поведение.

Выглядит как эквивалентное.

σ>Ток вот хорошо бы сначала поиметь описания поведения оригинального

Проссыте, но тема слишком большая чтобы искать оригинал. В чем принципиальные отличия от исходного оригинала или от упрощенного варианта с struct S? По сравнению с упрощенным я принципиальных отличий не вижу. Покажите пальцем, плиз.

S>>Если при этом есть какие-то нарушения стандарта, то хотелось бы об этом услышать.

σ>В свою очередь, хотелось бы увидеть описание поведения (с т.з. стандарта, естественно)

Напоминает зацикливание. Следовательно таким путем никуда не придем.

S>>>Это типа обязательные действия для того, чтобы объект был создан.

σ>>А можно ссылку на стандарт, плес?

S>Нет, я не знаток стандарта. Но эмпирический опыт говорит именно об этом.

>эмпирический опыт
>о, как сам писал, софистике

Я даже не знаю что сказать

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

σ>Дядя, с головой в порядке? Я вообще-то вопрос задавал (https://rsdn.org/forum/cpp/8581729.1), как я в принципе мог, как вы выражаетесь, «обдристаться»?
σ>Или вы перепутали кто из нас не осилил описать «ожидаему логику»?

Что, я не слышу, что ты говоришь? Я слышу с твоей стороны только какие-то странные звуки... кажется это звук, как по твоим штанишкам текут жидкие какашки XDDD }:0]

σ>>Ток вот хорошо бы сначала поиметь описания поведения оригинального

S>Проссыте, но тема слишком большая чтобы искать оригинал. В чем принципиальные отличия от исходного оригинала или от упрощенного варианта с struct S? По сравнению с упрощенным я принципиальных отличий не вижу. Покажите пальцем, плиз.

Я предложил вместо кода из https://rsdn.org/forum/cpp/8581729.1 взять код попроще https://rsdn.org/forum/cpp/8585034.1, чтобы не лезть в описание стандартной библиотеки из-за std::map. И описать поведение этого кода, если предположить, что NRVO.

S>>>Если при этом есть какие-то нарушения стандарта, то хотелось бы об этом услышать.

σ>>В свою очередь, хотелось бы увидеть описание поведения (с т.з. стандарта, естественно)

S>Напоминает зацикливание. Следовательно таким путем никуда не придем.

По-моему, никто (кроме меня) ещё не пытался даже начать описывать, одно невнятное мямленье про "эмпирический опыт" и "выглядит как", так что зацикливаться некуда.

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

S>>>>Это типа обязательные действия для того, чтобы объект был создан.

σ>>>А можно ссылку на стандарт, плес?

S>>Нет, я не знаток стандарта. Но эмпирический опыт говорит именно об этом.

>>эмпирический опыт
>>о, как сам писал, софистике

σ>Я даже не знаю что сказать

Приведите пример когда объект создается без выделения памяти под него и без присваивания ему значения (если мы говорим об объектах, а не о банальных int-ах). Этого будет достаточно.

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

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

V>>>>Согласно семантике — два.
σ>>>Да нет, согласно семантике — один.
V>>Два.
σ>Симптоматично, что ни одного пруфа от тебя до сих пор не было.

Чем исходник не пруф?

V>>В этом суть оптимизации.
V>>Точно такая же происходит здесь:
V>>

σ>const SomeObj obj = SomeObj(args);
σ>

V>>Согласно семантике, создаётся временный безымянный объект и копируется (либо перемещается) в целевую переменную obj.
σ>Или не создаётся и не копируется

А ты проверял?

class SomeObj {
public:
    SomeObj(int) {}
    //SomeObj(const SomeObj &) = delete;
};

//const SomeObj obj = SomeObj(42);
const SomeObj obj2(42);

Поиграй с раскомментированием строчек в различных сочетаниях.

σ>тоже «согласно семантике», а не «способу реализации»

Семантика описана простейшим исходником, который я ХЗ как можно было не суметь прочитать.

Если же ты опять пытаешься озвучить свою "эрудицию", то ты ошибся стадией рассуждения об исходнике — оптимизация выполняется над изначальной неоптимизированной моделью кода, и в этой модели кода должен быть доступен конструктор копирования, которого после оптимизации не будет. Но он всё-равно нужен.

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

V>>Лишнего копирования/перемещения можно избежать.
V>>При возврате по значению применяется ровно та же логика.
σ>Только при возврате по значению может быть несколько переменных с разной константностью

И какая разница, если оперируем данными по значению?
Семантически в этом случае создаются копии объектов.

А упоминание об обязательности RVO — это ж для дурачка-программиста, а не для компилятора, потому что с С++17 RVO будет использовано в любом случае, даже если конструкторы/деструкторы имеют побочные эффекты.

Выделенное — это для тебя, программиста, чтобы ты потом не задавал вопросов "а почему так?".
(Впрочем, в это уже тыкал, пошли по кругу)

σ>И тогда возникают некоторые вопросы.

Странные у тебя какие-то вопросы, которые ты не в состоянии даже просто сформулировать на 20-й итерации.

σ>Но даже если бы было и только — какая разница?

Никакой, бо оптимизация не изменяет семантику.

А даже если случилось RVO, то мы имеем дело с одной областью памяти, но с разными ссылками на неё в разные моменты работы программы, но никогда одновременно.
(Опять по кругу в тебя этим тыкают)

ХЗ, кароч...
Если сложно с пониманием передачи данных по значению, попробуй порассуждать про передачу через ссылочную семантику:

SomeObj * const obj = new SomeObj(42);

Тут оператор new создаёт в куче неконстантный объект и возвращает неконстантный указатель на этот объект, где значение неконстантного указателя копируется в константный указатель obj.

Надеюсь, хотя бы с примитивными типами данных сложности понимания не возникают — каким образом мы копируем числовое значение неконстантного указателя в константный? ))

А если обернуть числовое значение в некий класс SomeObj, ы?
Неужели понимать становится сложнее? ))

	От:	σ
	Дата:	21.08.23 16:17
	Оценка:

	От:	σ
	Дата:	21.08.23 16:19
	Оценка:

	От:	T4r4sB
	Дата:	21.08.23 16:23
	Оценка:	+1 -2

	От:	σ
	Дата:	21.08.23 16:23
	Оценка:

	От:	σ
	Дата:	21.08.23 16:25
	Оценка:

От:	so5team	https://stiffstream.com
Дата:	21.08.23 16:39
Оценка: