Личный опыт разработки ПО

Сборник рецептов

Использование Doxygen для документирования кода

Комментариев: 11

Написание документации к коду задача не самая простая и уж точно не самая приятная, но к счастью существуют инструменты которые могут существенно упростить эту процедуру. Для этих целей я использую инструмент Doxygen и именно о нем пойдет речь.

Что такое Doxygen?

Doxygen – это кроссплатформенная система документирования кода с поддержкой языков C++, C, Java, Objective-C, PHP, C# (список можно уточнить на сайте проекта).

Для создания документации достаточно просто писать комментарии в коде, придерживаясь нескольких простых правил.

Doxygen умеет анализировать исходный код проекта и создавать удобную документацию в формате HTML, Latex, RTF, XML, man, CHM.

Общие соображения

  1. Написание документации должно быть максимально простым, чтобы разработчики не "забывали" это делать. Отсюда вывод, что сложность форматирования комментариев должна быть минимальной.

    Хорошо:

    namespace A
    {
    /**
    Имя класса
     
    Описание класса
    */
    	class B
    	{
    	};
    }

    Плохо:

    namespace A
    {
    	/**
    	 * Имя класса
    	 * 
    	 * Описание класса
    	 */
    	class B
    	{
    	};
    }

    Почему второй вариант хуже? Очевидно, из-за необходимости выравнивать комментарии на одном уровне с комментируемой сущностью, а также из-за избыточных символов *. Это может показаться надуманным, но при написании комментариев из нескольких строк проблема проявляется, а при поддержке кода и вовсе становится кошмаром. Вы можете возразить, что подобный стиль делает код "рваным", но в любом случае комментирование интерфейсов делает код менее читаемым. К счастью все современные редакторы кода позволяют легко свернуть блоки с комментариями, что позволит взглянуть на код без помех.

  2. Много документации – плохо, так как мало кто будет читать длинные мануалы. Из этого следует, что документированы должны быть только открытые (public) и защищенные (protected) интерфейсы. Закрытые (private) интерфейсы – часть внутренней реализации и не должны быть в руководстве.

Читать заметку полностью »

7 февраля 2010
23:00


Скорость CMake

Прокомментировать

Некоторые интересуются, а как же у CMake со скоростью? Субъективно все достаточно быстро, если же говорить о цифрах, то один из разработчиков Quantum GIS приводит в своем блоге сравнение скорости сборки их проекта с CMake и с Autotools. Цифры конечно впечатляют – так хорошо, что даже странно. Смотрите сами:

http://blog.qgis.org/?q=node/16

3 февраля 2010
20:33

Рубрика: Разработка, Сборка

Метки:


Определение операционной системы с CMake

Прокомментировать

Часто при сборке кроссплатформенного приложения необходимо знать на какой платформе выполняется сборка. Это нужно для включения определенных файлов специфичных для конкретной платформы, например средства межпроцессного взаимодействия для Linux или для Windows.

Для определения типа платформы существует несколько переменных:

  • UNIX – системы соответствующие стандарту POSIX (например Linux, FreeBSD или MAC OS X), включает CygWin
  • WIN32 – понятно без комментариев

Зная это легко проделать нужные действия:

if (WIN32)
	set (SOURCES ${SOURCES} win_pipe.cpp)
elseif (UNIX)
	set (SOURCES ${SOURCES} posix_pipe.cpp)
else ()
	message (FATAL_ERROR "Неизвестная система")
endif ()

Обратите внимание, что команда message с ключом FATAL_ERROR выводит сообщение и прекращает выполнение работы.

Иногда этого бывает мало и необходимо точно определить тип системы или даже дистрибутив и его версию. Для этих целей можно использовать переменную CMAKE_SYSTEM:

if (${CMAKE_SYSTEM} MATCHES "Linux")
	message ("Linux")
	if (${CMAKE_SYSTEM} MATCHES "fc8")
		message ("Fedora 8")
	endif ()
elseif (${CMAKE_SYSTEM} MATCHES "FreeBSD")
	message ("FreeBSD")
elseif (${CMAKE_SYSTEM} MATCHES "Darwin")
	message ("Mac OS X")
endif ()

Полный список полезных переменных можно посмотреть в Kitware Public Wiki.

1 февраля 2010
21:29

Рубрика: Разработка, Сборка

Метки:


Освобождение памяти занятой контейнером

Комментариев: 2

На днях объяснял товарищу, что у std::vector метод clear(), хоть и удаляет свое содержимое, но вот выделенную память не возвращает. Например, после запуска следующей программы:

#include <iostream>
#include <vector>
 
int main(int argc, char* argv[])
{
	std::vector<int> data;
	data.resize(200000);
	std::cout << data.capacity() << std::endl;
	data.clear();
	std::cout << data.capacity() << std::endl;
	return 0;
}

Будет выведено:

200000
200000

Почему не возвращает? Потому, что есть метод resize и reserve, которые резервируют память и поэтому освободить память было бы крайне некорректно по отношению к ним.

Что же делать? Не паниковать, а после удаления содержимого использовать следующую идиому:

std::vector<int>().swap(data);

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

std::vector<int>(data).swap(data);

24 января 2010
21:55

Рубрика: C++

Метки:


Boost Test, юнит-тестирование и CMake

Комментариев: 4

Boost Test

