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

V>>И какое неопределённое поведение тут может быть?
V>>Пусть даже самое гипотетическое?
V>тут

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

, после слов "почему тут подозревается UB:" 5 пунктов разъясняющих гипотетическое UB

Тебе на это уже отвечали:

Это так не работает, реально. ))

Абсолютно любое потенциальное UB из стандарта может быть достаточно легко объяснено "на пальцах" — откуда может взяться расхождение описанного в коде и реально происходящего.

Конкретно в этой ситуации лично я не вижу потенциального UB, которое можно было бы разумно объяснить.
(оговорку про использование неинициализированных глобальных переменных сделал сразу же, но эта оговорка справедлива к любым таким переменным, необязательно константным)

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

V>5. следовательно, модификация s.i = 0 подозревается в UB
Никаких "следовательно", бо константного объекта еще не существует, отсылка к нему невалидна, т.к. сам объект еще не создан.

В любом случае, это не ответ на заданный вопрос — в чём именно заключается UB???

Для ответа на этот вопрос следует не ссылаться на стандарт, а ровно наоборот — брать упоминание UB из стандарта и пояснить своё понимание — каким образом в той или иной ситуации возникает неопределённое поведение в терминах происходящего в вычислительной модели С++ в рантайме.

Вот пример объяснения UB, на который вы ссылаетесь:

Разница есть в системе допущений, которыми вправе пользоваться компилятор в процессе оптимизации, например, не запрашивать некие поля или не вычислять некие значения от полей объекта повторно. Т.е. потенциальное UB возможно из-за неверных этих допущений, если горе-программист хакнул собственный константный объект, радостно обманув глупый компилятор.

Итого, просьба породить пример, который избегает UB по глобальной инициализации, но потенциально содержит UB по "хаку" константности, при этом необходимо указать не пункт стандарта, а объяснить суть потенциального UB (даже если оно не наблюдается в мейнстримовых актуальных компиляторах).

Не сможете пояснить суть UB — слили.

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

V>>И какое неопределённое поведение тут может быть?
V>>Пусть даже самое гипотетическое?
V>тут

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

, после слов "почему тут подозревается UB:" 5 пунктов разъясняющих гипотетическое UB

Тебе на это уже отвечали:

Это так не работает, реально. ))

Абсолютно любое потенциальное UB из стандарта может быть достаточно легко объяснено "на пальцах" — откуда может взяться расхождение описанного в коде и реально происходящего.

Конкретно в этой ситуации лично я не вижу потенциального UB, которое можно было бы разумно объяснить.
(оговорку про использование неинициализированных глобальных переменных сделал сразу же, но эта оговорка справедлива к любым таким переменным, необязательно константным)

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

V>5. следовательно, модификация s.i = 0 подозревается в UB
Никаких "следовательно", бо константного объекта еще не существует, отсылка к нему невалидна, т.к. сам объект еще не создан.

В любом случае, это не ответ на заданный вопрос — в чём именно заключается UB???

Для ответа на этот вопрос следует не ссылаться на стандарт, а ровно наоборот — брать упоминание UB из стандарта и пояснить своё понимание — каким образом в той или иной ситуации возникает неопределённое поведение в терминах происходящего в вычислительной модели С++ в рантайме.

Вот пример объяснения UB, на который вы ссылаетесь:

Разница есть в системе допущений, которыми вправе пользоваться компилятор в процессе оптимизации, например, не запрашивать некие поля или не вычислять некие значения от полей объекта повторно. Т.е. потенциальное UB возможно из-за неверных этих допущений, если горе-программист хакнул собственный константный объект, радостно обманув глупый компилятор.

Итого, просьба породить пример, который избегает UB по глобальной инициализации, но потенциально содержит UB по "хаку" константности, при этом необходимо указать не пункт стандарта, а объяснить суть потенциального UB (даже если оно не наблюдается в мейнстримовых актуальных компиляторах).

Не сможете пояснить суть UB — слили.