Как же так, CC — это C Compiler, а для C++ Compiler есть свои собственные CXX и CXXFLAGS. Нередко нереализованные мелочи — недопрочтённые мануалы:)

Что-то не помню я, чтобы приходилось для deps шаманства sed прикручивать, но к сожалению не могу найти исходник.

Для тестов есть make test и make check, что прекрасно поддерживается дистрибутивами.

make --trace помог выудить крайне неуловимый баг в системе сборки (дело оказалось не в самом Make, а в среде). Для сложных проектов с мегатоннами унаследованного кода конечно он не подойдёт, но он серьёзно выручает для генерации всяких graphviz, tex и т. п., для которых не всегда IDE-то существует, а автоматизировать процесс надо. Даже собственный парсер так удобнее запускать.

cmake и autotools преимущественно решают проблему унаследованного ПО (зависимости и совместимость), проект, где из сторонних библиотек только STL, собирать командой make одно удовольствие.

А пристрастие к такому стилю программирования обязательно рано или поздно приведёт к появлению в коде после препроцессинга какого-нибудь бреда вроде:

if(strcmp(strdup(a), strdup(b)) == 0)

Как правило сторонние разработчики, когда делают патчи, не всегда вдаются в тонкости устройства чужих дефайнов.

И такие ошибки cppcheck уже находил.

Cppcheck из git HEAD уже не рапортует о такой ошибке:)

А вообще там есть ещё много подозрительных мест, так что провериться cppcheck-ом не мешает.

Ошибки вида (ret = f()) уже давно компиляторы отстреливают, это говорит лишь о том, что никто не читает предупреждения компилятора:)

С ГИМПом всё гораздо интереснее: поддержка произвольной глубины цвета (хоть double на канал) есть уже лет 10 как, но в отдельном движке Gegl, который только недавно начал объединяться с GIMP. До релиза ещё очень далеко — все фильтры работают в режиме плавающей точки, что заметно медленнее восьмибитного GIMP. Зато есть надежда на OpenCL, в Gegl его уже можно попробовать — некоторые фильтры были портированы на OpenCL. Сейчас до полноценной интеграции Gegl не хватает многих необходимых фильтров и операций, которые уже есть в GIMP.

Язык очень похож на LuaJIT, с его FFI возможен довольно простой биндинг с Си. Не пробовали сравнить?

А сила Питона всё-таки в готовых библиотеках. Как в Julia обстоят дела с Qt? А GTK+? Тут у Питона неоспоримая ниша.

Сертификат ФСТЕК-а сейчас нет только у ленивого. Та же Мандрива его ещё в 2008-м получила. А результат — ноль (на счету в банке).

На мой взгляд, Магея для тех, кому нравилась «старая» Мандрива, так как они продолжают дело старого дистрибутива после того, как Мандрива волевым менеджерским решением превратилась непонятно во что. Т. е. Магея — это старая добрая Мандрива, какой она была в 2006-м с тем же сообществом разработчиков, которое было уволено из Мандривы, своим инсталлятором, контрол-центром и возможностью легко выбрать GNOME/KDE. Старый дистрибутив умер, и его нишу кто-то занял — это логично.

А хорошо это или нет — дело каждого. Мне от дистрибутива давно не нужен графический конфигуратор, но по привычке ставлю Магею, так как стабильный, свежий, без багов и со своими задачами справляется на ура. Даже стим есть из коробки:)

Рейтинг строится не на том, что ресурс посещают пользователи Магеи, а в том, что страницу с Магеей на дистровотче чаще посещают, чем ту же RHEL, это прямо в сноске под этим самым рейтингом написано. А рынок серверов посетителям DW действительно малоинтересен, так как рейтинг этот — непрофессиональный, как уже выше неоднократно было замечено. По этому рейтингу выходит, что все пользуются Минтом:)

Думаю дело даже обстоит так: человек интересуется, «что это за зверь» и ищет дистр в гугле, после чего прямиком отправляется на страницу с описанием этого дистра в DW. На фоне банкротства Мандривы и рождения Магеи как дистрибутива от французской команды разработчиков Мандривы этот дистр вызвал к себе большой интерес, вот и держится в топе.

