Все вместе это и формирует полное именование версии (Major.Minor.Pathch.Build):

4.6.12.589

Некоторые используют в качестве build уникальное числовое значение, которое увеличивается каждый раз, например, при ночной сборке. Я считаю, что никакого смысла в этом нет – гораздо удобнее привязать данный номер к ревизии в репозитории. Я использую Subversion и CMake, поэтому продемонстрирую как можно автоматизировать проставлении версии билда с этими инструментами.

Первое – необходимо добавить заголовочный файл в проект (например, version.h):

#include <string>
 
#include <boost/cstdint.hpp>
 
namespace Version
{
	const std::string& AsText();
	boost::uint64_t AsNumber();
}

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

Теперь приведу содержимое version.cpp:

#include <boost/format.hpp>
 
#include "../version.h"
 
namespace
{
	const boost::uint8_t MAJOR = 4;
	const boost::uint16_t MINOR = 6;
	const boost::uint16_t PATCH = 12;
	const boost::uint32_t BUILD = 589; // Это значение будет изменено автоматически
}
 
const std::string& Version::AsText()
{
	static const std::string text = boost::str(boost::format("%1%.%2%.%3%.%4%") %
		static_cast<unsigned>(MAJOR) % MINOR % PATCH % BUILD);
 
	return text;
}
 
boost::uint64_t Version::AsNumber()
{
	BOOST_STATIC_ASSERT(BUILD < 0xFFFFFF);
 
	using namespace boost;
	const size_t size = sizeof(uint64_t);
 
	static const boost::uint64_t number =
		(static_cast<uint64_t>(MAJOR) 
			<< (size - sizeof(MAJOR)) * 8) |
		(static_cast<uint64_t>(MINOR) 
			<< (size - sizeof(MAJOR) - sizeof(MINOR)) * 8) |
		(static_cast<uint64_t>(PATCH) 
			<< (size - sizeof(MAJOR) - sizeof(MINOR) - sizeof(PATCH)) * 8) |
		BUILD;
 
	return number;
}

Здесь все тривиально и, думаю, не требует комментариев. Последнее, что осталось – механизм изменения значения BUILD, на номер ревизии в репозитории. С этим отлично справится CMake, просто добавьте в CMakeLists.txt следующий код:

set (VERSION_FILE ../common/sources/version.cpp)
 
find_package (Subversion REQUIRED)
Subversion_WC_INFO (${PROJECT_SOURCE_DIR} Repo)
file (READ ${VERSION_FILE} OLD_CODE)
foreach (LINE ${OLD_CODE})
	string (REGEX MATCH "BUILD = ([0-9]+)" BUILD_NUMBER ${LINE})
	if (BUILD_NUMBER)
		string (REGEX REPLACE "[0-9]+$" ${Repo_WC_REVISION} LINE ${LINE})
	endif ()
	set (NEW_CODE ${NEW_CODE} ${LINE})
endforeach (LINE)
file (WRITE ${VERSION_FILE} "${NEW_CODE}")

Единственная тонкость в скрипте в последней строке, а конкретней – кавычки в "${NEW_CODE}", без них будут убраны все “;”.

Например приложение работает хорошо, ну скажем в 95 случаях из 100, но в оставшихся пяти оно может зависнуть или вылететь с segmentation fault. А может упасть.

Посмотрим на следующий код:

#include <condition_variable>
#include <iostream>
#include <queue>
#include <mutex>
#include <thread>
 
class Worker
{
public:
    Worker()
        : shutdown_(false)
        , thread_(&Worker::taskProcessor, this)
    {
    }
 
    ~Worker()
    {
        {
            std::lock_guard<decltype(mutex_)> lock(mutex_);
            shutdown_ = true;
        }
 
        hasTask_.notify_one();
 
        thread_.join();
    }
 
    void addTask(int taskId)
    {
        {
            std::lock_guard<decltype(mutex_)> lock(mutex_);
            std::cout << "Adding task " << taskId << std::endl;
            tasks_.push(taskId);
        }
 
        hasTask_.notify_one();
    }
 
private:
    void taskProcessor()
    {
        while (true)
        {
            int task = 0;
 
            {
                std::unique_lock<decltype(mutex_)> lock(mutex_);
 
                if (shutdown_)
                    return;
 
                while (tasks_.empty())
                {
                    hasTask_.wait(lock);
 
                    if (shutdown_)
                        return;
                }
 
                task = tasks_.front();
                tasks_.pop();
            }
 
            // освободили мютекс, чтобы не блокировать другие потоки и делаем работу
            std::cout << "Processing task " << task << std::endl;
        }
    }
 
private:
    bool shutdown_;
 
    std::queue<int> tasks_;
 
    std::thread thread_;
    std::mutex mutex_;
    std::condition_variable hasTask_;
};
 
int main(int argc, char* argv[])
{
    Worker worker;
 
    for (int i = 1; i < 6; ++i)
    {
        worker.addTask(i);
    }
 
    return 0;
}

Здесь приведен простой класс, объект которого обрабатывает некоторые задачи в параллельном потоке. Из основного потока функцией addTask можно добавить задачу в очередь и известить об этом параллельный поток. Поток проснувшись, возьмет из очереди задачу, обработает ее и если задач больше нет – уснет. В деструкторе, прежде чем объект будет уничтожен происходит ожидание обработки всех задач в очереди.

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

