Всем привет. Написал мини-книгу про вредные советы для программистов и приглашаю с ней познакомиться: 60 антипаттернов для С++ программиста. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования. Естественно, каждый антисовет сопровождается объяснением, почему он вредный. Так что информации будет много. Запасайтесь кофе и желаю приятного чтения.
Если вспомнится своё наболевшее, тоже делитесь
Здравствуйте, Нomunculus, Вы писали:
Н>Что-то большинство ну совсем примитивные. Типа == для даблов. Хоть один сишник делает так?
Вполне Добро пожаловать в реальный мир программирования.
О том, как мы опробовали статический анализ на своем проекте учебного симулятора рентгенэндоваскулярной хирургии
> Подобные ошибки повторяются достаточно часто в данной библиотеке. Не скажу, что это стало для меня неожиданностью. Уже ранее наталкивался на некорректную работу с числами с плавающей точкой в этом проекте. Однако систематически проверять исходники на этот счет не было ресурсов. По результатам проверки стало ясно, что нужно дать разработчику почитать что-то для расширения кругозора в части работы с числами с плавающей точкой. Скинул ему ссылки на пару хороших статей
Здравствуйте, Analytic2007, Вы писали:
A>Всем привет. Написал мини-книгу про вредные советы для программистов и приглашаю с ней познакомиться: 60 антипаттернов для С++ программиста. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования. Естественно, каждый антисовет сопровождается объяснением, почему он вредный. Так что информации будет много. Запасайтесь кофе и желаю приятного чтения. A>Если вспомнится своё наболевшее, тоже делитесь
Имхо, стиль "вредных советов" не очень подходит для публикаций по C++. Оно-то может и кажется остроумным, на первый взгляд. Но когда дело дойдет до каких-то не совсем тривиальных вещей, которых в С++ хоть пруд пруди, да захочется предоставить какие-нибудь примеры кода, вписаться в этот стиль может оказаться не так-то просто. Кроме того, при чтении этих материалов будет не очень-то комфортно постоянно держать в голове необходимость инверсии рекомендаций, особенно новичкам.
--
Купаев, "нахер" твоя жопа хороша, шоха ты на подсосе. Тебе кто разрешил использовать общаковый молоток для вымещения личных обид?
Здравствуйте, Нomunculus, Вы писали:
Н> Типа == для даблов. Хоть один сишник делает так?
Так можно делать и в статье написано когда.
С другой стороны, эта тема слишком глубока и то же сравнение с поправкой на double epsilon неверно.
Даже если результат меньше единицы, эта странная константа может не подойти. Например, значение функции всегда меньше 1, но вычисляется она с помощью рядов, члены которых могут быть сколь угодно огромными (вспоминается функция Бесселя, где участвует и степень, и факториал). Кроме того, формула может быть неустойчива, промежуточные результаты округляются в соответствии с погрешностью исходных данных в промежуточных вычислениях и т.д.
По итогу, для корректной работы с такими числами иногда надо прослушать университетский курс по погрешностям, устойчивости и вычислительным экспериментам. Знания того, как работает компилятор и что происходит в регистрах окажется мало.
Здравствуйте, Нomunculus, Вы писали:
Н>Для таких проверок предпочитаю булевый флаг заводить — было изменено значение или нет
Или 100 булевых флагов, если значения не вычисляются, а присваиваются константы. Или 1000 флагов, если у нас константный LUT, с которым надо сравниваться. Детский сад.
Здравствуйте, Нomunculus, Вы писали: Н>Типа == для даблов.
Наиболее адекватное решение сравнения на равенство floating point я видел в библиотеке google test.
Для тестов используются макросы EXPECT_EQ/ASSERT_EQ, которые для fp типов не используют оператор ==.
Кому интересно, посмотрите файл internal/gtest-internal.h.
Там есть шаблонный класс FloatingPoint<RawType>.
В нем метод AlmostEquals, который игнорирует различия в kMaxUlps=4 в дистанции между представимыми значениями мантиссы.
Здравствуйте, Analytic2007, Вы писали:
A>Вредный совет N37. Создай свой h-квест A>Пишите ваши .h-файлы так, чтобы они зависели от других заголовков, и при этом не включайте их в свой заголовочный файл. Пусть тот, кто инклудит, догадается, какие A>заголовки нужно заранее заинклудить перед использованием вашего файла. Развлеките коллег квестами!
Спорный момент.
Для библиотечного кода эта рекомендация имеет смысл.
Кому хочется копаться в кишках чужой библиотеки чтобы выяснить, что там от чего зависит?
В рамках же своего проекта хочется иметь больший контроль над зависимостями, какие каждый .cpp включает .h.
Очень помогают уменьшить связанность кода forward объявления.
Для своего кода у меня правило: никаких #include в .h (кроме прекомпайлед хидеров, конечно).