Популярность — не выручка, буква E в слове RHEL не просто так. Хотел бы я посмотреть на пользователей, ставящих дома RHEL с поддержкой от 50 до 300 баксов в год:)

Ещё в копилку: info — гипертекстовые мануалы, причём можно легко свои делать.

Это не программа, а внутренняя функция Bash. В убунте по-моему используется не Bash, а дебиановский Dash — разные оболочки, поэтому я не удивлён, что в Dash такой функции может и не быть вообще. В макоси всё правильно открывается — ман по Bash, дальше поиском можно найти подробную справку по complete.

С аналогичным успехом можно смотреть справку по if или echo.

Предлагаю посмотреть в сторону Bash completion — поддерживается куча утилит, можно писать свои правила автодополнения на Bash. Идея Zsh на два комментария выше интересная и её можно реализовать на Bash.

Ещё есть apropos — это агрегатор мануалов, помогает, если помните, что должна делать команда, но не помните её названия.

Как раз такими типичными вариантами работы программы являются обработчики ошибок — поставили return между alloc/dealloc — и встречайте. В реальной жизни этот код может никогда и не выполнится, а cppcheck эти ошибки частенько вскрывает.

Ваш комментарий натолкнул действительно на интересную проблему. Я сейчас отключил в исходниках тот блок анализатора, который отвечал за блокировку классов, и повторил анализ недавнего npp (у меня мало что плюсового находится под рукой).

Действительно, нашёл как минимум одну утечку памяти, которую я пропустил в предыдущем анализе:

bool ProjectPanel::openWorkSpace(const TCHAR *projectFileName)
{
	TiXmlDocument *pXmlDocProject = new TiXmlDocument(projectFileName);
	bool loadOkay = pXmlDocProject->LoadFile();
	if (!loadOkay)
		return false;
...
	delete pXmlDocProject;
	return loadOkay;
}

В ближайшее время попробую обсудить это с разработчиками cppcheck. На мой взгляд тот блок кода надо обернуть в inconclusive.

Если уж valgrind ничего не нашёл — возможно в коде действительно нет утечек:)

P.S. Я нашёл, что определяет поведение cppcheck в таком случае. Он просто не проверяет утечки для классов. Возможно это связано с деструкторами или частыми ложными срабатываниями, но можете попробовать: файл checkmemoryleak.cpp, строка 879, здесь даже есть комментарий:

                // don't check classes..
                if (alloc == CheckMemoryLeak::New) {
                    if (Token::Match(tok->tokAt(2), "new struct| %type% [(;]")) {
...

Если этот блок if убрать — он не будет пропускать инициализированные классы. Можете попробовать на своём проекте, результат может быть двояким — либо найдёте кучу ошибок, либо кучу ложных срабатываний.

В Git Blame по этому поводу ничего подозрительного, может быть, данный патч был не для утечек, а для предупреждений, но в результате повлиял на поиск утечек. Раньше эта проверка включалась флагом inconclusive…

Интересно. new Type[10] ловит, а просто new Type — уж не ловит. Возможно это либо баг, либо перестраховка. Но всё что не нашёл cppcheck можно найти с помощью valgrind:)

К Qt как таковому это не относится.

Кроме того, xargs не очень хорошо ведет себя с передачей специальных символов, как, например, пробел или кавычки

Используйте

find -print0 | xargs -0

и кавычки с переносами не страшны.

В cppcheck недавно добавили поддержку библиотек, включая Qt, что теоретически даёт возможность анализа без препроцессинга. В следующей статье я как раз расскажу, как этим пользоваться. Я не уверен, что поддержка Qt там стопроцентная, но она есть.

На cppcat.com фраза «Visual Studio Express is not supported» не находится даже поиском. Не все же разбираются в сортах Visual Studio.

Вот это поворот. Тогда понятно, в чём дело, но сообщение об ошибке могло бы быть более информативным. Попробую тогда найти нормальную версию, если получится натравить анализатор на ядро Linux Xorg — попробую сделать сравнение:) Это самый убитый OpenSource проект из которых мне довелось держать в руках. Можно специально взять старую версию 2005 года, когда никаких анализаторов ещё не было.