Проблема в списке инициализации. Как мы помним, конструирование членов класса происходит в порядке их объявления. В нашем случае сначала будет создан объект типа std::thread и только после него std::mutex. Если звезды сложатся удачно, то запуск параллельного потока займет некоторое время, за которое в основном потоке будет сконструирован мютекс и программа будет работать. Если со звездами не сложиться, то поток начав работу попробует заблокировать мютекс который еще не сконструирован, со всеми вытекающими. Решение простое, но не самое лучшее, так как делает код хрупким – изменить положение членов в списке инициализации:

boost::mutex Mutex_;
std::condition_variable hasTask_;
std::thread thread_;

Лучше будет разделить конструирование и инициализацию:

class Worker
{
public:
	static std::unique_ptr<Worker> create()
	{
		std::unique_ptr<Worker> worker(new Worker());
		worker->init();
		return worker;
	}
 
	...
 
private:
	Worker()
		: shutdown_(false)
	{
	}
 
	void init()
	{
		thread_ = std::thread(&Worker::taskProcessor, this));
	}
 
	...
 
};

Ура, товарищи!

Update. Собственно сам драфт: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf

Введение

Грубо говоря, конечный автомат (Finite State Machine), глазами пользователя – это черный ящик, в который можно что-то передать и что-то оттуда получить. Это очень удобная абстракция, которая позволяет скрыть сложный алгоритм, кроме того конечные автоматы очень эффективны.

Конечные автоматы изображают в виде диаграмм состоящих из состояний и переходов. Поясню на простом примере:

Как вы наверное догадались – это диаграмма состояний лампочки. Начальное состояние обозначается черным кружком, переходы стрелками, некоторые стрелки подписаны – это события после которых автомат переходит в другое состояние. Итак, сразу из начального состояния, мы попадаем в состояние Light Off – лампа не горит. Если нажать кнопку, то автомат изменит свое состояние и перейдет по стрелке помеченной Push Button, в состояние Light On – лампа горит. Перейти из этого состояния можно опять же по стрелке, после нажатия кнопки, в состояние Light Off.

Также широко используются таблицы переходов:

Практическое применение автоматов

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

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

Для примера мы реализуем автомат для подсчета чисел и слов в тексте. Для начала договоримся, что числом будет считаться последовательность цифр от 0 до 9 произвольной длины, окруженная пробельными символами (пробел, табуляция, перевод строки). Словом будет считаться последовательность произвольной длины состоящая из букв и также окруженная пробельными символами.

Рассмотрим диаграмму:

Из начального состояния мы попадаем в состояние Start. Проверяем текущий символ, и если он является буквой, то переходим в состояние Word по стрелке помеченной как Letter. Это состояние предполагает, что в данный момент мы рассматриваем слово, анализ дальнейших символов, либо подтвердит данное предположение, либо опровергнет. Итак, рассматриваем следующий символ, если он является буквой, то состояние не изменяется (обратите внимание на круговую стрелку помеченную как Letter). Если символ не является буквой, а соответствует пробельному символу, то это означает, что предположение было верным и мы обнаружили слово (делаем переход по стрелке Space в состояние Start). Если символ не является, ни буквой, ни пробелом, значит мы ошиблись в предположении и последовательность которую мы рассматриваем, не является словом (переходим по стрелке Unknown в состояние Skip).

В состоянии Skip мы находимся до тех пор, пока не будет встречен пробельный символ. После того как пробел был обнаружен мы переходим по стрелке Space в состояние Start. Это нужно, чтобы полностью пропустить строку не соответствующую нашему шаблону поиска.

После перехода в состояние Start, поиск цикл повторяется с начала. Ветвь с распознаванием чисел аналогична ветви распознавания слов.

Автомат с использованием switch-инструкций

Первое – возможные состояния:

enum States
{
	State_Start,
	State_Number,
	State_Word,
	State_Skip
};

Начальное состояние:

States state = State_Start;

После чего мы итерируем по строке подсовывая автомату текущий символ. Сам автомат представляет собой инструкцию switch сначала выполняющей переход в секцию текущего состояния. Внутри секции есть конструкция if-else, которая в зависимости от события (пришедшего символа) изменяет текущее состояние:

const size_t length = text.length();
for (size_t i = 0; i != length; ++i)
{
	const char current = text[i];
 
	switch (state)
	{
	case State_Start:
		if (std::isdigit(current))
		{
			state = State_Number;
		}
		else if (std::isalpha(current))
		{
			state = State_Word;
		}
		break;
	case State_Number:
		if (std::isspace(current))
		{

Здесь смотрим на диаграмму – текущее состояние Number, событие Space (встречен пробельный символ), а значит найдено число:

			FoundNumber(); 
			state = State_Start; 
		} 
		else if (!std::isdigit(current)) 
		{ 
			state = State_Skip; 
		} 
		break; 
	case State_Word: 
		if (std::isspace(current)) 
		{ 
			FoundWord(); 
			state = State_Start; 
		} 
		else if (!std::isalpha(current)) 
		{ 
			state = State_Skip; 
		} 
		break; 
	case State_Skip: 
		if (std::isspace(current)) 
		{ 
			state = State_Start; 
		} 
		break; 
	} 
}

Итог:

+ Высокая эффективность

+ Простота реализации для простых алгоритмов

— Тяжело поддерживать

Интерпретация времени выполнения

