@mrnimda

Из гуманитария в программисты программисты после 25.

2020-05-16T11:34:05.044Z

Однажды утром, когда мне было 25, я проснулся с сильным желанием самореализации. Спустя несколько месяцев раздумий было принято решение кардинально изменить свою жизнь. Потом ещё несколько месяцев заняло осознание того, что же во мне вызывает неподдельный интерес. За всё это время, в моей голове рождались только айтишные проекты и идеи. Для реализации любой из них нужно много денег или быть специалистом в своём деле. За неимением первого, я решил для начала научиться программировать.

Так начался мой путь из гуманитария в программисты. Первые полгода всё свободное время я уделял книгам, курсам на Stepik и огромному количеству роликов на Ютуб. Это был разбросанный в знаниях и очень хаотичный период времени. За те полгода я успел пройти 2 курса по Python, освоить основы HTML и CSS.

Далее пришло время практики. Месяц проб и ошибок, не дал мне никаких весомых результатов, лишь только осознание нескольких вещей:

Самостоятельное изучение, мне очень плохо даётся.
Получение желаемых результатов без сторонней помощи, может затянуться на долгие годы.
Программирование меня реально прёт, потому помимо реализации своих идей, я очень хочу работать программистом.

Было принято решение начать искать работу программистом. Живу я в маленьком городе, на тот момент на весь город была 1 вакансия на программиста. Написал письмо на корпоративный ящик работодателя, в котором рассказал, какие знания смог получить за время самостоятельного обучения, что у меня нет опыта работы, но зато есть огромное желание и стремление грызть гранит науки. Так по воле случая меня пригласили на собеседование, где я сразу согласился на бесплатную стажировку на вакансию С++ разработчик. Так я сделал свой окончательный выбор и посвятил всего себя изучению программирования.

Последующие две недели после собеседования, я целыми днями изучал теорию по С++ и пытался понять данный язык. За это время мне подготовили рабочее место и я вышел на стажировку. Считаю, что мне очень повезло в этом плане, т.к не каждый работодатель будет так запариваться ради стажёра, за что я очень благодарен.)

Тестовым заданием была задача написать парсер логов, с возможностью ведения базы знаний в бд. В итоге весь процесс растянулся на 4 месяца. За это время были:

Бесконечные вопросы будущим коллегам. Спасибо им, что помогали и научили пользоваться гуглом 🤣.
Бессонные ночи изучения документаций и Stack Overflow.
Выходные с репетитором, который тоже отвечал на безумное количество моих вопросов. Ведь на работе, уже было стыдно спрашивать 🤣🤣🤣.
Спасибо ему то же за терпение и то, что объяснял одно и то же по тысяче раз).

После написания утилиты меня взяли на работу с испытательным сроком, а спустя еще 3 месяца приняли в основной штат.

Если подытожить тот период времени, для себя я усвоил:

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

На данный момент:

В этом году решил поступить в универ на заочку, для получения профильного образования.
Получил перевод в другой филиал.
Изучаю в в свободное время cv и нейронки.
Пробую писать свои первые пет проекты.

Надеюсь Вам понравилась моя история, и в будущем буду Вас также радовать интересными рассказами из жизни)

BOOST :: MPL в естественной среде обитания.

2020-01-10T07:02:34.835Z

Немного теории:

Метапрограммирование обычно определяется как создание программ, которые генерируют другие программы. Сейчас для нас метапрограммирование это удобный механизм шаблонов, который предоставляет широкие возможности для вычислений во время компиляции.

boost::mpl - это библиотека метапрограммирования,которая удовлетворяет потребность в наиболее востребованных и часто используемых шаблонах кодирования. Так же, как и STL дала нам концепцию итераторов, библиотека ускоренного метапрограммирования предоставляет итераторы типов и протокол классов мета-функций.

Метафункция - центральная абстракция MPL. Это шаблонный класс, все параметры являются типами. В открытом доступе находится вложенный элемент «::type/::value», в отличии от свойств может выполнять действия.

Имя_метафункции<аргументы>::type/::value;

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

Стандартные примеры:

Одна из самых сильных сторон MPL, это концептуальное и синтаксическое сходство с STL. Алгоритмы и идиомы, которые программисты уже знают из STL, могут быть снова применены во время компиляции.

Большинство алгоритмов в mpl работают с последовательностями.
Например, поиск типа в списке выглядит следующим образом:

typedef mpl :: list <char, short, int, long, float, double> types;
typedef mpl :: find <types, long> :: type iter;

Здесь find принимает два параметра - последовательность для поиска ( types ) и значение ( long ) - и возвращает итератор iter, указывающий на первый элемент последовательности, так что iter :: type идентичен long .Если такого элемента не существует, iter идентичен end <types> :: type . По сути, именно так можно искать значение в std :: list или std :: vector , за исключением того, что mpl :: find принимает последовательность как один параметр, а std :: find занимает два итератора.

Есть возможность вызывать класс метафункций или лямбда-выражение с аргументами A1, ... An.

typedef mpl::apply< mpl::find<f>, list,long >::type iter;
typedef mpl::apply< lambda<f> , a1, ... an >::type lmd;

Даже если не использовать мета функцию lambda в MPL. Библиотека всё равно предоставляет средство использования лямбда-выражений во время компиляции.
Предположим, что мы хотим иметь лямбда-выражение, которое при вызове возвращает foo<Arg1,Arg2>. Такое лямбда-выражение может быть реализовано с помощью MPL Placeholder Expression - шаблон класса, созданный с одним или несколькими заполнителями:

typedef  foo < boost :: mpl :: _1 , boost :: mpl :: _2 >  foo_specifier ;

В данном случае foo_specifier это конкретный тип, такой же, как int или std::set<std::string>. Внутренние механизмы MPL способны обнаруживать, что этот тип был получен при создании экземпляра шаблона класса с заполнителями, boost::mpl::_1 и boost::mpl::_2, для первого и второго аргументов при вызове foo_specifier. Выраженные заполнители избавляют нас от необходимости писать типовые классы мета-функций.

Примеры из реальной жизни:

Пример ассоциативной последовательности, хранящей типы mpl::pair.

typedef boost::mpl::map<
	boost::mpl::pair<ITV8::GDRV::IVideoSource,		VideoSourceFactory>,
	boost::mpl::pair<ITV8::GDRV::IAudioSource,		AudioSourceFactory>,
	boost::mpl::pair<ITV8::GDRV::ITelemetry,		TelemetryFactory>,
	boost::mpl::pair<ITV8::GDRV::IIODevice,			IODeviceFactory>,
	boost::mpl::pair<ITV8::GDRV::IVideoAnalytics,	VideoAnaliticsFactory>,
	boost::mpl::pair<ITV8::GDRV::IAudioDestination,	AudioDestinationFactory>
> PanasonicDriverImplementationMap;

Map - может содержать не более одного элемента для каждого ключа.

Пример последовательности произвольного доступа, дополнительно поддерживающей операции back, push_back, pop_back.

typedef boost::mpl::vector<
	ITV8::Utility::MultipartFilter,
	ITV8::Utility::AudioBufferG7xxSendingFilter
> G7xxFilterChain;

Vector - самая простая и во многих случаях самая эффективная последовательность.

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

template<typename TFilterMap>
class MultiplexingFilter : public boost::mpl::inherit_linearly<TFilterMap,
	boost::mpl::inherit<boost::mpl::placeholders::_1,
		detail::FilterContainer<
			boost::mpl::first<boost::mpl::placeholders::_2>,
			boost::mpl::second<boost::mpl::placeholders::_2>
		>
	> >::type
{
    // ...
};

inherit_linearly по сути - это for each во время компиляции, который применяет типы из TFilterMap, к типу Node, который применяется к результату предыдущего "вызова". В данном случае Node - это boost::mpl::inherit, который строит иерархию из переданных ему типов.

mpl::inherit является прямой последовательностью.
Это концепция MPL, представляющая последовательность элементов во время компиляции.Метафункции mpl::first и mpl::second предоставляют итераторы, ограничивающие диапазон элементов последовательности.

Заполнитель в форме _n - это просто синоним соответствующей специализации arg <n>. Безымянный заполнитель. Имена заполнителей можно сделать доступными в пространстве имен пользователя с помощью mpl :: placeholder.

Таким образом у нас получается что-то вроде:

class MultiplexingFilter 
   : detail::FilterContainer<
            boost::mpl::first<TFilterMap::at<N - 1> >,
            boost::mpl::second<TFilterMap::at<N - 1> >
      > 
{
    // ...
};

Т.е. содержимое первого элемента TFilterMap наследуют в типе FilterContainer от пустого базового класса. Потом, что получилось, становится базовым классом для содержимого второго элемента нашего TFilterMap в типе FilterContainer. Так продолжается, пока элементы в TFilterMap не закончатся.

Это нужно, чтобы на этапе компиляции получить структуру вида:

class MultiplexingFilter 
{
     detail::FilterContainer<key_from_map1, value_from_map1> data1;
     detail::FilterContainer<key_from_map2, value_from_map2> data2;
     //.....
     detail::FilterContainer<key_from_mapN, value_from_mapN> dataN;
};

Лямбда выражения:

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

Можно сгенерировать класс метафункции из класса boost::add_pointer <_1>, используя лямбды MPL:

template <class X>
struct two_pointers
	: twice<typename mpl::lambda<boost::add_pointer<_1>>::type, X>	
{};

BOOST_STATIC_ASSERT
((
	boost::is_same
	<
		typename two_pointers<int>::type, 
		int**
	>::value
));

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

Хотя основная цель использования лямбды состоит в том, чтобы превратить placeholder выражения в классы метафункций, mpl::lambda может принять любое выражение лямбды, даже если это уже - класс метафункции. В этом случае лямбда возвращает свой неизменный аргумент. Алгоритмы MPL, такие как transform вызывают лямбду, прежде, чем обратиться к результату класса метафункции, это позволяет таким алгоритмам работать одинаково хорошо с любым видом лямбда выражений.

Применим эту стратегию к twice, чтобы не передавать в нее лямбду явно:

template <class F, class X>
struct twice : 
apply_helper
<
	typename mpl::lambda<F>::type, 
	typename apply_helper
	<
		typename mpl::lambda<F>::type, 
		X
	>::type
>
{};

Теперь можно использовать twice с классами метафункций и заполнителями:

int* x;

twice<add_pointer_f, int>::type          p = &x;		// передаем класс метафункции
twice<boost::add_pointer<_1>, int>::type q = &x;		// передаем метафункцию с заполнителем

Частичное приложение метафункции

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

Рассмотрите выражение лямбды mpl::plus<_1, _1>. Одинаковый аргумент передан обоим параметрам plus, таким образом число добавляется к самому себе. Двойная метафункция plus используется, чтобы создать унарное лямбда выражение. Другими словами, мы создали совершенно новое вычисление! Передавая не-заполнитель (non-placeholder) в качестве одного из аргументов, можно построить унарное лямбда выражение, которое добавляет постоянное значение, например, 42 к своему аргументу:

mpl::plus<_1, mpl::int_<42>>

Композиция метафункций:

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

mpl::multiplies<mpl::plus<_1,_2>, mpl::minus<_1,_2>>

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

MPL использует специальное правило, чтобы облегчить объединение обычных шаблонов в метапрограммы: после того, как все заполнители были заменены фактическими аргументами, если у получившейся специализации шаблона X нет вложенного «::type», результат лямбды является только X.

Например, mpl::apply<vector<_>, T> является всегда только vector<T>. Если бы не это поведение мы должны были бы создавать тривиальные метафункции для обеспечения обычных специализаций шаблона в лямбда выражениях:

// trivial std::vector generator
template<class U>
struct make_vector { typedef std::vector<U> type; };

typedef mpl::apply<make_vector<_>, T>::type vector_of_t;

Вместо этого достаточно написать лишь 1 строку:

typedef mpl::apply<std::vector<_>, T>::type vector_of_t;

BOOST

2019-12-23T06:11:08.741Z

BOOST::THREADS. Многопоточное программирование

Создание потока

Пример 1 демонстрирует очень простой пример использования класса boost::thread. Создается новый поток, который просто выводит “Hello World” на std::cout, а основной поток ждет его завершения.

// Пример 1 
#include <boost/thread/thread.hpp> 
#include <iostream> 
void hello() 
{ 
	std::cout << 
		"Hello world, I'm a thread!" 
		<< std::endl; 
} 
int main(int argc, char* argv[]) 
{ 
	boost::thread thrd(&hello); 
	thrd.join(); 
	return 0; 
}

Мьютексы

В примере 2 показано очень простое использование класса boost::mutex. Создаются два новых потока, каждый из них 10 раз выводит свой id и счетчик цикла, а основной поток дожидается их завершения. Объект std::cout является разделяемым ресурсом, поэтому каждый поток использует глобальный мьютекс, гарантирующий, что только один поток в каждый момент времени пытается осуществлять вывод.

// Пример 2 
#include <boost/thread/thread.hpp> 
#include <boost/thread/mutex.hpp> 
#include <iostream> 
boost::mutex io_mutex; 
struct count 
{ 
	count(int id) : id(id) { } 
	void operator()() 
	{ 
		for (int i = 0; i < 10; ++i) 
		{ 
			boost::mutex::scoped_lock lock(io_mutex); 
			Douglas Schmidt, Michael Stal, Hans Rohnert, and Frank 
				Buschmann. Pattern-Oriented Software Architecture 
				Volume 2 — Patterns for Concurrent and Networked 
				Objects (Wiley, 2000). 
				(Scoped Lock). 
				std::cout << id << ": " 
				<< i << std::endl; 
		} 
	} 
	int id; 
}; 
int main(int argc, char* argv[]) 
{ 
	boost::thread thrd1(count(1)); 
	boost::thread thrd2(count(2)); 
	thrd1.join(); 
	thrd2.join(); 
	return 0; 
}

Передача данных потоку требует ручного кодирования функционального объекта. Хотя этот код и тривиален, писать его всякий раз довольно скучно. Есть и более простое решение. Функциональные библиотеки позволяют создать новые функциональные объекты, связывая (bind) другие функциональные объекты с данными, которые при вызове будут им переданы. В примере 3 показано, как при использовании библиотеки Boost.Bind можно упростить код примера 2, отказавшись от ручного кодирования функционального объекта.

// Пример 3 
// Эта программа идентична программе 
// из примера 2, кроме того, что 
// использует Boost.Bind 
// при создании потока, 
// принимающего параметры. 
#include <boost/thread/thread.hpp> 
#include <boost/thread/mutex.hpp> 
#include <boost/bind.hpp> 
#include <iostream> 
boost::mutex io_mutex; 
void count(int id) 
{ 
	for (int i = 0; i < 10; ++i) 
	{ 
		boost::mutex::scoped_lock lock(io_mutex); 
		std::cout << id << ": " <<i << std::endl; 
	} 
} 
int main(int argc, char* argv[]) 
{ 
	boost::thread thrd1(boost::bind(&count, 1)); 
	boost::thread thrd2(boost::bind(&count, 2)); 
	thrd1.join(); 
	thrd2.join(); 
	return 0; 
}

Условные переменные

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

Условная переменная всегда используется в связке с мьютексом и разделяемым ресурсом (или ресурсами). Поток первым делом блокирует мьютекс, а затем проверяет, находится ли ресурс в состоянии, допускающем его безопасное использование требуемым образом. Если он не в нужном состоянии, поток вызывает для условной переменной операцию ожидания. Эта операция приводит к разблокированию мьютекса во время ожидания, так что другой поток получает возможность изменить состояние разделяемого ресурса. Она также гарантирует, что при возвращении потока после ожидания мьютекс окажется заблокированным. Когда другой поток изменяет состояние разделяемого ресурса, он должен уведомить потоки, которые могут ждать условную переменную, позволяя им завершить ожидание.

Пример 4 иллюстрирует применение класса boost::condition. Определен класс, реализующий ограниченный буфер — контейнер фиксированного размера с поддержкой ввода/вывода в порядке очереди (FIFO). Этот буфер сделан потокобезопасным благодаря использованию boost::mutex. Операции put и get используют условную переменную, чтобы удостовериться в том, что поток будет ждать, пока буфер не окажется в состоянии, необходимом для завершения операции. Создаются два потока, один помещает в этот буфер сто целых, а другой их же извлекает. Ограниченный буфер в каждый момент времени может содержать только 10 целых, поэтому каждому из потоков приходится периодически ждать другой поток. Для проверки того, что это действительно происходит, операции put и get выводят в std::cout диагностические сообщения. Наконец, основной поток ожидает завершения обоих потоков.

