Comments 23
void* memset( void* dest, int ch, std::size_t count ); // С
std::size_t
Эффект первой строки?) В С нет namespace std
Я вот недавно столкнулся с забавным приколом.
В QNX: void outb(int port, unsigned char value);
В Linux: void outb(unsigned char value,int port);
Ну и зачем такое было делать?
Зато сразу видно, какой вариант синтаксиса ассемблера кто предпочитает
А можно пригласить поставившему минус к дискуссии?
MASM:
out DX, AL
out imm, AL
GAS:
outb %AL,%DX
outb %AL, $imm
Два подхода на уровне опкодов - два подхода на уровне реализации в Си.
Я не тот, кто поставил минус, но в Си разница более существенная - разные версии функции бинарно несовместимы. А в ассембли из обоих вариантов ассемблится одна и та же бинарная инструкция
С другой стороны, а откуда вообще должно следовать, что это одна и та же функция, которая должна выглядеть одинаково? Эта функция (по факту наверняка интринсик) является частью стандартизированной апишки типа POSIX? Едва ли.
Следовательно, нет никаких причин смотреть на то, как сделано у других. Вопрос в другом: в конкретной платформе является ли апи внутренне консистентным?
В данном случае соглашусь с тем, что наименьшее удивление у разработчика будет, если разработчики более поздней апишки посмотрели бы на более раннюю и сделали так же, а не как всегда с мотивацией "там дураки, я сделаю лучшее решение".
Ошибка на 1 чаще всего появляется из из-за самой Microsoft, которая решила, что в одних функах WinAPI нужно считать с терминирующим нулём строки, а в других - без него. Итог из критичного: не учтёшь это, получишь недозатирание/перетирание других данных при копировании.
Например, я не стал упоминать про юнит-тесты, когда мы говорили о
функциях сравнения. Проверять их юнит-тестами — неблагодарное занятие:
Фокус в том, что в юнит-тестах тоже используется сравнение. И это тоже монотонная однообразная работа, что приводит к проблемам, характерным для описанных ситуаций "последней строки" и "функций сравнения". Что делать, куды бечь? Писать тесты для юнит-тестов?
Злополучная функция memset
Часто встречал случаи, когда при вызове меняют местами два последних параметра. Не знаю, что это, и чем это объяснить, но когда сталкиваешься с таким кодом, иногда даже становится непонятно, как оно вообще работало столько лет без замечаний, и как оно так у авторов кода получается.
С датой и временем ещё типичная ошибка - когда программисты думают, что в сутках 24 часа, забывая про перевод часов. Аналогично с константами 1440 минут в сутках и 86400 секунд. Но это не в 100% случаях ошибка. И часто проще ей пренебречь, чем переписывать на правильный код.
Расчёты с разными часовыми поясами - вот уж где огромное количество ошибок.
Сначала перевести все времена в UTC+0, а потом с ними все расчеты вести - этого недостаточно?
Ну и если в конце надо получить результат в нужном часовом поясе, то перевести в него.
база, до которой почему-то долго шли
недостаточно. Не смог быстро найти статью, она была, в частности, о том, что какой-нибудь delay(1000) может начаться в январе, а закончиться, например, в сентябре (если "удачно" перевели компьютер в какой-нибудь из режимов сна). И секунду в конце года могут добавить-убрать. И еще куча всяких сюрпризов.
Часто это почти ни на что не влияет, но вот Луну в Луну может внезапно поместить.
Без подробного описания непонятно, в чем именно проблема. Если алгоритм зависит от абсолютного значения времени/даты, это в принципе не очень хорошо.
От абсолютного значения времени зависит, например, положение объектов в солнечной системе...
Возможно, я ошибаюсь, но для расчёта положения объектов в космосе можно использовать время, не зависящее от земного и каких-либо часовых поясов, а также чудес календаря.
Совершенно верно. Для таких расчётов существует десяток своих систем счёта времени со своими приколами каждая. Они гарантированно монотонные и без разрывов, но не обязательно равномерные. А для перехода к "человеческим" есть такие вещи, как юлианские дни , поправки на эфемеридное время, редукции системы координат и времени, динамическое время и т.п.
Имхо, это уже довольно узкоспециализированные вещи, работу с которыми вряд ли можно отнести к часто встречающимся случаям опечаток и ошибок в программах на c++.
С одной стороны да, а с другой факапы могут быть и интереснее.
Отличный пример — Mars Climate Orbiter
Из Википедии
Из анализа данных было предположено, что аппарат прошел над поверхностью Марса на высоте 57 км вместо расчетных 110 км и распался в атмосфере. Столь большое отклонение было вызвано ошибкой в программном обеспечении: команды по тяге двигателя в программном обеспечении Mars Climate Orbiter использовали единицу измерения силы ньютон (международная система единиц (СИ)), в то время как программное обеспечение на Земле, которое создавало эти команды, использовало британскую единицу измерения (фунт-сила).
А зачем нужно неравномерное время в таких расчётах?
https://astro.tsu.ru/TGP/text/2_4.htm
Компенсация багов Вселенной :)
А если серьёзно, то в силу эффектов теории относительности время в разных СК течёт по-разному. Расчёты выполняются в системе координат центра масс Солнечной системы, а наблюдатель находится на Земле. Для перехода между СК также необходимо учитывать разный темп хода времени.
Также неравномерное время может использоваться для пересчёта с учётом конечности скорости света. Так, при наблюдении переменных звёзд используется шкала времени HJD (то есть JD, приведённые к Солнцу), которая для наблюдателя на Земле является неравномерной.
Распространённые паттерны опечаток при программировании