Идея данного подхода проста – надо создать таблицу переходов, заполнить ее, и потом, при наступлении события, найди в таблице следующее состояние и сделать переход:

enum Events
{
	Event_Space,
	Event_Digit,
	Event_Letter,
	Event_Unknown
};
 
void ProcessEvent(Events event);
 
...
 
struct Transition
{
	States BaseState_;
	Events Event_;
	States TargetState_;
};
 
void AddTransition(States fromState, Events event, States toState);
 
...
 
typedef std::vector<transition> TransitionTable;
 
TransitionTable Transitions_;
States CurrentState_;

Заполнение таблицы:

AddTransition(State_Start,	Event_Digit,	State_Number);
AddTransition(State_Start,	Event_Letter,	State_Word);
 
AddTransition(State_Number,	Event_Space,	State_Start);
AddTransition(State_Number,	Event_Letter,	State_Skip);
AddTransition(State_Number,	Event_Unknown,	State_Skip);
 
AddTransition(State_Word,	Event_Space,	State_Start);
AddTransition(State_Word,	Event_Digit,	State_Skip);
AddTransition(State_Word,	Event_Unknown,	State_Skip);
 
AddTransition(State_Skip,	Event_Space,	State_Start);

Получилось довольно наглядно. Платой за наглядность будет более медленная работа автомата, что впрочем, часто не имеет значения.

Чтобы автомат, при наступлении некоторых событий, мог оповестить некоторый код, можно добавить в структуру с информацией о переходе (Transition) указатель на функцию (Action), которая будет вызываться:

typedef void (DynamicMachine::*Action)();
 
struct Transition
{
	States BaseState_;
	Events Event_;
	States TargetState_;
	Action Action_;
};
 
...
 
void AddTransition(States fromState, Events event, States toState, Action action);
 
...
 
AddTransition(State_Number, Event_Space, State_Start, &DynamicMachine::FoundNumber);

Итог:

+ Гибкость и наглядность

+ Проще поддерживать

— Меньшая производительность по сравнению с switch-блоками

Интерпретация времени исполнения. Оптимизация по скорости

Можно ли объединить наглядность со скоростью? Сделать автомат настолько же эффективным, как автомат на switch-блоках вряд ли удастся, но сократить разрыв можно. Для этого надо из таблицы, построить матрицу, такую, чтобы для получения информации о переходе не выполнять поиск, а сделать выборку по номеру состояния и события:

struct Transition
{
	States TargetState_;
	Action Action_;
};
 
typedef std::vector<Transition> TransitionByEventsTable;
typedef std::vector<TransitionByEventsTable> StatesTable;
 
StatesTable States_;
States CurrentState_;

Здесь из вектора States_ по номеру текущего состояния, можно получить вектор с переходами (Transition), где индексом служит номер события. Таким образом поиск состояния для перехода выполняется за время O(1):

const TransitionByEventsTable& transitionByEvents = States_[CurrentState_];
const Transition& transition = transitionByEvents[event];

Достигается результат, за счет расхода памяти.

Итог:

+ Гибкость, наглядность

+ Эффективен

— Расход памяти (скорее всего несущественно)

Boost Statechart

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

Итак, сначала определим события:

namespace Events
{
	struct Digit	: boost::statechart::event<Digit> {};
	struct Letter	: boost::statechart::event<Letter> {};
	struct Space	: boost::statechart::event<Space> {};
	struct Unknown	: boost::statechart::event<Unknown> {};
}

Саму машину (обратите внимание, что второй параметр шаблона – начальное состояние):

struct Machine	: boost::statechart::state_machine<Machine, States::Start> {};

И собственно сами состояния. Внутри состояний требуется определить тип описывающий переходы (reactions), а если переходов несколько, то перечислить их в списке типов boost::mpl::list. Второй параметр шаблона simple_state – тип описывающий машину. Переходы описываются параметрами шаблона transition, парой Событие — Следующее состояние:

namespace States
{
	struct Start
		: boost::statechart::simple_state<Start, Machine>
	{
		typedef boost::mpl::list
		<
			boost::statechart::transition<Events::Digit,	States::Number>,
			boost::statechart::transition<Events::Letter,	States::Word>
		>
		reactions;
 
	};
 
	struct Number
		: boost::statechart::simple_state<Number, Machine>
	{
		typedef boost::mpl::list
		<
			boost::statechart::transition<Events::Space,	States::Start>,
			boost::statechart::transition<Events::Letter,	States::Skip>,
			boost::statechart::transition<Events::Unknown,	States::Skip>
		>
		reactions;
	};
 
	struct Word
		: boost::statechart::simple_state<Word, Machine>
	{
		typedef boost::mpl::list
		<
			boost::statechart::transition<Events::Space,	States::Start>,
			boost::statechart::transition<Events::Digit,	States::Skip>,
			boost::statechart::transition<Events::Unknown,	States::Skip>
		>
		reactions;
	};
 
	struct Skip
		: boost::statechart::simple_state<Skip, Machine>
	{
		typedef boost::statechart::transition<Events::Space,	States::Start> reactions;
	};
}

Машина построена, осталось только инициализировать ее и можно использовать:

Machine machine;
machine.initiate();
 
...
 
machine.process_event(Events::Space());

Итог:

+ Гибкость, расширяемость

— Эффективность

Быстродействие

