Т.Е. Union { void* ptr; std::uintptr_t ptr_int; } un; un.ptr = nullptr auto a = un.ptr_int; будет

ли это считаться UB?

Это UB, которое скорее всего везде работает как надо

да, вы осуществляете доступ к неактивному (мертвому) члену union http://eel.is/c++draft/class.union#general-2 http://eel.is/c++draft/basic.life#4.sentence-1

Я вообще слабо представляю, как это может работать не как надо. Достаточно глянуть как оно в ассемблере выглядит (могу судить по x86, x86-64, arm, aarch64, mips). Но блин, стандарт не хочет жизнь делать проще. С одной стороны близость к машине, с другой - дичь непонятная. Будто высокоуровневая часть борется с низкоуровневой

как то компилятор просто захочет выкинуть инструкцию и всё) В компиляторе есть дурная возможность рассуждать от обратного. Типа я знаю что ты записывал в union a, но читаешь b - так нельзя. Значит в if строчкой выше всегда false, а если в там всегда фалсе, то ... и кароче в итоге он там сам придумал себе программу, которая ничего не имеет общего с твоей.

Я в курсе. Иногда такое в уныние вводит. Я ещё помню, когда emacs собранный с O3 падал с сегфолтом на старте. А пересобранный с O2 работал и есть не просил (хотя там не цпп). При этом ситуаций, когда, вроде, код безобидный, а там ub, очень много. И логика не совсем ясна. Так то ясно, что типа погромист пишет правильно, а если что неправильно, то он понимает, что делает, а значит можно соптимиздить... но как-то такое себе допущение, ИМХО (имею мнение, хрен оспоришь)

А не надо программы с багами писать

> код безобидный, а там ub Это противоречие, код с ub - невалиден и всё.

Ты все UB знаешь/помнишь? Я же как раз про случаи, когда вроде всё логично, в том числе с точки зрения ассемблера и/или шелеза, а на самом деле - ub.

Невалидный код не должен собираться и всё)

Такой технологии пока никто не изобрёл

В С++ выпиливают часть UB постепенно.

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

1) ub нужно для оптимизаций 2) это для тебя логично, а на какой-то стремной машине может что-то отвалится. уб значит что компилятор это никак не проверяет и не гарантирует никакого поведения, все зависит от машины/погоды/других факторов

По мне, так целый выпуск стандарта этому посвятить и нужно) и нового с UB не принимать

> нет проблем с записью в одно поле, а чтение по другому Есть проблема - union не был под это задизайнен. Авторы стандарта считают, то так делать никто не будет, потому что это бред. И они дают возможность компилятору ускорить программу, применив оптимизации основанные на этом факте. После такого у тебя нет гарантий, что >там просто адрес тот же

UB неразрывно со скоростью, осознай это

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

Ну это гавнокодеры прост писали

уб для того и нужно что мы считаем что если программист написал неправильный код то мы этому коду ничего гарантировать не будем и всё, а если правильный — на разных фактах (а-ля если разыменовывают указатель => он не null) не будем делать лишних проверок и будем делать хорошие оптимизации

Я и volatile для многопоточности видел

в нем ничего плохого нет... до с++11 так и жили

Ну эт мы все прекрасно знаем) говнокодер кто угодно, только не ты) ну опенсурс одно сплошное по колено в коде...

В данном случае критерий чёткий есть

Вот будет у нас разный ассемблер... Чо делать, как определять, где валидно?

Повторюсь, есть логические ошибки, то есть программа работает корректно, но алгоритм запрограммирован не верно, есть синтаксические, тогда компилятор ругнётся. А UB... это что-то среднее, что использует компилятор, молча проглатывая (не всегда) и что рамазано по стандарту, как манка по тарелке. При этом алгоритм вроде работает, компилятор не ругается, но вцелом, всё зависит от погоды на Марсе)

Кстати, как раз актуально для volatile в рамках архитектур с TSO и без

а есть семантические ошибки, лексические ошибки и еще Н видов ошибок..

UB это как раз логическая ошибка и есть, у тебя есть правила, ты их нарушил

ну так волатиль для многопоточки используют только с написанием своего ассемблера для атомиков

Меня смущает слово "своего", а в остальном соглашусь

Начнём с того, насколько разный и сколько их осталось? X86 в разных ипостасях, arm, aarch64, mips, microblaze, xTensa?

А e2k? risc-v?

своего я имел ввиду под конкретную архитектуру учитывая модель памяти процессора, в линуксе она своя, в тбб вот была своя, они с С++03 перешли буквально год назад, до этого самописными атомиками пользовались, эх..

Точно, e2k точно нормально енум переваривал)

нет, это разрешено явно в gcc так делать.