Comments 21
Часа два вчера думал о том, что же я забыл. Добавил абзац про дорогого Дядю Мишу.
+2
Motorola Droid 4. Эх, скучаю. Шикарнейшая клавиатура.
+3
>>> pchan->words[i] = pwords[i++];
Тут undefined behaviour, оно может в будущем сломаться и от другой версии Студии, например.
>>>Просто внезапно для себя открыл, что все char на ARM — беззнаковые.
А стандарт языка не специфицирует знаковость char. Компилятор вправе реализовать этот момент как ему удобнее. Странно, что где-то он знаковый, в большинстве компиляторов он как раз unsigned по умолчанию.
Тут undefined behaviour, оно может в будущем сломаться и от другой версии Студии, например.
>>>Просто внезапно для себя открыл, что все char на ARM — беззнаковые.
А стандарт языка не специфицирует знаковость char. Компилятор вправе реализовать этот момент как ему удобнее. Странно, что где-то он знаковый, в большинстве компиляторов он как раз unsigned по умолчанию.
+3
А расскажите про баг с умножением на 1
0
pandoralive.info/?p=5043
Вот тут точно описано. Баг исправил ptitSeb, который сильно помог с багами на ARM. Он занимается движоком на Pandora.
Вот тут точно описано. Баг исправил ptitSeb, который сильно помог с багами на ARM. Он занимается движоком на Pandora.
0
Это не бага ARM, это вполне себе бага разработчиков (оригинальной версии). У них там плавающая арифметика считается с точностью single float. Но на x86 на некоторых компиляторах плавающие числа всё равно считались с точностью 80 бит (внутреннее представление FPU), а потом конвертировались (округлялись) к нужно точности.
А на ARM всё считается с указанной точностью (более того, никто не обещает даже double float на ARM) и повылазили ошибки округления. Ровно с тем же успехом они бы повылазили и на x86 с другим компилятором или с другими ключами сборки, т.к. компилятор по факту отклонялся от стандарта в данном случае.
Более того, кажется, что там алгоритмическая/архитектурная ошибка и патч не исправляет её полностью — пропадают лишь самые явные проявления, но, возможно, что это не критично.
А на ARM всё считается с указанной точностью (более того, никто не обещает даже double float на ARM) и повылазили ошибки округления. Ровно с тем же успехом они бы повылазили и на x86 с другим компилятором или с другими ключами сборки, т.к. компилятор по факту отклонялся от стандарта в данном случае.
Более того, кажется, что там алгоритмическая/архитектурная ошибка и патч не исправляет её полностью — пропадают лишь самые явные проявления, но, возможно, что это не критично.
0
>char на ARM — беззнаковые
Используйте int8_t (или аналоги из SDL) и ваши волосы будут мягкие и шелковистые
Используйте int8_t (или аналоги из SDL) и ваши волосы будут мягкие и шелковистые
+2
Это существующий код. Я все же стараюсь делать так, чтобы работало оно везде.
+1
Не очень понятно, почему вдруг fixed-width типы должны где-то не работать.
0
Пока не посмотришь скриншоты, из текста совершенно невозможно понять при чем здесь собственно Half-Life :)
0
Про баг с одинаковыми именами:
Насколько я помню, в Visual Studio при правильном подборе заголовочных файлов и дефайнов max(a, b) является макросом с содержанием в духе (((a) > (b))? (a): (b)). Это объясняет, почему данная строка компилируется (в правой части скобки есть, и поэтому max развернулся в тело соответствующего макроса, в левой остался, как был, переменной max).
Особо приятной плюшкой такого макроса является черт знает какое поведение, когда выражения a и b имеют сайд-эффекты при вычислении, или, что еще хуже, когда макрос используется в рекурсии (легкой подстановкой макроса время исполнения функции из логарифмического становится экспоненциальным!)
max = max( max( r, g ), b );
Насколько я помню, в Visual Studio при правильном подборе заголовочных файлов и дефайнов max(a, b) является макросом с содержанием в духе (((a) > (b))? (a): (b)). Это объясняет, почему данная строка компилируется (в правой части скобки есть, и поэтому max развернулся в тело соответствующего макроса, в левой остался, как был, переменной max).
Особо приятной плюшкой такого макроса является черт знает какое поведение, когда выражения a и b имеют сайд-эффекты при вычислении, или, что еще хуже, когда макрос используется в рекурсии (легкой подстановкой макроса время исполнения функции из логарифмического становится экспоненциальным!)
0
Прошло всего каких-то 4 года, и все ссылки на гитхаб протухли. Эх, груздь-пищаль...
0
Only those users with full accounts are able to leave comments. Log in, please.
Как создавался кроссплатформенный Half-Life или «Хедкрабы внутри ваших часов»