SashaMercuryBagaBagaпропущено...


Можно попробовать выстрелить себе в ногу



но нужно ли?

И зачем так пробовать? Разве в данном случае мы не имеем ub?

Там же сказано - выстрелить себе в ногу :)

Это классический (можно сказать - бородатый) трюк со времен С. И да, это UB, если следовать букве стандарта. По стандарту, если вы уж получили непрерывные кусок памяти (в т.ч. массив), то вся ваша адресная арифметика должна уложиться "внутрь" выделенного непрерывного диапазона адресов. Например, вот такой код


тоже UB в чистом виде.

Этот UB можно наглядно словить, если вы "захотите обработать" больше сегмента. Или если вдруг "разность" должна стать отрицательным числом... Что тогда будет, ведь отрицательных адресов не бывает? (подсказка - скорее всего "улетите" в чужой сегмент).

Но к несчастью, в большинстве случаев на x86 этот UB работает так, как ожидается )

SashaMercuryBagaBaga Это классический (можно сказать - бородатый) трюк со времен С.

Может быть (хотя трюки должны быть законными). Было бы интересно увидеть где этот "трюк" встречается (увидеть отсылку времен K&R к такому примеру) и как его комментируют авторы

SashaMercury, ты не поверишь, но трюки никому ничего не должны :) Более того, большинство из них по определению UB. Ну вот взять хоть те же трюки по доступу к закрытым полям класса. Как их сделать без UB? Никак :)

Во времена K&R, на сколько я знаю, интернета не было. Так что дать ссылку на первоисточник вряд ли можно. Этот трюк встречался в разных кодах, но популяризировали его, скорее всего, авторы книги Numerical Recipes in C. В новых переизданиях этот трюк убрали как не совсем соответсвующий стандарту.

PS
Да, к стати, никого не смущает, что итератор end() указывает _ЗА_ последний элемент? Похоже, что именно для этой практики в адресной арифметике в стандарте сделано исключение - можно получать (про разъыменовывать - ни ни) адрес, на один элемент больший, чем последний адрес выделенной непрерывной области. Иначе пришлось бы "закопать" весь STL :))

SashaMercuryВы выше писали про то, что трюки не обязаны соответствовать стандарту, более того, по определению ub

SashaMercury,
вы как-то интересно надёргиваете мои слова. Я ни где не писал, что ВСЕ трюки - UB. Как и то, что все UB - трюки... Неужели нужно переформулировать? Ок: большинство трюков (нужно ли уточнять, что из тех, что я видел?) являются UB по определению UB.

SashaMercuryУ нас с вами разные определения для этого слова. На мой взгляд трюк это что-то законное, но не явное.

Можно подумать, UB - это что-то незаконное :). UB это всего лишь UB. Стандарт регламентирует ряд ситуаций. Есть ситуации, которые стандарт отказывается регламентировать. Эти ситуации и есть Undefined стандартом Behavior, т.е. по-просту неопределённые. Это значит, что в этих ситуациях может произойти что угодно, и это "что угодно" будет законным. И зависеть от усмотрения разработчика (компилятора).
Например,


чистой воды UB, но при этом этот код спокойно откомпилируется компиляторами от MS, от Borland (а, ну да - Embarcadero), но тот же gcc выдаст ошибку компиляции ))

SashaMercuryBagaBagaPS
Да, к стати, никого не смущает, что итератор end() указывает _ЗА_ последний элемент? Похоже, что именно для этой практики в адресной арифметике в стандарте сделано исключение - можно получать (про разъыменовывать - ни ни) адрес, на один элемент больший, чем последний адрес выделенной непрерывной области. Иначе пришлось бы "закопать" весь STL :))
Мне кажется что в данной ситуации все ровно наоборот
Что - ровно наоборот?

SashaMercuryИ конечно возможность проводить сравнение с элементов следующим за последним элементов скорее всего связана с устоявшейся традицией работать с полуоткрытыми интервалами при непосредственном кодировании и разработке алгоритмов [a,b), т.о. классический цикл в качестве шаблона будет иметь следующий вид:
for(T i=0;i<n;++i){
smth do
}

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

Вот из чего что следует, тут совершенно непонятно )))

Вы привели классический пример цикла из С и С++. Вот только он не соответствует устоявшейся практике разработчиков STL. Загляните, там полно другого кода, всё больше в стиле


Обратите внимание, типовая реализация от STL требует только наличия оператора сравнения на равенство (ну, или неравенство). Ваш же цикл требует значительно большего - он требует не только сравнимости равно - не равно (как в STL), но и упорядоченности (какой из двух элементов больше). Причём, строгой :)). Что может вызвать некоторые проблемы, причём ровно те же, что и UB в решении с трюком-на-указателях :)

Dima T,
следуйте соглашениям STL и используйте "!=" вместо "<" - тогда и "бесконечного цикла" не будет :)

SashaMercuryBagaBaga, у нас здесь не курица с яйцом и не сообщество благородных девиц Сорбонны, потому софистикой заниматься мне не интересно. Вы безусловно можете оставаться при своем мнении
Софистикой здесь занимаетесь только вы. Укажите на пункт стандарта, запрещающий UB, и тогда я с вами соглашусь. Но вы такого не найдёте.

SashaMercuryBagaBaga Ваш же цикл требует значительно большего - он требует не только сравнимости равно - не равно (как в STL), но и упорядоченности (какой из двух элементов больше). Причём, строгой :)). Что может вызвать некоторые проблемы, причём ровно те же, что и UB в решении с трюком-на-указателях :)


Приведите пожалуйста пример