// Пример 4 
#include <boost/thread/thread.hpp> 
#include <boost/thread/mutex.hpp> 
#include <boost/thread/condition.hpp> 
#include <iostream> 
const int BUF_SIZE = 10; 
const int ITERS = 100; 
boost::mutex io_mutex; 
class buffer 
{ 
public: 
	typedef boost::mutex::scoped_lock scoped_lock; 
	buffer() : p(0), c(0), full(0) { } 
	void put(int m) 
	{ 
		scoped_lock lock(mutex); 
		if (full == BUF_SIZE) 
		{ 
			{ 
				boost::mutex::scoped_lock lock(io_mutex); 
				std::cout <<"Buffer is full. Waiting..."<< std::endl; 
			} 
			while (full == BUF_SIZE) 
				cond.wait(lock); 
		} 
		buf[p] = m; 
		p = (p+1) % BUF_SIZE; 
		++full; 
		cond.notify_one(); 
	} 
	int get() 
	{ 
		scoped_lock lk(mutex); 
		if (full == 0) 
		{ 
			{ 
				boost::mutex::scoped_lock lock(io_mutex); 
				std::cout << "Buffer is empty. Waiting..."
<< std::endl; 
			} 
			while (full == 0) 
				cond.wait(lk); 
		} 
		int i = buf[c]; 
		c = (c+1) % BUF_SIZE; 
		--full; 
		cond.notify_one(); 
		return i; 
	} 
private: 
	boost::mutex mutex; 
	boost::condition cond; 
	unsigned int p, c, full; 
	int buf[BUF_SIZE]; 
}; 
buffer buf; 
void writer() 
{ 
	for (int n = 0; n < ITERS; ++n) 
	{ 
		{ 
			boost::mutex::scoped_lock lock(io_mutex); 
			std::cout << "sending: " << n << std::endl; 
		} 
		buf.put(n); 
	} 
} 
void reader() 
{ 
	for (int x = 0; x < ITERS; ++x) 
	{ 
		int n = buf.get(); 
		{ 
			boost::mutex::scoped_lock lock(io_mutex); 
			std::cout << "received: " << n << std::endl; 
		} 
	} 
} 
int main(int argc, char* argv[]) 
{ 
	boost::thread thrd1(&reader); 
	boost::thread thrd2(&writer); 
	thrd1.join(); 
	thrd2.join(); 
	return 0; 
}

Локальная память потока

Пример 5 иллюстрирует очень простое применение класса boost::thread_specific_ptr. Создаются два потока, в них инициализируется локальная память потока, а затем в цикле 10 раз значение целого, расположенного по адресу «умного» указателя инкрементируется, а результат выводится в std::cout (который синхронизирован с помощью мьютекса, так как является разделяемым ресурсом). Основной поток ожидает завершения этих двух потоков. Вывод в этом примере ясно показывает, что каждый поток оперирует со своим экземпляром данных, хотя оба они используют один и тот же boost::thread_specific_ptr.

// Пример 5 
#include <boost/thread/thread.hpp> 
#include <boost/thread/mutex.hpp> 
#include <boost/thread/tss.hpp> 
#include <iostream> 
boost::mutex io_mutex; 
boost::thread_specific_ptr<int> ptr; 
struct count 
{ 
	count(int id) : id(id) { } 
	void operator()() 
	{ 
		if (ptr.get() == 0) 
			ptr.reset(new int(0)); 
		for (int i = 0; i < 10; ++i) 
		{ 
			(*ptr)++; 
			boost::mutex::scoped_lock lock(io_mutex); 
			std::cout << id << ": " << *ptr << std::endl; 
		} 
	} 
	int id; 
}; 
int main(int argc, char* argv[]) 
{ 
	boost::thread thrd1(count(1)); 
	boost::thread thrd2(count(2)); 
	thrd1.join(); 
	thrd2.join(); 
	return 0; 
}

Однократно вызываемые функции

Остается разобраться с одним вопросом: как сделать функции инициализации (такие как конструкторы) потокобезопасными. Например, когда «глобальный» экземпляр объекта создается как синглетон уровня приложения (единственный существующий в приложении объект данного типа), существует проблема порядка инстанцирования, поэтому используется функция, возвращающая статический экземпляр, которая гарантирует, что при первом к ней обращении этот экземпляр будет создан. Проблема в том, что если несколько потоков одновременно вызовут эту функцию, конструктор для статического объекта также может быть вызван несколько раз, и результаты могут оказаться плачевными.

Решение проблемы в так называемых «однократно вызываемых функциях» (once routine). Такая функция вызывается в приложении только один раз. Если несколько потоков попытаются ее вызвать одновременно, только один из них получит такую возможность, а в это время все остальные потоки будут ждать, пока выполнение функции не завершится. Чтобы гаранти ровать однократное выполнение, такая функция вызывается косвенно через другую функцию, которой передается указатель на исходную и ссылка на специальный флаг, сигнализирующий о факте вызова функции. Этот флаг инициализируется статически, что гарантирует инициализацию в период компиляции, а не в период выполнения. И таким образом не представляет проблемы для многопоточной инициализации. Библиотека Boost.Threads предоставляет возможность однократного вызова функции посредством boost::call_once, а также определяет тип для флага boost::once_flag и специальную макроподстановку, используемую для статической инициализации флага, BOOST_ONCE_INIT.

Пример 6 показывает очень простой пример использования boost::call_once. Глобальное целое статически инициализируется нулем, а экземпляр boost::once_flag статически инициализируется с помощью BOOST_ONCE_INIT. Основной поток запускает два потока, каждый из которых пытается «инициализировать» глобальное целое, вызывая boost::call_once с указателем на функцию, инкрементирующую целое. Затем основной поток дожидается завершения обоих потоков и выводит конечное значение целого в std::cout. Вывод демонстрирует, что функция действительно была вызвана только однажды, так как значение целого – единица.

// Пример 6 
#include <boost/thread/thread.hpp> 
#include <boost/thread/once.hpp> 
#include <iostream> 
int i = 0; 
boost::once_flag flag = BOOST_ONCE_INIT; 
void init() 
{ 
	++i; 
} 
void thread() 
{ 
	boost::call_once(&init, flag); 
} 
int main(int argc, char* argv[]) 
{ 
	boost::thread thrd1(&thread); 
	boost::thread thrd2(&thread); 
	thrd1.join(); 
	thrd2.join(); 
	std::cout << i << std::endl; 
	return 0; 
}

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

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

int i;
boost::once_flag flag = BOOST_ONCE_FLAG;
void init()
{
 i = 0;
}
void thread()
{
 boost::call_once(&init, flag);
 // дальнейший код
}

Так вот, инициализация произойдёт всего один раз, независимо от числа конкурирующих потоков.

Ожидание внутри потоков

Иногда надо подождать немного в потоке. Для этого есть два разных способа
• boost::this_thread::sleep(params)
• boost::this_thread::yield()
Первый (с установленными параметрами) замораживает поток на указанное время.
Второй действует хитрее - он ненадолго замораживает поток, отдавая тем самым ресурсы другим участникам состязания за них. Эдакая джентльменская уступка.

BOOST::BIND

Предположим, что есть функция:

bool compare(int a, int b) {return a < b;}

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

std::vector<int> vec(…);
std::sort(vec.begin(), vec.end(), compare);

Теперь немного усложним задачу – в зависимости от флага нам необходимо сортировать либо по возрастанию, либо по убыванию. При использовании только STL пришлось бы писать две функции. Накладно. С помощью boost эту задачу решить значительно проще:

bool compare(int a, int b, bool reverseSort) {return reverseSort ? a > b : a < b;}

std::vector<int> vec(…);
std::sort(vec.begin(), vec.end(), boost::bind(compare, _1, _2, order));

где order – булевская переменная, задающая порядок сортировки. Последняя строчка выглядит несколько странновато, но именно в ней и заключается вся суть. В результате ее компиляции будет получен код, реализующий сортировку массива, использующий для сравнения функцию compare, и передающей ей на вход три аргумента – два числа, которые необходимо сравнить, и способ их сравнения.
Рассмотрим этот код подробнее, записав его так:

int a = 1, b = 2;
boost::bind(compare, _1, _2, false)(a, b);

(что-то подобное содержится в недрах функции std::sort). Последняя строчка в этом коде обозначает следующее:

boost::bind – функция, создающая необходимый нам связыватель. Возвращает экземпляр функционального объекта (функтора), для которого применим оператор вызова функции. (compare, - первый аргумент функции определяет имя/указатель на функцию, которая должна быть вызвана в связывателе. В данном случае это функция compare; _1, _2 – плейсхолдеры, определяющие логику передачи параметров из оператора вызова функции в функцию compare. , false) – значение последнего аргумента, передаваемого в compare. (a, b) – оператор вызова функции, производящий связывание аргументов и вызов функции compare. В итоге будет выполнена следующий код:

compare(a, b, false);

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

boost::bind(compare, _1, 4, false)(a, b); // неправильно. 
boost::bind(compare, _1, 4, false)(a); // правильно
boost::bind(compare, _1, _2, false)(a); // неправильно
boost::bind(compare, _1, _2, false)(a, b); // правильно

Очевидно, что попытка задать в вызове boost::bind количество параметров, несоответствующее количеству обязательных параметров в вызываемой функции приведет к ошибке. Равно как и попытка указания количества параметров большего, чем количество параметров в вызываемой функции. Действуя по аналогии мы можем записать:

std::find_if(vec.begin(), vec.end(), boost::bind(compare, _1, 4, false)); // поиск первого числа, меньшего 4
std::remove_if(vec.begin(), vec.end(), boost::bind(compare, _1, 4, true)); // удаление из последовательности всех элементов, больших 4
// и т. д.

В случае использования чистого STL для каждого случая пришлось бы искать подходящий функтор… Или писать его. Здесь необходимо обратить внимание на то, что в качестве первого параметра функции bind может выступать не только указатель на функцию, но и другой функциональный объект. Например:

std::find_if(vec.begin(), vec.end(), boost::bind(std::equal_to<int>(), _1, 4));

этот строчка найдет в массиве первый элемент, равный 4.

Использование с указателями на функции члены

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

class GraphicsObject
{
public:
 void Draw(Canvas* canvas, DrawModes mode);
};
// Объявляем коллекцию объектов этого класса:
std::list<GraphicsObject*> GraphObjects;
// А теперь нам нужно отрисовать все объекты коллекции на заданном канвасе
std::for_each(GraphObjects.begin(), GraphObjects.end(); ……..);

при использовании чистого STL нам бы пришлось писать свой собственный функтор, вызывающий у переданного объекта метод Draw с заданными параметрами. Но можно воспользоваться boost::bind:

std::for_each(GraphObjects.begin(), GraphObjects.end(), 
 boost::bind(&GraphObject::Draw, _1, canvas, mode));

в результате чего мы получаем требуемый результат. У всех объектов коллекции вызывается метод Draw, которому передаются параметры canvas и mode. При использовании указателя на функцию-член класса необходимо помнить о том, что первым параметром ей должен передаваться указатель на объект, для которого эта функция должна вызываться. В приведенном примере мы указываем, что метод должен вызываться у переданного в bind единственного параметра. Но никто не мешает нам в качестве первого передаваемого параметра указать this, или любой другой указатель. Но, как говориться в современных набивших оскомину рекламах, это еще не все.

Использование с указателем на член данных

Помимо указателей на члены-функции можно использовать указатели на члены данных. Синтаксис подобный и правила использования при этом почти такие же. Возьмем задачу. Есть структура и вектор ее экземпляров:

struct Point
{
 int x;
 int y;
};
std::vector<Point> PointsArray;

Теперь надо удалить из этого массива все элементы, у которых координата x равна нулю. Сделать это просто:

std::remove_if(PointsArray.begin(), PointsArray.end(), 
 boost::bind(std::equal_to<int>(), boost::bind(&Point::x, _1), 0));

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

Каскадное использование связывателей

Связыватели могут вкладываться друг в друга. Один из вариантов такого вкладывания проиллюстрирован предыдущем примером. Единственное, что в этом случае надо «держать в голове» - это то, что плейсхолдеры, вне зависимости от того, в каком bind'ере (по уровню вложенности) они находятся, «адресуют» параметры самого внешго binder'а. Усложним предыдущий пример. Нужно выбросить все точки, имеющие нулевые координаты:

std::remove_if( PointsArray.begin(), PointsArray.end(), boost::bind(
 std::logical_and(), 
 boost::bind(std::equal_to<int>(), boost::bind(&Point::x, _1), 0),
 boost::bind(std::equal_to<int>(), boost::bind(&Point::y, _1), 0)
 )
));

Это хотя и работает так, как хочется, но выглядит слишком наворочено. По этому начиная с версии 1.33 в boost::bind появилась новая возможность -

Перегруженные операторы

Для упрощения приведенных выше многоэтажных конструкций для boost::bind (начиная с версии 1.33 boost'а) перегружены следующие операторы: !, ==, !=, <, ?, > и >=. Таким образом, приведенное выше выражение упрощается до:

std::remove_if( PointsArray.begin(), PointsArray.end(), boost::bind(
 boost::bind(&Point::x, _1) == 0 && boost::bind(&Point::y, _1) == 0)
 ));

Использование ссылок

Одна из неприятностей заключается в том, что если связываемая функция принимает какой-то из своих аргументов по ссылке, то с использованием boost::bind его (напрямую) передать нельзя. Т. е. например, в следующем случае:

void foo(int& a, int& b);
int a = 1, b = 2;
boost::bind(foo, a, b);

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

boost::bind(foo, boost::ref(a), boost::ref(b));

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

Пример использования.

#include <vector>
#include <boost/bind.hpp>
#include <boost/function.hpp>
class Test
{
public:
	void f_1()
	{
		std::cout << "void f()" << std::endl;
	}
	void f_2(int i)
	{
		std::cout << "void f_2(): " << i << std::endl;
	}
	void f_3(const int &i)
	{
		std::cout << "void f_2(): " << i << std::endl;
	}
	void two_params(int a, int b)
	{
		std::cout << "void two_params(int a, int b): " << a << ", " << b << std::endl;
	}
};

class Test2
{
public:
	void do_stuff(const std::vector<int>& v)
	{
		std::copy(v.begin(), v.end(), std::ostream_iterator<int>(std::cout, " "));
	}
};

void test(const std::string &a)
{
	std::cout << "void test(const std::string &a). a = " << a << std::endl;
}

void prn(boost::function<void(int)> fn, int a)
{
	fn(a);
}

int _tmain(int argc, _TCHAR* argv[])
{
	////////////////////// bind //////////////////////
	std::cout << "boost::bind test" << std::endl;
	Test a;
	boost::bind(&Test::f_1, &a)();

	boost::bind(&Test::f_2, &a, 1)();
	int test_int(2);
	boost::bind(&Test::f_2, &a, _1)(test_int);

	boost::bind(&Test::f_3, &a, 3)();
	int test_int_2(4);
	boost::bind(&Test::f_3, &a, _1)(test_int_2);

	int one(100), two(200);
	boost::bind(&Test::two_params, &a, _1, _2)(one, two);
	boost::bind(&Test::two_params, &a, _2, _1)(one, two);

	std::string test_str("Hi there.");
	boost::bind(&test, test_str)();
	boost::bind(&test, _1)(test_str);
	std::cout << std::endl;

	////////////////////// function //////////////////////
	std::cout << "boost::function test" << std::endl;

	boost::function<void(void)> func;
	func = boost::bind(&Test::f_1, &a);
	func();
	func = boost::bind(&Test::f_2, &a, 201);
	func();
	func = boost::bind(&Test::f_3, &a, 202);
	func();
	func = boost::bind(&Test::two_params, &a, 203, 204);
	func();

	boost::function<void(int)> func_2;
	func_2 = boost::bind(&Test::f_2, &a, _1);
	prn(func_2, 301);
	func_2 = boost::bind(&Test::f_3, &a, _1);
	prn(func_2, 302);

	int i_303(303), i_304(304), i_305(305), i_306(306);
	func_2 = boost::bind(&Test::two_params, &a, i_303, _1);
	prn(func_2, 1);
	func_2 = boost::bind(&Test::two_params, &a, _1, i_304);
	prn(func_2, 1);

	Test2 t;
	std::vector<int> vec;
	vec.resize(20);
	std::generate_n(vec.begin(), 20, rand);
	std::copy(vec.begin(), vec.end(), std::ostream_iterator<int>(std::cout, " "));
	//simple_bind(&Test::do_stuff, t, _1)(vec);
	//boost::bind(&Test2::do_stuff, t, _1)(vec);

	return 0;
}

BOOST::ASIO (::IO_SERVICE)

boost::asio на самом деле, хоть и называется библиотекой асинхронной, но может выполнять и синхронные, и асинхронные операции. Вся библиотека при этом завязана на объекты класса boost::asio::io_service – именно asio::io_service предоставляет программе связь с нативными объектами ввода/вывода. Соответственно, что бы ваша программа могла работать с boost::asio, нужно создать хотя бы один объект этого класса и уже после этого “аттачить” все другие объекты к нему, например вот так:

boost::asio::io_service io_service;
boost::asio::ip::tcp::socket socket(io_service);

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

boost::system::error_code ec; // здесь будет записана ошибка, если она была
socket.connect(server_endpoint, ec); // server_endpoint задаёт куда подключаемся

После того как мы подключили объекты ввода-вывода (в данном случае socket) к asio::io_service – этот сервис будет осуществлять взаимодействие с операционной системой и получать/отправлять данные.

boost::asio асинхронный

Тот вариант, что мы рассмотрели выше – это синхронное взаимодействие, т.е., в данном случае это значит, что пока происходит подключение – наша программа “зависнет” до того момента, пока подключение не выполнится, либо не произойдёт ошибка. Если же мы хотим что бы работа boost::asio была асинхронной, надо идти немного другим путём, который тоже предусмотрен в библиотеке. Для работы с асинхронными операциями мы должны передать в функцию так называемый completion handler, или, говоря по русски, функцию, которая будет вызвана, когда операция завершится (т.е. либо подключится, либо возникнет ошибка):

void your_completion_handler(const boost::system::error_code& ec)
{
// тут обрабатываем подключение либо ошибку
}

boost::asio::io_service io_service;
boost::asio::ip::tcp::socket socket(io_service);
socket.async_connect(server_endpoint, your_completion_handler);

Все асинхронные функции в boost::asio работают именно по такому принципу. С одной стороны, это довольно удобно для программирования – логика работы каждой из функций отделена от других, с другой стороны это может может показаться Вам немного непривычным.

Использование boost::asio

Приведу короткий и простой пример использования boost::asio , это код примера из самого boost, лишь перевёл комментарии:

