Профессионализм сегодня измеряется не тем, как сильно ты держишься за написанные строки, а тем, насколько легко ты готов их стереть ради движения компании вперёд.
Интересное мнение. Вот только нет ли здесь подмены понятий? Держаться за написанные тобой строки можно ведь не только потому, что это твой шедевр. Причина может быть проще - они формирую архитектуру, решают запросы пользователя, обеспечивают возможность масштабирования. Взять и легко позволить их стереть ради решения сиюминутной задачи, корни которой покоятся совсем в другом месте - разве это профессионализм?
Код Doom анализируется до сих пор. Особенности реализации Elite пример бережного отношения к ресурсам. Да, ремесленников надо больше, чем творцов. Но плох тот солдат, который не мечтает стать генералом - в смысле плох тот ремесленник, который не мечтает стать творцом. А то, что получается не у всех - так это не страшно.
Точно, после подсказки о то, что "Артур – гик и фанат научной фантастики", и наличии цифр 2 и 4 ответ становится очевидным без всякой математики и криптографии. Социальная инженерия собственной персоной.
Сергей, тогда единственный вопрос - а это было озвучено пациенту? При чем вот ровно в таком виде? У меня есть полипы. Который год наблюдаем - не растут. Когда обнаружили был вопрос ко мне - удаляем? Я спросил каковы риски для обоих случаев. И все... Выяснилось, что это мое решение и моя ответственность. А какого решения вы ждете от меня? Я даже не с жалобами пришел - просто скринингом накрыло. Мне жить не мешает. Сказали раз в год проверять - ну проверяю. Было бы сказано "жить с этим - все равно что жить на пороховой бочке - до сих пор не рвануло, но гарантии что прямо сейчас не рванет не даст никто" - да и рассуждать бы не стал.
Ну и чисто технический момент. Хорошо, решил я удалять. И куда? Я примерно представляю себе что мне скажут в государственной поликлинике. Да-да, то самое "вот убьют, тогда и приходите". Т.е. по сути, государственная страховая медицина не считает это состояние настолько опасным, что требуется экстренное вмешательство. А почему тогда негосударственная считает по другому? Опять же - общемировая практика. Хорошо, а примеры можно? Вот так, чтоб четко - обнаружили значит удаляем?
Мне кажется несколько некорректным сравнивать указанные вами сущности. Хотя...
Обычному человеку сложно сравнивать риски закупорки с рисками последствий хирургии. А врачи, в частности авторы, сваливают ее на пациента. У которого нет специальных знаний. Больше чем уверен - если бы доктор четко сказал прямо: "риски ходить с камнем превышают риски от хирургии и ее последствий", то тот же IT'шник легко лег бы под нож. С прививками, конечно, ситуация схожая. И есть множество врачей, которые буквально отговаривают от прививок. Что как минимум порождает уверенность в том, что "даже врачи ни в чем не уверены". А часто рождает уверенность в безусловной вредности прививок. Т.е. по сути да - хотел поспорить, но похоже соглашаюсь...
В целом со статьей получается странная ситуация - мы убежали от ответственности, но при этом пугаем окружающих. Как по мне это просто некрасиво.
"История одного пациента" - уважаемая СМ-клиника, а как на счет истории множества других пациентов? Многие из которых живут годами с полипами и камнями, многие из которых при этом ведут нормальный образ жизни а не настолько специфический как у указанного пациента. Жути целенаправленно нагоняете, или просто случайно получилось?
Как и среди любых других групп людей. И естественно я выражаю исключительно свое видение, и надеюсь оно совпадает с видением профессионального сообщества разработчиков встраиваемых систем.
Мы привыкли к тому, что "в каждой избушке свои погремушки", и то же деление на ноль разные платформы обрабатывают по разному. Дайте даже не идею - дайте один рецепт пяти поварам и получите пять похожих, но разных блюд. Так и у нас - платформы похожи в целом, но различаются в деталях. Местами на эти детали можно наплевать, а местами их приходится учитывать. Более того, в большинстве случаев для нас крайне нежелательно сваливаться в исключения. Для нас не секрет, что набор машинных кодов у них разный, а значит разные и ассемблеры. А язык С для нас - это некоторый "усредненный ассемблер", который переводит написанное на нем в конкретный ассемблер архитектуры по вполне понятным правилам. И да - отпимизация для нас это не про "сделай меньше и быстрее", это про "делай что просят и не делай лишнего".
Фраза "могут реализовать по-разному, но должны реализовать хоть как-то, чтобы соответствовать стандарту" - она сродни привычному новоязу. Или есть четкий набор правил или его нет. Но конкретно нам, по сути, не важно. Для нас не новость, что одни и те же действия на разных платформах выполняются по разному и приводят к разным результатам. Это вполне привычный кактус. За то, уж если я прошу поделить X на X, то в соответствии с базовыми требованиями, теми самыми "делай что просят и не делай лишнего", я ожидаю что компилятор сделает именно это и сильно недоволен, если вдруг этого не случается. Мало ли зачем это может понадобится? В конце-концов набившее оскомину "xor x,x" или ее налог на С "x ^= x" вместо "ч = 0" не менее странная конструкция с точки зрения математики. И тем не менее она вполне себе применяется. И на это есть причины.
Программа, использующая UB, не является программой на языке Си.
Сильное заявление. Но не правильное.
Если моя программа использует UB - она не перестает быть написанной на языке С. Она перестает быть переносимой. Нужна ли мне переносимость - зависит от множества факторов.
Но, именно для меня, она обычно важна в части переносимости между компиляторами (Keil, IAR, GCC), но не важна в части переносимости между платформами. Обычно я не хочу использовать код под Arm на AVR или наоборот. Зато есть желание писать код в коммерческих системах (Keil, IAR), но при этом иметь возможность собирать его рабочую версию Open Source инструментами (gcc). Потому UB (а вернее, как верно подсказали выше - platform specific realisation) - мне не страшно. Конечно, что при условии что все производители компиляторов его понимают одинаково.
А лучше с ветряными мельницами вообще не бороться.
Человек который почувствовал ветер перемен должен строить не щит от ветра а ветряную мельницу (с)
Я не борюсь с ветряными мельницами. Я просто вижу естественное развитие языка. Как бы ни казалось адептам других богов, язык С продолжает развиваться. А тот факт, что его развитие не всегда идет в ногу с моими требованиями... Ну и ладно. Мне, в принципе, понятны механизмы которыми я могу добиваться нужного результата. Тут и ассемблерные вставки, и функции непосредственно на ассемблере, и набившая оскомину volatile, и разные ключи компиляции для разных файлов проекта, и #pragma и много чего еще. Что-то переносимо между реализациями, что-то нет. Абсолютно ничего страшного. А весь мой спич исключительно по теме, заданной автором.
Я прекрасно понимаю ПОЧЕМУ оптимизатор так сделал. Ровно так же понимаю почему при оптимизации под минимальный размер он агрессивно выискивает что бы вынести в функцию. Почему при оптимизации на скорость меняется порядок присвоений. Опять же - мне, для моих частных задач, часть решений кажутся спорными. Но мои задачи очень частные. Даже с позиции "железяного" использования языка. И да, опыт позволяет находить и исправлять их достаточно быстро.
Что до конкретного примера автора - то для учебных целей было бы куда полезнее конструкции типа a=x/(x-1), а еще лучше a=x/(x-y). У них не было бы таких проблем, и к реальности они были бы сильно ближе. Но, при всем при этом, мне бы очень хотелось, чтобы с -O0 (или ее аналогами) компилятор четко выполнял пожелания автора и ни на шаг не отступал то того, что написано в программе. Как по мне, вполне справедливая хотелка. Но только она и ничего больше.
Последовательность операций, важная для правильной инициализации оборудования. Формально компилятор имеет право, по факту при определенных ключах поведение железа ломается. Избыточное выделение функции, в тех местах где я борюсь за производительность и пишу линейный код. Оно не ломает видимое поведение, но роняет производительность. И это только то, что на поверхности. К сожалению, это норма жизни. И отлавливается (а за одно исправляется) очень сложно.
Почему не меняет? Как раз меняет. Достаточно посмотреть на ассемблерных код, получаемый из указанного примера.
И я серьезно не понимаю чем позиция автора "не железячная". Впрочем, я свое видение того, как это стоило бы показать детям приводил. (x/x) действительно очень плохой пример. Во всех смыслах этого слова. И даже безотносительно языка программирования.
Потом переделываем процессоры, чтобы они такие глупости не делали, а клали в вещественный, нечего остатку пропадать.
Ты не поверишь (с), но в большинстве известных мне архитектур остаток не пропадает. А путь для работы оптимизатора в конструкциях типа
int a,b,c,d;
...
c = a/b;
d = a%b;
вполне очевиден. В отличии от операций с вещественными числами.
Вы можете продолжать думать, что код на C++ написан для оборудования, я вряд ли в силах вас переубедить.
Я, если уж меня спрашивают, считаю что для работы с аппаратурой создан язык С. Плюсы - это работа с математическим описанием объектов реального мира. Первое меня кормит. Второе... В лучшем случае хобби. И я бы очень не хотел ставить знаки даже приближенного равенства между этими двумя задачами. Они просто разные.
С того, что в программе на Си нельзя выразить вашу хотелку. Пишите ассемблерную вставку.
Я утащу это в список цитат. Про остальное - сдвиг отрицательных чисел тоже не просто так UB. И те, кто работает с реальным железом об этом знают. К сожалению, авторы компиляторов... Впрочем, не будем о грустном.
P.S.
Впрочем, доля правды есть. На С переносимо очень сложно поймать overflow/underflow. И не только это. И тут да - не все хотелки можно.
Вы упускаете из внимания тот факт, что программу вы пишете не для оборудования.
Интересно. А я думал, что мне, embedder'щику, деньги платят ровно за это. И язык С создавался как "переносимый ассемблер"... Я бы позволил такие вольности плюсам. Они, обычно, сильно дальше от аппаратуры. Но классическому, безплюсовому С... Это уже перебор.
Проверьте, если GCC под них собирать умеет.
Прямо сейчас в доступе нет. Да и специфика тамошней аппаратуры накладывает некоторые ограничения на использование scanf/printf. Но при случае проверю. Не забуду - отпишусь с результатами.
Приведите мне, пожалуйста, пример, при котором это имеет смысл в целочисленном делении. По мимо вашего желания запихнуть в регистр 0xFF, на него я уже ответил.
Т.е. все таки цензура. Вариант "потому, что могу" не катит. Малоли что ты можешь - высший разум считает что не нужно.
Вы ограничиваете мою свободу, как автора? В другом мире это называется словом цензура и сильно не приветствуется. Я не говорю что так правильно. Я говорю что так можно - аппаратура это не запрещает. А любой компилируемый код, в конце концов работает именно на аппаратуре. Даже если кому-то кажется по другому.
Компилятор ничего не додумывает, да и на намерения художника ему все равно.
Первое хорошо, но не соответствует действительности. А второе очень плохо - намерения художника для него обязаны быть четким приказом, а не поводом для принятия собственного решения.
выбирает (в лице людей его написавших) оптимальный путь в рамках оборудования и формальной системы, которой является язык.
Я не против, чтоб деление или умножение на 2^n заменяли сдвигом - все в рамках. Но если я пишу x/x то это означает именно то, что мне НЕОБХОДИМО поделить x на x. И я, как автор, понимаю как это будет работать на конкретной аппаратуре. И ожидаю вполне конкретный выхлоп от компилятора и реакцию оборудования. Я не нарушаю ни правила для оборудования, ни правила формальной системы. С чего вдруг не делается то, что нужно мне как автору?
То же про volatile - к сожалению очень часто приходится пользоваться этим указанием там, где оно не должно стоять в принципе. Это приводит к крайне плохому стилю написания кода, когда оное указание ставится "на всякий случай". Что в корне неправильно.
Либо берете в руки asm.
Да, и именно избыточная оптимизация и приводит к тому, что ассемблерных вставок еще хватает. Там, где реально надо то, что я хочу как автор (и гарантии того, что следующая версия компилятора точно ничего не сломает), ничего другого и не остается.
Впрочем, SUN еще в далеком 2008-ом с гордостью рассказывала о том, что мы теперь оптимизируем и ассемблерные вставки. Мы лучше знаем - у нас есть контекст окружения. А недовольны - используйте volatile asm {}; Так что лучше отдельным файлом.
Ну да - та самая детская уверенность. Мы лучше взрослых все знаем... И взрослая улыбка в ответ: "Ок! Действуй! Пока сам шишек не набъешь все равно не поймешь". Так что пусть не страдает. Страдать будет позже, когда подрастет.
Дайте ссылку на компилятор Rust для PIC и AVR. А еще для AIX, beOs, OS/2 и MSDOS (а еще Windows 3.1, QnX и прочего зооларка и бестиария возможных осей и архитектур).
Нет, он не умер молодым. Но в лучшем случае детский сад с отличием закончил. А доживет ли хотя бы зрелости - это мы еще посмотрим.
А это, на самом деле, очень спорный вопрос. Дело компилятора транслировать код в язык аппаратуры. И если автор желает делить на ноль - на здоровье. Дели. И уже аппаратура будет решать что делать. А решить она может по разному. Например 8051 выставит флаги и (сюрприз!) неопределенный результат (который обычно 0xFF, но это не точно). АVR и PIC даже флагами не пошевелят, правда выставят 0xFF. ARM кинет исключение. Собственно это и есть причина, по которой в С это UB.
И не дело компилятора додумывать что я, как автор, хочу в данном месте. Может мне надо таким вот образом 0xFF в регистры на AVR поместить. Или флажки выставить на PIC. Или принудительно в исключение свалиться. Я автор - мне решать. А компилятор... Может помочь - замечательно. Но мешать не надо.
Да что вы прицепились к стандарту языка, которому уже много лет. Он пережил разный endian, разную разрядность и много чего еще. Все его UB просто следствие необходимости работы в очень разном окружении, которое не ограничивается Linux на amd64/arm64. Проблема не в стандарте. Проблема в избыточной оптимизации, ломающей логику работы. А подобные проблему будут у абсолютно любого языка, когда он достигнет зрелости. Только вот... Большинство умирает молодыми и просто не доживут до этой прекрасной поры. Ну устаю повторять про python при переходе со 2-ой на 3-ю версию. Он уже поломался. В отличии от дряхлого старичка, который держится.
Впрочем - ну его нафиг. Я не буду ввязываться в очередной раз в эти войны. Вообще учить детей сегодня С или плюсам - ну так себе идея. Сюда надо ЗАХОТЕТЬ погрузиться. Это очень специфические языки для очень специфических задач. Это не то, с чем есть шанс случайно встретиться. Удел инженеров. С старом смысле этого слова.
Интересное мнение. Вот только нет ли здесь подмены понятий? Держаться за написанные тобой строки можно ведь не только потому, что это твой шедевр. Причина может быть проще - они формирую архитектуру, решают запросы пользователя, обеспечивают возможность масштабирования. Взять и легко позволить их стереть ради решения сиюминутной задачи, корни которой покоятся совсем в другом месте - разве это профессионализм?
Код Doom анализируется до сих пор. Особенности реализации Elite пример бережного отношения к ресурсам. Да, ремесленников надо больше, чем творцов. Но плох тот солдат, который не мечтает стать генералом - в смысле плох тот ремесленник, который не мечтает стать творцом. А то, что получается не у всех - так это не страшно.
Точно, после подсказки о то, что "Артур – гик и фанат научной фантастики", и наличии цифр 2 и 4 ответ становится очевидным без всякой математики и криптографии. Социальная инженерия собственной персоной.
Точно точно. Особенно если ты назвал эту функцию "погружение на грубину" и вдруг она зачем-то оказывается почти в центе пустыни. Реверс - он такой.
Сергей, тогда единственный вопрос - а это было озвучено пациенту? При чем вот ровно в таком виде? У меня есть полипы. Который год наблюдаем - не растут. Когда обнаружили был вопрос ко мне - удаляем? Я спросил каковы риски для обоих случаев. И все... Выяснилось, что это мое решение и моя ответственность. А какого решения вы ждете от меня? Я даже не с жалобами пришел - просто скринингом накрыло. Мне жить не мешает. Сказали раз в год проверять - ну проверяю. Было бы сказано "жить с этим - все равно что жить на пороховой бочке - до сих пор не рвануло, но гарантии что прямо сейчас не рванет не даст никто" - да и рассуждать бы не стал.
Ну и чисто технический момент. Хорошо, решил я удалять. И куда? Я примерно представляю себе что мне скажут в государственной поликлинике. Да-да, то самое "вот убьют, тогда и приходите". Т.е. по сути, государственная страховая медицина не считает это состояние настолько опасным, что требуется экстренное вмешательство. А почему тогда негосударственная считает по другому? Опять же - общемировая практика. Хорошо, а примеры можно? Вот так, чтоб четко - обнаружили значит удаляем?
Мне кажется несколько некорректным сравнивать указанные вами сущности. Хотя...
Обычному человеку сложно сравнивать риски закупорки с рисками последствий хирургии. А врачи, в частности авторы, сваливают ее на пациента. У которого нет специальных знаний. Больше чем уверен - если бы доктор четко сказал прямо: "риски ходить с камнем превышают риски от хирургии и ее последствий", то тот же IT'шник легко лег бы под нож. С прививками, конечно, ситуация схожая. И есть множество врачей, которые буквально отговаривают от прививок. Что как минимум порождает уверенность в том, что "даже врачи ни в чем не уверены". А часто рождает уверенность в безусловной вредности прививок. Т.е. по сути да - хотел поспорить, но похоже соглашаюсь...
В целом со статьей получается странная ситуация - мы убежали от ответственности, но при этом пугаем окружающих. Как по мне это просто некрасиво.
"История одного пациента" - уважаемая СМ-клиника, а как на счет истории множества других пациентов? Многие из которых живут годами с полипами и камнями, многие из которых при этом ведут нормальный образ жизни а не настолько специфический как у указанного пациента. Жути целенаправленно нагоняете, или просто случайно получилось?
Как и среди любых других групп людей. И естественно я выражаю исключительно свое видение, и надеюсь оно совпадает с видением профессионального сообщества разработчиков встраиваемых систем.
Мы привыкли к тому, что "в каждой избушке свои погремушки", и то же деление на ноль разные платформы обрабатывают по разному. Дайте даже не идею - дайте один рецепт пяти поварам и получите пять похожих, но разных блюд. Так и у нас - платформы похожи в целом, но различаются в деталях. Местами на эти детали можно наплевать, а местами их приходится учитывать. Более того, в большинстве случаев для нас крайне нежелательно сваливаться в исключения. Для нас не секрет, что набор машинных кодов у них разный, а значит разные и ассемблеры. А язык С для нас - это некоторый "усредненный ассемблер", который переводит написанное на нем в конкретный ассемблер архитектуры по вполне понятным правилам. И да - отпимизация для нас это не про "сделай меньше и быстрее", это про "делай что просят и не делай лишнего".
Фраза "могут реализовать по-разному, но должны реализовать хоть как-то, чтобы соответствовать стандарту" - она сродни привычному новоязу. Или есть четкий набор правил или его нет. Но конкретно нам, по сути, не важно. Для нас не новость, что одни и те же действия на разных платформах выполняются по разному и приводят к разным результатам. Это вполне привычный кактус. За то, уж если я прошу поделить X на X, то в соответствии с базовыми требованиями, теми самыми "делай что просят и не делай лишнего", я ожидаю что компилятор сделает именно это и сильно недоволен, если вдруг этого не случается. Мало ли зачем это может понадобится? В конце-концов набившее оскомину "xor x,x" или ее налог на С "x ^= x" вместо "ч = 0" не менее странная конструкция с точки зрения математики. И тем не менее она вполне себе применяется. И на это есть причины.
Сильное заявление. Но не правильное.
Если моя программа использует UB - она не перестает быть написанной на языке С. Она перестает быть переносимой. Нужна ли мне переносимость - зависит от множества факторов.
Но, именно для меня, она обычно важна в части переносимости между компиляторами (Keil, IAR, GCC), но не важна в части переносимости между платформами. Обычно я не хочу использовать код под Arm на AVR или наоборот. Зато есть желание писать код в коммерческих системах (Keil, IAR), но при этом иметь возможность собирать его рабочую версию Open Source инструментами (gcc). Потому UB (а вернее, как верно подсказали выше - platform specific realisation) - мне не страшно. Конечно, что при условии что все производители компиляторов его понимают одинаково.
Смотрите мой комментарий выше. Увы, но и без ключей, и с -O0 результат константа.
Человек который почувствовал ветер перемен должен строить не щит от ветра а ветряную мельницу (с)
Я не борюсь с ветряными мельницами. Я просто вижу естественное развитие языка. Как бы ни казалось адептам других богов, язык С продолжает развиваться. А тот факт, что его развитие не всегда идет в ногу с моими требованиями... Ну и ладно. Мне, в принципе, понятны механизмы которыми я могу добиваться нужного результата. Тут и ассемблерные вставки, и функции непосредственно на ассемблере, и набившая оскомину volatile, и разные ключи компиляции для разных файлов проекта, и #pragma и много чего еще. Что-то переносимо между реализациями, что-то нет. Абсолютно ничего страшного. А весь мой спич исключительно по теме, заданной автором.
Я прекрасно понимаю ПОЧЕМУ оптимизатор так сделал. Ровно так же понимаю почему при оптимизации под минимальный размер он агрессивно выискивает что бы вынести в функцию. Почему при оптимизации на скорость меняется порядок присвоений. Опять же - мне, для моих частных задач, часть решений кажутся спорными. Но мои задачи очень частные. Даже с позиции "железяного" использования языка. И да, опыт позволяет находить и исправлять их достаточно быстро.
Что до конкретного примера автора - то для учебных целей было бы куда полезнее конструкции типа a=x/(x-1), а еще лучше a=x/(x-y). У них не было бы таких проблем, и к реальности они были бы сильно ближе. Но, при всем при этом, мне бы очень хотелось, чтобы с -O0 (или ее аналогами) компилятор четко выполнял пожелания автора и ни на шаг не отступал то того, что написано в программе. Как по мне, вполне справедливая хотелка. Но только она и ничего больше.
Согласен, не самая правильная формулировка. Но...
Последовательность операций, важная для правильной инициализации оборудования. Формально компилятор имеет право, по факту при определенных ключах поведение железа ломается. Избыточное выделение функции, в тех местах где я борюсь за производительность и пишу линейный код. Оно не ломает видимое поведение, но роняет производительность. И это только то, что на поверхности. К сожалению, это норма жизни. И отлавливается (а за одно исправляется) очень сложно.
Почему не меняет? Как раз меняет. Достаточно посмотреть на ассемблерных код, получаемый из указанного примера.
И я серьезно не понимаю чем позиция автора "не железячная". Впрочем, я свое видение того, как это стоило бы показать детям приводил. (x/x) действительно очень плохой пример. Во всех смыслах этого слова. И даже безотносительно языка программирования.
Ты не поверишь (с), но в большинстве известных мне архитектур остаток не пропадает. А путь для работы оптимизатора в конструкциях типа
вполне очевиден. В отличии от операций с вещественными числами.
Я, если уж меня спрашивают, считаю что для работы с аппаратурой создан язык С. Плюсы - это работа с математическим описанием объектов реального мира. Первое меня кормит. Второе... В лучшем случае хобби. И я бы очень не хотел ставить знаки даже приближенного равенства между этими двумя задачами. Они просто разные.
Я утащу это в список цитат. Про остальное - сдвиг отрицательных чисел тоже не просто так UB. И те, кто работает с реальным железом об этом знают. К сожалению, авторы компиляторов... Впрочем, не будем о грустном.
P.S.
Впрочем, доля правды есть. На С переносимо очень сложно поймать overflow/underflow. И не только это. И тут да - не все хотелки можно.
Интересно. А я думал, что мне, embedder'щику, деньги платят ровно за это. И язык С создавался как "переносимый ассемблер"... Я бы позволил такие вольности плюсам. Они, обычно, сильно дальше от аппаратуры. Но классическому, безплюсовому С... Это уже перебор.
Прямо сейчас в доступе нет. Да и специфика тамошней аппаратуры накладывает некоторые ограничения на использование scanf/printf. Но при случае проверю. Не забуду - отпишусь с результатами.
Т.е. все таки цензура. Вариант "потому, что могу" не катит. Малоли что ты можешь - высший разум считает что не нужно.
Вы ограничиваете мою свободу, как автора? В другом мире это называется словом цензура и сильно не приветствуется. Я не говорю что так правильно. Я говорю что так можно - аппаратура это не запрещает. А любой компилируемый код, в конце концов работает именно на аппаратуре. Даже если кому-то кажется по другому.
Первое хорошо, но не соответствует действительности. А второе очень плохо - намерения художника для него обязаны быть четким приказом, а не поводом для принятия собственного решения.
Я не против, чтоб деление или умножение на 2^n заменяли сдвигом - все в рамках. Но если я пишу x/x то это означает именно то, что мне НЕОБХОДИМО поделить x на x. И я, как автор, понимаю как это будет работать на конкретной аппаратуре. И ожидаю вполне конкретный выхлоп от компилятора и реакцию оборудования. Я не нарушаю ни правила для оборудования, ни правила формальной системы. С чего вдруг не делается то, что нужно мне как автору?
То же про volatile - к сожалению очень часто приходится пользоваться этим указанием там, где оно не должно стоять в принципе. Это приводит к крайне плохому стилю написания кода, когда оное указание ставится "на всякий случай". Что в корне неправильно.
Да, и именно избыточная оптимизация и приводит к тому, что ассемблерных вставок еще хватает. Там, где реально надо то, что я хочу как автор (и гарантии того, что следующая версия компилятора точно ничего не сломает), ничего другого и не остается.
Впрочем, SUN еще в далеком 2008-ом с гордостью рассказывала о том, что мы теперь оптимизируем и ассемблерные вставки. Мы лучше знаем - у нас есть контекст окружения. А недовольны - используйте volatile asm {}; Так что лучше отдельным файлом.
Ну да - та самая детская уверенность. Мы лучше взрослых все знаем... И взрослая улыбка в ответ: "Ок! Действуй! Пока сам шишек не набъешь все равно не поймешь". Так что пусть не страдает. Страдать будет позже, когда подрастет.
Дайте ссылку на компилятор Rust для PIC и AVR. А еще для AIX, beOs, OS/2 и MSDOS (а еще Windows 3.1, QnX и прочего зооларка и бестиария возможных осей и архитектур).
Нет, он не умер молодым. Но в лучшем случае детский сад с отличием закончил. А доживет ли хотя бы зрелости - это мы еще посмотрим.
А это, на самом деле, очень спорный вопрос. Дело компилятора транслировать код в язык аппаратуры. И если автор желает делить на ноль - на здоровье. Дели. И уже аппаратура будет решать что делать. А решить она может по разному. Например 8051 выставит флаги и (сюрприз!) неопределенный результат (который обычно 0xFF, но это не точно). АVR и PIC даже флагами не пошевелят, правда выставят 0xFF. ARM кинет исключение. Собственно это и есть причина, по которой в С это UB.
И не дело компилятора додумывать что я, как автор, хочу в данном месте. Может мне надо таким вот образом 0xFF в регистры на AVR поместить. Или флажки выставить на PIC. Или принудительно в исключение свалиться. Я автор - мне решать. А компилятор... Может помочь - замечательно. Но мешать не надо.
Да что вы прицепились к стандарту языка, которому уже много лет. Он пережил разный endian, разную разрядность и много чего еще. Все его UB просто следствие необходимости работы в очень разном окружении, которое не ограничивается Linux на amd64/arm64. Проблема не в стандарте. Проблема в избыточной оптимизации, ломающей логику работы. А подобные проблему будут у абсолютно любого языка, когда он достигнет зрелости. Только вот... Большинство умирает молодыми и просто не доживут до этой прекрасной поры. Ну устаю повторять про python при переходе со 2-ой на 3-ю версию. Он уже поломался. В отличии от дряхлого старичка, который держится.
Впрочем - ну его нафиг. Я не буду ввязываться в очередной раз в эти войны. Вообще учить детей сегодня С или плюсам - ну так себе идея. Сюда надо ЗАХОТЕТЬ погрузиться. Это очень специфические языки для очень специфических задач. Это не то, с чем есть шанс случайно встретиться. Удел инженеров. С старом смысле этого слова.