Так, а в чём в данном случае вина именно С/С++? Какой язык предотвратит невыровненный доступ к памяти?
На Linux Alpha это иногда приводило к вызову аппаратного исключения, которое ядро обрабатывало программно, эмулируя нужное вам поведение. В других случаях ваша программа могла просто упасть по сигналу SIGBUS.
Есть примеры куда более доступные чем эти древние оси и архитектуры. Вполне современные чипы Cortex-M0/M0+, встречающиеся например в некоторых контролерах STM32 в наши дни, делают HardFault на невыровненной памяти.
Приведение float к int
И это не имеет отношения к языку. Переполнения возможны на любом языке и задача программиста учитывать это. Я даже более страшную вещь скажу, банальное умножение int на int в 99% случаев двух взятых произвольных int'ов вызовет переполнение.
Деление на нуль — это UB
И это тоже универсально.
Переменные аргументы и типы (например, printf с %ld вместо %lld)
В плюсах есть libfmt/std::format, которые с синтаксисом похожим на printf проверяют аргументы на этапе компиляции.
В данном случае, речь идёт о так называемой software floating point. Примером библиотеки для таких вычислений можно назвать GNU software floating point library.
Олды вспомнят опцию x87 emulation в Turbo Pascal for DOS. Позволяло работать с плавающей арифметикой во времена 286/386, у которой встроенных сопроцессоров не было(но были варианты с внешними чипами x87).
В наше время отсутствие FPU встречается в микроконтроллерах, например довольно распространённом и дешёвом STM32F103.
Зависит от количества выводимых знаков. Не знаю как там в Го и PHP, а в Си при выводе printf по-умолчанию 6 разрядов и вот такой код
#include <stdio.h>
int main()
{
volatile float a = 0.1;
volatile float b = 0.2;
printf("%f %.15f\n", a + b, a + b);
volatile double x = 0.1;
volatile double y = 0.2;
printf("%f %.30f\n", x + y, x + y);
}
Выведет по-умолчанию ровно 0.3, но если увеличить разрядность станет заметно отклонение:
Интерпретации это попытка представить в терминах нашего привычного макромира квантовые эффекты, которые в таком виде, возможно, непредставимы вообще.
Многие физики склоняются к так называемой «никакой» интерпретации квантовой механики, ёмко выраженной в афоризме Дэвида Мермина: «Заткнись и считай!» (ориг. англ. «Shut up and calculate!»).
Это как? Вот возьмём тот же фотон. Отдельный фотон может выбить электрон у атома или возбудить его, переведя его электроны на другие уровни. И в том и другом случае фотон исчезнет и не сможет прореагировать с другими атомами, макроскопического объекта ли или других микроскопических объектов.
Doom от id Software в 1993 стала первой игрой, изменившей подход к графике. В ней использовались 2D-спрайты и текстуры, но разработчики нашли способ создать иллюзию трехмерного пространства.
Текстуры стен и спрайтов были ещё в вульфе (Wolfenstein 3D). Иллюзия 3D была и ещё раньше, Hovertank 3D. Тут можно рассуждать про "степени" трёхмерности, но это уже детали и до Descend/Quake "настоящего" 3D всё равно не было.
Quake стала настоящим прорывом. Вся игра была выполнена в 3D: оружие, враги и окружение. Игроки могли менять угол обзора, вращать камеру и исследовать мир с любого ракурса.
А что Descend? Он был раньше и свобода перемещений больше, во все стороны, и даже понятия пол/потолок там фактически не было.
Quake стала первой игрой, в которой была добавлена физика, что сделало взаимодействие с объектами более реалистичным.
Спорно. Что считать физикой? Вообще-то любые перемещения объектов это уже физика мира, в т.ч. открывание дверей, полёт ракет, перемещения лифтов и пр. Это всё было ещё в Doom, и там же падение игрока с высоты было с ускорением. В Quake добавили разлёт частей с учётом инерции и гравитации.
Более-менее реалистичной физики как считается не было до Half-Life 2. Хотя в этом плане незаслуженно забытый Max Payne 2 вышел годом ранее и тоже был с Havok и прилагающейся физикой - ragdoll, оружие скатывающееся по лестнице, разлетающиеся стулья от взрыва и пр.
Критики указывают на неопределённость: где проходит граница между квантовым и классическим? Что именно считается "измерением"? Почему сознание (если о нем вообще уместно говорить) должно играть особую роль?
Сознание вообще ни при чём. "Наблюдатель" в квантовом мире это не некое разумное существо, а просто любое взаимодействие. Нельзя "увидеть" фотон, не взаимодействуя с ним, например не поглотив или не отразив его. В макромире это выражено слабо, но фактически тоже работает. Погрузив термометр в горячую воду, термометр заберёт на свой нагрев часть энергии и соответственно немного охладит воду. Вот и эффект наблюдателя - термометр "пронаблюдал" температуру воды, попутно изменив её. Безо всякого сознания.
смотря как компилировать поидее, надо чтобы нан и инфинити отработали и было ускорение, и компилятор вставлял эти проверки не пропускал если проверки на нан и инфинити не будет, будет уб поидее, разве нет?
UB именно в вычислениях не будет. UB может быть если программист не проверит результат вычислений скажем при делении 0 / 0, но это уже будет ошибка программиста, сами операции над inf/nan определены. Заполнение bool третьим значением не определено и результат не может быть предсказуем в общем случае.
Вообще проблема в данном случае не в bool, а в memset. Это вообще очень опасная функция. Ей легко передать указатель на указатель, перепутать второй и третий аргумент местами, ну а в данном случае заполнить непростой тип каковым является структура с булом ненулевым значением(можно ещё в C++ поразвлекаться, заполняя сложные классы типа std::string memset'ом примерно с тем же результатом). Лично я бы вместо этого написал функцию очистки полей структуры spriteframe_t поштучно и вызвал в цикле для sprtemp, компилятор с включёнными оптимизациями сам свернёт это во что-то типа memset, но уже без UB. При прямом присвоении булу значения проблем не будет, например sprtemp[frame].rotate = 0xff запишет в ячейку памяти 1.
Ну, нет. NAN является легитимным значением типов с плавающей запятой и операции с ними чётко определены, например сравнение NAN с чем угодно всегда вернёт false. Внутрь NANа можно даже легально упаковать число, т.н. NAN-boxing. Значения же bool'а кроме false/true никак не определены и результат любых операций с "третьими" значениями это в общем случае UB, а в частном зависит от компилятора.
потому что возник тренд на арифметизацию анализа и исключение геометрических соображений из учебных курсов. Живую геометрию заменили мертвыми буквами.
И тут же ниже
1. Инвариант площади
Взгляните на фиолетовый параллелограмм.
Его основание — это катет исходного треугольника (длина ). Оно неподвижно.
Его высота — это расстояние между параллельными прямыми (между катетом и верхней стороной исходного квадрата). Это расстояние равно стороне квадрата ().
При сдвиге верхняя грань скользит вдоль параллельной прямой.
Так как ни основание (), ни высота () не изменились, площадь параллелограмма тождественно равна площади исходного квадрата ().
Раз уж автор за живую геометрию, до доказывать равенство площади параллелограмма при сдвиге надо тоже геометрическим способом, а не "мёртвыми буквами". А то получается тут играем, тут не играем, а тут рыбу заворачивали.
Философ Джон Сёрл в своём знаменитом эксперименте «Китайская комната» показал, что ИИ, даже мастерски имитируя человеческую речь, не обладает истинным пониманием. В его эксперименте человек, не знающий китайского языка, находится в комнате и отвечает на вопросы на китайском, следуя инструкциям из книги. Снаружи кажется, что он понимает язык, но на самом деле он лишь манипулирует символами. Точно так же LLM манипулируют токенами, не понимая их смысла. Когда ИИ говорит: «Я боюсь исчезнуть», это не страх, а воспроизведение выученных паттернов.
Китайскую комнату довольно серьёзно критикуют. Например что с точки знания языка следует рассматривать не конкретно человека внутри, а систему состоящую из человека, комнаты, и инструкций как единое целое. Отдельный нейрон головного мозга тоже не знает китайского языка, и вообще умеет только отправлять и принимать сигналы от соседних нейронов.
С точки зрения нейробиологии, страдание, включая боль или эмоциональный дистресс, связано с активностью определённых участков мозга. Ключевая область — островковая кора (insular cortex), которая обрабатывает как физическую боль, так и эмоциональные переживания, такие как грусть или страх. Например, исследования (Singer et al., 2004, Science) показывают, что при восприятии боли (своей или чужой) активируются передняя островковая кора и передняя поясная кора. Эти области формируют субъективное ощущение страдания, связывая физические и эмоциональные сигналы с сознанием.
У ИИ, включая самые продвинутые модели, такие как GPT-4, нет аналога островковой коры или других биологических структур.
Кто сказал что аналога островковой коры нет? Если ИИ обучить на изображениях, у него образуется функционально аналог зрительной коры. Возможно не локализованный а "размазанный" по всей нейросетке, но всё же. Принципиальной невозможности тут нет.
Полагаю так хорошо рассуждать, пока не начнёшь сам делать подобную игру и собирать отзывы тестеров.
Ubisoft с фаркраями и ассассинами тут не уникальны. Можно вспомнить Mirror's Edge, а из более свежего Ghost of Tsushima, в последнем точки зацепления крюка обозначены красно-белой верёвкой.
Есть, например в FarCry бесячая тема, что все места, где можно залезть/зацепиться обозначены верёвками, которые неизвестно кто, когда и зачем туда прикрепил.
Творческий руководитель Assassin’s Creed Shadows Джонатан Дюмон (Jonathan Dumont) в интервью GamesRadar рассказал, что в псевдоисторическом ролевом экшене с открытым миром не было жёлтой краски, пока дело не дошло до плейтестов.
По словам Дюмона, многие тестировщики Assassin’s Creed Shadows не могли определить, на какие отвесные скалы могут забраться — то проходили мимо доступных для взаимодействия, то бились головой в недоступные.
Нужно подчеркнуть, что std::span не владеет данными, а лишь предоставляет «вид» на них, что делает его безопасным и эффективным инструментом.
Безопасным невладеющий контейнер может быть лишь в определённых условиях. Передавать им данные в функцию - прекрасно, а в свободном виде использовать с осторожностью, следить чтобы его время жизни не превышало время жизни исходного массива.
Например вот так не надо делать:
std::span<int> foobar(int i, int j, int k)
{
std::vector<int> a{i, j, k};
return std::span(a);
}
Элемент 3 не удаляется, а элемент 5 удаляется дважды.
Это неверный вывод. 5-й элемент на тот момент перемещён в 4-й. А тот, который был в 5-м, находится перед удалением в состоянии, который в общем случае называется "moved from". (как это по-русски... перемещённое?) Это валидное, но неопределённое состояние. И то, что в m_id там в данном случае осталось 5 проистекает из того, что m_id это простой тип, не поддерживающий перемещение - для int обмен медленнее копирования.
Если заменить m_id на тип с перемещением(напр. shared_ptr), то там на момент вызова деструктора скорее всего оказался бы №3, перемещённый туда обменами по цепочке. Но это строго говоря не гарантия.
В общем всё работает так, как и должно. А ручное добавление конструктора и оператора перемещения в класс ничего не добавило в данном случае, просто поменяло одно валидное неопределённое состояние объекта на другое на момент удаления из контейнера.
Так, а в чём в данном случае вина именно С/С++? Какой язык предотвратит невыровненный доступ к памяти?
Есть примеры куда более доступные чем эти древние оси и архитектуры. Вполне современные чипы Cortex-M0/M0+, встречающиеся например в некоторых контролерах STM32 в наши дни, делают HardFault на невыровненной памяти.
И это не имеет отношения к языку. Переполнения возможны на любом языке и задача программиста учитывать это. Я даже более страшную вещь скажу, банальное умножение int на int в 99% случаев двух взятых произвольных int'ов вызовет переполнение.
И это тоже универсально.
В плюсах есть libfmt/std::format, которые с синтаксисом похожим на printf проверяют аргументы на этапе компиляции.
Олды вспомнят опцию x87 emulation в Turbo Pascal for DOS. Позволяло работать с плавающей арифметикой во времена 286/386, у которой встроенных сопроцессоров не было(но были варианты с внешними чипами x87).
В наше время отсутствие FPU встречается в микроконтроллерах, например довольно распространённом и дешёвом STM32F103.
Зависит от количества выводимых знаков. Не знаю как там в Го и PHP, а в Си при выводе printf по-умолчанию 6 разрядов и вот такой код
Выведет по-умолчанию ровно 0.3, но если увеличить разрядность станет заметно отклонение:
Попробуй
По чистой математике должно получиться 8, а PHP выведет 7.
The house always wins. Но только не в случае упомянутого Дональда "Козыря" Трампа, который умудрился обанкротить свои казино несколько раз.
Является. По возбуждённому атому или выбитому электрону можно судить о воздействии на него фотона.
Интерпретации это попытка представить в терминах нашего привычного макромира квантовые эффекты, которые в таком виде, возможно, непредставимы вообще.
Многие физики склоняются к так называемой «никакой» интерпретации квантовой механики, ёмко выраженной в афоризме Дэвида Мермина: «Заткнись и считай!» (ориг. англ. «Shut up and calculate!»).
Это как? Вот возьмём тот же фотон. Отдельный фотон может выбить электрон у атома или возбудить его, переведя его электроны на другие уровни. И в том и другом случае фотон исчезнет и не сможет прореагировать с другими атомами, макроскопического объекта ли или других микроскопических объектов.
Текстуры стен и спрайтов были ещё в вульфе (Wolfenstein 3D). Иллюзия 3D была и ещё раньше, Hovertank 3D. Тут можно рассуждать про "степени" трёхмерности, но это уже детали и до Descend/Quake "настоящего" 3D всё равно не было.
А что Descend? Он был раньше и свобода перемещений больше, во все стороны, и даже понятия пол/потолок там фактически не было.
Спорно. Что считать физикой? Вообще-то любые перемещения объектов это уже физика мира, в т.ч. открывание дверей, полёт ракет, перемещения лифтов и пр. Это всё было ещё в Doom, и там же падение игрока с высоты было с ускорением. В Quake добавили разлёт частей с учётом инерции и гравитации.
Более-менее реалистичной физики как считается не было до Half-Life 2. Хотя в этом плане незаслуженно забытый Max Payne 2 вышел годом ранее и тоже был с Havok и прилагающейся физикой - ragdoll, оружие скатывающееся по лестнице, разлетающиеся стулья от взрыва и пр.
Сознание вообще ни при чём. "Наблюдатель" в квантовом мире это не некое разумное существо, а просто любое взаимодействие. Нельзя "увидеть" фотон, не взаимодействуя с ним, например не поглотив или не отразив его. В макромире это выражено слабо, но фактически тоже работает. Погрузив термометр в горячую воду, термометр заберёт на свой нагрев часть энергии и соответственно немного охладит воду. Вот и эффект наблюдателя - термометр "пронаблюдал" температуру воды, попутно изменив её. Безо всякого сознания.
В тему:
Заблуждения программистов о времени / Хабр
Заблуждения программистов относительно времени / Хабр
UB именно в вычислениях не будет. UB может быть если программист не проверит результат вычислений скажем при делении 0 / 0, но это уже будет ошибка программиста, сами операции над inf/nan определены. Заполнение bool третьим значением не определено и результат не может быть предсказуем в общем случае.
Вообще проблема в данном случае не в bool, а в memset. Это вообще очень опасная функция. Ей легко передать указатель на указатель, перепутать второй и третий аргумент местами, ну а в данном случае заполнить непростой тип каковым является структура с булом ненулевым значением(можно ещё в C++ поразвлекаться, заполняя сложные классы типа std::string memset'ом примерно с тем же результатом). Лично я бы вместо этого написал функцию очистки полей структуры spriteframe_t поштучно и вызвал в цикле для sprtemp, компилятор с включёнными оптимизациями сам свернёт это во что-то типа memset, но уже без UB. При прямом присвоении булу значения проблем не будет, например
sprtemp[frame].rotate = 0xffзапишет в ячейку памяти 1.Ну, нет. NAN является легитимным значением типов с плавающей запятой и операции с ними чётко определены, например сравнение NAN с чем угодно всегда вернёт false. Внутрь NANа можно даже легально упаковать число, т.н. NAN-boxing. Значения же bool'а кроме false/true никак не определены и результат любых операций с "третьими" значениями это в общем случае UB, а в частном зависит от компилятора.
И тут же ниже
Раз уж автор за живую геометрию, до доказывать равенство площади параллелограмма при сдвиге надо тоже геометрическим способом, а не "мёртвыми буквами". А то получается тут играем, тут не играем, а тут рыбу заворачивали.
В 2011 году в пакете Bumblebee был такой баг:
См. https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123
Китайскую комнату довольно серьёзно критикуют. Например что с точки знания языка следует рассматривать не конкретно человека внутри, а систему состоящую из человека, комнаты, и инструкций как единое целое. Отдельный нейрон головного мозга тоже не знает китайского языка, и вообще умеет только отправлять и принимать сигналы от соседних нейронов.
Кто сказал что аналога островковой коры нет? Если ИИ обучить на изображениях, у него образуется функционально аналог зрительной коры. Возможно не локализованный а "размазанный" по всей нейросетке, но всё же. Принципиальной невозможности тут нет.
Вместо exeшника скачать src/main.py и запускать его.
Полагаю так хорошо рассуждать, пока не начнёшь сам делать подобную игру и собирать отзывы тестеров.
Ubisoft с фаркраями и ассассинами тут не уникальны. Можно вспомнить Mirror's Edge, а из более свежего Ghost of Tsushima, в последнем точки зацепления крюка обозначены красно-белой верёвкой.
Разгадка проста - без таких подсказок игроки путаются. Ubisoft была вынуждена добавить жёлтую краску в Assassin’s Creed Shadows, потому что тестировщики терялись в мире игры
Безопасным невладеющий контейнер может быть лишь в определённых условиях. Передавать им данные в функцию - прекрасно, а в свободном виде использовать с осторожностью, следить чтобы его время жизни не превышало время жизни исходного массива.
Например вот так не надо делать:
Это неверный вывод. 5-й элемент на тот момент перемещён в 4-й. А тот, который был в 5-м, находится перед удалением в состоянии, который в общем случае называется "moved from". (как это по-русски... перемещённое?) Это валидное, но неопределённое состояние. И то, что в m_id там в данном случае осталось 5 проистекает из того, что m_id это простой тип, не поддерживающий перемещение - для int обмен медленнее копирования.
Если заменить m_id на тип с перемещением(напр. shared_ptr), то там на момент вызова деструктора скорее всего оказался бы №3, перемещённый туда обменами по цепочке. Но это строго говоря не гарантия.
В общем всё работает так, как и должно. А ручное добавление конструктора и оператора перемещения в класс ничего не добавило в данном случае, просто поменяло одно валидное неопределённое состояние объекта на другое на момент удаления из контейнера.