Вам же привели пример
Dima TЕсли последний элемент занимает последние байты адресного пространства, то это бесконечный цикл, т.к. ++ уведет в начало.
Вам достаточно подобрать такой адрес, когда it < end() заведомо не выполнится. Т.е. в (it+1) будет происходить переполнение, и "неожиданно" (it+1) < it < end() :)
Как думаете, что выдаст в качестве значения "с"


такой код? Всегда ли он вернёт одно и то же? Зависит ли возвращаемое от чего-либо? Вернёт ли он что либо? )))

mayton,
рискну предположить, что "проблемы трюка - с - указателем" как раз и проявляются из-за необработки "переполнения" - выхода результирующего адреса за диапазон допустимых значений (e.g., за границы выделенного сегмента).

SashaMercury привёл код
SashaMercuryт.о. классический цикл в качестве шаблона будет иметь следующий вид:
for(T i=0;i<n;++i){
smth do
}

и попросил меня
SashaMercuryBagaBaga ... Что может вызвать некоторые проблемы, причём ровно те же, что и UB в решении с трюком-на-указателях :)

Приведите пожалуйста пример

показать его проблемы. Для чего мне пришлось привести пример,



полностью повтояющий структуру приведённого т.н. "классического цикла", но при этом являющийся UB в чистом виде.

PS
Я только за гавайские рубашки :)

SashaMercuryBagaBaga, ваши контрпримеры неудачны. Придумайте что-нибудь получше ;)
Ну так и давайте по пунктам:
- в чём конкретно они неудачны и почему:
- на основании каких критериев сделаны такие выводы;
- откуда вообще эти "критерии" взялись? Желательно, со ссылками на стандарт.

И да, где ссылка на пункт стандарта, утверждающего "UB - это незаконно"? :) Вы же так обильно его цитируете, приведите и здесь )

SashaMercuryНеудачны потому, что ничего не доказывают. ... из этого не следует что именно операция сравнения привела к этому.
Именно операция сравнения знакового char и беззнакового 255 привела к UB. Но для вас, так и быть, "из этого не следует"...

Модератор: Прекращайте спорить

Пётр СедовПо-моему, вы смешиваете две принципиально разные вещи -- unspecified behavior и undefined behavior. Undefined behavior плохо тем, что оптимизирующий компилятор полагается на то, что оно не случается. Например, есть код:

Знаковое (signed) переполнение -- это undefined behavior, оптимизирующий компилятор полагается на то, что оно не случается. Значит, условие в if -- всегда true, его можно не проверять, а вызов функции handle_overflow -- вообще выкинуть.

Пётр, чесслово, очень хотелось бы увидеть на русском "на пальцах" (но без "распальцовки :) ) объяснение, что же такое undefined behavior, unspecified behavior, и на каких критериях (желательно, всё же формальных, а то ведь скатимся до "я ТАК вижу") и тест-кейсах можно отличить одно от другого.

Если честно, мне немного непривычно, что в качестве примера unspecified behavior вы привели результаты работы оптимизатора. Оптимизатор, это такая "вещь в себе", что его работа остаётся загадкой - т.к. зависит от набора доступных ему правил преобразования кода и умения "распознавать" .. клише, что-ли... для оптимизации. И первое, и последнее зависят от разработчиков. Но на первое мы можем влиять через ключи. Правда, мало кто на себе (на своём коде, конечно же) прочувствовал, что выбирая опцию выше O2 собственноручно позволяешь ему произвести ... как бы это ... исполняемый, но неработающий как ожидается код :)

Как думаете, прав ли будет оптимизатор, выкидывая конструкцию вида


?

А удивление моё вызвано простой вещью. Существует очень старый, ещё со времён С, пример. Как думаете, что вернёт код

Пётр СедовBagaBagaЕсли честно, мне немного непривычно, что в качестве примера unspecified behavior вы привели результаты работы оптимизатора.Там было про undefined behavior :).

тогда согласен :)

Пётр Седов
BagaBagaКак думаете, прав ли будет оптимизатор, выкидывая конструкцию вида


?Думаю, прав. Здесь же нет volatile, поэтому можно выкинуть if. Вот если написать «volatile double d = 1;», то компилятор должен сохранить if, потому что мы сообщили ему, что другой поток (thread) может в любой момент изменить значение переменной d.

volatile здесь совершенно непричем. И нет ни слова о многопоточности. Этот код - x!=x - не что иное как полный аналог isnan(x). NaN - это единственное число, коротое не равно самому себе :) Так что будет выкинута проверка получения не-числа...

Пётр СедовBagaBagaА удивление моё вызвано простой вещью. Существует очень старый, ещё со времён С, пример. Как думаете, что вернёт код

В последней строке -- два побочных эффекта на одну и ту же переменную, это undefined behavior, насколько я понимаю. Так что неизвестно, что тут будет происходить, и этот код надо переписать. Ну и в старом C-шном коде не может быть лямбды :).
Про лямбду. Замените её на функцию :) Это просто чтобы "визуально омолодить" пример и сэкономить пару строк на экране. В стандарте С++ (и С - тоже) порядок вычисления аргументов, переданных в функцию, unspecified. Результат, взвращаемый данной функцией, корректен, но завсист от прядка вычисления аргументов. Так что это был пример на unspecified behavior. Ради интереса, попробуйте скомпилировать его же на компиляторе MS C++ под x86 и под ARM - получите разные результаты :) Его можно (при желании) привратить в UB, если допустить вычисление параметров конкурентно в __разных__ потоках (вот тогда получим UB из-за "одновременного" доступа к "незащищённой" переменной из разных потоков...), вот только ни один компилятор, на сколько я знаю, такого извращения не делает :)