Я написал тестовую программу для проверки быстродействия построенных автоматов. Через автоматы я прогнал текст размером ~17 Мб. Вот результаты прогона:

Loading text
Text length: 17605548 bytes
0.19 s

Running BoostMachine
Words: 998002, numbers: 6816
0.73 s

Running DynamicMachine
Words: 998002, numbers: 6816
0.56 s

Running FastDynamicMachine
Words: 998002, numbers: 6816
0.29 s

Running SimpleMachine
Words: 998002, numbers: 6816
0.20 s

Что осталось не рассмотренным

Неохваченными остались еще несколько реализаций конечных автоматов (рекомендую http://www.rsdn.ru/article/alg/Static_Finite_State_Machine.xml и http://www.rsdn.ru/article/alg/FiniteStateMachine.xml), генераторы строящие автоматы из описаний, библиотека Meta State Machine из Boost версии 1.44.0, а также формальные описания конечных автоматов. Со всем перечисленным любопытный читатель может ознакомиться самостоятельно.

Исходный код автоматов и тестовой программы

http://www.devexp.ru/wp-content/uploads/2011/02/state_machines.zip

Цена вопроса

Есть программы которые стоят немалых денег (Coverity Prevent for C/C++, Klocwork), а есть абсолютно бесплатные (Cppcheck).

Платные я не тестировал, но судя по статье, Cppcheck им нисколько не уступает. Так на тесте приведенном в указанной статье она находит все ошибки. Вот результат работы:

Checking check.cpp... 
[check.cpp:11]: (error) Array 'c[10]' index 10 out of bounds 
[check.cpp:5]: (error) Memory leak: __p 
[check.cpp:17]: (error) Memory leak: a 
[check.cpp:14]: (error) Mismatching allocation and deallocation: A::__p 
[check.cpp:8]: (error) Null pointer dereference 

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

Есть версия программы с графическим интерфейсом, где единственное усилие которое нужно сделать – выбрать пункт меню Check->Files для проверки одного файла, или Check->Directory для проверки всей директории, после чего просмотреть результаты работы.

Также есть консольная версия, на вход которой также достаточно подать  имена проверяемых файлов.

Интеграция в систему сборки

Уже упомянутую консольную версию программы легко добавить в скрипт сборки проекта, чтобы автоматически проводить проверку. При этом Cppcheck может в случае нахождения ошибок вернуть определенный код. Используйте для этого ключ —error-exitcode=код_возврата.

Вывод

Cppcheck отличный инструмент, очень простой в использовании, бесплатный и довольно эффективный. Крайне рекомендую к использованию. Есть версии как для Windows, так и для Linux.

Домашняя страница проекта: http://cppcheck.sourceforge.net/

1. Полномочиями данными компилятору автоматически генерировать деструктор, если он не определен в классе
2. Возможностью вызвать оператор delete для объекта тип которого в точке удаления еще не известен

Рассмотрим простой код и посмотрим, что делает компилятор:

test.h

#ifndef TEST_H
#define TEST_H
 
class Test
{
public:
	Test();
	~Test();
};
 
#endif//TEST_H

test.cpp

#include <iostream>
 
#include "test.h"
 
Test::Test()
{
	std::cout << "Test" << std::endl;
}
 
Test::~Test()
{
	std::cout << "~Test" << std::endl;
}

trouble.h

#ifndef TROUBLE_H
#define TROUBLE_H
 
#include <memory>
 
class Test;
 
class Trouble
{
public:
	Trouble();
 
private:
	std::auto_ptr<Test> Test_;
};
 
#endif//TROUBLE_H

trouble.cpp

#include "test.h"
 
#include "trouble.h"
 
Trouble::Trouble()
	: Test_(new Test())
{
}

main.cpp

#include "trouble.h"
 
int main(int argc, char* argv[]) 
{
	Trouble trouble;
	return 0;
}

Итак, имеется два класса: Test и Trouble, причем в целях ускорения компиляции разработчик решил сделать предварительное объявление класса Test в trouble.h, но не написал деструктор для класса Trouble, а значит компилятор заботливо создаст деструктор сам. Когда он это сделает? Вообще компилятор не мечется по коду, а последовательно его анализирует.

Начнет он с функции main в main.cpp, определит, что создается объект trouble типа Trouble из trouble.h, обнаружит конструктор.

Далее он сделает вывод, что по выходу из main объект trouble должен быть удален, попытается найти деструктор, не найдет его и создаст его сам.

Что будет в этом деструкторе? Естественно удаление членов класса, то есть в данном случае std::auto_ptr<Test>, в деструкторе которого будет соответственно вызван оператор delete для указателя на Test.

Внимательно следим за руками! В данном месте компилятор еще ничего не знает о типе Test, поскольку еще не дошел до test.h и поэтому оператор delete будет применен к неполному типу, что вызовет неопределенное поведение.

Откомпилировав приведенный код и выполнив программу вы скорее всего на выводе получите только сообщение из конструктора, деструктор для Test вызван не будет!

Далее подробности и методы борьбы с данным явлением.

Что делать? Можно сделать неправильный вывод, что предварительное объявление зло и всегда включать все заголовочные файлы в *.h, что приведет к резко возросшему времени компиляции при изменении заголовочных файлов, так как при этом будут перекомпилированы все заголовочные файлы включающие измененный. В больших проектах это может стать настоящей проблемой. Поэтому будем действовать разумно.

Решение №1

Всегда объявлять деструктор в *.h и определять его в *.cpp. В этом случае компиляция деструктора произойдет в том месте, где для типа Test есть уже полная информация.

Решение №2. Boost в помощь

Хотя некоторые компиляторы предупреждают о проблеме в данной ситуации, но имеет смысл подстраховаться. Не используйте std::auto_ptr! Используйте вместо него boost::scoped_ptr, который заставит вас написать деструктор, выдавая ошибки вроде:

C:\libs\boost-1.41.0\boost/checked_delete.hpp(32) : error C2027: use of undefined type 'Test'
c:\work\undefined_type\trouble.h(9) : see declaration of 'Test'
C:\libs\boost-1.41.0\boost/smart_ptr/scoped_ptr.hpp(80) : see reference to function template instantiation 'void boost::checked_delete<T>(T *)' being compiled
	with
	[
		T=Test
	]
C:\libs\boost-1.41.0\boost/smart_ptr/scoped_ptr.hpp(76) : while compiling class template member function 'boost::scoped_ptr<T>::~scoped_ptr(void)'
	with
	[
		T=Test	
	]
c:\work\undefined_type\trouble.h(18) : see reference to class template instantiation 'boost::scoped_ptr<T>' being compiled
	with
	[
		T=Test
	]
C:\libs\boost-1.41.0\boost/checked_delete.hpp(32) : error C2118: negative subscript

Или:

/usr/include/boost/checked_delete.hpp: In function ‘void boost::checked_delete(T*) [with T = Test]’:
/usr/include/boost/smart_ptr/scoped_ptr.hpp:80: instantiated from ‘boost::scoped_ptr<T>::~scoped_ptr() [with T = Test]’
/home/tma/Documents/undefined_type/trouble.h:15: instantiated from here
/usr/include/boost/checked_delete.hpp:32: error: invalid application of ‘sizeof’ to incomplete type ‘Test’ 
/usr/include/boost/checked_delete.hpp:32: error: creating array with negative size (‘-0x000000001’)
/usr/include/boost/checked_delete.hpp:33: error: invalid application of ‘sizeof’ to incomplete type ‘Test’ 
/usr/include/boost/checked_delete.hpp:33: error: creating array with negative size (‘-0x000000001’)

Причина ошибки – проверка осуществляемая scoped_ptr перед вызовом delete для объекта. Суть проверки в попытке создания массива:

typedef char type_must_be_complete[ sizeof(T)? 1: -1 ];
(void) sizeof(type_must_be_complete);

В случае неполного типа будет предпринята попытка создания массива длиной –1, что приведет к ошибке компиляции.

Если по каким либо причинам использовать boost::scoped_ptr нельзя, используйте boost::shared_ptr. Он не использует проверки, но из-за особенностей его устройства удаление объекта происходит в месте, где уже есть полная информация о его типе.

Не копируйте!

Задайте себе вопрос, действительно ли класс должен поддерживать копирование? Скорее всего это не нужно как по соображениям эффективности (передавать объект по ссылке или указателю менее накладно, чем создавать его копию при передаче по значению), так и просто исходя из здравого смысла – зачем две копии объекта, представляющего к примеру базу данных с пользователями или порт? Поэтому сделайте класс некопируемым. Для этого надо перенести объявления копирующего конструктора и оператора присваивания в защищенную секцию (определять их необязательно):

class Port
{
public:
	Port();
	virtual ~Port();
 
private:
	Port(const Port&);
	Port& operator=(const Port&);
};

В этом случае при попытке скопировать объект возникнет ошибка компиляции из-за недоступности либо конструктора копирования, либо оператора присваивания.

Но чтобы каждый раз не писать данный код и дать людям ясно понять чего вы хотите, унаследуйте класс от boost::noncopyable:

#include <boost/noncopyable.hpp>
 
class Port
	: private boost::noncopyable
{
public:
	Port();
	virtual ~Port();
};

На этом можно остановиться, но если же вы решили, что класс должен поддерживать копирование, то читайте дальше.

Функции создаваемые компилятором

Компилятор будет стараться вам помочь и если вы не написали конструктор по умолчанию, деструктор, оператор присваивания или копирующий конструктор, создаст их сам. Причем созданы они будут только если они действительно требуются. Рассмотрим простой класс:

class Message
{
private:
	unsigned Id_;
	std::string Text_;
};

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

Message()
	: Text_()
{
}

При копировании:

Message m1;
Message m2;
m1 = m2;

Будет автоматически сгенерирован оператор присваивания, который вызовет оператор присваивания для каждого члена:

Message& operator=(const Message& from)
{
	Id_ = from.Id_;
	Text_ = from.Text_;
	return *this;
}

Здесь я хочу обратить внимание на то, что оператор присваивания возвращает ссылку на *this. Это нужно для того, чтобы запись вида

m1 = m2 = m3;

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

Копирующий конструктор будет создан если вы напишете:

Message m1;
Message m2(m1);

И как и ожидается, он проинициализирует каждый член конструируемого объекта значением из другого объекта:

Message(const Message& from)
	: Id_(from.Id_)
	, Text_(from.Text_)
{
}

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

Теперь следующее правило:

Дайте компилятору помочь вам

Не мешайте компилятору написать за вас оператор присваивания и копирующий конструктор – в отличии от нас он не забудет скопировать каждый из членов. Особенно часто программисты забывают при добавлении нового члена в класс обновить также и данные методы. Компилятор обиженный отказом от предложенной помощи не скажет вам, что класс копируется не полностью!

Копируйте полностью

Но иногда помощь компилятора бывает неуместна. Например необходимо чтобы каждый объект содержал уникальный идентификатор. В таком случае оператор присваивания и копирующий конструктор придется написать самостоятельно:

class Message
{
public:
	Message()
		: Id_(GetId())
	{
	}
 
	virtual ~Message()
	{
	}
 
	Message(const Message& from)
		: Id_(GetId())
		, Text_(from.Text_)
	{
	}
 
	Message& operator=(const Message& from)
	{
		Id_ = GetId();
		Text_ = from.Text_;
		return *this;
	}
 
private:
	unsigned Id_;
	std::string Text_;
};

Здесь присутствует одна проблема, о которой поговорим позже, а пока все выглядит неплохо. Но давайте создадим класс на основе Message:

class DataMessage
	: public Message
{
public:
	DataMessage()
		: Data_()
	{
	}
 
	~DataMessage()
	{
	}
 
	DataMessage(const DataMessage& from)
		: Data_(from.Data_)
	{
	}
 
	DataMessage& operator=(const DataMessage& from)
	{
		Data_ = from.Data_;
		return *this;
	}
 
private:
	CompressedData Data_;
};

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

DataMessage(const DataMessage& from)
	: Message(from)
	, Data_(from.Data_)
{
}
 
DataMessage& operator=(const DataMessage& from)
{
	Message::operator=(from);
	Data_ = from.Data_;
	return *this;
}

Кстати напомню, что инициализация членов происходит в порядке их объявления в классе, а не в порядке следования в секции инициализации конструктора. Опасайтесь багов такого рода:

class Customer { public: Customer(const std::string& firstName, const std::string& secondName);   private: HashType Hash_; std::string FirstName_; std::string SecondName_; };   Customer::Customer(const std::string& firstName, const std::string& secondName) : FirstName_(firstName) , SecondName_(secondName) , Hash_(GetHash(FirstName_ + SecondName_)) { }

Ой! Мы хотим получить хэш от еще не инициализированных строк!

Теперь о проблеме которая осталась – мы не проверяем присваивание самому себе. Следующее правило:

Проверяйте на присваивание самому себе

Конечно вы никогда не напишите

message = message;

А как насчет этого:

Messages[i] = Messages[j];

В любом случае, по закону Мерфи, если уж что-то можно сделать неправильно, то это будет сделано. Просто защитите себя от этого:

DataMessage& operator=(const DataMessage& from)
{
	if (this == &from)
	{
		return *this;
	}
	Message::operator=(from);
	Data_ = from.Data_;
	return *this;
}

Также можно например писать о некорректном присваивании в лог ошибок.

Теперь можно поговорить о устранении дублирования кода в операторе присваивания и копирующем конструкторе. Буду краток:

Не пытайтесь реализовать оператор присваивания через копирующий конструктор или наоборот

У вас ничего не выйдет. И хотя делают они очень много похожего, но по своей сути они слишком разные чтобы их удалось скрестить. В первом случае вы будете создавать объект который уже существует, во втором присваивать что-то еще не созданному объекту. Единственное, что можно сделать – это выделить общий код в отдельную функцию вызываемую обоими методами:

class Sensor
{
public:
	Sensor(Controller* controller)
		: Controller_(controller)
	{
		Init();
	}
 
	~Sensor()
	{
		Shutdown();
	}
 
	Sensor(const Sensor& from)
		: Controller_(from.Controller_)
	{
		Init();
	}
 
	Sensor& operator=(const Sensor& from)
	{
		if (this == &from)
		{
			return *this;
		}
		Shutdown();
		Controller_ = from.Controller_;
		Init();
		return *this;
	}
 
private:
	void Init()
	{
		// Тут может быть что угодно
		Controller_->Register(this);
	}
 
	void Shutdown()
	{
		// Тут может быть что угодно
		Controller_->Unregister(this);
	}
 
private:
	Controller* Controller_;
};

Но и здесь зоркий глаз может обнаружить проблему. Последнее правило:

Напишите безопасный в смысле исключений оператор присваивания

Дело в том, что в предыдущем примере, если из Init в операторе присваивания вылетит исключение, объект останется в несогласованном состоянии, так как был вызван метод Shutdown, но повторная инициализация проведена не была. Рассмотрение данного вопроса выходит за рамки заметки, поэтому посоветую обратиться к Правилу 29: Стремитесь, чтобы программа была безопасна относительно исключений из книги Эффективное использование C++ 55 верных советов улучшить структуру и код ваших программ Скотта Мэйерса.

О том как добавить данный функционал и правильно собрать проект я расскажу в данной заметке. Также будет приведен пример кода для сжатия и распаковки файлов и сравнение zlib (алгоритм DEFLATE, методы gzip и zlib) и libbzip2 (алгоритм bzip2) по скорости работы и уровню сжатия тестовых, бинарных и исполняемых файлов.

Я не буду рассматривать интерфейсы данных библиотек, так как Boost предоставляет довольно удобную абстракцию. Суть абстракции в следующем – имеются устройства представляющие собой например файл отрытый для записи, фильтры, например архивирующий и есть возможность создать фильтрующий поток, содержащий устройство и цепочку из произвольных фильтров. Таким образом создав фильтр сжимающий переданные в него данные и соединив его с устройством пишущим в файл мы получим готовое решение для сжатия и записи данных. Соответственно чтобы распаковать сжатый файл, нам нужно создать устройство представляющее открытый для чтения файл, фильтр который будет распаковывать поступающие в него данные и соединить их.

Сразу приведу код, который рассмотрю ниже:

boost::iostreams::filtering_ostreambuf out;
out.push(boost::iostreams::bzip2_compressor());
out.push(boost::iostreams::file_sink("data.bin", std::ios::binary));
boost::iostreams::copy(boost::iostreams::file_source("data.bz2", std::ios::binary), out);
...
boost::iostreams::filtering_istreambuf in;
in.push(boost::iostreams::bzip2_decompressor());
in.push(boost::iostreams::file_source("data.bz2", std::ios::binary));
boost::iostreams::copy(in, boost::iostreams::file_sink("data.bin", std::ios::binary));

По сути в этих восьми строках содержится все необходимое для сжатия и распаковки файла. В обоих случаях мы создаем однонаправленный (только на чтение или только на запись) фильтрующий буфер потока. Создаем фильтр осуществляющий сжатие или распаковку, устройство представляющее файл, и соединяем их в буфере. После этого можно используя утилиту copy из Boost Iostreams копировать содержимое другого потока в буфер или наоборот.

Если вместо буфера (filtering_streambuf) использовать поток (filtering_stream), то писать или читать из него можно используя интерфейс потоков C++.

Устройства в Boost Iostream могут быть источниками (Source) или приемниками (Sink). Соответственно одни могут поставлять данные по требованию откуда либо, например из файла, а другие наоборот данные только куда то отправляют. Причем вы можете написать свой приемник или источник (это несложно) и создать свое устройство реализующее необходимую абстракцию. Например socket_source и socket_sink позволяющие работать с сокетами, pipe_source и pipe_sink тоже самое для именованных каналов или вообще null_sink (который кстати в Boost уже есть), которое просто получив данные тут же о них забывает. Причем соединив, скажем socket_source с фильтром boost::iostreams::bzip2_compressor вы получите передачу через сокеты сжатых данных, а дописав еще шифрующий фильтр можно получить передачу зашифрованных сжатых данных.

Сборка

Чтобы собрать ваш проект с Boost и одной из библиотек сжатия нужно сделать три вещи:

1. Собрать библиотеку zlib или bzip2/libzip2 и убедиться, что ваша система сборки увидит путь к заголовочным файлам и собранным библиотекам. Кстати на большинстве Unix систем об этом можно не задумываться, так как скорее всего библиотека уже установлена.
2. Установить при сборке проекта переменную компиляции BOOST_IOSTREAMS_NO_LIB
3. Включить в сборку один из файлов из Boost (в версии 1.41.0 они находятся в libs/iostreams/src) в зависимости от используемого метода:
   • zlib – zlib.cpp
   • gzip – gzip.cpp
   • bzip2 – bzip2.cpp

Сравнение методов сжатия zlib/gzip/bzip2

Увлекшись я написал небольшой тест для сравнения описываемых методов. Вот результаты запуска программы:

Бинарный файл со случайными числами

Размер: 5 242 880 байт

Текстовой файл (несколько мануалов Linux слитые в один файл)

Размер: 3 534 333 байт

Исполняемый файл

Размер: 4 568 332 байт

Тест конечно не претендует на серьезное исследование, но определенные выводы сделать позволяет:

• bzip2 сжимает лучше, но при этом значительно медленнее.
• zlib и gzip практически одинаковы. Это правда так, так как они используют один алгоритм, единственное отличие в том, что zlib оптимизирован для сжатия потоковых данных, например из-за этой особенности он используется в протоколе HTTP/1.1, в то время как gz применяется для сжатия файлов.

Файлы к заметке

По традиции вы можете скачать исходный код тестового проекта. Архив содержит код библиотек и файлы для сборки с CMake, таким образом вам нужно только иметь установленный Boost, Cmake и положить в директорию data проекта свои тестовые данные.

Ну и напомню, что содержимое переменной XXX можно посмотреть:

message (${XXX})

И изменить:

set (XXX ${XXX} значение)

А также проверить присутствует ли в переменной определенная подстрока:

if (XXX MATCHES "подстрока")
	...
endif ()

Если нужно изменить часть содержимого переменной (например флаг компилятора), то на помощь придут регулярные выражения:

string (REGEX REPLACE /W[0-4] /W4 CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})

