Тогда запрещаем писать на MSVC. В MSVC стрикт алиасинга нет.
Если мы все еще в контексте доступа по указателю вне обозримого лайфтайма (в условную память процесса) - почему? Кажется, достаточными условиями является отсутствие изменений поведения WF-программ (соблюдается) и сохранение диагностик IF (соблюдается).
Можно почитать о мотивации почему в MSVC так было сделано — мотивация не ломать кодобазы, использующие тайп-паннинг и стрикт алиасинг, в том числе их собственную.
согласен, не надо на msvc писать
Ну тут согласен, я еще баг с requires не простил.
Ну да, но в следующей версии они могут про это забыть и начать. Имеют право. Полагаясь на эту фичу вы делаете плохие и неправильные вещи и обрекаете себя на проблемы.
Имеют. Но эта фича используется этот риск принимается в рассчет.
Ну вот. Я собственно об этом. Вы решили написать некорректный код, задокументировали это и написали. Но это не означает что это хорошая практика, то так надо делать или что поэтому стандарт не имеет значения. Это означает что вы написали некорректный код и прокатило. Бывает.
А я нигде и не утверждал, что стандарт не имеет значения. Просто есть юз-кейсы, где от него приходится отходить.
Доступ вне обозримого лайфтайма вопрос более сложный, тут надо думать, потому что у меня такое ощущение что там можно нарыть аргументов в обе стороны. Но в данном случае вопрос более простой: стрикт алиасинг.
Вы от него отходите не потому что вам пришлось а потому что у вас оптимизатор плохой. Это не "пришлось", это вы так, извините "оптимизируете".
Увы, заключение я не понял. Вы утверждаете, что доопределение делает имплементацию неконформной, поскольку нарушается что-то из перечисленного или что перечисление не исчерпывающее?
Чего оптимизировать? Я привел выше два примера, которые без всяких оптимизаторов нельзя решить стандартно. И я сейчас вообще не про тайп-паннинг юнионами, который можно просто не делать, хоть и в ущерб перфу.
Там были проблемы в API и в том, что вы хотите менять вещи закладываясь на конкретный ассемблер. И то и другое неправильно.
В каком апи? Я привел второй пример - пишем чит.
Вы неправильно читаете этот пункт. Конформная реализация может добавлять расширения если [...] но она должна изначально быть конформной.
Я согласен с Вами здесь, но не понимаю, что ее делает неконформной с Вашей т.з. Определение UdB явно указывает, что Стандарт просто-напросто не регламентирует последствий, если ссылаетесь на него. Edit: Порядок закрепляется еще и здесь. Edit: Ну и as-if, да.
Да это интересная точка зрения. Возможно доопределить алиасинг это конформинг и тут получается довольно забавно. Внезапный полезный выхлоп дискуссии, которая казалась безнадёжной, спасибо.
Обсуждают сегодня