#include <iostream>
#include <istream>
#include <ostream>
#include <string>
#include <boost/asio.hpp>
 
using boost::asio::ip::tcp;
 
int main(int argc, char* argv[])
{
 try
 {
 if (argc != 3) // если аргументы не заданы или заданы не все
 {
 std::cout << "Usage: sync_client <server> <path>\n";
 std::cout << "Example:\n";
 std::cout << " sync_client www.boost.org /LICENSE_1_0.txt\n";
 return 1;
 }

boost::asio::io_service io_service; // основной класс asio

// Получаем список конечных точек для указанного сервера
 tcp::resolver resolver(io_service);
 tcp::resolver::query query(argv[1], "http");
 tcp::resolver::iterator endpoint_iterator = resolver.resolve(query);
 tcp::resolver::iterator end;

 // Перебираем эти конечные точки и пробуем подключиться
 tcp::socket socket(io_service);
 boost::system::error_code error = boost::asio::error::host_not_found;
 while (error && endpoint_iterator != end)
 {
 socket.close();
 socket.connect(*endpoint_iterator++, error);
 }
 if (error) // подключиться не удалось
 throw boost::system::system_error(error);

 // Формируем запрос к веб-серверу. Указываем "Connection: close" что бы
 // сервер закрыл соединение как только отправит нам данные. Это
 // позволит нам узнать что отправка завершенна как только возникнет EOF
 boost::asio::streambuf request;
 std::ostream request_stream(&request);
 request_stream << "GET " << argv[2] << " HTTP/1.0\r\n";
 request_stream << "Host: " << argv[1] << "\r\n";
 request_stream << "Accept: */*\r\n";
 request_stream << "Connection: close\r\n\r\n";

 // Отправляем сформированный запрос веб-серверу.
 boost::asio::write(socket, request);

 // Читаем ответ сервер. streambuf response примет все данные
 // он сам будет увеличиваться по мере поступления данных от сервера.
 boost::asio::streambuf response;
 boost::asio::read_until(socket, response, "\r\n");

 // Проверяем что бы не было ошибок.
 std::istream response_stream(&response);
 std::string http_version;
 response_stream >> http_version;
 unsigned int status_code;
 response_stream >> status_code;
 std::string status_message;
 std::getline(response_stream, status_message);
 if (!response_stream || http_version.substr(0, 5) != "HTTP/") // ошибка
 {
 std::cout << "Invalid response\n";
 return 1;
 }
 if (status_code != 200) // если код ответа не 200, то это тоже ошибка
 {
 std::cout << "Response returned with status code " << status_code << "\n";
 return 1;
 }

 // Читаем ответ. Он закончится пустой строкой.
 boost::asio::read_until(socket, response, "\r\n\r\n");

 // Парсим заголовки
 std::string header;
 while (std::getline(response_stream, header) && header != "\r")
 std::cout << header << "\n";
 std::cout << "\n";

 // Выводим в лог
 if (response.size() > 0)
 std::cout << &response;

 // Теперь читаем до конца
 while (boost::asio::read(socket, response, 
 boost::asio::transfer_at_least(1), error))
 std::cout << &response;

 if (error != boost::asio::error::eof) // ошибка
 throw boost::system::system_error(error);
 }
 catch (std::exception& e) // возникло исключение
 {
 std::cout << "Exception: " << e.what() << "\n";
 }

 return 0;
}

Вот эти 100 строк кода работают как HTTP-клиент и позволяют нам читать страницы с веб-серверов.

Асинхронное программирование

Этот раздел глубоко разбирает некоторые вопросы, с которыми вы столкнетесь при работе с асинхронным программированием.

Необходимость работать асинхронно

как правило, синхронное программирование гораздо проще, чем асинхронное. Потому что гораздо легче думать линейно (вызываем функцию А, после ее окончания вызываем ее обработчик, вызываем функцию В, после ее окончания вызываем ее обработчик и так далее, так что можно думать в манере событие-обработчик). В последнем случае вы можете иметь, скажем, пять событий и вы никогда не сможете узнать порядок, в котором они выполняются, и вы даже не будете знать выполнятся ли они все! Но даже при том, что асинхронное программирование сложнее вы, скорее всего, предпочтете его, скажем, в написании серверов, которые должны иметь дело с большим количеством клиентов одновременно. Чем больше клиентов у вас есть, тем легче асинхронное программирование по сравнению с синхронным. Скажем, у вас есть приложение, которое одновременно имеет дело с 1000 клиентами, каждое сообщение от клиента серверу и от сервера клиенту заканчивается символом ‘\n’. Синхронный код, 1 поток:

using namespace boost::asio;
struct client 
{
	ip::tcp::socket sock;
	char buff[1024]; // each msg is at maximum this size
	int already_read; // how much have we already read?
};
std::vector<client> clients;
void handle_clients() 
{
	while ( true)
		for ( int i = 0; i < clients.size(); ++i)
			if ( clients[i].sock.available() ) on_read(clients[i]);
}
void on_read(client & c) 
{
	int to_read = std::min( 1024 - c.already_read, c.sock.
		available());
	c.sock.read_some( buffer(c.buff + c.already_read, to_read));
	c.already_read += to_read;
	if ( std::find(c.buff, c.buff + c.already_read, '\n') < c.buff + c.already_read) 
	{
		int pos = std::find(c.buff, c.buff + c.already_read, '\n') - c.buff;
		std::string msg(c.buff, c.buff + pos);
		std::copy(c.buff + pos, c.buff + 1024, c.buff);
		c.already_read -= pos;
		on_read_msg(c, msg);
	}
}
void on_read_msg(client & c, const std::string & msg) 
{
	// analyze message, and write back
	if ( msg == "request_login")
		c.sock.write( "request_ok\n");
	else if ...
}

Одна вещь, которую вы хотите избежать при написании серверов (да и в основном любого сетевого приложения) это чтобы код перестал отвечать на запросы. В нашем случае мы хотим, чтобы функция handle_clients() блокировалась как можно меньше. Если функция заблокируется в какой-либо точке, то все входящие сообщения от клиента будут ждать, когда функция разблокируется и начнет их обработку. Для того чтобы оставаться отзывчивым мы будем читать из сокета только тогда, когда в нем есть данные, то есть if ( clients[i].sock.available() ) on_read(clients[i]). В on_read мы будем читать только столько, сколько есть в наличии; вызов read_until(c.sock, buffer(...),'\n') было бы не очень хорошей идеей, так как она блокируется, пока мы не прочитаем сообщение от конкретного клиента до конца (мы никогда не узнаем когда это произойдет).

Узким местом здесь является функция on_read_msg(); все входящие сообщения будут приостановлены, до тех пор, пока выполняется эта функция. Хорошо-написанная функция on_read_msg() будет следить, чтобы этого не произошло, но все же это может произойти (иногда запись в сокет может быть заблокирована, например, если заполнен его буфер).

Синхронный код, 10 потоков:

using namespace boost::asio;
struct client
{
	// ... same as before
	bool set_reading() 
	{
		boost::mutex::scoped_lock lk(cs_); 
		if ( is_reading_) return false; // already reading
		else { is_reading_ = true; return true; }
	}
	void unset_reading()
	{
		boost::mutex::scoped_lock lk(cs_); 
		is_reading_ = false;
	}
private:
	boost::mutex cs_;
	bool is_reading_;
};
std::vector<client> clients;
void handle_clients() 
{
	for ( int i = 0; i < 10; ++i)
		boost::thread( handle_clients_thread);
}
void handle_clients_thread() 
{
	while ( true)
		for ( int i = 0; i < clients.size(); ++i)
			if ( clients[i].sock.available() ) 
				if ( clients[i].set_reading()) 
				{
					on_read(clients[i]); 
					clients[i].unset_reading();
				}
}
void on_read(client & c)
{
	// same as before
}
void on_read_msg(client & c, const std::string & msg) 
{
	// same as before
}

Для того, чтобы использовать несколько потоков, нам нужно их синхронизировать, что и делают функции set_reading() и set_unreading(). Функция set_reading() является очень важной. Вы хотите, чтобы «проверить можно ли читать и начать читать» выполнялось за один шаг. Если у вас это выполняется за два шага («проверить можно ли читать» и «начать чтение»), то вы можете завести два потока: один для проверки на чтение для какого-либо клиента, другой для вызова функции on_read для того же клиента, в конечном итоге это может привести к повреждению данных и возможно даже к зависанию системы.

Вы заметите, что код становится все более сложным. Возможен и третий вариант для синхронного кода, а именно иметь по одному потоку на каждого клиента. Но так как число одновременных клиентов растет, то это в значительной степени становится непозволительной операцией. А теперь рассмотрим асинхронные варианты. Мы постоянно делали асинхронной операцию чтения. Когда клиент делает запрос, вызывается операция on_read, мы отвечаем в ответ, а затем ждем, когда поступит следующий запрос (запускаем еще одну операцию асинхронного чтения).

Асинхронный код, 10 потоков:

using namespace boost::asio;
io_service service;
struct client
{
	ip::tcp::socket sock;
	streambuf buff; // reads the answer from the client
}
std::vector<client> clients;
void handle_clients() 
{
	for ( int i = 0; i < clients.size(); ++i)
		async_read_until(clients[i].sock, clients[i].buff, '\n', boost::bind(on_read, clients[i], _1, _2));
	for ( int i = 0; i < 10; ++i)
		boost::thread(handle_clients_thread);
}
void handle_clients_thread() 
{
	service.run();
}
void on_read(client & c, const error_code & err, size_t read_bytes) 
{
	std::istream in(&c.buff);
	std::string msg;
	std::getline(in, msg);
	if ( msg == "request_login")
		c.sock.async_write( "request_ok\n", on_write);
	else if ...
		...
		// now, wait for the next read from the same client
		async_read_until(c.sock, c.buff, '\n', boost::bind(on_read, c, _1, _2));
}

Обратите внимание, насколько проще стал код. Структура client имеет только два члена, handle_clients() просто вызывает async_read_until, а затем создает десять потоков, каждый из которых вызывает service.run(). Эти потоки будут обрабатывать все операции асинхронного чтения или записи клиенту. Еще одно нужно отметить, что функция on_read() будет постоянно готовиться к следующей операции асинхронного чтения (смотрите последнюю строку).

Методы отладки и тестирования программы

2019-12-18T06:25:54.432Z

Теоретические сведения

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

Во-первых, компилятор указывает не ту строку исходного текста программы, в которой произошла ошибка, а ту, в которой она проявилась. Эта строка может оказаться гораздо ниже, чем та, на которой сделана ошибка. Например, если вы забудете закончить описание класса на языке С++ точкой с запятой, как в следующем примере, то компилятор будет считать, что описание продолжается, и сообщит об ошибке только тогда, когда в этом "продолжении" возникнет какое-нибудь противоречие. Оно может проявиться спустя несколько десятков строк исходного текста, и вы будете ломать голову, недоумевая, какая же в этом месте может быть ошибка. Нужен некоторый опыт, чтобы сообразить, что ошибка находится гораздо выше.

class А{ int п;
public:
A(int n){ this.n = n;
}
}
class B{ } ;

Во-вторых, ошибка может произойти по разным причинам, компилятор же укажет только одну. Иногда компилятор честно сообщает, что не может определить причину ошибки, написав просто: "Syntax error". В большинстве случаев он указывает наиболее часто встречающуюся, по мнению разработчиков компилятора, ошибку, в вашей программе может оказаться совсем другая, поэтому принимайте сообщения компилятора не как истину, а только как один из возможных вариантов.

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

Синтаксические ошибки обнаруживаются и устраняются довольно легко после нескольких запусков программы. Без исправления этих ошибок программа просто не будет работать. Гораздо труднее исправить семантические ошибки — ошибки в алгоритме работы программы.

Часто встречающаяся семантическая ошибка — неправильная расстановка скобок в выражении. Компилятор может проверить парность скобок, но если число открывающих скобок совпадает с числом закрывающих скобок, то компилятор не может сказать, в нужных ли местах они стоят. Здесь надо быть особенно внимательным и отдавать себе отчет в том, что вы хотите вычислить. Например, переменная х может получить значение, вычисленное следующим оператором:

double х = 2 * (а - Ь) / (а + Ь) + к * 5 * (а + Ь) / (а * Ь) ;

Но значение х вполне можно вычислить и таким оператором:

double х = 2 * (а - b) / (а + Ь) + к * (5 * а + Ь) / (а * Ь) ;

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

Еще одна распространенная ошибка, не обнаружимая компилятором, возникает из-за неправильной расстановки или отсутствия фигурных скобок.

В следующем примере, очевидно, переменная s, в которой накапливается сумма, должна изменяться при каждой итерации цикла, но компилятор не может "понять", что, фактически, она меняется только один раз: после выполнения цикла.

int m, S = 0;
for (int k = 0; k < a.sizeO - 1; k++) m = a[k + 1] - a[k]; s += 2 * m * m - 3 * m + 2;

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

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

Процесс отладки проходит несколько этапов. Ошибку сначала надо обнаружить. Потом найти место ее появления, как говорят, локализовать ошибку. После этого ошибку надо устранить. Рассмотрим подробнее каждую стадию отладки.

Обнаружение ошибки

Большинство синтаксических ошибок обнаруживается компилятором или выявляется сразу же после первых запусков программы. Их нетрудно обнаружить и исправить. Как правило, трудности вызывает обнаружение семантических ошибок. О них обычно и идет речь, когда говорят об отладке.

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

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

Программа не дает результатов

В этой ситуации надо, прежде всего, добиться все-таки от программы хоть какой-то выдачи. Это достигается добавлением в программу функций вывода printf(), fprintf о, puts() или других функций, выводящих промежуточные значения всех или наиболее важных переменных. Они образуют так называемую отладочную печать. Это название появилось в эпоху телетайпов, когда результаты выводились на бумажную ленту. Сейчас отладочные сведения выводятся на экран дисплея или записываются в файл, но слово "печать" осталось в лексиконе программистов, означая выдачу результатов на какое-нибудь устройство вывода.

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

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

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

Программа дает неверные результаты

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

double х = 3.45 * а[к - 1] + 2.5 * а[к + 1];

и написать, поставив вместо десятичной точки звездочку:

double х = 3.45 * а[к - 1] + 2*5 * а[к + 1];

Из-за этой мало заметной ошибки значение переменной х изменится в четыре раза.

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

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

Еще одно средство поиска ошибок — пошаговое выполнение программы, при котором она приостанавливается после выполнения каждого оператора. После останова можно просмотреть промежуточные значения переменных и выполнить следующий оператор. Разумеется, полное пошаговое выполнение всей программы займет слишком много времени. Поэтому его обычно начинают с какой-либо контрольной точки и прекращают, как только ошибка найдена.

Еще труднее найти ошибки в алгоритме решения задачи. Они могут накапливаться понемногу от оператора к оператору. По отладочной печати трудно отследить момент появления таких ошибок. Пошаговое выполнение программы тоже не поможет найти ее. В таком случае надо проверять сам алгоритм и убеждаться в его правильности.

Программа дает правдоподобные результаты

Это самая коварная ситуация. Получив результаты, близкие к предполагаемым, вы можете подумать, что программа работает правильно, и передать ее в эксплуатацию.

Как убедиться в том, что результаты правильны, а не правдоподобны? Здесь помогает тестирование программы. Тщательно подобранные тесты позволят отличить правдоподобные значения от правильных результатов. Как правило, одного набора тестов недостаточно для убедительного доказательства неверности работы программы. Специалисты-тестировщики всегда подбирают несколько наборов тестов так, чтобы точнее выявить дефекты программы.

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

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

Локализация ошибки

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

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

Когда и прокрутка не помогает, приходится проверять логику выполнения программы. Проверка начинается с места обнаружения ошибки. Просматривается полученная в этой точке отладочная печать, и проводятся рассуждения вроде следующих: "Такие результаты мог дать оператор А или оператор В. Но оператор В в этом случае не может выполняться. Значит, посмотрим на оператор А. Оператор А дал значение С, а оно могло получиться только в ситуации D. Чтобы возникла ситуация D, надо, чтобы...". На каждом логическом шаге приходится делать отладочную печать и небольшую прокрутку. Привлечение логических рассуждений помогает быстрее проделать эту трудную работу, поскольку концентрирует внимание только на тех переменных, которые могут получить ошибочные значения, а таких переменных немного.

Наконец, каждый программист знает, что при попытке объяснить ошибку, которая никак не поддается локализации, своему коллеге по работе или постороннему консультанту, неожиданно, в процессе рассказа, самому автору программного кода вдруг становится ясно, в чем заключается ошибка. Иногда даже письменное изложение проблемы помогает найти ее решение. Это объясняется тем, что при последовательном изложении проблемы мысли приходят в порядок, выстраивается логическая цепочка, приводящая к решению задачи. Поэтому очень важно периодически обсуждать возникающие проблемы всей командой разработчиков. Такие обсуждения не только позволяют устранять трудности, возникающие в процессе разработки, но и держат программистов в курсе всех задач, решаемых на каждом этапе реализации проекта.

Устранение ошибки

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

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

Чтобы не попасть в неприятный цикл отладки или быстрее выйти из него, следуйте простому правилу: "Исправлять за один раз только одну ошибку". Тогда вы будете знать, из-за чего возникла новая ошибка, и сможете быстро устранить ее.

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

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

Средства отладки

Трудоемкость процесса отладки всегда вызывала стремление автоматизировать его. С появлением первых компиляторов стали появляться и программы- отладчики (debuggers), называемые на жаргоне программистов "дебаггерами". Они предоставляют программные средства для выполнения основных работ по отладке. С их помощью легко установить контрольные точки, сделать трассировку и пошаговое выполнение программы, просмотреть текущие значения всех или выбранных переменных.