В данном случае будет установлен максимальный уровень предупреждений /W4 для компилятора от Microsoft.

Недавно (с версии 1.41.0) в Boost появилась библиотека Property Tree, предназначенная для решения данной задачи. Помимо поддержки XML, также поддерживаются форматы INI, JSON и свой формат INFO.

В данной заметке я рассмотрю указанные форматы и приведу код для разбора файла.

Форматы файлов

Обойду стороной вопрос об удобстве синтаксиса, так как вопрос этот достаточно субъективный, просто приведу примеры файлов описывающих одну и ту же конфигурацию:

INI

; Комментарий
[server]
name	=	"alpha server"
port	=	9010
 
[channels]
; Иерархии в INI-файлах не поддерживаются
 
[channel]
; Не работает
name	=	first
id	=	1
comment	=	"Необязательный комментарий"
enabled	=	true
 
[channel]
; Не работает
name	=	second
id	=	2
enabled	=	false

XML

<?xml version="1.0" encoding="utf-8"?>
<!-- Комментарий -->
<server>
	<name>alpha server</name>
	<port>9010</port>
	<channels>
		<channel>
			<name>first</name>
			<id>1</id>
			<comment>Необязательный комментарий</comment>
			<enabled>true</enabled>
		</channel>
		<channel>
			<name>second</name>
			<id>2</id>
			<enabled>false</enabled>
		</channel>
	</channels>
