thambs писал: то этот r1 изредка почти лежит на границе и пересечение не детектируется
Либо где-то стоит ">" вместо ">=", либо снижена точность математики.
Ты во флоатах или в даблах считаешь?
_controlfp юзаешь?
Проблемы только в релизе или в дебаге тоже?
Получение (и изменение) контрольного слова сопроцессора. В частности, точность арифметики с плавающей точкой. Проверь, может она у тебя снижена в релизе (компилятор постарался).
Контрольные значения, брекпоинты. Иногда в Релиз моде выдает ошибку не там где надо, тогда помогает Дебаг Мод, а иногда в Релизе крашится, а Дебаге работает, тогда чуть посложнее. Если проблемы с памятью, могу подключить Visual Leak Detector иль PVS studio.
Дядя Миша
На линупсе гцц - пожалуй, лучшее, что есть для плюсов.
Это когда кучи шаблонов и прочего гамна.
Для обычного си, имхо, особой разницы между конпилерами нет, ну окромя ICL, который сам умеет все известные SSE (но он платный, и разумеется, оптимизирует исключительно под интеловские процы).
Добавлено 05-04-2013 в 22:48:
Я под виндой проекты на С торадиционно конпилю MinGW, а на С++ - десятой студией. Под линупсом только GCC.
Добавлено 05-04-2013 в 22:49:
Кстати, консольный gdb очень понравился. И gprof тоже ничего. Но опять же - только для си-кода (рейтрейсеры там всякие и тому подобное). Навороченные проекты с классами и шаблонами я таки под студией дебажу.
сместо ma стояло na. величины отличаются на ~30 порядков, причём результирующий эффект сам себя компенсирует так что заметить его очень трудно. две суток счёта коту под хвост. убейте меня кто ни будь.
С тех пор как начал мучить язык D, теперь в Си вставляю ассерты и пишу юниттесты, хотя на уровне языка такой поддержки нет.
Насчёт имён - XaeroX дело говорит. Понимаю, что в книжечках по матану алгоритмы наверно так и описаны, но в программировании всё-таки другие правила. И кстати, в книжках по математике из-за таких коротких названий тоже бывают ошибки, а потом сиди думай, то ли ты такой тупой, что не понимаешь, то ли просто опечатка.
FreeSlave писал: С тех пор как начал мучить язык D, теперь в Си вставляю ассерты и пишу юниттесты
Ну ассерты - дело нужное. У меня к примеру какой-то ассерт сработал через полтора года после написания кода.
А вот юнит-тесты занятие прямо скажем бесполезное.
Я еще могу понять, если вы написали фундаментальную функцию, типа strcpy или sincos, которая используется чуть менее чем везде и ошибка в ней способна угробить абсолютно всё. Но во всех остальных случаях оно лишь создаёт ложную иллюзию оттестированости.
Вот китайцы берут мотор от таёты, коробку от хонды, ходовку наверное сами делают по чьей-то лицензии. По отдельности всё классно, а на выходе почему-то GellyMK и прсти гспди GreatWall.
Да и все китайские разработки почему-то устроены из хороших стабильных модулей, которые кое-как вместе склеены.
Это всё очень ненадёжно. Самое надёжное тестирование - на конечных потребителях продукта. Такой подход не означает, что в продукте будут выловлены абсолютно все ошибки. Он всего лишь означает, что с ними не столкнутся конечные потребители - т.к. мы будем вылавливать именно то, на что они жалуются. Метод тоже неидеальный, но хотя бы народ доволен.
Из серии "мыши кололись-давились".
Я тоже южу шестёрку. Потому что быстрая и потому что, бкьждлжд, срамная халва. Но некоторые баги в ней просто ДИКО БЕСЯТ. Например, рандомные ошибки в циклах for, когда новая переменная ВНЕЗАПНО в первой итерации принимает последнее значение.
Вообще против ошибок есть базовые приёмы:
- warning lever: over9000
- нормальные детальные имена переменных
- инициализация дефолтных значений и конструкторов классов
- ассерты (ерунда, но иногда может стать подсказкой)
- try...catch
- DBG_FORCEBREAK
Кстати, Ксайрокс, подскажи:
#ifdef _MSC_VER
#define DBG_FORCEBREAK _asm {int 3};// XDM3035
#else
#define DBG_FORCEBREAK ASSERT(0);// что вот здеся для мингвы и линуксов писать?
#endif
#else // !DEBUG
| IP: 
04-02-2013 16:41
