Профилировка программ в Linux'е

Для начала определим, что же такое "профилировка программ" и зачем она нужна. Профилировка программ - это процесс определения времени выполнения отдельных элементов программы с целью поиска "бутылочного горлышка".
Книга "Техника оптимизации программ" Криса К., дает еще одно определение профилировки:

Профилировкой мы будем называть измерение производительности как всей программы в целом, так и отдельных ее фрагментов, с целью нахождения "горячих" точек (Hot Spots), — тех участков программы,  на выполнение которых расходуется наибольшее количество времени.

Профилировка программ выполняется при помощи специальных утилит - профилировщиков, которые на основе собранных при выполнении программы данных вычисляют время выполнения практически для каждой логической единицы программы - строка кода, функции и так далее. А затем, эта информация представляется пользователю в виде таблиц или графиков.
Подобная информация может быть полезной если в вашей программе есть узкие места из-за которых ее производительность оставляет желать лучшего. Либо же, такая информация может пригодиться если вам необходимо портировать программу с "большого" PC на какой-нибудь низкопроизводительный микроконтроллер.

Программа для создания карточек настольной игры "Алиас"

Недавно, мне подарили настольную игру под названием "Алиас", суть которой заключается в угадывании слов и всяких "известных персонажей" по словесному описанию от партнера по команде.
Именно с угадыванием известных персонажей и возникли проблемы у компании из двух программистов и одного филолога. Если с такими людьми как Арнольд Шварценеггер или Уилл Смит не возникало никаких проблем, то попытки описать Колин Фарелл или Род Стюарта наталкивались на препятствие вида "эээ, а кто все эти люди?".
Тогда же, одному из двух программистов пришла в голову светлая идея - заменить всех этих "звезд эстрады и шоубизнеса" на таких привычных и понятных программистскому уху именах и фамилиях как: Линус Торвальдс, Ричард Столлман, Деннис Ритчи и так далее.
Естественно, рисовать карточки от руки было, что называется "не с руки", поэтому мною была написана простенькая программка, рисующая карточки автоматически.

Статический анализ кода на C в Linux'е

Теоретически ребенок может предпочесть общение с консолью и компилятором общению с реальными людьми, особенно если со сверстниками проблемы. Плюсы общения с машиной для него будут очевидны: даешь задание получаешь результат(кому еще ребенок может дать задание), если результат не верен, значит сам напортачил(а люди могут врать или ошибаться по морю причин и пойди разбери по какой именно). А еще у машины всегда есть время общаться с ребенком(она не скажет что устала на работе и ей нужно попить пивка).

http://habrahabr.ru/blogs/linux/123768/#comment_4092675

К сожалению, поиски того, где же ты напортачил, могут затянуться если не использовать анализаторы кода. Там, где человек от усталости вполне может и пропустить какую-то, не вполне очевидную, ошибку, программа ничего не упустит и предупредит о том, что "здесь что-то не так".
Поскольку я пишу на C и использую GNUтые или же просто опенсорсные средства разработки (GNU Emacs, GNU GCC, Doxygen и так далее), то меня интересовали, в первую очередь, средства для статического анализа кода с открытыми исходниками. О них то, по меньшей мере о тех, которые мне приглянулись, и пойдет речь в данном посте.

CUnit - фреймворк для юнит-тестирования программ на C

Наконец-то я получил все зачеты и автоматы и могу не тратить некоторую часть своего времени на официальную учебную деятельность, а весь день заниматься тем, что мне интересно.

Когда я писал на Clojure, мне очень нравилась встроенная в него в система для проведения юнит-тестирования. До этого я не пользовался юнит-тестами и идея писать некоторые функции, которые проверяют работоспособность моего кода на некотором наборе входных значений, а также, по совместительству, являются готовыми примерами использования, мне весьма приглянулась.
Юнит-тестированием для кода, написанного на Си, я еще ни разу не занимался и не знал что там принято использовать. Задав вопрос в своем G+ я получил совет попробовать CUnit - http://cunit.sourceforge.net. О моем небольшом опыте использования этого фреймворка для юнит-тестирования и пойдет речь в моем сегодняшнем посте...

Об использовании неподходящих инструментов

В последнее время, я все чаще сталкиваюсь с тем, что люди все больше склонны использовать привычный им инструмент, а не более удобный для решения поставленной задачи.
Например, они пытаются как-то странно использовать Дропбокс (http://www.dropbox.com). Почему-то, когда встает задача обмена файлами внутри определенной рабочей группы, первым предложением обычно звучит "а давайте использовать дропбокс!".