</server>

JSON

{
	/* Комментарий */
	"server":
	{
		"name":	"alpha server",
		"port":	9010,
		"channels":
		[
			{
				"name":		"first",
				"id":		1,
				"comment":	"Необязательный комментарий",
				"enabled":	true
			},
			{
				"name":		"second",
				"id":		2,
				"enabled":	false
			}
		]
	}
}

INFO

; Комментарий
server
{
	name	"alpha server"
	port	9010
	channels
	{
		channel
		{
			name	"first"
			id	1
			comment	"Необязательный комментарий"
			enabled	true
		}
		channel
		{
			name	"second"
			id	2
			enabled	false
		}
	}
}

Теперь по существу:

1. Формат INI не поддерживает иерархическое представление данных
2. C документами сохраненными в UTF-8, проблем при чтении у Boost Property Tree не обнаружено
3. JSON очень строго регламентирует синтаксис и структуру файла, поэтому при ошибках в файле, например из-за пропущенной запятой, файл разобран не будет
4. JSON проверяет правильность написания булевых значений – написав "fals" вместо "false", вы получите ошибку на этапе разбора файла. Внимание, в случае XML и INFO ошибки на будет, а код get<bool>("…") вернет true (как и ожидается, если "false" написан верно, возвращаемое значение будет false).
5. Во всех форматах корректно идет работа как с целыми числами, так и с числами с плавающей точкой. Возможна запись в виде: 1560, 1560.5, 1.5605e3