Отладчики тесно связаны с компиляторами. Для улучшения отладки компилятор может вставлять в машинный код дополнительную, отладочную, информацию, которую отладчик использует при прогоне программы. Поэтому отладчики чаще всего поставляются вместе с компиляторами, в одной интегрированной среде разработки IDE (Integrated Development Environment). В меню Options, или каком-нибудь другом меню, предназначенном для настройки параметров компилятора в такой интегрированной среде, можно выбрать один из нескольких режимов работы компилятора, в том числе отладочный режим, Debug, или окончательный режим, Release.

Во время разработки программы надо выбрать отладочный режим компилятора. Тогда можно будет использовать все средства отладчика, которые обычно перечислены в меню Debug интегрированной среды. После окончания отладки, когда уже решено передавать программу в эксплуатацию, компилятор надо перестроить на создание окончательной версии (release, build). В режиме Release компилятор удаляет из машинного кода отладочную информацию и генерирует оптимизированный рабочий код.

Тестирование

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

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

Unit-тестирование

По сути дела, тестированием своего участка программы занимается каждый разработчик программного обеспечения. Написав какой-либо класс, процедуру или несколько процедур, программист обязательно проверяет их работу на характерных для этого кода наборах данных. Появившаяся недавно методика unit-тестирования возводит эту привычку в абсолютное правило. Эта методика предписывает проводить тестирование после написания каждой процедуры или класса. Более того, unit-тестирование обязывает писать тесты еще до создания исходного кода программы!

Допустим, мы решили написать класс комплексных чисел complex. По методике unit-тестирования мы начинаем с того, что пишем пустой класс complex и вместе с ним сразу же пишем класс Testcomplex, который будет впоследствии содержать тесты.

class Complex{};
class TestComplex{
Complex z; 
public:
    TestComplex(Complex z)
    { 
        this.z = z;
    }
    void runTest(){ }
};

Весь этот код сразу компилируется, чтобы убедиться в правильности написанной конструкции. Затем начинаем разработку класса complex. В процессе разработки каждый создаваемый метод класса complex записывается еще и в тестовый класс Testcomplex, например, следующим образом:

#include <iostream>
class Complex
{
    double re, im; 
public:
    Complex(double a = 0.0, double b = 0.0)
    { 
         re = a; im = b;
    }
    double mod()
    {
         return sqrt(re * re + im * im) ;
    }
};
class TestComplex
{
Complex z; 
public:
     TestComplex(Complex z) 
     { 
         this.z = z;
     }
     void runTest(double result)
     {
         cout « testMod(result) « endl;
     }
     bool testMod(double result)
     { 
          return z.modO == result;
     }
};
void main()
{
     Complex zl(), z2(0.0, 1.0), z3(3.0, -4.0);
     TestComplex tl(zl), t2(z2), t3(z3); 
     tl.runTest(0.0); 
     t2.runTest(1.0); 
     t2.runTest(5.0);
}

После компиляции и отладки этого кода сразу же начинается тестирование. Только после того, как все тесты выполнены успешно, продолжается создание класса.

Такая методика программирования получила название программирования, управляемого тестами (TDP, test-driven programming). Она вошла обязательной составной частью в быстро получившую популярность среди разработчиков свободного программного обеспечения методику экстремального программирования ХР (extreme programming). Unit-тестирование первоначально возникло в технологии Java. Не удивительно, что и наибольшее развитие получил свободно распространяемый программный продукт JUnit, автоматизирующий unit-тестирование Java-ioiaccoB. Для разработчиков, пишущих программы на языке С++, по аналогии с этим программным продуктом, создана библиотека классов, названная CppUnit.

Сейчас в распоряжении программистов есть множество программных продуктов, облегчающих unit-тестирование. Более того, есть продукты, генерирующие наборы тестов. Например, фирмой Parasoft Corporation создан и распространяется программный продукт JTest, подготавливающий тесты для JUnit.

Методики тестирования

За полувековую историю развития компьютеров предложено множество методик тестирования. Самая простая рассматривает программу как "черный ящик", внутренняя структура которого неизвестна. Испытатель проверяет работу "черного ящика", подавая на его вход определенные сигналы и наблюдая, как программа реагирует на них. Первым эту методику предложил, пожалуй, Козьма Прутков, сказавший: "Щелкни кобылу в нос, она махнет хвостом".

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

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

Реальные методики тестирования используют оба подхода. Одни методики приближаются к "черному ящику", другие — к "прозрачному ящику". Так или иначе, в настоящее время практически во все наборы тестов включаются тесты, учитывающие исходный текст программы. Это значительно облегчает тестирование.

Пусть, например, надо протестировать программу, находящую площадь треугольника по длинам его сторон а , b, с. Если мы знаем, что эта программа вычисляет отдельно площадь прямоугольного треугольника как полупроизведение его катетов, и отдельно площадь остальных треугольников по формуле Герона, то нам не надо создавать огромное количество тестов. Мы можем разбить все множество исходных данных а , b, с на два класса — образующих прямоугольный треугольник и не образующих его — и прогнать всего по одному тесту для каждого класса.

По своему назначению тесты делятся на несколько групп:
□ функциональное тестирование;
□ тестирование обращений к базам данных;
□ тестирование логики программы;
□ нагрузочное тестирование;
□ стрессовое тестирование;
□ тестирование интерфейса пользователя;
□ тестирование безопасности и прав доступа;
□ тестирование инсталляции программного продукта. Рассмотрим подробнее каждую из этих групп тестов.

Функциональное тестирование

Это основной вид тестирования, проверяющий соответствие программы функциональным требованиям, предъявленным к ней на самом первом этапе проектирования программного продукта. Функциональное тестирование призвано убедиться в правильности ввода исходных данных, обработки и вывода результатов, а также в правильности работы всех элементов управления программой. Для этого проигрываются все сценарии использования программы (use case). При этом в тестах задаются и правильные и неправильные входные данные. Это позволяет проверить реакцию программы на ошибки ввода.

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

уравнение ax + Ьх + с = 0 с действительными коэффициентами. Для этого надо подготовить тестовый набор коэффициентов а, b, с, учитывающих все возможные ситуации. Не зная о том, что решение уравнения зависит от знака дискриминанта, мы можем упустить один из тестов, приводящих к положительному или отрицательному дискриминанту. Зато, зная алгоритм нахождения корней, мы можем разбить все тестовые значения коэффициентов на те, которые дают неотрицательный дискриминант, и те, для которых дискриминант отрицателен. В каждой группе можно взять только один набор значений коэффициентов а , b, с. Дополнив этот набор вырожденными и граничными значениями, мы получим полный набор тестов.

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

Тестирование обращений к базам данных

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

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

Тестирование бизнес-логики программы

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

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

Нагрузочное тестирование

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

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

Стрессовое тестирование

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

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

Стрессовые тесты полезны не только для выявления дефектов программы, но и для получения информации о реакции программы на пиковые нагрузки. Эту информацию затем можно включить в инструкцию по эксплуатации программы.

Тестирование интерфейса пользователя

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

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

Тестирование безопасности и прав доступа

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

Для тестирования безопасности в системе создаются несколько временных пользователей с разными правами доступа. Тесты выполняются несколько раз от имени каждого из них. В наборе тестов следует предусмотреть все действия пользователя, имеющиеся в программе, и посмотреть, какие из них разрешены пользователю, а какие — нет.

Тестирование инсталляции программного продукта

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

Наборы тестов

Набор тестов (test suite) следует подготовить еще до проектирования программного продукта, на этапе определения требований к нему. Именно требования к программе и составляют круг тех задач, которые должны быть выражены в тестовых заданиях. Кроме того, спроектировав систему, уже трудно беспристрастно оценивать ее. Направление мысли разработчика во- лей-неволей будет идти в русле готового проекта, а это помешает всесторонней оценке проделанной работы. Поэтому подготовку тестов и последующее тестирование следует поручить не разработчикам проекта, а профессионально подготовленной команде специалистов-тестировщиков.

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

Каждый отдельный тест, называемый специалистами тестовым случаем (test case), состоит из исходных данных, вводимых в тестируемый программный модуль, и предполагаемого результата, который должен получить модуль.

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

Процесс тестирования

Не следует думать, что тестирование завершает разработку и тестировать надо уже готовую программу. Напротив, этот процесс надо начинать на самых ранних стадиях разработки. Тестирование может выявить упущения в проектировании программного модуля, а такие упущения лучше устранить пораньше. Кроме того, известно, что исправление одних ошибок часто вносит другие. Хотя общее число ошибок уменьшается, после каждого исправления приходится снова тестировать программу. Таким образом, тестирование вклинивается в процесс разработки. По этим причинам сейчас получила большую популярность методика непрерывного тестирования программы во время ее разработки. Она называется zero-defect mindset.

Согласно методике zero-defect mindset, все ошибки подразделяются на несколько уровней по своей грубости. Программист не имеет права добавлять новую функциональность в программу, пока он не исправит все крупные ошибки до определенного уровня. Допустимый уровень ошибки устанавливается для каждого этапа разработки, он повышается по мере завершения работы.

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

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

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

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

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

Особенности тестирования объектно-ориентированных программ

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

Количество классов, их строение и взаимодействие между ними определяются на стадии объектно-ориентированного проектирования. На этой стадии создаются диаграммы классов и диаграммы связей. Зачастую по этим диаграммам генерируется исходный программный код в виде абстрактных классов и/или интерфейсов. После этого уже можно провести полноценное тестирование полученной модели. Исправление ошибок на такой ранней стадии позволит значительно сэкономить время отладки и всей разработки в целом. Более того, тестирование поможет выяснить, соответствует ли модель требованиям, предъявленным к программному продукту, и своевременно исправить проект.

Тестирование объектно-ориентированных программ чаще всего выполняется снизу вверх. Вначале проверяется программный код методов класса и тестируются отдельные методы. Затем начинается тестирование класса.

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

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

После того как тестирование отдельных классов уже не выявляет ошибок в них, создаются объекты разных классов, и проверяется их взаимодействие. Выстраивается иерархия классов и тестируется правильность наследования в этой иерархии. Здесь удобнее стиль тестирования сверху вниз, от базовых классов к порожденным классам, от вершины иерархии классов к самым конкретным классам. Для тестирования абстрактных классов специально создаются его реализации-заглушки.

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

Средства тестирования

Процесс автоматизации коснулся и тестирования. Множество фирм занимается выпуском программных продуктов, предназначенных для тестирования. Наиболее известны компании: Parasoft Corporation, TestQuest, Optimyz Software, Segue Software, Compuware Coiporation, AutomatedQA Corporation. Ими и другими фирмами создано множество программных продуктов, облегчающих и автоматизирующих этот процесс. Мы уже упоминали JUnit, JTest, CppUnit. К ним можно добавить программные продукты Rational Functional Center, Insure++, ITG Center, SilkPerformer, CARS. Это только малая часть средств автоматизации тестирования и генерации тестов.

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

Разработка сетевых приложений

2019-12-17T06:33:02.154Z

Модель OSI

Чтобы понять все принципы взаимодействия компьютеров на расстоянии, надо знать так называемую модель OSI (ISO OSI == International Organization for Standardization Open System Interconnection - Взаимодействие Открытых Систем по Стандарту Международной Организации по Стандартизации).

Вот эти уровни:

7. Прикладной

Это уровень, максимально приближенный к пользовательскому интерфейсу. Пользователи конечного программного продукта не волнует, как передаются данные, зачем и через какое место... Они сказали "ХОЧУ!" - а мы, программисты, должны им это обеспечить. В качестве примера можно взять на рассмотрение любую сетевую игру: для игрока она работает на этом уровне. Пользователь куда то ткнул, в интерфейсной части программы зафиксирована его команда. Что надо передать? Что то приняли, что произошло в мире игры?

6. Представительский

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

5. Сеансовый

Этот уровень позволяет пользователям осуществлять "сеансы связи". То есть именно на этом уровне передача пакетов становится для программиста прозрачной, и он может, не задумываясь о реализации, непосредственно передавать данные, как цельный поток. Здесь на сцену вступают протоколы HTTP, FTP, Telnet, SMTP и т.д.

4. Транспортный

Осуществляет контроль над передачей данных (сетевых пакетов). То есть, проверяет их целостность при передаче, распределяет нагрузку и т.д. Этот уровень реализует такие протоколы, как TCP, UDP и т.д. Для нас представляет наибольший интерес.

3. Сетевой

Логически контролирует адресацию в сети, маршрутизацию и т.д. Должен быть интересен разработчикам новых протоколов и стандартов. На этом уровне реализованы протоколы IP, IPX, IGMP, ICMP, ARP. В основном, управляется драйверами и операционными системами. Сюда влезать, конечно, стоит, но только когда ты знаешь, что делаешь, и полностью в себе уверен.

2. Канальный

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

1. Аппаратный (Физический)

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

Итак, подведем небольшой итог к тому, что было представлено... Мы видим, что, чем выше уровень - тем выше степень абстракции от передачи данных, к работе с самими данными. Это и есть смысл всей модели OSI: поднимаясь все выше и выше по ступенькам ее лестницы, мы все меньше и меньше заботимся о том, как данные передаются, мы все больше и больше становимся заинтересованными в самих данных, нежели в средствах для их передачи. Каждый следующий уровень скрывает в себе предыдущий, облегчая жизнь пользователю этого уровня, будь он программист, радиоинженер или твоя подруга, которая не знает, как настроить MS Outlook Express...

Нас, как программистов, интересуют уровни 3, 4 и 5. Мы должны использовать средства, которые они предоставляют, для того чтобы построить 6 и 7 уровни, с которыми смогут работать конечные пользователи.

Сокеты

У каждой современной операционной системы есть средства для взаимодействия с другими компьютерами. Самым распространенным среди программистов средством для упомянутых целей являются сокеты. Сокеты - это API (Application Programming Interface - Интерфейс Программирования Приложений) для работы с уровнями OSI. Сокеты настолько гибки, что позволяют работать почти с любым из уровней модели OSI. Хочешь - формируй IP-пакеты руками и займись хакингом, отправляя "неправильные" пакеты, которые будут вводить сервера в ступор, хочешь - займись более благоразумным делом и создай новый удобный голосовой чат, хочешь - игрульку по сети гоняй, не хочешь - твое право, но этот случай мы в данном руководстве не рассматриваем... :)

Когда мы создаем сокет (socket - гнездо), мы получаем возможность доступа к нужному нам уровню OSI. Ну а дальше мы можем использовать соответствующие вызовы для взаимодействия с ним. Когда мы создаем сокет, мы также заставляем систему организовать два канала: входящий (это как громкоговоритель у телефона) и исходящий (микрофон). Осуществляя чтение и запись в эти каналы, мы приказываем системе взять на себя дальнейшую судьбу данных, т.е. передать и проследить, чтоб данные дошли вовремя, в нужной последовательности, не искаженные и т.п. Система должна давать (и дает) максимум гарантий (для каждого уровня OSI - гарантии свои), что данные будут переданы правильно. Наша задача - поместить их в очередь, а на другом конце - прочитать из входящей очереди и обработать должным образом. В каждой ОС степень поддержки сокетов разная, но точно могу сказать: в современных операционных системах MS и *nix - сокеты поддерживаются настолько, насколько нам, они могут понадобиться.

Введение в Windows Sockets API C++

Выделяют клиентские и слушающие (серверные) сокеты. Различия между ними очевидны: клиентские подключаются к процессу (к слушающему сокету), слушающие сокеты, соответственно, обрабатывают эти подключения. Передача данных между процессами происходит через клиентские сокеты.

Общая схема работы с сокетами в Windows

Клиент

• Инициализация WSA
• Создание сокета
• Присоединение к серверу
• Прием/передача данных
• Разрыв соединения
Сервер
• Инициализация WSA
• Создание слушающего сокета и привязка к порту
• Прослушивание порта
• Обработка входящих подключений
• Прием/передача данных
• Разрыв соединения

Пример. Клиентское и серверное приложение

КЛИЕНТ:

#include < winsock2.h > 
#include < ws2tcpip.h >
#include < iostream >

#define ip "127.0.0.1"
#define port 27015
#define bufsize 256
#pragma comment(lib, "Ws2_32.lib")

int main()
{
	setlocale(LC_ALL, "Russian");

	//Инициализация WSA
	WSADATA wsaData;

	int result;
	result = WSAStartup(MAKEWORD(2, 2), &wsaData);
	if (result != 0)
	{
		std::cout << "Ошибка WSAStartup: " << result << std::endl;
		return 1;
	}

	//Создание сокета
	SOCKET clientSocket = INVALID_SOCKET;
	clientSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
	if (clientSocket == INVALID_SOCKET)
	{
		std::cout << "Ошибка socket(): " << WSAGetLastError() << std::endl;
		WSACleanup();
		return 1;
	}

	//Присоединение к серверу
	sockaddr_in clientService;
	clientService.sin_family = AF_INET;
	clientService.sin_addr.s_addr = inet_addr(ip);
	clientService.sin_port = htons(port);
	result = connect(
		clientSocket,
		reinterpret_cast< SOCKADDR* >(&clientService),
		sizeof(clientService)
		);
	if (result != 0)
	{
		std::cout << "Ошибка в connect(): " << WSAGetLastError() << std::endl;
		WSACleanup();
		return 1;
	}

	//Передача данных серверу
	char data[] = "Test";
	result = send(clientSocket, data, static_cast< int >(strlen(data)), 0);
	if (result < 0)
	{
		std::cout << "Ошибка в send(): " << WSAGetLastError() << std::endl;
		return 1;
	}

	//Прием данных от сервера
	char buf[bufsize];
	int r;
	do
	{
		r = recv(clientSocket, buf, bufsize, 0);
		if (r > 0)
			std::cout << "Приянтно " << r << " байт" << std::endl;
		else if (r == 0)
			std::cout << "Соединение разорвано" << std::endl;
		else
			std::cout << "Ошибка в recv(): " << WSAGetLastError() << std::endl;
	} while (r > 0);
	
    //Разрыв соединения
	closesocket(clientSocket);
	// Если работа с сокетами больше не предполагается вызываем WSACleanup()
	WSACleanup();
	return 0;
}