Написанием модульных тестов можно не только повысить скорость разработки за счет экономии времени на отладке, но и повысить качество. Также написание тестов позволяет критично взглянуть на интерфейсы классов и функций, что выливается в создание простых и логичных интерфейсов. Но разработка с применением тестов может не принести ощутимых плодов из-за сложности написания тестов, что выльется в слабое покрытие кода тестами. Поэтому инструмент для тестирования должен быть максимально простым, написание тестов должно происходить с приложением минимального количества усилий. Я пользовался фреймворком для написания тестов UnitTest++ – это очень хороший и удобный инструмент и если вы не используете Boost, я бы порекомендовал обратить на него пристальное внимание. Но в данной заметке речь пойдет не о нем, а о фреймворке Boost Test.

Читать заметку полностью »

24 января 2010
19:09


CMake и Boost

Комментариев: 2

В этой заметке я хочу рассмотреть тему сборки проектов использующих библиотеки Boost. Мы рассмотрим проект из исполняемого файла использующего Boost Thread и двух библиотек использующих Boost Unit Test Framework.

Первым делом необходимо установить значения переменных отвечающих за тип линковки библиотек (статическая или динамическая):

set (Boost_USE_STATIC_LIBS ON)

И использование многопоточности библиотеками:

set (Boost_USE_MULTITHREADED ON)

После этого можно выполнить уже знакомую по заметке о CMake и QT команду find_package:

find_package (Boost COMPONENTS список_нужных_модулей REQUIRED)

Дополнительно можно указать необходимую версию Boost:

find_package (Boost 1.35.0 COMPONENTS список_нужных_модулей REQUIRED)

В случае если Boost корректно установлен, результатом работы команды будет создание переменных содержащих директории с заголовочными файлами Boost и пути к необходимым библиотекам:

include_directories(${Boost_INCLUDE_DIRS})
...
target_link_libraries (${PROJECT} ${Boost_LIBRARIES})

Читать заметку полностью »

23 января 2010
18:48

Рубрика: Разработка, Сборка

Метки: ,


CMake и Qt

Комментариев: 21

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

Помимо файлов с примерами есть файл с шаблоном приложения, используя который можно быстро создать достаточно сложный проект.

Читать заметку полностью »

16 января 2010
18:36

Рубрика: Разработка, Сборка

Метки: ,


Сборка проектов с CMake. Введение

Комментариев: 5

Для автоматизации сборки проектов традиционно используют системы сборки, такие как make на Unix подобных системах и nmake для компилятора Microsoft. Также традиционно написание файлов для сборки проекта под эти системы является задачей нетривиальной. Конечно в пользуясь только Mictosoft Visual Studio можно даже не подозревать о существовании этих файлов, так как интегрированная среда разработки достаточно удобно скрывает всю кухню, оставляя снаружи несколько диалоговых окон и кнопку Build. Но для сложных проектов использующих массу сторонних библиотек и кроссплатформенных проектов такой подход часто оказывается неприемлемым.

Кратко говоря make-файл представляет из себя описания последовательности действий необходимых для того чтобы достичь какой либо цели, например скомпилировать программу. На псевдокоде это может выглядеть примерно так:

Что нужно сделать?

Собрать программу hello_world.

Как ее делать?

Взять файлы hello_world.h и hello_world.cpp и запустить компилятор передав их в качестве параметров.

Что делать когда компилятор закончит работать?

Взять получившийся в результате работы компилятора объектный файлы hello_world.o и запустить линковщик передав ему этот файл.

Все.

Причем каждый подпроект может иметь свой файл сборки, а главный make-файл сможет пройти рекурсивно по подпроектам, выполнив его файл сборки, а потом собрать проект из этих компонентов.

Выглядит все просто, проблемы возникают дальше и проблем несколько:

  1. Разрешение зависимостей возникающих между частями проекта
  2. Синтаксическая сложность и неоднозначность классических make-файлов
  3. Привязка к конкретной утилите автоматической сборки и как следствие непереносимость на другие платформы

Для решения части этих проблем или всех сразу были созданы следующие инструменты: Automake (http://sourceware.org/automake/) , CMake (http://www.cmake.org/), SCons (http://www.scons.org/). Список далеко не полный.

Я предлагаю рассмотреть CMake, как простой для изучения, понятный, мощный и кроссплатформенный инструмент, который решает сразу все три проблемы. Подробности ниже.

Читать заметку полностью »

7 января 2010
20:52

Рубрика: Разработка, Сборка

Метки:


Работа с ветвями в SVN

1 комментарий

От основной ветки разработки можно отделить ветвь являющуюся ее копией на данный момент времени. Этим решаются следующие задачи:

  • Фиксация состояния разработки (например выпуск новой версии) к которому можно будет вернуться в любой момент.
  • Разработка независимо от основной ветви — актуально когда над проектом работают несколько разработчиков.

В этой заметке будут рассмотрены эти возможности, а также подводные камни работы с ветками и о том как их избежать.

Читать заметку полностью »

19 декабря 2009
21:29


Публикация кода online

Комментариев: 2

Иногда бывает нужно проверить немного кода, а компилятора под рукой нет. Или возникает необходимость обсудить что-либо с человеком доступным в данный момент только через сеть. В этом случае здорово выручит замечательный сайт Codepad. Без регистрации, быстро и удобно можно скомпилировать программу, посмотреть вывод, получить короткую ссылку которой можно поделиться с людьми и даже устроить небольшое обсуждение (вот для этого правда придется зарегистрироваться).

Поддерживаются языки: C, C++, D, Haskell, Lua, OCaml, PHP, Perl, Python, Ruby, Scheme, Tcl.

Немного погонял на C++ — ключевые слова подсвечиваются, сообщения об ошибках адекватные, можно даже использовать Boost! Резюмирую — отличный ресурс!

Повторяю ссылку: codepad.org

1 декабря 2009
20:33