Разбор файла

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

#include <boost/property_tree/ini_parser.hpp>
#include <boost/property_tree/xml_parser.hpp>
#include <boost/property_tree/json_parser.hpp>
#include <boost/property_tree/info_parser.hpp>

После этого создается объект типа boost::property_tree::ptree, в котором при удачном разборе файла будет сохранена структура файла со значениями. Далее собственно вызывается функция для разбора файла. Об ошибке во время разбора файла можно вывести подробное сообщение:

1
2
3
4
5
6
7
8
9
10
11
12

boost::property_tree::ptree config;
try
{
	Parser("fileName", config);
}
catch (Exception& error)
{
	std::cout 
		<< error.message() << ": " 
		<< error.filename() << ", line " 
		<< error.line() << std::endl;
}

Parser в четвертой строке и Exception в шестой в зависимости от типа файла принимают следующие значения:

Разбор конфигурации

После успешно выполненного разбора документ будет представлен узлами содержащими элементы (узел из одного значения) или другие узлы.

Доступ к нужному узлу осуществляется методом:

Для доступа к элементу узла используются три метода:

Пример кода:

try
{
	const boost::property_tree::ptree& server = config.get_child("server");
	std::cout 
		<< "\nServer ===================================\n"
		<< "Name:\t" << server.get<std::string>("name") << '\n'
		<< "Port:\t" << server.get("port", 9000) << '\n';
	BOOST_FOREACH (const boost::property_tree::ptree::value_type& channel, 
		config.get_child("server.channels"))
	{
		const boost::property_tree::ptree& values = channel.second;
		std::cout 
			<< "\tChannel --------------------------\n"
			<< "\tName:\t" << values.get<std::string>("name") << '\n'
			<< "\tId:\t" << values.get<unsigned>("id") << '\n'
			<< "\tEnabled:" << values.get<bool>("enabled", true) << '\n';
		if (const boost::optional<std::string> optionalComment = 
				values.get_optional<std::string>("comment"))
		{
			std::cout << "\t" << optionalComment.get() << '\n';
		}
	}
}
catch (const boost::property_tree::ptree_bad_data& error)
{
	std::cout << error.what() << std::endl;
}
catch (const boost::property_tree::ptree_bad_path& error)
{
	std::cout << error.what() << std::endl;
}

Запись конфигурации

Теоретически можно создавать и редактировать конфигурационные файлы, для этого есть соответствующие методы:

config.put("enabled", false);
write_xml("test.xml", config);

К сожалению практически в этом смысла мало:

1. Файлы XML и JSON становятся трудночитаемыми человеком, так как полностью пропадает форматирование
2. UTF-8 фрагменты в JSON сохраняются с полной потерей информации
3. На этом фоне INFO смотрится прилично, но комментарии не сохраняются

Заключение

У меня, как правило не стоит задача сохранения конфигураций из программы. Система конфигурируется человеком в текстовом редакторе, а программа данную конфигурацию читает и настраивает себя. Для этих целей библиотека очень удобна и действительно упрощает разбор конфигураций. В качестве формата файлов я выбрал JSON из-за его легкого синтаксиса и строгих проверок.

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

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

Файлы к заметке

Архив с тестовой программой и конфигурацией в формате INI, XML, JSON, INFO