СЕРВЕР:

#include < winsock2.h > 
#include < ws2tcpip.h >
#include < iostream >

#define DEFAULT_PORT "27015"
#define DEFAULT_BUFLEN 512
#pragma comment(lib, "Ws2_32.lib")

int main()
{
	setlocale(LC_ALL, "Russian");

	//Инициализация WSA
	int iResult;
	WSAData d;
	iResult = WSAStartup(MAKEWORD(2, 2), &d);
	
    if (iResult != 0)
	{
		std::cout << "Error at WSAStartup: " << iResult;
		return 1;
	}
	
    //Подготовка данных для создания сокета
	struct addrinfo *result = NULL, *ptr = NULL, hints;
	ZeroMemory(&hints, sizeof (hints));
	hints.ai_family = AF_INET;
	hints.ai_socktype = SOCK_STREAM;
	hints.ai_protocol = IPPROTO_TCP;
	hints.ai_flags = AI_PASSIVE;
	iResult = getaddrinfo(NULL, DEFAULT_PORT, &hints, &result);
	
    if (iResult != 0)
	{
		std::cout << "Ошибка getaddrinfo: " << iResult;
		WSACleanup();
		return 1;
	}
	
    //Создание сокета
	SOCKET listenSocket = INVALID_SOCKET;
	listenSocket = socket(result->ai_family, result->ai_socktype, result->ai_protocol);
	
    if (listenSocket == INVALID_SOCKET)
	{
		std::cout << "Error at socket(): " << WSAGetLastError();
		freeaddrinfo(result);
		WSACleanup();
		return 1;
	}
	
    //Связывание сокета с сетвевым адресом
	iResult = bind(listenSocket, result->ai_addr, result->ai_addrlen);
	if (iResult == SOCKET_ERROR)
	{
		std::cout << "Bind failed with error: " << WSAGetLastError();
		freeaddrinfo(result);
		closesocket(listenSocket);
		WSACleanup();
		return 1;
	}
	
    freeaddrinfo(result);
	
    //Прослушивание подключений
	if (listen(listenSocket, SOMAXCONN) == SOCKET_ERROR)
	{
		std::cout << "Listen failed with error: " << WSAGetLastError();
		closesocket(listenSocket);
		WSACleanup();
		return 1;
	}
	
    //Обработка запроса на подключение
	SOCKET ClientSocket;
	ClientSocket = INVALID_SOCKET;
	ClientSocket = accept(listenSocket, NULL, NULL);
	if (ClientSocket == INVALID_SOCKET)
	{
		std::cout << "Accept failed with error: " << WSAGetLastError();
		closesocket(listenSocket);
		WSACleanup();
		return 1;
	}
	
    //Обмен данными
	char recvbuf[DEFAULT_BUFLEN];
	int iSendResult;
	int recvbuflen = DEFAULT_BUFLEN;
	do
	{
		// Принимаем данные от клиента
		iResult = recv(ClientSocket, recvbuf, recvbuflen, 0);
		if (iResult > 0)
		{
			std::cout << "Принято " << iResult << " байт" << std::endl;
			// Отправляем данные, принтые от клиента, обратно
			iSendResult = send(ClientSocket, recvbuf, iResult, 0);
			if (iSendResult == SOCKET_ERROR)
			{
				std::cout << "Send failed with error: " << WSAGetLastError();
				closesocket(ClientSocket);
				WSACleanup();
				return 1;
			}
			std::cout << "Отправлено " << iSendResult << " байт";
		}
		else if (iResult == 0)
			std::cout << "Соединение закрыто..." << std::endl;
		else
		{
			std::cout << "Ошибка recv " << WSAGetLastError();
			closesocket(ClientSocket);
			WSACleanup();
			return 1;
		}
	} while (iResult > 0);
}

Создание и использование DLL

2019-12-10T05:48:43.362Z

При разработке программ часто оказывается, что разным программным приложениям требуются одни и те же объекты, их свойства методы, процедуры и функции. Например, почти все программы выводят информацию на экран и пользуются стандартными объектами интерфейса Windows (окна, кнопки, меню…) Было бы в высшей степени неразумно запихивать код отрисовки каждого такого элемента во все программы.

Таким образом, возникает задача разделения большой программы на отдельные независимые модули, каждый из которых содержит определенный набор процедур и функций. Процедуры и функции такого модуля может вызывать любая другая программа. Подобные модули получили название динамически подключаемых библиотек (DLL – dynamically linked library). Слово "динамический" указывает на то, что подключение библиотеки происходит не на этапе компиляции, а уже после запуска программы.

DLL-библиотеки нашли самое широкое применение в большинстве программ. Скажем, сама операционная система Windows включает в свой состав несколько сотен DLL, и заключенная в них функциональность может использоваться нашими программами во избежание очередного изобретения велосипеда.

Создание повторно используемого кода

С помощью Visual C++ можно создавать библиотеки трех следующих типов:
• библиотеки динамической компоновки (DLL);
• статические библиотеки;
• управляемые сборки.

Как правило, если необходимо создать библиотеку, которая могла бы использоваться машинным кодом C++, то следует предпочесть библиотеку динамической компоновки или статическую библиотеку. Если необходимо создать библиотеку, которая могла бы использоваться кодом на языках C++/CLI или на любом ином языке .NET, например C# или Visual Basic, то следует предпочесть управляемую сборку.

Создание и использование библиотеки DLL (C++)

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

В этом пошаговом руководстве рассматриваются следующие действия:
• создание проекта библиотеки динамической компоновки (DLL);
• добавление класса в библиотеку динамической компоновки;
• создание приложения, ссылающегося на библиотеку динамической компоновки;
• использование функциональных возможностей библиотеки классов в консольном приложении;
• запуск приложения.

Создание проекта библиотеки динамической компоновки (DLL)
1. В меню Файл выберите пункт Создать и затем пункт Проект....
2. В узле Visual C++ области Типы проектов выберите Win32.
3. В области Шаблоны выберите Консольное приложение Win32.
4. Выберите имя проекта, например MathFuncsDll, и введите его в поле Имя. Выберите имя решения, например DynamicLibrary, и введите его в поле Имя решения.
5. Для запуска мастера приложений Win32 нажмите кнопку ОК. На странице Общие сведения диалогового окна Мастер приложений Win32 нажмите кнопку Далее.
6. На странице Параметры приложения диалогового окна Мастер приложений Win32, в поле Тип приложения, выберите пункт DLL, если он доступен, либо пункт Консольное приложение в противном случае. В некоторых версиях Visual Studio создание проектов DLL с помощью мастеров не поддерживается. Необходимые изменения можно внести позднее для компиляции проекта в библиотеку DLL.
7. На странице Параметры приложения диалогового окна Мастер приложений Win32 в поле Дополнительные параметры выберите пункт Пустой проект.
8. Чтобы создать проект, нажмите кнопку Готово.

Добавление класса в библиотеку динамической компоновки
1. Чтобы создать файл заголовка для нового класса, в меню Проект выберите команду Добавить новый элемент.... Откроется диалоговое окно Добавление нового элемента. В узле Visual C++ области Категории выберите пункт Код. В области Шаблоны выберите пункт Заголовочный файл (.h). Выберите имя заголовочного файла, например MathFuncsDll.h, и нажмите кнопку Добавить. Отобразится пустой файл.
2. Добавьте простой класс с именем MyMathFuncs, осуществляющий обычные арифметические операции, такие как сложение, вычитание, умножение и деление. Код должен выглядеть примерно следующим образом:

// MathFuncsDll.h
namespace MathFuncs
{
 class MyMathFuncs
 {
 public:
 // Returns a + b
 static __declspec(dllexport) double Add(double a, double b);
 // Returns a - b
 static __declspec(dllexport) double Subtract(double a, double b);
 // Returns a * b
 static __declspec(dllexport) double Multiply(double a, double b);
 // Returns a / b
 // Throws DivideByZeroException if b is 0
 static __declspec(dllexport) double Divide(double a, double b);
 };
}

3. Обратите внимание на модификатор __declspec(dllexport) в объявлениях методов в этом коде. Этот модификатор разрешает экспорт метода библиотекой DLL для использования его другими приложениями. Дополнительные сведения см. в разделе dllexport, dllimport.
4. Чтобы создать исходный файл для нового класса, в меню Проект выберите команду Добавить новый элемент.... Откроется диалоговое окно Добавление нового элемента. В узле Visual C++ области Категории выберите пункт Код. В области Шаблоны выберите пункт Файл C++ (.cpp). Выберите имя исходного файла, например MathFuncsDll.cpp, и нажмите кнопку Добавить. Отобразится пустой файл.
5. Реализуйте функциональность класса MyMathFuncs в исходном файле. Код должен выглядеть примерно следующим образом:

// MathFuncsDll.cpp
// compile with: /EHsc /LD
#include "MathFuncsDll.h"
#include <stdexcept>
using namespace std;
namespace MathFuncs
{
 double MyMathFuncs::Add(double a, double b)
 {
 return a + b;
 }
 double MyMathFuncs::Subtract(double a, double b)
 {
 return a - b;
 }
 double MyMathFuncs::Multiply(double a, double b)
 {
 return a * b;
 }
 double MyMathFuncs::Divide(double a, double b)
 {
 if (b == 0)
 {
 throw new invalid_argument("b cannot be zero!");
 }
 return a / b;
 }
}

6. Чтобы построить библиотеку DLL проекта, в меню Проект выберите СвойстваMathFuncsDll. В левой области в поле Свойства конфигурации выберите Общие. В правой области в поле Тип конфигурации выберите Динамическая библиотека (.dll). Нажмите кнопку ОК для сохранения изменений.
7. Скомпилируйте библиотеку динамической компоновки, выбрав команду Построить решение в меню Построение. В результате будет создана библиотека DLL, которая может использоваться другими программами.

Создание приложения, ссылающегося на библиотеку динамической компоновки
1. Чтобы создать приложение, которое будет ссылаться и использовать созданную ранее библиотеку динамической компоновки, в меню Файл выберите пункт Создать и затем пункт Проект....
2. В узле Visual C++ области Типы проектов выберите Win32.
3. В области Шаблоны выберите Консольное приложение Win32.
4. Выберите имя проекта, например MyExecRefsDll, и введите его в поле Имя. В раскрывающемся списке рядом с полем Решение выберите пункт Добавить в решение. После этого новый проект будет добавлен в то же решение, что и библиотека динамической компоновки.
5. Для запуска мастера приложений Win32 нажмите кнопку ОК. На странице Общие сведения диалогового окна Мастер приложений Win32 нажмите кнопку Далее.
6. На странице Параметры приложения диалогового окна Мастер приложений Win32 в поле Тип приложения выберите пункт Консольное приложение.
7. На странице Параметры приложения диалогового окна Мастер приложений Win32 в поле Дополнительные параметры снимите флажок Предкомпилированный заголовок.
8. Чтобы создать проект, нажмите кнопку Готово.

Использование функциональных возможностей библиотеки классов в консольном приложении
1. По завершении создания консольного приложения будет создана пустая программа. Имя исходного файла будет совпадать с именем, выбранным ранее для проекта. В этом примере он имеет имя MyExecRefsDll.cpp.
2. Для использования математических процедур из библиотеки динамической компоновки необходимо сослаться на эту библиотеку. Для этого в меню Проект(Project) выберите пункт Ссылки....(Reference…) В диалоговом окне Окна свойств(Properties) разверните узел Общие свойства (Common Properties), выберите пункт Ссылки, а затем нажмите кнопку Добавить новую ссылку.... (Add New Rewference…).
3. Появится диалоговое окно Добавить ссылку. В этом диалоговом окне отображается список всех библиотек, на которые можно ссылаться. На вкладке Проект перечисляются все проекты текущего решения и включенные в них библиотеки. На вкладке Проекты выберите MathFuncsDll. Затем нажмите кнопку ОК.
4. Для создания ссылки на заголовочные файлы библиотеки динамической компоновки необходимо изменить путь к каталогам включения. Для этого в диалоговом окне Окна свойств (Properties) последовательно разверните узлы Свойства конфигурации (Configuration Properties), C/C++, а затем выберите Общие (General). Рядом с полем Дополнительные каталоги включения (Additional Include Directories) введите путь к месту размещения заголовочного файла MathFuncsDll.h.
5. Исполняемый файл не загружает библиотеки динамической компоновки во время выполнения. Необходимо указать системе место для поиска библиотеки MathFuncsDll.dll. Это можно сделать с помощью переменной среды PATH. Для этого в диалоговом окне Окна свойств (Properties) разверните узел Свойства конфигурации (Configuration Properties), а затем выберите Отладка(Debugging). В поле Среда(Environment) введите следующую строку: PATH=<путь к файлу MathFuncsDll.dll>, где вместо <путь к файлу MathFuncsDll.dll> необходимо подставить фактическое местоположение библиотеки MathFuncsDll.dll. Нажмите кнопку ОК для сохранения всех изменений.
6. Теперь класс MyMathFuncs можно использовать в приложении. Замените код в файле MyExecRefsDll.cpp следующим кодом:

// MyExecRefsDll.cpp
// compile with: /EHsc /link MathFuncsDll.lib
#include <iostream>
#include "MathFuncsDll.h"
using namespace std;
int main()
{
 double a = 7.4;
 int b = 99;
 cout << "a + b = " <<
 MathFuncs::MyMathFuncs::Add(a, b) << endl;
 cout << "a - b = " <<
 MathFuncs::MyMathFuncs::Subtract(a, b) << endl;
 cout << "a * b = " <<
 MathFuncs::MyMathFuncs::Multiply(a, b) << endl;
 cout << "a / b = " <<
 MathFuncs::MyMathFuncs::Divide(a, b) << endl;
 return 0;
}

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

Запуск приложения

1. Убедитесь, что проект MyExecRefsDll выбран в качестве проекта по умолчанию. В Обозревателе решений выберите проект MyExecRefsDll и затем в меню Проект выберите команду Назначить запускаемым проектом.
2. Чтобы запустить проект, в меню Отладка выберите команду Запуск без отладки. Результат выполнения должен выглядеть примерно следующим образом:

a + b = 106.4
a - b = -91.6
a * b = 732.6
a / b = 0.0747475

Создание и использование статической библиотеки (C++)

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

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

Создание проекта статической библиотеки

1. В меню Файл выберите пункт Создать и затем пункт Проект....
2. В узле Visual C++ области Типы проектов выберите Win32.
3. В области Шаблоны выберите Консольное приложение Win32.
4. Выберите имя проекта, например MathFuncsLib, и введите его в поле Имя. Выберите имя решения, например StaticLibrary, и введите его в поле Имя решения.
5. Для запуска мастера приложений Win32 нажмите кнопку ОК. На странице Общие сведения диалогового окна Мастер приложений Win32 нажмите кнопку Далее.
6. На странице Параметры приложения диалогового окна Мастер приложений Win32 в поле Тип приложения выберите пункт Статическая библиотека.
7. На странице Параметры приложения диалогового окна Мастер приложений Win32 в поле Дополнительные параметры снимите флажок Предкомпилированный заголовок.
8. Чтобы создать проект, нажмите кнопку Готово.

Добавление класса в статическую библиотеку

1. Чтобы создать файл заголовка для нового класса, в меню Проект выберите команду Добавить новый элемент.... Откроется диалоговое окно Добавление нового элемента. В узле Visual C++ области Категории выберите пункт Код. В области Шаблоны выберите пункт Заголовочный файл (.h). Выберите имя заголовочного файла, например MathFuncsLib.h, и нажмите Добавить. Отобразится пустой файл.
2. Добавьте простой класс с именем MyMathFuncs, осуществляющий обычные арифметические операции, такие как сложение, вычитание, умножение и деление. Код должен выглядеть примерно следующим образом:

// MathFuncsLib.h
namespace MathFuncs
{
 class MyMathFuncs
 {
 public:
 // Returns a + b
 static double Add(double a, double b);
 // Returns a - b
 static double Subtract(double a, double b);
 // Returns a * b
 static double Multiply(double a, double b);
 // Returns a / b
 // Throws DivideByZeroException if b is 0
 static double Divide(double a, double b);
 };
}

3. Чтобы создать исходный файл для нового класса, в меню Проект выберите команду Добавить новый элемент.... Откроется диалоговое окно Добавление нового элемента. В узле Visual C++ области Категории выберите пункт Код. В области Шаблоны выберите пункт Файл C++ (.cpp). Выберите имя исходного файла, например MathFuncsLib.cpp, и нажмите Добавить. Отобразится пустой файл.
4. Реализуйте функциональность класса MyMathFuncs в исходном файле. Код должен выглядеть примерно следующим образом:

// MathFuncsLib.cpp
// compile with: /c /EHsc
// post-build command: lib MathFuncsLib.obj
#include "MathFuncsLib.h"
#include <stdexcept>
using namespace std;
namespace MathFuncs
{
 double MyMathFuncs::Add(double a, double b)
 {
 return a + b;
 }
 double MyMathFuncs::Subtract(double a, double b)
 {
 return a - b;
 }
 double MyMathFuncs::Multiply(double a, double b)
 {
 return a * b;
 }
 double MyMathFuncs::Divide(double a, double b)
 {
 if (b == 0)
 {
 throw new invalid_argument("b cannot be zero!");
 }
 return a / b;
 }
}

5. Чтобы построить статическую библиотеку проекта, в меню Проект выберите СвойстваMathFuncsLib. В левой области в поле Свойства конфигурации выберите Общие. В правой области в поле Тип конфигурации выберите Статическая библиотека (.lib). Нажмите кнопку ОК для сохранения изменений.
6. Скомпилируйте статическую библиотеку, выбрав команду Построить решение в меню Построение. В результате будет создана статическая библиотека, которая может использоваться другими программами.

Создание приложения, ссылающегося на статическую библиотеку

1. Чтобы создать приложение, которое будет ссылаться и использовать созданную ранее статическую библиотеку, в меню Файл выберите пункт Создать и затем пункт Проект....
2. В узле Visual C++ области Типы проектов выберите Win32.
3. В области Шаблоны выберите Консольное приложение Win32.
4. Выберите имя проекта, например MyExecRefsLib, и введите его в поле Имя. В раскрывающемся списке рядом с полем Решение выберите пункт Добавить в решение. После этого новый проект будет добавлен в то же решение, что и статическая библиотека.
5. Для запуска мастера приложений Win32 нажмите кнопку ОК. На странице Общие сведения диалогового окна Мастер приложений Win32 нажмите кнопку Далее.
6. На странице Параметры приложения диалогового окна Мастер приложений Win32 в поле Тип приложения выберите пункт Консольное приложение.
7. На странице Параметры приложения диалогового окна Мастер приложений Win32 в поле Дополнительные параметры снимите флажок Предкомпилированный заголовок.
8. Чтобы создать проект, нажмите кнопку Готово.

Использование функциональных возможностей статической библиотеки в консольном приложении

1. По завершении создания консольного приложения мастер создаст пустую программу. Имя исходного файла будет совпадать с именем, выбранным ранее для проекта. В этом примере он имеет имя MyExecRefsLib.cpp.
2. Для использования математических процедур из статической библиотеки необходимо сослаться на эту библиотеку. Для этого в меню Проект выберите пункт Ссылки.... В диалоговом окне Окна свойств разверните узел Общие свойства и выберите пункт Ссылки. Затем нажмите кнопку Добавить новую ссылку….
3. Появится диалоговое окно Добавить ссылку. В этом диалоговом окне отображается список всех библиотек, на которые можно ссылаться. На вкладке Проект перечисляются все проекты текущего решения и включенные в них библиотеки. На вкладке Проекты выберите MathFuncsLib. Затем нажмите кнопку ОК.
4. Для создания ссылки на заголовочные файлы статической библиотеки необходимо изменить путь к каталогам включения. Для этого в диалоговом окне Окна свойств последовательно разверните узлы Свойства конфигурации, C/C++, а затем выберите Общие. Рядом с полем Дополнительные каталоги включения введите путь к месту размещения заголовочного файла MathFuncsLib.h.
5. Теперь класс MyMathFuncs можно использовать в приложении. Замените код в файле MyExecRefsLib.cpp следующим кодом:

// MyExecRefsLib.cpp
// compile with: /EHsc /link MathFuncsLib.lib
#include <iostream>
#include "MathFuncsLib.h"
using namespace std;
int main()
{
 double a = 7.4;
 int b = 99;
 cout << "a + b = " <<
 MathFuncs::MyMathFuncs::Add(a, b) << endl;
 cout << "a - b = " <<
 MathFuncs::MyMathFuncs::Subtract(a, b) << endl;
 cout << "a * b = " <<
 MathFuncs::MyMathFuncs::Multiply(a, b) << endl;
 cout << "a / b = " <<
 MathFuncs::MyMathFuncs::Divide(a, b) << endl;
 return 0;
}

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

Запуск приложения

1. Убедитесь, что проект MyExecRefsLib выбран в качестве проекта по умолчанию. В Обозревателе решений выберите проект MyExecRefsLib и затем в меню Проект выберите команду Назначить запускаемым проектом.
2. Чтобы запустить проект, в меню Отладка выберите команду Запуск без отладки. Результат выполнения должен выглядеть примерно следующим образом:

a + b = 106.4
a - b = -91.6
a * b = 732.6
a / b = 0.0747475

Создание и использование управляемой сборки (C++)

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

Создание нового проекта библиотеки классов

1. В меню Файл выберите пункт Создать и затем пункт Проект....
2. В узле Visual C++ области Типы проектов выберите CLR. При этом будет создан проект, предназначенный для среды CLR.
3. В области Шаблоны выберите пункт Библиотека классов.
4. Выберите имя проекта, например MathFuncsAssembly, и введите его в поле Имя. Выберите имя решения, например ManagedAssemblies, и введите его в поле Имя решения.
5. Нажмите ОК, чтобы создать проект.
6. По умолчанию создаваемые проекты настраиваются на использование предкомпилированных заголовков. Чтобы отключить предкомпилированные заголовки, в меню Проект выберите Свойства. Последовательно разверните узлы Свойства конфигурации, C/C++, а затем выберите пункт Предварительно скомпилированные заголовки. В раскрывающемся списке рядом с полем Создавать или использовать предварительно скомпилированный заголовочный файл выберите пункт Не использовать предкомпилированный заголовок. Нажмите кнопку ОК для сохранения этих изменений.

Добавление класса в библиотеку классов

1. По завершении создания библиотеки классов CLR мастер создаст простейший класс. Имена файла заголовка и файла исходного кода будет совпадать с именем, выбранным ранее для проекта. В этом примере они имеют имена MathFuncsAssembly.h и MathFuncsAssembly.cpp.
2. Замените код в файле MathFuncsAssembly.h простейшим классом MyMathFuncsAssembly, осуществляющим обычные арифметические операции, такие как сложение, вычитание, умножение и деление. Код должен выглядеть примерно следующим образом:

// MathFuncsAssembly.h
using namespace System;
namespace MathFuncs
{
 public ref class MyMathFuncs
 {
 public:
 // Returns a + b
 static double Add(double a, double b);
 // Returns a - b
 static double Subtract(double a, double b);
 // Returns a * b
 static double Multiply(double a, double b);
 // Returns a / b
 // Throws DivideByZeroException if b is 0
 static double Divide(double a, double b);
 };

3. Реализуйте функциональность класса MyMathFuncs в исходном файле. Код должен выглядеть примерно следующим образом:

// MathFuncsAssembly.cpp
// compile with: /clr /LD
#include "MathFuncsAssembly.h"
namespace MathFuncs
{
 double MyMathFuncs::Add(double a, double b)
 {
 return a + b;
 }
 double MyMathFuncs::Subtract(double a, double b)
 {
 return a - b;
 }
 double MyMathFuncs::Multiply(double a, double b)
 {
 return a * b;
 }
 double MyMathFuncs::Divide(double a, double b)
 {
 if (b == 0)
 {
 throw gcnew DivideByZeroException("b cannot be zero!");
 }
 return a / b;
 }
}

4. Скомпилируйте библиотеку классов, выбрав команду Построить решение в меню Построение. В результате будет создана библиотека динамической компоновки (DLL), которая может использоваться другими программами.

Создание приложения, ссылающегося на библиотеку классов

1. Чтобы создать приложение, которое будет ссылаться и использовать созданную ранее библиотеку классов, в меню Файл выберите пункт Создать и затем пункт Проект....
2. В узле Visual C++ области Типы проектов выберите CLR. При этом будет создан проект, предназначенный для среды CLR.
3. В области Шаблоны выберите Консольное приложение CLR.
4. Выберите имя проекта, например MyExecRefsAssembly, и введите его в поле Имя. В раскрывающемся списке рядом с полем Решение выберите пункт Добавить в решение. После этого новый проект будет добавлен в то же решение, что и библиотека классов.
5. Нажмите ОК, чтобы создать проект.
6. По умолчанию создаваемые проекты настраиваются на использование предкомпилированных заголовков. Чтобы отключить предкомпилированные заголовки, в меню Проект выберите Свойства. Последовательно разверните узлы Свойства конфигурации, C/C++, а затем выберите пункт Предварительно скомпилированные заголовки. В раскрывающемся списке рядом с полем Создавать или использовать предварительно скомпилированный заголовочный файл выберите пункт Не использовать предкомпилированный заголовок. Нажмите кнопку ОК для сохранения этих изменений. Дополнительные сведения о предкомпилированных заголовках см. в разделе Создание файлов предкомпилированных заголовков.

Использование функциональных возможностей библиотеки классов в консольном приложении

1. По завершении создания консольного приложения CLR будет создана программа, выводящая на консоль приветствие "Hello World". Имя исходного файла будет совпадать с именем, выбранным ранее для проекта. В этом примере он имеет имя MyExecRefsAssembly.cpp.
2. Для использования математических процедур из библиотеки классов необходимо сослаться на эту библиотеку. Для этого в меню Проект выберите пункт Ссылки.... В диалоговом окне Окна свойств разверните узел Общие свойства, выберите пункт Ссылки, а затем нажмите кнопку Добавить новую ссылку....
3. Появится диалоговое окно Добавить ссылку. В этом диалоговом окне отображается список всех библиотек, на которые можно ссылаться. На вкладке .NET перечислены библиотеки, включенные в .NET Framework. На вкладке COM перечислены все COM-компоненты, установленные на компьютере. На вкладке Проект перечисляются все проекты текущего решения и включенные в них библиотеки. На вкладке Проекты выберите MathFuncsAssembly, после чего нажмите кнопку ОК.
4. Теперь класс MyMathFuncs можно использовать в приложении. Замените содержимое функции в файле MyExecRefsAssembly.cpp следующим кодом:

// MyExecRefsAssembly.cpp
// compile with: /clr /FUMathFuncsAssembly.dll
using namespace System;
int main(array<System::String ^> ^args)
{
 double a = 7.4;
 int b = 99;
 Console::WriteLine("a + b = {0}",
 MathFuncs::MyMathFuncs::Add(a, b));
 Console::WriteLine("a - b = {0}",
 MathFuncs::MyMathFuncs::Subtract(a, b));
 Console::WriteLine("a * b = {0}",
 MathFuncs::MyMathFuncs::Multiply(a, b));
 Console::WriteLine("a / b = {0}",
 MathFuncs::MyMathFuncs::Divide(a, b));
 return 0;
}

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

Запуск приложения

1. Убедитесь, что проект MyExecRefsAssembly выбран в качестве проекта по умолчанию. В Обозревателе решений выберите проект MyExecRefsAssembly и затем в меню Проект выберите команду Назначить запускаемым проектом.
2. Чтобы запустить проект, в меню Отладка выберите команду Запуск без отладки. Результат должен выглядеть следующим образом:

a + b = 106.4
a - b = -91.6
a * b = 732.6
a / b = 0.0747474747474748

Создание DLL

Ничего особенного здесь нет. Как обычно, вы просто пишите функции, как в обычной программе. Если вы используете MSVC, создайте новый проект и укажите, что вы создаете Win32 Dynamic-Link Library, в опциях указать Пустой проект(Empty project). После компиляции вы получите DLL, библиотеку импорта (.lib) и библиотеку экспорта (.exp). Далее показан примерный код вашей DLL:

Заголовочный файл (DLLTEST.H)

#ifndef _DLLTEST_H_
#define _DLLTEST_H_ 

#include <iostream>
#include <stdio.h>
#include <windows.h> 

using namespace std;
extern "C" __declspec(dllexport) void NumberList();
extern "C" __declspec(dllexport) void LetterList(); 

#endif

Код библиотеки (DLLTEST.CPP)

#include "dlltest.h" 
#define MAXMODULE 255 
char module[MAXMODULE]; 
extern "C" __declspec(dllexport) void NumberList() 
{
	GetModuleFileNameA(NULL, module, MAXMODULE);
 cout << "\n\nThis function was called from \n"
 << module 
 << endl << endl;
 cout << "NumberList(): ";
 for(int i=0; i<10; i++) 
 {
 cout << i << " ";
 }
 cout << endl << endl;
} 
extern "C" __declspec(dllexport) void LetterList() 
{
	GetModuleFileNameA(NULL, module, MAXMODULE);
 cout << "\n\nThis function was called from \n"
 << module 
 << endl << endl;
 cout << "LetterList(): ";
 for(int i=0; i<26; i++) 
 {
 cout << char(97 + i) << " ";
 }
 cout << endl << endl;
}

Как видите, ничего особенного в коде нет. Приложение, используемое для примера - консольное, так что здесь просто запрограммированы две функции, выводящие текст. Строка extern "C" __declspec(dllexport) означает, что функция будет видна вне DLL (т.е. ее можно вызывать из нашей программы). После компиляции мы получим библиотеку. Теперь посммотрим, как ее можно использовать. Использование DLL без библиотеки импорта. Динамическое подключение. Чтобы загрузить DLL в программу на этапе выполнения, нужно пройти несколько шагов.
Шаг 1:
Использовать функцию LoadLibrary или LoadLibraryEx, чтобы загрузить DLL.
Шаг 2:
Использовать функцию GetProcAddress, чтобы получить указатель на интересующую нас функцию.
Шаг 3:
По окончании работы не забыть выгрузить DLL с помощью функции FreeLibrary.
В своей программе я пользовался функцией LoadLibrary. Эта функция возвращает дескриптор DLL.
Код:
HINSTANCE hDllInstance = LoadLibrary( "DLLTEST.dll");
Первый параметр - путь к DLL.
Дальше - нам нужно получить указатель на функцию. Тоесть нужно определить тип указателя. Это делается строкой (в нашем случае)
Код:
typedef void (WINAPI *cfunc)( );
Тоесть мы определили cfunc как тип, который указывает на функцию, которая без параметра и возвращает значение void. Далее - дело за малым.
Код:
cfunc NumberList;
cfunc LetterList;
NumberList=(cfunc)GetProcAddress((HMODULE)hLib, "NumberList");
LetterList=(cfunc)GetProcAddress((HMODULE)hLib, "LetterList");

Мы объявили указатель, и с помощью функции GetProcAddress получаем адрес интересующей нас функции. Первый параметр - дескриптор DLL. Второй - имя функции. Теперь можно вызывать эти функции
Код:
NumberList();
LetterList();

Исходный файл приложения, использующего библиотеку DLL - консольное приложение Win32 (DLLRUN02.EXE)

#include <windows.h>
#include <iostream>
#include <stdio.h>
#include <conio.h> 
using namespace std;

#define MAXMODULE 255 

typedef void (WINAPI *cfunc)(); 
cfunc NumberList;
cfunc LetterList; 

void main() 
{
	HINSTANCE hLib=LoadLibrary(TEXT("DLLTEST.DLL"));
 if(hLib==NULL) 
 {
 cout << "Unable to load library!" << endl;
 getch();
 return;
 } 
	char mod[MAXMODULE];

 GetModuleFileNameA((HMODULE)hLib, mod, MAXMODULE);
 cout << "Library loaded: " << mod << endl;
 NumberList=(cfunc)GetProcAddress((HMODULE)hLib, "NumberList");
 LetterList=(cfunc)GetProcAddress((HMODULE)hLib, "LetterList");
 if((NumberList==NULL) || (LetterList==NULL)) 
 {
 cout << "Unable to load function(s)." << endl;
 FreeLibrary((HMODULE)hLib);
 return;
 }
 NumberList();
 LetterList();
 FreeLibrary((HMODULE)hLib);
 getch();
}

Этот код загружает DLL (если она находится в путях или в текущем каталоге), а затем определяет адреса функций, которые мы будем вызывать. Конечно, в этом случае пришлось написать намного больше кода, и, соответственно, придется отловить немало ошибок. Однако такой подход универсальней.

Результаты работы DLLRUN02.EXE

Library loaded: C:\DLLTEST\DLLTEST.DLL 

This function was called from C:\DLLTEST\DLLRUN02.EXE
NumberList(): 0 1 2 3 4 5 6 7 8 9 
This function was called from C:\DLLTEST\DLLRUN02.EXE
LetterList(): a b c d e f g h i j k l m n o p q r s t u v w x y z

Многопоточность С++

2019-12-05T06:47:23.404Z

Процессом (process) называется экземпляр программы, загруженной в память. Этот экземпляр может создавать нити (thread), которые представляют собой последовательность инструкций на выполнение. Важно понимать, что выполняются не процессы, а именно нити.

Причем любой процесс имеет хотя бы одну нить. Эта нить называется главной (основной) нитью приложения.

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

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

Инициализация потока

В новом стандарте C++11 многопоточность осуществлен в классе thread, который определен в файле thread.h. Для того чтобы создать новый поток нужно создать объект класса thread и инициализировать передав в конструктор имя функции которая должна выполнятся в потоке.

#include<iostream> 
#include<thread> //Файл в котором определен класс thread 
using namespace std; 
void anyFunc() { 
	cout<<"thread function"; 
} 
int main() { 
	thread func_thread(anyFunc); 
	return 0; 
}

В этой программе создается новый объект класса thread и в объявлении конструктору передается имя функции anyFunc, который печатает на экране текст "thread function". Но если скомпилировать данное приложение и запустить, то как бы странно не было оно закончится аварийна с сообщением об ошибке. Все дело в том что главная функция программы main создает объект func_thread, с параметром конструктора anyFunc и продолжает свое выполнение не дожидаясь чтобы процесс закончился, что и вызывает ошибку времени выполнения. Чтобы ошибки не было надо чтобы до того как закончится функция main все потоки были закончены. Это осуществляется путем синхронизации потоков вызывая метод join. Метод join возвращает выполнение программе когда поток заканчивается, после чего объект класса thread можно безопасно уничтожить.

using namespace std; 
void anyFunc() { 
	cout << "thread function"; 
} 
int main() { 
	thread func_thread(anyFunc); 
	func_thread.join(); 
	// Выполнение возвращается функции main когда поток заканчивается 
	return 0; 
}

Метод join нужно указывать там, где мы хотим дождаться выполнения нашего потока.

Позвольте добавить что перед вызовом функции join надо проверить является ли объект joinable то есть представляет он реальный поток или нет, к примеру объект может быть объявлен но не инициализирован или уже закончен вызовом функции join. Проверка делается функцией joinable, который возвращает true в случае если объект представляет исполняемый поток и false в противном случаи. Надо отметить что может быть ситуация когда нам ненужно ждать чтобы поток закончился, для этого у класса thread есть другой метод по имени detach. Обе метода ничего не принимают и не возвращают и после их вызова объект становится not joinable и можно безопасно уничтожить.

#include<iostream> 
#include<thread> //Файл в котором определен класс thread 
using namespace std; 

void anyFunc() 
{ 
	cout << "thread function"; 
}
 
int main() 
{ 
	thread func_thread(anyFunc); 
	if (func_thread.joinable()) 
		func_thread.join(); 
	// Выполнение возвращается функции main когда поток заканчивается 
	// func_thread.detach(); В этом случае поток заканчивается принудительно 
	return 0; 
}

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

#include<iostream> 
#include<thread> //Файл в котором определен класс thread 
using namespace std; 

void printStr(char * str) 
{ 
	cout << str << '\n'; 
}
 
void printArray(int a[],const int len) 
{ 
	for (int i = 0; i < len; i++) { 
		cout << a[i] << ' '; 
	} 
} 

int main() 
{ 
	char* str = "thread function with parametrs"; 
	const int len = 8; 
	int arr[len] = {12, 45, -34, 57, 678, 89, 0, 1}; 
	// Передаем параметр функции во время инициализации 
	thread func_thread(printStr, str); 
	// Параметров может быть много 
	thread func_thread2(printArray, arr, len); 
	if (func_thread.joinable()) func_thread.join(); 
	if (func_thread2.joinable()) func_thread2.join(); 
	return 0; 
}

Параметры можно передавать не только по значению но и по ссылке. Для чего воспользуемся функцией ref из пространства имен std. В ниже приведенной программе вызываемому потоку передается массив и его длина, а в потоке в него добавляются 5 новых значений.

#include<iostream> 
#include<cstdlib> 
#include<thread> 
using namespace std; 

void addElements(int a[], int &len) 
{ 
	for (int i = len; i < len + 5; i++) { 
		a[i] = rand(); 
	} 
	len += 5; 
} 

int main() 
{ 
	const int LENGTH = 20; 
	int arr[LENGTH] = {1, 2, 3, 4, 5}, current_length = 5; 
	cout << "Output the array before thread\n"; 
	for (int i = 0; i < current_length; i++) { 
		cout << arr[i] << ' '; 
	} 
	thread arr_thread(addElements, arr, ref(current_length)); 
	if (arr_thread.joinable()) arr_thread.join(); 
	cout << "\nOutput th array after thread\n"; 
	for (int i = 0; i < current_length; i++) { 
		cout << arr[i] << ' '; 
	} 
	return 0; 
}

Потоки могут быть инициализированны не только функцией но и объект функцией, то есть в классе объекта определен метод operator(), и обычным открытым методом класса. В первом случае нужно передать объект этого класса в конструктор thread, а во втором случае ссылку на функцию и адрес объекта, конечно не надо забыть про список параметров если они есть.

#include<iostream> 
#include<thread> 
using namespace std;
 
class arrayModifier 
{ 
public: 
	void operator()(int a[], int len) { 
		for (int i = 0; i < len; i++) { 
			a[i] *= 2; 
		} 
	} 
	void invers(int a[], int len) { 
		for (int i = 0; i < len; i++) { 
			a[i] *= -1; 
		} 
	} 
}; 

int main() 
{ 
	const int length = 5; 
	int arr[length] = {1, 2, 3, 4, 5}; 
	arrayModifier obj; 
	cout << "Output the array before threads\n"; 
	for (int i = 0; i < length; i++) 
    { 
		cout << arr[i] << ' '; 
	} 
	// Инициализируется объект функцией 
	thread arr_thread(obj, arr, length); 
	// Инициализируется обычным открытым методом 
	thread arr_thread2(&arrayModifier::invers, &obj, arr, length); 
	if (arr_thread.joinable()) arr_thread.join(); 
	if (arr_thread2.joinable()) arr_thread2.join(); 
	cout << "\nOutput th array after threads\n"; 
	for (int i = 0; i < length; i++) 
    { 
		cout << arr[i] << ' '; 
	} 
	return 0; 
}

В вышеприведенном примере у класса arrayModifier есть два метода первый это operator() который элементы массива умножает на 2, а второй умножает на -1. Во втором объекте мы передаем адрес объекта связи с тем что метод класса в качестве скриптового параметра принимает адрес объекта для которого был вызван этот метод.

ID потока

У каждого потока есть свой уникальный номер который отличается от других потоков этой программы. Для этого в классе thread есть закрытый член id и открытый метод get_id вызов которого возвращает значение этого члена.

#include<iostream> 
#include<cstdlib> 
#include<thread> 
using namespace std; 

class printNumber 
{ 
public: 
	void operator()(int number,int arr[],int idx) 
    { 
		int sum = 0; 
		for(int i = 0; i < number; i++) 
        { 
			if(1%15 == 0) continue; 
			if(i%3 == 0) sum += 3*i; 
			if(i%5 == 0) sum += 5*i; 
		} 
		arr[idx] = sum; 
	} 
}; 

int main() 
{ 
	const int length = 10; 
	thread::id id; 
	thread thread_array[length]; 
	int res_arr[length] = {0}; 
	for (int i = 0; i < length; i++) 
    { 
		thread_array[i] = thread(printNumber(), rand(),res_arr,i); 
	} 
	for (int i = 0; i < length; i++) 
    { 
		if (thread_array[i].joinable()) 
        { 
			id = thread_array[i].get_id(); 
			thread_array[i].join(); 
			cout << "Thread with id " << id << " finished. With result "<<res_arr[i]<<"\n"; 
		} 
	} 
	return 0; 
}

Пространство имен this_thread

В заголовочном файле thread.h определено пространство имен this_thread который содержит в себе функции для работы с конкретным потоком. Три из этих функций для того чтобы на некоторое время остановить выполнение потока: sleep_until - передается переменная класса chrono:time_point и блокируется выполнение потока пока системные часы не дойдут до этого времени; sleep_for - передается переменная класса chrono::duration и выполнение потока блокируется пока не прошло столько времени сколько было преданно; yield - останавливает выполнение потока на некоторое время предоставляя возможность выполнится другим потокам. А четвертая функция это get_id и как метод класса thread возвращает id потока.

#include<iostream> 
#include<sstream> 
#include<chrono> 
#include<thread> 
using namespace std; 

class printNumber 
{ 
public: 
	void operator()() 
    { 
		ostringstream out; 
		thread::id id = this_thread::get_id(); 
		out << "Thread with id " << id << " started\n"; 
		cout << out.str(); 
		// Останавливает выполнение на одну секунду 
		this_thread::sleep_for(chrono::seconds(1)); 
		out.str(""); 
		out << "Thread with id " << id << " finished\n"; 
		cout << out.str(); 
	} 
}; 

int main() 
{ 
	const int length = 10; 
	thread thread_array[length]; 
	for (int i = 0; i < length; i++) 
    { 
		thread_array[i] = thread(printNumber()); 
	} 
	for (int i = 0; i < length; i++) 
    { 
		if (thread_array[i].joinable()) 
        { 
			thread_array[i].join(); 
		} 
	} 
	return 0; 
}

Одновременный доступ к ресурсам

В вышеприведенном примере для печати на экран использовался sstream, предварительно превращая в строку то что хочу печатать а потом передаю в поток вывода. А что если сразу передать в поток вывода, сперва первую строку, потом переменную типа thread::id и наконец вторую строку. Но в этом случае потоки не по очереди будут передавать в поток вывода и в итоге получается совсем не то что мы хотели. Такая ситуация бывает когда несколько потоков работают с одним и тем же объектом. Для того чтобы предотвратить это воспользуемся классом mutex который определен в файле mutex. Переменная типа mutex можно блокировать и разблокировать. Когда вызывается метод lock класса mutex, метод проверяет объект и если он разблокирован то блокирует его и возвращает выполнение, в противном случае оно ждет пока объект разблокируется и после чего делает то же самое. А метод unlock разблокирует объект класса mutex этим позволяя другим процессам его блокировать.

#include<iostream> 
#include<cstdlib> 
#include<vector> 
#include<mutex> 
#include<thread> 
using namespace std; 
const int elementsCount = 10; 

void push(vector<int> &arr, mutex& m_arr, mutex& m_out) 
{ 
	int num; 
	for (int i = 0; i < elementsCount; i++) 
    { 
		m_arr.lock(); 
		num = rand(); 
		arr.push_back(num); 
		m_arr.unlock(); 
		m_out.lock(); 
		cout << "Push " << num << "\n"; 
		m_out.unlock(); 
	} 
} 
void pop(vector<int> &arr, mutex& m_arr, mutex& m_out) 
{ 
	int i = 0, num; 
	while (i < elementsCount) 
    { 
		m_arr.lock(); 
		if (arr.size() > 0) 
        { 
			num = arr.back(); 
			arr.pop_back(); 
			m_out.lock(); 
			cout << "Pop " << num << "\n"; 
			m_out.unlock(); 
			i++; 
		} 
		m_arr.unlock(); 
	} 
} 

int main() 
{ 
	mutex m_arr, m_out; 
	vector<int> vec; 
	thread push_thread(push, ref(vec), ref(m_arr), ref(m_out)); 
	thread pop_thread(pop, ref(vec), ref(m_arr), ref(m_out)); 
	if (push_thread.joinable()) push_thread.join(); 
	if (pop_thread.joinable()) pop_thread.join(); 
	return 0; 
}

В вышеприведенной программе мы создаем два объекта класса thread первый инициализируем функцией push, который добавляет в вектор 10 элементов блокируя и раз блокируя объекты m_arr и m_out, а второй функцией pop, который удаляет 10 элементов из вектора, конечно опять блокируя и раз блокируя объекты m_arr и m_out.

Механизмы синхронизации

Вводные понятия синхронизации потоков

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

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

Синхронизация потоков – согласование потоками взаимного порядка доступа к общим ресурсам и очередности обработки событий.

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

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

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

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

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

Работа с потоками с помощью функций WinAPI
Несинхронизированные потоки

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

#include <process.h>
#include <stdio.h>
int a[ 5 ];
void Thread( void* pParams )
{ 
    int i, num = 0;
    while ( 1 )
    { 
        for ( i = 0; i < 5; i++ ) a[ i ] = num;
        num++;
    }
}

int main( void )
{ 
	_beginthread( Thread, 0, NULL );
	
	while( 1 )
    printf("%d %d %d %d %d\n", 
          a[ 0 ], a[ 1 ], a[ 2 ],
          a[ 3 ], a[ 4 ] );
	return 0;
}

Как видно из результата работы процесса, основной поток (сама программа) и поток Thread действительно работают параллельно (подчёркиванием обозначено состояние, когда основной поток выводит массив во время его заполнения потоком Thread):

81751652 81751652 81751651 81751651 81751651
81751652 81751652 81751651 81751651 81751651
83348630 83348630 83348630 83348629 83348629
83348630 83348630 83348630 83348629 83348629
83348630 83348630 83348630 83348629 83348629

Запустите программу, затем нажмите "Pause" для остановки вывода на дисплей (т.е. приостанавливаются операции ввода/вывода основного потока, но поток Thread продолжает свое выполнение в фоновом режиме) и любую другую клавишу для возобновления выполнения.

Критические секции

А что делать, если основной поток должен читать данные из массива после его обработки в параллельном процессе? Одно из решений этой проблемы - использование критических секций.

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

#include <windows.h>
#include <process.h>
#include <stdio.h>
CRITICAL_SECTION cs;
int a[5];
void Thread(void* pParams) 
{
	int i, num = 0;
	while (TRUE)
	{
		EnterCriticalSection(&cs);
		for (i = 0; i < 5; i++) a[i] = num;
		LeaveCriticalSection(&cs);
		num++;
	}
}

int main(void) 
{
	InitializeCriticalSection(&cs);
	_beginthread(Thread, 0, NULL);
	while (TRUE)
	{
		EnterCriticalSection(&cs);
		printf("%d %d %d %d %d\n",
			a[0], a[1], a[2],
			a[3], a[4]);
		LeaveCriticalSection(&cs);
	}
	return 0;
}

Мьютексы (взаимоисключения)

Мьютекс (взаимоисключение, mutex) - это объект синхронизации, который устанавливается в особое сигнальное состояние, когда не занят каким-либо потоком. Только один поток владеет этим объектом в любой момент времени, отсюда и название таких объектов - одновременный доступ к общему ресурсу исключается. Например, чтобы исключить запись двух потоков в общий участок памяти в одно и то же время, каждый поток ожидает, когда освободится мьютекс, становится его владельцем и только потом пишет что-либо в этот участок памяти. После всех необходимых действий мьютекс освобождается, предоставляя другим потокам доступ к общему ресурсу.

Два (или более) процесса могут создать мьютекс с одним и тем же именем, вызвав метод CreateMutex . Первый процесс действительно создает мьютекс, а следующие процессы получают хэндл уже существующего объекта. Это дает возможность нескольким процессам получить хэндл одного и того же мьютекса, освобождая программиста от необходимости заботиться о том, кто в действительности создает мьютекс. Если используется такой подход, желательно установить флаг bInitialOwner в FALSE, иначе возникнут определенные трудности при определении действительного создателя мьютекса.

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

Дочерний процесс, созданный при помощи функции CreateProcess может наследовать хэндл мьютекса в случае, если при его (мьютекса) создании функией CreateMutex был указан параметр lpMutexAttributes .
Процесс может получить дубликат существующего мьютекса с помощью функции DuplicateHandle .
Процесс может указать имя существующего мьютекса при вызове функций OpenMutex или CreateMutex .

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

#include <windows.h>
#include <process.h>
#include <stdio.h>
HANDLE hMutex;
int a[ 5 ];
void Thread( void* pParams )
{ 
	int i, num = 0;
	while ( TRUE ) { 
		WaitForSingleObject( hMutex, INFINITE );
		for ( i = 0; i < 5; i++ ) a[ i ] = num;
		ReleaseMutex( hMutex );
		num++;
	}
}
int main( void )
{
	hMutex = CreateMutex( NULL, FALSE, NULL );
	_beginthread( Thread, 0, NULL );
	while( TRUE )
	{
		WaitForSingleObject( hMutex, INFINITE );
		printf( "%d %d %d %d %d\n", 
				a[ 0 ], a[ 1 ], a[ 2 ],
				a[ 3 ], a[ 4 ] );
		ReleaseMutex( hMutex );
	}
	return 0;
}

События

Событие - это объект синхронизации, состояние которого может быть установлено в сигнальное, путем вызова функций SetEvent или PulseEvent . Существует два типа событий:

Событие с ручным сбросом
Это объект, сигнальное состояние которого сохраняется до ручного сброса функцией ResetEvent . Как только состояние объекта установлено в сигнальное, все находящиеся в цикле ожидания этого объекта потоки продолжают свое выполнение (освобождаются).

Событие с автоматическим сбросом
Объект, сигнальное состояние которого сохраняется до тех пор, пока не будет освобожден единственный поток, после чего система автоматически устанавливает несигнальное состояние события. Если нет потоков, ожидающих этого события, объект остается в сигнальном состоянии.

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

Поток может использовать функцию CreateEvent для создания объекта события. Создающий событие поток устанавливает его начальное состояние. В создающем потоке можно указать имя события. Потоки других процессов могут получить доступ к этому событию по имени, указав его в функции OpenEvent .

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

#include <windows.h>
#include <process.h>
#include <stdio.h>
HANDLE hEvent1, hEvent2;
int a[ 5 ];
void Thread( void* pParams )
{
   int i, num = 0;
   while ( TRUE )
   {
      WaitForSingleObject( hEvent2, INFINITE );
      for ( i = 0; i < 5; i++ ) a[ i ] = num;
      SetEvent( hEvent1 );
      num++;
   }
}
int main( void )
{
    hEvent1 = CreateEvent( NULL, FALSE, TRUE, NULL );
    hEvent2 = CreateEvent( NULL, FALSE, FALSE, NULL );
    _beginthread( Thread, 0, NULL );
    while( TRUE )
    { 
        WaitForSingleObject( hEvent1, INFINITE );
        printf( "%d %d %d %d %d\n", 
        a[ 0 ], a[ 1 ], a[ 2 ],
        a[ 3 ], a[ 4 ] );
        SetEvent( hEvent2 );
    }
    return 0;
}

Потокобезапасность

STL не потокобезопасная библиотека, но исправить это очень просто. Предположим, вам необходимо сохранять данные в вашу коллекцию в одном потоке, когда другой поток также сохраняет их туда. Тогда просто используйте критическую секцию или Mutex.

Типовые задачи синхронизации

Процесс - вычисление, применение конечного множества операций к конечному набору данных. Два процесса считаются параллельными, если первая операция одного процесса начинает выполняться до завершения другого. Ресурсы, используемые несколькими процессами, называются разделяемыми. Критический ресурс - это разделяемый ресурс, который одновременно может использоваться не более чем одним процессом. Критический интервал или критическая секция - участок кода, где процесс работает с критическим ресурсом. Взаимосвязанные процессы - это процессы, использующие общий ресурс или обменивающиеся информацией. Синхронизация процессов - ограничения, накладываемые на порядок выполнения процессов. Эти ограничения задаются с помощью правил синхронизации, которые описываются с помощью механизмов синхронизации (примитивов).

К типовым задачам синхронизации можно отнести:
• взаимное исключение;
• обедающие философы;
• поставщики - потребители;
• читатели - писатели.

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

Задача "обедающие философы": на круглом столе находятся k тарелок с едой, между которыми лежит столько же вилок, k>=2. В комнате имеется k философов, чередующих философские размышления с принятием пищи. За каждым философом закреплена своя тарелка; для еды философу нужны две вилки, причем он может использовать только вилки, примыкающие к его тарелке. Требуется так синхронизировать философов, чтобы каждый из них мог получить за ограниченное время доступ к своей тарелке. Предполагается, что длительность еды и размышлений философа конечна, но заранее недетерминирована.

Задача "поставщики-потребители": имеется ограниченный буфер на m мест (m порций информации). Он является критическим ресурсом для процессов двух типов: процессы-поставщики, получая доступ к ресурсу, помещают на свободное место порцию информации; процессы-потребители, получая доступ к ресурсу, считывают из него порцию информации. Требуется исключить одновременный доступ процессов к ресурсу. При полном опустошении буфера задерживаются процессы-потребители, при полном заполнении буфера задерживаются процессы-поставщики.

Задача "читатели-писатели": имеется разделяемый ресурс - область памяти, к которой требуется обеспечить доступ процессам двух типов: процессы-читатели могут получать доступ к ресурсу одновременно, они считывают информацию (неразрушающее считывание); процессы-писатели взаимно исключают друг друга и читателей. Известны два варианта этой задачи:

1. читатели, изъявившие желание получить доступ к ресурсу, должны получить его как можно быстрее;

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

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

Механизм семафоров

Пусть S - семафор - переменная специального типа с целочисленными значениями, над которой определены две операции: Р (закрытие) и V (открытие).

P(S): если S≥1, то процесс продолжает выполняться, а S уменьшается на единицу; если S = 0, то процесс задерживается, а имя его передается в очередь процессов, ожидающих доступа к данному ресурсу (обычно семафоры связывают с некоторыми ресурсами).

V(S): если в очереди к семафору S есть процессы, то один из них выбирается и активизируется (переводится в состояние готовности: помещается в очередь процессов, претендующих на процессорное время); если в очереди нет процессов, то выполняется операция S = S+1 (при условии непревышения результатом максимально допустимого значения семафора; для двоичного семафора S ∈{0,1}).

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

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

S=1;
Процесс_i:
P(S);
Критическая секция
V(S);

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

S1=1 S2=1 P(S1) P(S2) P(S2) P(S1)
V(S2) V(S1) V(S1) V(S2)

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

Семафорное решение задачи о философах

Обозначим через Р1, Р2, Р3, Р4 - процессы-философы; b1, b2, b3, b4 - вилки. Для еды философу необходимо использовать две соседние вилки

Алгоритм работы каждого философа предполагает использование пяти семафоров (Si, i =1,4 ; S). Семафор S предназначен для взаимного исключения процессов при получении доступа к массиву b, отвечающему за вилки. Каждый семафор Si предназначен для подвешивания i-го философа в том случае, если в результате проверки вилок он обнаружит, что нужных ему вилок в наличии нет. Приведем алгоритм работы первого философа, остальные работают аналогично.

P1: P(S[1]); P(S); if (b1>0)&(b2>0) then begin b1:=0; b2:=0; V(S);
{питание} P(S);
b1:=1; b2:=1; V(S);
for i:=1 to 4 do V(S[i]); {философствование} end else 
V(S); goto P1;

Обработка исключительных ситуаций

2019-12-04T05:43:19.931Z

Исключительная ситуация, или исключение — это возникновение непредвиденного или аварийного события, которое может порождаться некорректным использованием аппаратуры. Например, это деление на ноль или обращение по несуществующему адресу памяти. Обычно эти события приводят к завершению программы с системным сообщением об ошибке. C++ дает программисту возможность восстанавливать программу и продолжать ее выполнение.

Try-catch-throw
Давайте же разберем основы обработки исключений в С++. Чтобы комфортно работать с исключениями в С++ вам нужно знать лишь три ключевых слова:
• try (пытаться) - начало блока исключений;
• catch (поймать) - начало блока, "ловящего" исключение;
• throw (бросить) - ключевое слово, "создающее" ("возбуждающее") исключение.
А теперь пример, демонстрирующий, как применить то, что вы узнали:

void func()
{
	try
	{
		throw 1;
	}
	catch (int a)
	{
		cout << "Caught exception number: " << a << endl;
		return;
	}
	cout << "No exception detected!" << endl;
	return;
}

Если выполнить этот фрагмент кода, то мы получим следующий результат:
Caught exception number: 1
Теперь закоментируйте строку throw 1; и функция выдаст такой результат:
No exception detected!
Как видите все очень просто, но если это применить с умом, такой подход покажется вам очень мощным средством обработки ошибок. Catch может "ловить" любой тип данных, так же как и throw может "кинуть" данные любого типа. Т.е. throw AnyClass(); будет правильно работать, так же как и catch
(AnyClass &d) {};.

работать что-нибудь типа этого:
catch(dumbclass) { }
так же, как и
catch(dumbclass&) { }
Так же можно "поймать" и все исключения:
catch(...) { }

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

try {
	throw 1;
	// throw 'a';
}
catch (long b) {
	cout << "пойман тип long: " << b << endl;
}
catch (char b) {
	cout << "пойман тип char: " << b << endl;
}

"Создание" исключений

Когда возбуждается исключительная ситуация, программа просматривает стек функций до тех пор, пока не находит соответствующий catch. Если оператор catch не найден, STL будет обрабатывать исключение в стандартном обработчике, который делает все менее изящно, чем могли бы сделать вы, показывая какие-то непонятные (для конечного пользователя) сообщения и обычно аварийно завершая программу.

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

Перегрузка глобальных операторов new/delete

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

char *a;
try
{
	a = new char[10];
}
catch (...) {
	// a не создан - обработать ошибку распределения памяти, 
	// выйти из программы и т.п.
}
// a успешно создан, продолжаем выполнение

Это, на первый взгляд, кажется длиннее, чем стандартная проверка в С "а равен NULL?", однако если в программе выделяется десяток динамических переменных, то такой метод оправдывает себя.

Операторы throw без параметров

Итак, мы увидели, как новый метод обработки ошибок удобен и прост. Блок try-catch может содержать вложенные блоки try-catch и если не будет определено соответствующего оператора catch на текущем уровне вложения, исключение будет поймано на более высоком уровне. Единственная вещь, о которой вы должны помнить, - это то, что операторы, следующие за throw, никогда не выполнятся.

try
{
	throw;
	// ни один оператор, следующий далее (до закрывающей скобки) 
	// выполнен не будет
}
catch (...)
{
	cout << "Исключение!" << endl;
}

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

Стандарт С++ 11

2019-12-03T06:35:21.810Z

https://habr.com/ru/post/182920/

1 — auto
До С++11, ключевое слово auto использовалось как спецификатор хранения переменной (как, например, register, static, extern). В С++11 auto позволяет не указывать тип переменной явно, говоря компилятору, чтобы он сам определил фактический тип переменной, на основе типа инициализируемого значения.

auto i = 42; // i - int
auto l = 42LL; // l - long long
auto p = new foo(); // p - foo*

Использование auto позволяет сократить код (если, конечно, тип не int, который на одну букву меньше).

// C++03
for (std::vector<std::map<int, std::string>>::const_iterator it = container.begin(); it != container.end(); ++it)
{
 // do smth
}

// C++11
for (auto it = container.begin(); it != container.end(); ++it)
{
 // do smth
}

Стоить отметить, что возвращаемое значение не может быть auto. Однако, вы можете использовать auto вместо типа возвращаемого значения функции. В таком случае, auto не говорит компилятору, что он должен определить тип, он только дает ему команду искать возвращаемый тип в конце функции. В примере ниже, возвращаемый тип функции compose— это возвращаемый тип оператора +, который суммирует значения типа T и E.

template <typename T, typename E>
auto compose(T a, E b) -> decltype(a+b) // decltype - позволяет определить тип на основе входного параметра
{
 return a+b;
}
auto c = compose(2, 3.14); // c - double

2 — nullptr

Раньше, для обнуления указателей использовался макрос NULL, являющийся нулем — целым типом, что, естественно, вызывало проблемы (например, при перегрузке функций). Ключевое слово nullptr имеет свой собственный тип std::nullptr_t, что избавляет нас от бывших проблем. Существуют неявные преобразования nullptr к нулевому указателю любого типа и к bool (как false), но преобразования к целочисленным типам нет.

void foo(int* p) {}

void bar(std::shared_ptr<int> p) {}

int* p1 = NULL;
int* p2 = nullptr;

if (p1 == p2)
{
}

foo(nullptr);
bar(nullptr);
bool f = nullptr;
int i = nullptr; // ошибка: для преобразования в int надо использовать reinterpret_cast

3 — range-based циклы

Range-Based for — это цикл по контейнеру. Он аналогичен циклу for each в Java или C#. Синтаксически он повторяет for each из Java. Назван он Range-Based в первую очередь потому, чтобы избежать путаницы, ибо в STL уже давно есть алгоритм, именуемыйstd::for_each.

std::vector<int> foo;
// заполняем вектор
for (int x : foo)
std::cout << x << std::endl;

Модель ссылок работает также, как и везде:

for (int& x : foo)
 x *= 2;
for (const int& x : foo)
    std::cout << x << std::endl;

Красиво и удобно, правда? Рассмотренный выше auto усиливает данную конструкцию:

std::vector<std::pair<int, std::string>> container;
// ...
for (const auto& i : container)
    std::cout << i.second << std::endl;

Range-Based for, к слову, работает и на обычных статических массивах:

int foo[] = {1, 4, 6, 7, 8};

for (int x : foo)
    std::cout << x << std::endl;

4 — override и final

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

class B 
{
public:
 virtual void f(short) {std::cout << "B::f" << std::endl;}
};

class D : public B
{
public:
 virtual void f(int) override {std::cout << "D::f" << std::endl;}
};

Теперь это вызовет ошибку при компиляции (точно так же, если бы вы использовалиoverride во втором примере):

D::f: method with override specifier 'override' did not override any base class methods

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

class B 
{
public:
 virtual void f(int) {std::cout << "B::f" << std::endl;}
};

class D : public B
{
public:
 virtual void f(int) override final {std::cout << "D::f" << std::endl;}
};

class F : public D
{
public:
 virtual void f(int) override {std::cout << "F::f" << std::endl;}
};

Функция, объявленная как final, не может быть переопределена функцией F::f() — в этом случае, она переопределяет метод базового класса (В) для класса D.

5 — строго-типизированный enum

У «традиционных» перечислений в С++ есть некоторые недостатки: они экспортируют свои значения в окружающую область видимости (что может привести к конфликту имен), они неявно преобразовываются в целый тип и не могут иметь определенный пользователем тип.

Эти проблемы устранены в С++11 с введением новой категории перечислений, названных strongly-typed enums. Они определяются ключевым словом enum class. Они больше не экспортируют свои перечисляемые значения в окружающую область видимости, больше не преобразуются неявно в целый тип и могут иметь определенный пользователем тип (эта опция так же добавлена и для «традиционных» перечислений").

enum class Options {None, One, All};
Options o = Options::All;

6 — интеллектуальные указатели

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

unique_ptr: должен использоваться, когда ресурс памяти не должен был разделяемым (у него нет конструктора копирования), но он может быть передан другому unique_ptr

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

weak_ptr: содержит ссылку на объект, которым управляет shared_ptr, но не осуществляет подсчет ссылок; позволяет избавиться от циклической зависимости

Приведенный ниже пример демонстрирует unique_ptr. Для передачи владения объектом другому unique_ptr, используйте std::move (эта функция будет обсуждаться в последнем пункте). После передачи владения, интеллектуальный указатель, который передал владение, становится нулевым и get() вернет nullptr.

void foo(int* p)
{
	std::cout << *p << std::endl;
}
std::unique_ptr<int> p1(new int(42));
std::unique_ptr<int> p2 = std::move(p1); // transfer ownership

if (p1)
foo(p1.get());

(*p2)++;
if (p2)
foo(p2.get());

Второй пример демонстрирует shared_ptr. Использование похоже, хотя семантика отличается, поскольку теперь владение совместно используемое.

void foo(int* p)
{
}
void bar(std::shared_ptr<int> p)
{
	++(*p);
}
std::shared_ptr<int> p1(new int(42));
std::shared_ptr<int> p2 = p1;

bar(p1);
foo(p2.get());

И, наконец, пример с weak_ptr. Заметьте, что вы должны получить shared_ptr для объекта, вызывая lock(), чтобы получить доступ к объекту.

auto p = std::make_shared<int>(42);
std::weak_ptr<int> wp = p;
{
	auto sp = wp.lock();
	std::cout << *sp << std::endl;
}
p.reset();
if (wp.expired())
    std::cout << "expired" << std::endl;

7 — лямбды

В новом стандарте наконец-то была добавлена поддержка лямбда-выражений. Мы можете использовать лямбды везде, где ожидается функтор или std::function. Лямбда, вообще говоря, представляет собой более короткую запись функтора, что-то вроде анонимного функтора.

std::vector<int> v;
v.push_back(1);
v.push_back(2);
v.push_back(3);

std::for_each(std::begin(v), std::end(v), [](int n) {std::cout << n << std::endl;});

auto is_odd = [](int n) {return n%2==1;};
auto pos = std::find_if(std::begin(v), std::end(v), is_odd);
if(pos != std::end(v))
     std::cout << *pos << std::endl;

Теперь немного более хитрые — рекурсивные лямбды. Представьте лямбду, представляющую функцию Фибоначчи. Если вы попытаетесь записать ее, используя auto, то получите ошибку компиляции:

auto fib = [&fib](int n) {return n < 2 ? 1 : fib(n-1) + fib(n-2);};

error C3533: 'auto &': a parameter cannot have a type that contains 'auto'
error C3531: 'fib': a symbol whose type contains 'auto' must have an initializer
error C3536: 'fib': cannot be used before it is initialized
error C2064: term does not evaluate to a function taking 1 arguments

Здесь имеет место циклическая зависимость. Чтобы избавиться от нее, необходимо явно определить тип функции, используя std::function.

std::function<int(int)> lfib = [&lfib](int n) {return n < 2 ? 1 : lfib(n-1) + lfib(n-2);};

Класс String

2019-11-27T16:36:45.866Z

Конструктор string (string && str) noexcept подобен конструктору
копирования в том смысле, что новый объект string является копией объекта str.

Конструктор string (initializer_list<char> il) обеспечивает возможность
списковой инициализации класса string. To есть он делает возможными объявления наподобие следующих:

string piano_man = { 'L ', 'i1, 's ','z','t'};
string comp_lang {'L', 'i1, 's', 'p'};

Один из аспектов класса, который следует знать — доступные для него варианты ввода.

string stuff;
cin >> stuff; // чтение слова
getline(cin, stuff); // чтение строки с отбрасыванием символа \п

Существует несколько ограничений на длину строки. Первый ограничивающий фактор — максимально допустимая длина строки, задаваемая константой
string: :npos. Обычно она равна максимальному значению типа unsigned int, и на
практике этого хватает для обычного интерактивного ввода. Однако проблемы могут возникнуть при попытке считывания содержимого всего файла в один объект типа string. Второй ограничивающий фактор —размер памяти, доступной программе.

Функция getline (), применяемая к классу string, будет читать данные из
входного потока и сохранять их в объекте string до тех пор, пока не произойдет одно из трех событий.

Будет достигнут конец файла. В этом случае во входном потоке будет установлен флаг eofbit и обе функции fail () и eof () возвратят значение true.
Будет достигнут разделительный символ (\п по умолчанию). Этот символ
удаляется из входного потока, но не сохраняется.
Будет прочитано максимально возможное количество символов (меньшее из
значений константы string: :npos и доступного количества байтов памяти).
В этом случае во входном потоке будет установлен флаг failbit и функция
fail () возвратит значение true.

Существуют две функции-члена класса string для определения размера строки — size ( ) и length ( ).

Метод find_first_of( ) отыскивает первое вхождение в строке любого из
символов, переданных в аргументах метода.

int where = snakel.find_first_of("hark");

Интеллектуальный указатель (smart pointer) — это объект класса, который
действует подобно указателю, но обладает дополнительными возможностями.

Если в программе требуется более одного указателя на объект, необходимо выбрать shared_ptr. Если программа не нуждается в нескольких указателях на один и тот же объект, unique_ptr работает вполне успешно. Это хороший вариант для возвращаемого типа функции, которая возвращает указатель на память, выделенную операцией new. Объекты unique_ptr можно сохранять в контейнере STL, если только не требуется вызывать методы или алгоритмы, такие как sort (), которые копируют или присваивают один объект unique_ptr другому.

Объект unique_ptr можно присваивать объекту shared_ptr при соблюдении тех
же условий, при которых один объект unique_ptr допускается присваивать другому — источником должно быть rvalue.