Установка Boost

1. Скачивание и подготовка библиотеки

Скачайте библиотеку по адресу https://www.boost.org/users/download/ и распакуйте архив, например, в директорию C:/Boost. Затем перейдите в директорию и запустите файл bootstrap.bat, дождитесь окончания его работы. После этого запустите b2.exe и дождитесь окончания его работы. b2.exe осуществляет компиляцию исходного кода библиотек и у меня этот процесс занял более получаса. Точнее сказать не могу, так как оставил его работать и лёг спать, утром всё было готово.

2. Настройка CMake

Для подключения библиотеки Boost к вашему проекту добавьте следующие строки в CMakeLists.txt.

set (BOOST_ROOT "C:/boost_1_78_0/") # Путь к библиотеке Boost

set (CMAKE_CXX_STANDARD 20) 
set (Boost_NO_SYSTEM_PATHS ON)
set (Boost_USE_MULTITHREADED ON)
set (Boost_USE_STATIC_LIBS ON)
set (Boost_USE_STATIC_RUNTIME OFF)
set (BOOST_ALL_DYN_LINK OFF)
 
# Подключаем необходимые модули. Для примера подключим program_options
find_package (Boost REQUIRED COMPONENTS program_options REQUIRED) 
 
# Если библиотека найдена, то
if (Boost_FOUND)
    include_directories (SYSTEM ${Boost_INCLUDE_DIR}) # подключаем заголовочные файлы
    add_executable (Boost_test "main.cpp") # Создаем исполняемый файл для нашего проекта
    target_link_libraries (Boost_test ${Boost_LIBRARIES}) # подключаем библиотеку
endif ()

Обратите внимание на строку 16 – мы создаем исполняемый файл нашего проекта только в том случае, если библиотека найдена. Это условие не обязательно, но если вы работаете, например, в Visual Studio, то в случае отсутствия библиотеки, студия не будет отображать доступную к запуску цель, но и ошибки при компиляции не выдаст тоже. Использовать ли это условие или нет – выбор за вами.

Boost в действии

Давайте теперь для примера добавим в проект файл main.cpp со следующим кодом, взятым из примера работы с компонентом program_options библиотеки Boost:

#include <iostream>
#include <boost/program_options.hpp>

using namespace std;
namespace po = boost::program_options;

int main(int argc, char* argv[])
{
    po::options_description desc("Allowed options");
    int c;
    desc.add_options()
        ("help,h", "produce help message")
        ("compression,c", po::value<int>()->default_value(3), "set compression level")
        ;

    po::variables_map vm;
    po::store(po::parse_command_line(argc, argv, desc), vm);
    po::notify(vm);

    if (vm.count("help")) {
        cout << desc << "\n";
        return 1;
    }

    if (vm.count("compression")) {
        cout << "Compression level was set to "
            << vm["compression"].as<int>() << ".\n";
    }
    else {
        cout << "Compression level was not set.\n";
    }
	return 0;
}

Program_options является обработчиком параметров командной строки и предоставляет удобный интерфейс для работы. В рассмотренном фрагменте создается экземпляр объекта program_options desc и устанавливается заголовок для отображения справки. Справка будет вызываться параметром –help или -h. Далее регистрируются доступные параметры, с указанием через запятую полной и укороченной версии и описания команды. Укороченная версия параметров не является обязательной и может быть опущена. Для параметра compression устанавливается значение по умолчанию = 3. Далее идёт обработка введённых параметров.

П.с. из-за установленного значения по умолчанию код в строке 30 никогда не выполняется.

Скомпилируйте программу и запустите её передавая следующие комбинации:

1. Boost_test.exe
2. Boost_test.exe -c 5
3. Boost_test.exe -h
4. Boost_test.exe –help

Справка о доступных параметров будет выглядеть так:

The post Работа с Boost и CMake под Windows first appeared on Блог Ильи Житенёва.

Содержание статьи

1. Как это работает?
2. Пример использования?
3. Достоинства и недостатки

В прошлой статье упоминалось, что использование метода противоречит принципам SOLID. А именно принципу открытости\закрытости (O – “open\closed principle”). Но принцип на то и принцип, что дает лишь общее абстрактное описание, не опираясь на конкретную задачу, а потому возможные некоторые вариации. Разработчику приходится самому “дозировать” те или иные принципы в своих задачах. Поэтому отбрасывать один из способов создания потока только из-за того, что один из принципов слабо реализуется, как минимум не корректно.

1. Как это работает?

Если вы знакомы с языком Java, то это очень похоже на реализацию интерфейса Runnable. Создайте класс с предком QThread и переопределите метод run(). Этот метод будет запущен в отдельном потоке, а все остальные методы-члены и параметры класса, как и сам экземпляр класса продолжат своё существование в том потоке, где был аллоцирован экземпляр.

class ThreadMethod : public QThread {
    private:
    void run() override {
        // this code is executed in another thread
    }
};

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

Важно помнить, что в Qt объекты существуют в том потоке, где они созданы, а при взаимодействии с некоторыми классами из других потоков может привести к неопределённому поведению (Undefined behavior).

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

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

Реализация класса представлена ниже

class DataModel : public QThread {
public:
    DataModel(QStringView port, qint32 baud, int timeout_ms = 0) 
    : m_port(port.toString()),
    m_baud(baud),
    m_timeout(timeout_ms)
    {}
    // Останавливаем выполнение потока и дожидаемся окончания
    ~DataModel() {
        stop();
        wait();
    }
    // Метод отправки данных в последовательный порт
    void send(const QByteArray& msg) {
        QMutexLocker lk(&m_mtx);
        m_queue.enqueue(msg);
        if(isRunning()) {
            m_sem.release();
        } else {
            start();
        }
    }
    // Метод остановки потока
    void stop() {
        QMutexLocker lk(&m_mtx);
        m_stop = true;
        if(isRunning() && m_sem.available() == 0) 
            m_sem.release();
    }


private:
    // метод, работающий в отдельном потоке
    void run() override {
        QScopedPointer<QSerialPort> port(new QSerialPort());
        port->setPortName(m_port);
        port->setBaudRate(m_baud);
        if(!port->open(QIODevice::ReadWrite) {
            emit errorOccured(QString("Can't open %1, error code %2").arg(m_port).arg(port.error()));
            return;
        }
        emit connected(true);
        do {
            m_mtx.lock();
            auto txBuffer = m_queue.dequeue();
            m_mtx.unlock();

            m_port.write(txBuffer);
            if(m_port.waitForBytesWritten(m_timeout)) {
                if(m_port.waitForReadyRead(m_timeout)) {
                    auto rxBuffer = m_port.readAll();
                    emit readyRead(rxBuffer);
                } else {
                    emit errorOccured("Read timeout");
                }
            } else {
                emit errorOccured("Can't write data");
            }

            if(m_sem.available() > 0) {
                m_sem.acquire();
            } else {
                emit queueIsEmpty();
            }
            
        } while(!m_stop);
        if(m_port.isOpen())
            m_port.close();
        emit connected(false);
    }

    QQueue<QByteArray> m_queue;
    QSemaphore m_sem;
    QMutex m_mtx;
    bool m_stop {false};
    QString m_port;
    qint32 m_baud;
    int m_timeout;
singals:
    void readyRead(const QByteArray&);
    void connected(bool);
    void errorOccured(const QString&);
    void queueIsEmpty();
};

Работа с классом осуществляется следующим образом. Создается экземпляр класса, в конструктор которого передается имя последовательного порта, бод рейт и таймаут в мс. Если понадобиться остановить и уничтожить класс, вызывается метод void stop(). Новые данные передаются в качестве аргумента в метод void send(const QByteArray&) и складываются в очередь. Если это первая попытка передачи данных, то запускается поток на выполнение, в противном случае, инкрементируем семафор.

При запуске потока производится подключение к последовательному порту. Если подключение не удалось, то излучаем сигнал с текстом ошибки и выходим из метода void run(). При завершении метода void run() поток будет завершен.

Далее попадаем в цикл, где берем данные из очереди и записываем их в порт и вызываем waitForBytesWritten() – это блокирующий метод, осуществляющий запись данных в порт в течение заданного таймаута (или оставьте аргумент пустым, чтобы метод ждал бесконечно до записи данных). Затем ожидаем чтения данных из порта и копируем их в rxBuffer. Полученные данные выводим в сигнале readyRead(const QByteArray&).

Затем проверяем есть ли необработанные состояния семафора. Если есть – обрабатываем, если нет, выдаем сигнал queueIsEmpty().

3. Достоинства и недостатки

• Прост в реализации, просто наследуйте класс QThread и переопределите метод void run();
• Позволяет инкапсулировать разделяемые данные, нет необходимости создания отдельного класса для реализации потокобезопасной структуры хранения данных.
• Отсутствует обработчик событий, поэтому использование сигналов для объектов, созданных внутри метода run() не возможно.

Благодарю за внимание! В следующей статье рассмотрим применение асинхронности в Qt и C++ как более высокоуровнего API для многопоточных разработок

The post Многопоточность в Qt через наследование QThread first appeared on Блог Ильи Житенёва.

Первой книгой для обзора стала книга Адитьи Бхаргавы “Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих” издательства “Питер”. 

Каждый кто впервые видел название книги обращал внимание на незнакомое и непонятное слово “грокаем”. Что же означает “грокать”? Ответ на этот вопрос приведен там же, прямо на обложке книги в виде цитаты:

“Грокнуть” означает понять так полно, что наблюдатель становится частью объекта наблюдения…

Р. Хайнлайн – американский писатель-фантаст 

Содержание статьи

1. Содержание 
2. Изложение материала 
3. Примеры и аналогии из жизни 
4. Оформление, печать, общее впечатление
5. Итоговая оценка и заключение

1. Содержание

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

Не обходится повествование без хэш-таблиц и графов. Приводится описание и реализация алгоритмов поиска в ширину и в глубину.  

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

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

2. Изложение материала

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

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

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

3. Примеры и аналогии из жизни

В качестве жизненной аналогии очень понравилась оценка сложности простейших операций с массивом на примере библиотеки. Привожу пример из книги в вольном пересказе: 

Представьте библиотеку, большую библиотеку, и перед вами стоит две задачи: найти книгу в библиотеке и добавить новую книгу. Конечно же, в этой задачи книги хранятся в отсортированном виде. Если известен индекс книги (её адрес: № шкафа, № полки и позицию книги на полке), например подсказал библиотекарь, где лежит эта книга, то можно найти книгу очень быстро – просто прийти и взять её. В этом случае книга найдена за константное время O(1). Если индекса нет, то придётся потратить побольше времени. Можно пойти к полке в центре зала, посмотреть на какую букву там книги и понять в какой половине зала вам искать эту книгу. Затем пойти к среднему шкафу в оставшейся половине зала и повторить операцию. Это алгоритм бинарного поиска и его сложность по времени пропорциональна O(lg(n)), где n – количество книг в библиотеке.  

Переходим к ситуации, когда в библиотеку поступила новая книга и надо поставить её на нужное место. Тут и начинается самое сложное и интересное. Найти место можно бинарным поиском, но чтобы поставить книгу в шкаф, необходимо все последующие книги сдвинуть на одно место вправо! Не только полку, а весь шкаф и все полки во всех последующих шкафах! Худшим случаем будет ситуация, когда книга должна заняться самое первое место, а значит все n-книг в библиотеке необходимо будет передвинуть. Сложность этой операции в худшем случае равна O(n). 

4. Оформление, печать, общее впечатление

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

5. Итоговая оценка и заключение

Итак, подводя итоги, я решил оценивать, эту и последующие в этой рубрике книги, по следующим параметрам: 

• Содержание – 5  
• Изложение материала – 5 
• Примеры, пояснения и аналогии – 4 
• Иллюстрации и примеры кода – 5 
• Качество печати, перевода, бумаги, отсутствие опечаток и ляпов – 5 
• Порекомендовал бы я её кому-то ещё? – 5 

Итоговая оценка книги “Грокаем алгоритмы”: 4,83.

А вы читали Грокаем алгоритмы? Поделитесь мнением в комментариях. 

В следующий раз на обзор попадет книга Скотта Майерса “Эффективное программирование C++. 42 рекомендации по использованию С++11 и С++14” 

Удачи!

The post “Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих” обзор книги first appeared on Блог Ильи Житенёва.

Содержание статьи

1. Создание главного окна
2. Фильтры событий
2.1 Определение класса фильтра событий
2.2 Реализация фильтра событий
2.3 Обработчик события нажатия кнопки
2.4 Обработчик события отпускания кнопки
2.5 Обработчик события перемещения мыши
3. Выводы
4. Исходный код

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

Алгоритм следующий

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

1. Создание главное окна

Создадим файл main.cpp следующего содержания (см. листинг 1)

#include <QApplication>
#include <QtWidgets>
#include "PaintEvent.h"

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    auto view = new QGraphicsView();
    view->resize(800,600);

    auto scene = new QGraphicsScene(view);
    view->setScene(scene);

    auto paintEvent = new PaintEvent(scene);
    scene->installEventFilter(paintEvent);

    view->show();

    return a.exec();
}

Листинг 1. Код файла main.cpp

Рисование в Qt осуществляется в объекте QGraphicsScene, указатель на который передается для отображения в виджет QGraphicsView. Связка QGraphicsScene и QGraphicsView работает в парадигме модель-представление.

В приведенном выше исходном коде создается экземпляр класса QGraphicsView и устанавливается размер 800х600 пикселей. Создается экземпляр QGraphicsScene с указанием предка — экземпляра класса QGraphicsView. Экземпляру класса QGraphicsView устанавливаем сцену для отображения. Создаем фильтр событий — экземпляр пользовательского класса (подробно разберем далее) PaintEvent, передавая в конструктор указатель на сцену. Методом installEventFilter устанавливаем фильтр событий paintEvent для объекта scene. И делаем экземпляр QGraphicsView видимым.

При попытке запустить приложение увидим окно программы как на рисунке 1.

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

Очевидный и одновременно громоздкий способ реализации алгоритма это создать объект, унаследованный от класса QGraphicsScene и в собственном классе переопределить методы:

• virtual void mousePressEvent(QGraphicsSceneMouseEvent *mouseEvent);
• virtual void mouseReleaseEvent(QGraphicsSceneMouseEvent *mouseEvent);
• virtual void mouseMoveEvent(QGraphicsSceneMouseEvent *mouseEvent);

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

2. Фильтры событий

Фильтры событий это объекты унаследованные от QObject и имеющие метод bool eventFilter(QObject* object, QEvent* event); Метод принимает 2 параметра: указатель QObject на объект, событие для которого было перехвачено и указатель на QEvent – объект, описывающий произошедшее событие. Возвращает метод значение булева типа. Это свойство я называю поглощением события. Поглощение события не дает событию выйти за пределы фильтра, оно поглощается. При возвращении значения true событие перехватывается фильтром и не будет передано далее к стандартным обработчикам — фильтр поглощает событие, при возвращении false событие будет передано дальше — фильтр прозрачен.

2.1 Определение класса фильтра событий

Создадим определение класса PaintEvent в файле painEvent.cpp (см. листинг 2). Разместим в закрытой секции указатели на экземпляры следующих классов:

• QGraphicsScene – отвечает за рисование объектов;
• QGraphicsItem – хранит последний отрезок, созданный при перемещении курсора;
• QPointF – хранит позицию курсора мыши в момент нажатия кнопки;
• два экземпляра QPen для задания стиля рисуемых отрезков: один для вспомогательного и один для постоянных отрезков,

и булеву переменную pressed – хранящую состояние длящегося нажатия.

Конструктор принимает указатель на объект сцены класса QGraphicsScene. Сцена будет использоваться для рисования и будет родителем для PaintEvent. Метод bool eventFilter(QObject* object, QEvent* event) будет исполнять роль фильтра событий.

#pragma once

#include <QObject>
#include <QtWidgets>

class PaintEvent : public QObject
{
    Q_OBJECT
    QGraphicsScene* scene {nullptr};
    QPointF startPoint;
    QGraphicsItem* draftLine {nullptr};
    QPen tempPen;
    QPen pen;
    bool pressed = false;
public:
    explicit PaintEvent(QGraphicsScene* inScene);
    bool eventFilter(QObject* object, QEvent* event);
};

Листинг 2. Определение класса PaintEvent в файле paintEvent.h

2.2 Реализация фильтра событий

Приступим к реализации методов класса PaintEvent. Их два: конструктор и eventFilter.

В конструкторе инициализируем параметр scene указателем inScene и настроим экземпляры класса QPen описывающие стили пера для рисования отрезков: pen и tempPen. Перу pen установим цвет Qt::blue методом setColor и толщину 2 пикслея методом setWidth. Аналогично для пера tempPen установим цвет Qt::gray и толщину 1 пиксель. Pen определяет стиль нарисованных отрезков, появляющиеся после отпускания кнопки мыши. TempPen задает стиль для вспомогательных отрезков, рисуемых из позиции курсора в момент нажатия и до текущего положения мыши, пока кнопка мыши ещё нажата. (см. листинг 3)

#include "PaintEvent.h"

#include <QGraphicsSceneEvent>
#include <QPainter>
#include <QDebug>

PaintEvent::PaintEvent(QGraphicsScene* inScene) :
    QObject(inScene),
    scene(inScene)
{
    tempPen.setColor(Qt::gray);
    tempPen.setWidth(1);
    pen.setColor(Qt::blue);
    pen.setWidth(2);
}

Листинг 3. Определение конструктора класса PaintEvent

А теперь самое интересное – реализация метода eventFilter (см. листинг 4). Первым делом удостоверимся, что источник события — это объект сцецны. Получим тип события вызовом метода type() экземпляра класса QEvent и отловим одно из трёх событий:

• «Нажатие кнопки мыши» – QEvent::GraphicsSceneMousePress;
• «Отпускание кнопки мыши» – QEvent::GraphicsSceneMouseRelease;
• «Перемещение указателя мыши» – QEvent::GraphicsSceneMouseMove.

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

Все события мыши произошедшие с объектом класса QGraphicsScene описываются классом QGraphicsSceneMouseEvent, поэтому необходимо привести указатель на объект события QEvent к классу QGraphicsSceneMouseEvent предоставляющему доступ к информации о позиции курсора и нажатым клавишам мыши.

2.3 Обработчик события нажатия кнопки

Прежде чем приступать к обработке события, необходимо убедиться, что нажата именно левая кнопка мыши, а не другая. Для этого сравним результат вызова метода button() экземпляра класса QGraphicsSceneMouseEvent с константой Qt::LeftButton. Если условие выполняется, то сохраним текущее положение курсора (вызов метода sсenePos() экземпляра события) в параметр startPoint. Установим параметр pressed значение true. Pressed используется в обработчике события перемещения мыши как индикатор того, что нажата левая кнопка и процесс построения отрезка ещё не завершен.

2.4 Обработчик события отпускания кнопки

Обработчик отпускания кнопки содержит такую же проверку на нажатие левой кнопки мыши. После проверки осуществляем рисование отрезка из сохраненной точки в точку текущего положения курсора, используя метод addLine() объекта сцены. Вторым параметром в метод addLine() передается перо pen для стилизации отрезка. Процесс рисования отрезка на этом завершен, поэтому параметру pressed присвоим значение false.

2.5 Обработчик события перемещения мыши

Отрисовку вспомогательных отрезков реализуем в третьем обработчике. Проверять нажатие кнопки в этом случае нет смысла, но удалить предыдущий вспомогательный отрезок, если таков был создан ранее, мы просто обязаны. Убедимся, что значение параметра pressed == true, тогда рисуем новый вспомогательный отрезок с использованием другого пера — tempPen.

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

Исходные код метода eventFilter приведен в листинге 4.

bool PaintEvent::eventFilter(QObject* object, QEvent* event) {
    if(object == scene) {
        QGraphicsSceneMouseEvent* mouseEvent = nullptr;
        switch(event->type()) {
        case QEvent::GraphicsSceneMousePress:
            mouseEvent = static_cast<QGraphicsSceneMouseEvent*>(event);
            if(mouseEvent->button() == Qt::LeftButton) {
                startPoint = mouseEvent->scenePos();
                pressed = true;
            }
            break;
        case QEvent::GraphicsSceneMouseRelease:
            mouseEvent = static_cast<QGraphicsSceneMouseEvent*>(event);
            if(mouseEvent->button() == Qt::LeftButton) {
                scene->addLine(QLineF(startPoint, mouseEvent->scenePos()), pen);
                pressed = false;
            }
            break;
        case QEvent::GraphicsSceneMouseMove:
            mouseEvent = static_cast<QGraphicsSceneMouseEvent*>(event);
            if(draftLine != nullptr) {
                scene->removeItem(draftLine);
                delete draftLine;
                draftLine = nullptr;
            }
            if(pressed)
                draftLine = scene->addLine(QLineF(startPoint, mouseEvent->scenePos()), tempPen);
            break;
        default:
            break;
        }
    }
    return false;
}

Листинг 4. Исходный код метода eventFilter

Запускаем приложение и наслаждаемся готовым результатом (см. рис. 2).

3. Выводы

• Фильтры событий это объекты унаследованные от QObject и реализующие метод bool eventFilter(QObject* object, QEvent* event);
• Фильтры событий позволяют выносить в отдельный класс реализацию обработчиков событий, расширять или переопределять функционал, избежать дублирования кода;
• Один и тот же фильтр может быть применен сразу к нескольким объектам;
• Несколько фильтров может быть применено к одному объекту;

4. Исходный код

Скачать исходный код можно по ссылке ниже:

The post Отлов событий в Qt с помощью фильтров событий first appeared on Блог Ильи Житенёва.

Содержание статьи

1. Общая информация
2. std::unique_ptr
3. std::shared_ptr
4. std::weak_ptr

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

1. Общая информация

• Определение умных указателей содержится в заголовочном файле <memory>
• Умные указатели назвали “умными” потому, что они хранят указатель на объект или некий ресурс, а также осуществляют владение этими данными. Они основаны на идиоме RAII.
• Указатели unique_ptr и shared_ptr имеют перегруженные оператора доступа * и ->, поэтому умные указатели могут быть разыменованы как и обычные “сырые” (raw) указатели.
• Для получения сырого указатели из объекта unique_ptr и shared_ptr используйте метод get().
• Метод .get() может быть полезен, когда вам необходимо передать в функцию сырой указатель для отслеживания состояния объекта (желательно не изменять объект, которым владеет умный указатель, через сырые указатели).

void useObject(MyType* pObj) { }
useObject(mySmartPtr.get());

• unique_ptr (начиная со стандарта C++11) и shared_ptr (со стандарта C++17) получили специализацию шаблона для управления массивами данных. Нововведение заключается во внедрении вызова оператора delete[] при удалении управляемого объекта). Это может быть полезно, когда вы получаете указатель на массив, например, из какой-либо библиотеки. Однако, если возможно, старайтесь использовать вместо массивов стандартные контейнеры такие как std::vector<T> или std::array<T>.
• Напоминаю! Не используйте в своем коде auto_ptr! Этот указатель имеет ряд критических проблем, отмечен устаревшим в стандарте C++11 и полностью удален в стандарте С++17. Взамен используйте unique_ptr. Для поиска таких мест можете воспользоваться настройкой modernize-replace-auto-ptr утилиты Clang Tidy для автоматизации рефакторинга.
• В стандартах C++17/20 отсутствует выведение аргументов шаблонов классов (class template argument deduction – CTAD) для умных указателей. Поэтому компилятор не в состоянии отличить указатель на массив от указателя на объекты не массивы созданные оператором new().
• Начиная со стандарта С++20 появились возможность применение атомарных указателей std::atomic<std::shared_ptr<T>> и std::atomic<std::weak_ptr<T>>. Также, в этом стандарты были отмечены устаревшими глобальные атомарные функции для умных указателей, доступных с С++11.
• C++20 добавляет различные функции конструирования *_for_overwrite, которые не принимают аргументов конструктора и используют инициализацию по умолчанию (аналогичную применению оператора new T). Это позволяет избежать ненужной инициализации в ситуациях, когда начальное значение никогда не считывается (например, чтение в буфер).

2. std::unique_ptr

std::unique_ptr это легковесный указатель монопольно владеющий ресурсом.

• std::unique_ptr уничтожает управляемый объект когда указатель покидает область видимости. Для удаления объекта и назначения (при необходимости) нового объекта в управление std::unique_ptr используйте метод reset().
• std::unique_ptr не может быть скопирован, но его можно переместить.
• Обычно, указатель имеет небольшой размер, сопоставимый с размером обычного сырого указателя на объект или размер двух указателей, если при создании умного указателя устанавливается пользовательская функция очистки памяти.

Создание

Наилучший и самый безопасный способ создания unique_ptr это использование переменной типа auto и присваивание ей результата выполнения статического метода std::make_unique

auto pObj = make_unique<MyType>(...);

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

unique_ptr<MyType> pObject(new MyType(...));

Код выше имеет два недостатка в сравнении с первым способом:

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

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

1. для создания умного указателя с пользовательским оператором удаления (об этом далее)
2. для создания полиморфных объектов, см. пример ниже

unique_ptr<Base> pObject(new MyDerived(...));

Пользовательские функции (операторы) удаления

Оператор или функция удаления это функциональный объект используемый для удаления ресурса. По умолчанию используются стандартные операторы delete или delete[].

struct DelFn {  
  void operator()(MyTy* p) {
    p->SpecialDelete(); 
    delete p;
  }
};

using my_ptr = unique_ptr<MyTy, DelFn>;

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

• Оператор удаления не вызывается, если указатель содержит нулевой указатель
• Метод get_deleter() возвращает не константную ссылку на оператор удаления. Этот факт позволяет использовать ссылку и для замены оператора удаления.

Передача в функцию

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

auto pObj = make_unique<MyType>(...);
func(std::move(pObj));
// pObj является невалидным указателем после вызова std::move()

Дополнительная информация

• Метод reset() – сбрасывает указатель (владеемый объект удаляется)
• unique_ptr – полезен при реализации идиомы “pimpl” (pointer to implementation – указатель на реализацию).
• Уникальный указатель рассматривается в первую очередь как кандидат на возвращаемый объект из фабричных методов. Если уникальный указатель не подходит, тогда рассмотрите возможность применения shared_ptr (или weak_ptr).

3. std::shared_ptr

Общий (shared) указатель обеспечивает “распределенное” владение объектом. Множество shared_ptr могут указывать на один и тот же объект. Рядом с каждым объектом создается счетчик указателей, ссылающегося на него. Уничтожение объекта происходит в тот момент, когда уничтожается последний указатель на него (shared_ptr или weak_ptr).

• shared_ptr могут быть перемещены или скопированы
• shared_ptr имеет размер двух указателей: первый на контролируемый объект и второй на управляющий блок
• Управляющий блок содержит счетчик shared_ptr, счетчик weak_ptr, указатели на оператор удаления и аллокатор.

Создание

Рекомендуемый метод, как и с уникальными указателями, это использованием статического метода make_shared:

auto pObj = make_shared<MyType>(...)

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

Пользовательские операторы удаления

Указатель на оператор удаления хранится в управляющем блоке. При создании shared_ptr с помощью конструктора можно указать пользовательский оператор удаления.

void DelFn(MyTp* p) {
    if (p) p->OnDelete(); 
    delete p;
}

shared_ptr<MyTp> ptr(new MyTp(), DelFn);

• Оператор удаления обязан корректно обрабатывать нулевые указатели. Допускаются ситуации, когда оператор удаления может быть вызван в пустых указателях shared_ptr.
• Метод get_deleter() возвращает неконстантный указатель на оператор удаления.

Передача в функцию

Владение объектом в указателе shared_ptr не является монопольным, поэтому вы можете поделиться указателем на объект владения (для указателей unique_ptr не рекомендуется создавать несколько unique_ptr указателей на один и тот же объект). Счетчик shared указателей обновляется автоматически при создании и уничтожении объектов shared_ptr, но за этот функционал конечно приходится немного заплатить. Shared указатели можно перемещать методом std::move().

Для получения сырого указателя используйте метод get().

Дополнительная информация

• Изменение состояния счетчика указателей является атомарным, но доступ к указателю не является потоко-безопасным.
• Для создания shared_ptr указателей на *this используйте метод shared_from_this() и унаследуйте класс от std::enable_shared_from_this.
• Приведение типов указателей может выполняться функциями dynamic_pointer_cast, static_pointer_cast или reinterpret_pointer_cast.
• В виду не монопольности владения объектом, неаккуратное использование shared указателей может приводить к возникновению циклических зависимостей, когда несколько указателей ссылаются друг на друга и не могут уничтожить объект, что может приводить у утечке памяти

4. std::weak_ptr

Слабые (weak) указатели содержат слабую ссылку на объект, который управляется shared указателем. std::weak_ptr для доступа к указываемому объекту обязан быть преобразован в std::shared_ptr методом lock().

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

Создание

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

std::weak_ptr pWeak = pSharedPtr;

if (auto observe = pWeak.lock()) {
    // Объект существует
} else {
   // shared_ptr является пустым
}

При создании std::weak_ptr из std::shared_ptr происходит инкремент счетчика слабых указателей в управляющем блоке shared указателя. Это происходит даже в том случае, если все shared указатели, ссылающиеся на объект, были уничтожены, тогда управляющий блок существует до тех пора, пока существует хотя бы один std::weak_ptr, указываемый на него. Это может быть проблемой если управляющий блок был выделен в памяти рядом с управляемым объектом (например при использовании метода make_shared<T>()). Получается, что управляемый объект уничтожается, а вот управляющий блок остается висеть в памяти.

Дополнительная информация

• метод use_count() возвращает количество shared указателей, которые управляют одним и тем же объектом
• используйте expired() для проверки факта существования управляемого объекта
• слабые указатели не содержат операторов * и ->, поэтому единственный способ получить доступ к управляемому объекту – конвертировать weak_ptr в shared_ptr методом lock().

В качестве выводов

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

Пост является переводом статьи: https://www.cppstories.com/2021/smart-ptr-ref-card/

The post Краткий справочник по умным указателям С++ first appeared on Блог Ильи Житенёва.

Содержание статьи

1. Проблема
2. Мьютексы (mutex)
3. Семафоры (semaphore)
4. Переменные условия ­(Condition variables или Wait conditions)
5. Другие способы
6. Выводы

Описанная выше задача известная как race conditions – или просто “гонки”, когда несколько параллельных задач конкурируют за общие ресурсы. Решается она разграничением доступа к данным во времени. Для этих целей используются следующие сущности:

Применение этих сущностей я покажу на примерах и расскажу как они устроены и как их применять. Приведённый далее код будет написан на Qt, т. к. С++ код практически идентичен, есть лишь некоторые отличия между чистым С++ и Qt, и в таких случаях я приведу оба примера кода.

1. Проблема

Давайте перейдем к примерам и поставим задачу. Пусть имеется 2 банковских счета с 1000 рублей на каждом. Два пользователя одновременно инициируют операции перевода между ними: со счета №1 переводится 500 рублей на счет №2, а со счета №2 на счет №1 переводится 1200 рублей. Чтобы переводы выполнялись «одновременно», создадим объект выполняющий операцию перевода и его выполнение запустим в двух разных потоках.

#include <QCoreApplication>
#include <QThread>
#include <QDebug>

struct Account {
    int balance{1000};
};

class Transfer : public QThread {
    Account& from;
    Account& to;
    int amount;
    void run() override {
        if(from.balance >= amount) {
            from.balance -= amount;
            QThread::usleep(1);
            to.balance += amount;
        }
    }
public:
     Transfer(Account& from, 
     Account& to,
     int amount, 
     QObject* parent = nullptr) : 
     QThread(parent),
     from(from),
     to(to),
     amount(amount)
    {

    }
};

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    Account acc1;
    Account acc2;

    Transfer t1(acc1, acc2, 500);
    Transfer t2(acc2, acc1, 1200);

    t1.start();
    t2.start();

    t1.wait();
    t2.wait();

    qDebug() << "Acc1.balance=" << acc1.balance;
    qDebug() << "Acc2.balance=" << acc2.balance;


    return a.exec();
}

Запускаем программу и получаем следующий результат:

Acc1.balance = 500
Acc2.balance = 1500

Ну что, вас ничего не смущает? Как мы видим, выполнилась лишь первая операция — перевод 500 рублей с первого счета на второй, а перевести 1200 рублей со второго на первый не удалось, т. к. в момент начала операции на втором счете ещё не было нужной суммы. Давайте решать эту проблему.

2. Мьютексы (mutex)

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

QMutex m;
...
m.lock();
// Осуществляем монопольный доступ
m.unlock();

Будьте осторожны с мьютексом. Его надо обязательно отпустить, иначе его нельзя будет захватить. Поскольку это частая ошибка и в больших проектах выявить её очень сложно, то были придуманы сущности для работы с мьютексами с использованием идиомы RAII (Resource Acquisition Is Initialization).

RAII — идиома, смысл которой заключается в том, что получение ресурса совмещено с инициализацией объекта, а освобождение с уничтожением объекта. Таким образом, вместе с уничтожением объекта QMutexLocker автоматически вызывается unlock мьютекса, если требуется. Давайте применим эти сущности для исправления нашего кода с помощью мьютексов.

#include <QCoreApplication>
#include <QThread>
#include <QDebug>
#include <QMutex>
#include <QMutexLocker>

QMutex m;

struct Account {
    int balance{1000};
};

class Transfer : public QThread {
    Account& from;
    Account& to;
    int amount;
    void run() override {
        QMutexLocker lk(&m);
        if(from.balance >= amount) {
            from.balance -= amount;
            QThread::usleep(1);
            to.balance += amount;
        }
    }
public:
    Transfer(Account& from, Account& to, int amount, QObject* parent = nullptr) :
     QThread(parent),
     from(from),
     to(to),
     amount(amount)
    {

    }
};

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    Account acc1;
    Account acc2;

    Transfer t1(acc1, acc2, 500);
    Transfer t2(acc2, acc1, 1200);

    t1.start();
    t2.start();

    t1.wait();
    t2.wait();

    qDebug() << "Acc1.balance=" << acc1.balance;
    qDebug() << "Acc2.balance=" << acc2.balance;


    return a.exec();
}

Получаем результат:

Acc1.balance = 1700
Acc2.balance = 300

Другое дело!

3. Семафоры (semaphore)

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

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

#include <QCoreApplication>
#include <QThread>
#include <QDebug>
#include <QSemaphore>

struct Account {
    QSemaphore balance;
};

class BuyIceCream : public QThread {
    Account& from;
    static const int cost = 500;
    QString name;
    void run() override {
        while (1) {
            from.balance.acquire(cost);
            qDebug() << name << "! Enough money! Wallet = " << from.balance.available()+cost << "-" << cost << "=" << from.balance.available();
        }


    }
public:
    BuyIceCream(QStringView name, Account& from, QObject* parent = nullptr) :
    QThread(parent),
     from(from),
     name(name.toString())
{}
};

class Transfer : public QThread {
    Account& to;
    int amount;
    void run() override {
        for(int i = 0; i < 12; ++i) {
            QThread::msleep(1000);

            qDebug() << i+1 << ") Transfer from WORK: " << amount << ". Wallet = " << to.balance.available()+amount;
            to.balance.release(amount);

        }
    }
public:
    Transfer(Account& to, int amount, QObject* parent = nullptr) :
    QThread(parent),
    to(to),
    amount(amount)
    {

    }
};

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    Account fathersWallet;

    Transfer t1(fathersWallet, 400);
    BuyIceCream son1(u"Vasya", fathersWallet);

    t1.start();
    son1.start();

    t1.wait();

    son1.quit();


    return a.exec();
}

и выводимый результат:

1 ) Transfer from WORK:  400 . Wallet =  400
2 ) Transfer from WORK:  400 . Wallet =  800
"Vasya" ! Enough money! Wallet =  800 - 500 = 300
3 ) Transfer from WORK:  400 . Wallet =  700
"Vasya" ! Enough money! Wallet =  700 - 500 = 200
4 ) Transfer from WORK:  400 . Wallet =  600
"Vasya" ! Enough money! Wallet =  600 - 500 = 100
5 ) Transfer from WORK:  400 . Wallet =  500
"Vasya" ! Enough money! Wallet =  500 - 500 = 0
6 ) Transfer from WORK:  400 . Wallet =  400
7 ) Transfer from WORK:  400 . Wallet =  800
"Vasya" ! Enough money! Wallet =  800 - 500 = 300
8 ) Transfer from WORK:  400 . Wallet =  700
"Vasya" ! Enough money! Wallet =  700 - 500 = 200
9 ) Transfer from WORK:  400 . Wallet =  600
"Vasya" ! Enough money! Wallet =  600 - 500 = 100
10 ) Transfer from WORK:  400 . Wallet =  500
"Vasya" ! Enough money! Wallet =  500 - 500 = 0
11 ) Transfer from WORK:  400 . Wallet =  400
12 ) Transfer from WORK:  400 . Wallet =  800
"Vasya" ! Enough money! Wallet =  800 - 500 = 300

4. Переменные условия­ (Condition variables или Wait conditions)

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

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

#include <QCoreApplication>
#include <QThread>
#include <QDebug>
#include <QWaitCondition>
#include <QMutex>

QMutex m;

struct Account {
    int balance{0};
    QWaitCondition enoughMoney;
};

class BuyIceCream : public QThread {
    Account& from;
    static const int cost = 500;
    QString name;
    void run() override {
        while (1) {
            QMutexLocker lk(&m);
            from.enoughMoney.wait(&m);

            if(from.balance >= cost) {
                qDebug() << name << "! Enough money! Wallet = " << from.balance << "-" << cost << "=" << from.balance-cost;
                from.balance -= cost;
            }
        }


    }
public:
    BuyIceCream(QStringView name, Account& from, QObject* parent = nullptr) :
     QThread(parent),
    from(from),
     name(name.toString())
 {}
};

class Transfer : public QThread {
    Account& from;
    Account& to;
    int amount;
    void run() override {
        for(int i = 0; i < 12; ++i) {
            QThread::msleep(1000);

            QMutexLocker lk(&m);
            if(from.balance >= amount) {
                from.balance -= amount;
                to.balance += amount;
                qDebug() << i+1 << ") Transfer from WORK: " << amount << ". Wallet = " << to.balance;
            }

            to.enoughMoney.notify_one();
        }
    }
public:
    Transfer(Account& from, Account& to, int amount, QObject* parent = nullptr) :
     QThread(parent),
     from(from), to(to),
     amount(amount)
    {

    }
};

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    Account work;
    work.balance = 10'0000'000;
    Account fathersWallet;

    Transfer t1(work, fathersWallet, 900);
    BuyIceCream son1(u"Vasya", fathersWallet);
    BuyIceCream son2(u"Petya", fathersWallet);

    t1.start();
    son1.start();
    son2.start();

    t1.wait();

    son1.quit();
    son2.quit();


    return a.exec();
}

Обратите внимание, что в строке 54 мы вызываем метод notify_one(), который пробуждает один поток, поэтому лишь один сын сможет купить мороженное и отец может накапливать деньги.

Получаемый результат:

1 ) Transfer from WORK:  1400 . Wallet =  1400
"Vasya" ! Enough money! Wallet =  1400 - 500 = 900
2 ) Transfer from WORK:  1400 . Wallet =  2300
"Petya" ! Enough money! Wallet =  2300 - 500 = 1800
3 ) Transfer from WORK:  1400 . Wallet =  3200
"Vasya" ! Enough money! Wallet =  3200 - 500 = 2700
4 ) Transfer from WORK:  1400 . Wallet =  4100
"Petya" ! Enough money! Wallet =  4100 - 500 = 3600
5 ) Transfer from WORK:  1400 . Wallet =  5000
"Vasya" ! Enough money! Wallet =  5000 - 500 = 4500
6 ) Transfer from WORK:  1400 . Wallet =  5900
"Petya" ! Enough money! Wallet =  5900 - 500 = 5400
7 ) Transfer from WORK:  1400 . Wallet =  6800
"Vasya" ! Enough money! Wallet =  6800 - 500 = 6300
8 ) Transfer from WORK:  1400 . Wallet =  7700
"Petya" ! Enough money! Wallet =  7700 - 500 = 7200
9 ) Transfer from WORK:  1400 . Wallet =  8600
"Vasya" ! Enough money! Wallet =  8600 - 500 = 8100
10 ) Transfer from WORK:  1400 . Wallet =  9500
"Petya" ! Enough money! Wallet =  9500 - 500 = 9000
11 ) Transfer from WORK:  1400 . Wallet =  10400
"Vasya" ! Enough money! Wallet =  10400 - 500 = 9900
12 ) Transfer from WORK:  1400 . Wallet =  11300
"Petya" ! Enough money! Wallet =  11300 - 500 = 10800

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

1 ) Transfer from WORK:  900 . Wallet =  900
"Vasya" ! Enough money! Wallet =  900 - 500 = 400
2 ) Transfer from WORK:  900 . Wallet =  1300
"Vasya" ! Enough money! Wallet =  1300 - 500 = 800
"Petya" ! Enough money! Wallet =  800 - 500 = 300
3 ) Transfer from WORK:  900 . Wallet =  1200
"Vasya" ! Enough money! Wallet =  1200 - 500 = 700
"Petya" ! Enough money! Wallet =  700 - 500 = 200
4 ) Transfer from WORK:  900 . Wallet =  1100
"Vasya" ! Enough money! Wallet =  1100 - 500 = 600
"Petya" ! Enough money! Wallet =  600 - 500 = 100
5 ) Transfer from WORK:  900 . Wallet =  1000
"Vasya" ! Enough money! Wallet =  1000 - 500 = 500
"Petya" ! Enough money! Wallet =  500 - 500 = 0
6 ) Transfer from WORK:  900 . Wallet =  900
"Vasya" ! Enough money! Wallet =  900 - 500 = 400
7 ) Transfer from WORK:  900 . Wallet =  1300
"Vasya" ! Enough money! Wallet =  1300 - 500 = 800
"Petya" ! Enough money! Wallet =  800 - 500 = 300
8 ) Transfer from WORK:  900 . Wallet =  1200
"Vasya" ! Enough money! Wallet =  1200 - 500 = 700
"Petya" ! Enough money! Wallet =  700 - 500 = 200
9 ) Transfer from WORK:  900 . Wallet =  1100
"Vasya" ! Enough money! Wallet =  1100 - 500 = 600
"Petya" ! Enough money! Wallet =  600 - 500 = 100
10 ) Transfer from WORK:  900 . Wallet =  1000
"Vasya" ! Enough money! Wallet =  1000 - 500 = 500
"Petya" ! Enough money! Wallet =  500 - 500 = 0
11 ) Transfer from WORK:  900 . Wallet =  900
"Vasya" ! Enough money! Wallet =  900 - 500 = 400
12 ) Transfer from WORK:  900 . Wallet =  1300
"Petya" ! Enough money! Wallet =  1300 - 500 = 800
"Vasya" ! Enough money! Wallet =  800 - 500 = 300

Теперь в январе, июне и ноябре мороженное ест лишь один сын (к счастью для Васи и к несчастью для Пети).

В С++ CV предоставляют лаконичный интерфейс, позволяя совместить проверку условия и ожидание CV:

std::condition_variable cw
std::mutex m;
…
int balance;
std::unique_lock<std::mutex> lk(m);
cw.wait(lk, []{
    return (balance > cost);
});

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

5. Другие способы

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

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

Пример кода:

#include <QCoreApplication>
#include <QThread>
#include <QDebug>
#include <QStringView>
#include <QReadWriteLock>
#include <QStringList>
#include <QWriteLocker>
#include <QReadLocker>

QReadWriteLock lock;

QString msg { "Hello "};

class Transfer : public QThread {
    void run() override {
        QStringList list {"Hi", "Privet"};
        for(int i = 0; i < list.size(); ++i) {
            QThread::sleep(1);
            QWriteLocker locker(&lock);
            msg = list.at(i);
        }
        QThread::sleep(1);
    }
public:
    Transfer(QObject* parent = nullptr) :
        QThread(parent)
    {

    }
};

class Receive : public QThread {
    QString name;
    void run() override {
        while(1) {
            QReadLocker locker(&lock);
            qDebug() << msg << name;
            QThread::msleep(500);
        }
    }
public:
    Receive(QStringView name, QObject* parent = nullptr) :
        QThread(parent),
        name(name.toString())
    {

    }
};

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    Receive t1(u"Vasya");
    Receive t2(u"Petya");

    Transfer w;

    t1.start();
    t2.start();
    w.start();

    QObject::connect(&w, &QThread::finished, &t1, &QThread::terminate);
    QObject::connect(&w, &QThread::finished, &t2, &QThread::terminate);

    w.wait();


    return a.exec();
}

и результат:

"Hello " "Vasya"
"Hello " "Petya"
"Hello " "Vasya"
"Hello " "Petya"
"Hello " "Vasya"
"Hi" "Vasya"
"Hi" "Petya"
"Hi" "Vasya"
"Hi" "Petya"
"Hi" "Petya"
"Hi" "Vasya"
"Privet" "Petya"
"Privet" "Vasya"
"Privet" "Vasya"
"Privet" "Petya"

6. Выводы

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

The post Синхронизация потоков и безопасная работа с общими данными в многопоточной среде на C++ и Qt first appeared on Блог Ильи Житенёва.

Содержание статьи

1. Как устроена многопоточность в Qt?
2. Создание потока через обертку
3. Переопределение метода run() класса QThread
4. Достоинства и недостатки

1. Как устроена многопоточность в Qt?

В Qt потоками управляет класс QThread. Он представляет собой обёртку для потоков операционной системы и предоставляет кросс-платформенный интерфейс для работы с ними.

Запустить код в отдельном потоке можно двумя способами:

1. создание обёртки для нашего класса, который будет жить в отдельном потоке;
2. переопределение метода run() в унаследованном от QThread классе.

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

2. Создание потока через обёртку

Допустим, что вся тяжелая работа выполняется в методе doWork() класса HeavyWork, поэтому необходимо перенести его в отдельный поток. Код класса представлен ниже:

#include <iostream>
class HeavyWork : public QObject {
    Q_OBJECT
	public:
	    void doWork() {
	        std::cout << "Начинаем сложную работу";
      	    // Для эмуляции долгого выполнения сложной операции
	        // отправим поток в сон на 1 секунду
	        QThread::sleep(1);
	        std::cout << "Всё готово!";
	    }
	};

Экземпляр такого класса необходимо создать внутри потока. Напрямую сделать этого не возможно, поэтому создадим обработчик, который и будет создавать, взаимодействовать и уничтожать такой объект. Создаем класс Worker с одним методом и сигналом, излучаемым с флагом типа bool, оповещающем об (не) успешности выполненной работы. Все это происходит внутри метода process():

#include <QObject>
class Worker : public QObject {
    Q_OBJECT
    HeavyWork* work;
public slots:
    void process();
signals:
    void finished(bool);
};

void Worker::process() {
    // Этот метод будет запущен при старте потока
    // Аллоцируем наш объект. Теперь это происходит в отдельном потоке
    work = new HeavyWork();
    if(work == nullptr) {
        // Если произошла ошибка, то сигнализируем что поток завершен с отрицательным результатом и покидаем функцию (а с ней и завершается поток)
        emit finished(false);
        return;
    }
    // Делаем сложную работу
    work->doWork();
    // Сигнализируем об успешном выполнении
    emit finished(true);
}

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

class Controller : public QObject {
    Q_OBJECT
public:
    void makeThread();
};

Единственный метод класса – makeThread(), вот он то нам и нужен, давайте его пошагово реализуем!

1. Создаем экземпляры обработчика Worker и экземпляр потока QThread

Worker* worker = new Worker();
QThread* thread = new QThread();

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

3. Перемещаем worker в новорожденный поток

worker->moveToThread(thread);

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

// При запуске потока запускаем выполнение метода Worker::process()
connect(thread, &QThread::started, worker, &Worker::process);
// При излучении сигнала finished получаем флаг успешности и выводим в консоль соответствующее сообщение
connect(worker, &Worker::finished, this, [](bool state){
    if(state)
        std::cout << "Успех" << std::endl;
    else
        std::cout << "Хьюстон, у нас проблемы!" << std::endl;
});
// Также, по сигналу finished отправляем команду на завершение потока
connect(worker, &Worker::finished, thread, &QThread::quit);
// А потом удаляем экземпляр обработчика
connect(worker, &Worker::finished, worker, &QObject::deleteLater);
// И наконец, когда закончит работу поток, удаляем и его
connect(thread, &QThread::finished, thread, &QObject::deleteLater);

3..2..1.. Поехали! Запускаем выполнение потока

thread->start();

Реализация метода makeThread() завершена. Для проверки выполните следующий код и наблюдайте за стандартным выводом приложения:

Controller ctrl;
ctrl.makeThread();

3. Переопределение метода run() класса QThread

Второй способ заключается в наследовании класса QThread и переопределении метода run(). Однако, этот метод нарушает принципы SOLID в подавляющем большинстве случаев, поэтому пойдем окольными путями

Обновлено 23.02.22

Информация о нарушении принципов SOLID не совсем корректна. Подробнее об этом способе создания потоков я рассказал в статье Многопоточность в Qt через наследование QThread

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

class AnotherController : public QObject {
    Q_OBJECT
public:
    void makeThread();
};

, где метод makeThread() реализуем следующим образом:
1. Создаем экземпляр класса HeavyWork

HeavyWork* work = new HeavyWork();

2. Создаем поток через статический метод QThread::create() принимающий Function в качестве параметра. Function — это адаптер функциональных объектов. Создать адаптер можно с помощью функции std::bind из стандартной библиотеки шаблонов (STL). Этот адаптер будет запущен при запуске потока. Синтаксис следующий:

QThread* thread = QThread::create(std::bind(&HeavyWork::doWork, work));

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

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

3. Налаживаем связь

connect(thread, &QThread::finished, work, &QObject::deleteLater);
connect(thread, &QThread::finished, thread, &Qobject::deleteLater);

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

4. И наконец запускаем выполнение потока.

thread->start();

Метод makeThread() реализован. Запуск программы аналогичен предыдущему случаю

AnotherController anCtrl;
anCtrl.makeThread();

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

4. Достоинства и недостатки

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

Исходя из выше написанного, можно заключить, что ни один из них не является панацеей и не даёт 100% гарантий, но «наломать дров» в первом способе чуть сложнее, чем во втором, если у вас большой и сложный объект. Однако, в случае когда у вас маленькая функция, можно смело использовать второй метод. Окончательное решение за выбор того или иного метода — за вами! Всего доброго!

==============

В следующей статье рассмотрим вопрос синхронизации потоков и разделения доступа к общим ресурсам.

The post О Многопоточности в Qt и как создать поток first appeared on Блог Ильи Житенёва.

Git – это инструмент, хранящий изменения между файлами, верно?

Неверно. Git не полагается на diff (инструмент, фиксирующий изменения между версиями файла). Если бы это было так, то при просмотре определённой версии проекта потребовалось бы вычисление всех изменений, внесённых во все файлы проекта с момента первого commit’а. А что если репозиторий имеет историю в 10 лет? Выходит весьма затратная операция.

И как же тогда быть, если надо быстро и “безболезненно” залезть в глубь репозитория?

3 Столпа Git:

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

тогда Git сохранит это в следующей структуре:

Что же произойдёт, если мы внесем изменения в файл libs/base_libs/file.py и закомитим снова? При изменении файла Git создаст новый blob-объект, а также будет создан и новый tree-объект, потому что содержимое директории base_libs было также изменено, и её родительская директория тоже, выходит, была изменена. Таким образом, новый commit будет выглядеть так:

Обратите внимание, что для неизменённых файлов используются указатели на объекты от предыдущего коммита. И второй и первый комит ссылаются на одни и те же объекты. Эта простая концепция и есть движущей силой Git! А что произойдёт если мы изменим settings.py и закомитим снова? Поскольку этот файл расположен в корневом уровне, то потребуется создать лишь один единственный blob-объект и родительский к нему tree-объект. Такая операция оставит абсолютно не тронутым ветвь ‘libs’ директории, поэтому Git может использовать имеющиеся объекты снова.

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

Так Git абсолютно не использует сравнение версий?

Не совсем. Поскольку Git пытается быть очень эффективным инструментом, когда дело доходит до хранения своих объектов на диске, а программные проекты могут очень быстро раздуваться, то Git сжимает ваши файлы и на этом он не останавливается. Что произойдёт, если вы измените лишь одну строчку в огромном файле? Исходя из того, что мы уже изучили, Git должен создать новый blob-объект. Получим 2 больших объекта в базе Git, которые очень похожи между собой.

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

Таким образом, Git старается быть максимально эффективным.

Подведём итоги

• Git основан не на хранении изменений в версиях (diff), а на деревьях состояний;
• Git не использует diff для представления версий проекта;
• Git использует обход объектных-деревьев для представления версий;
• Git использует diff для минимизации занимаемого дискового пространства.

The post Как работает Git? Одно из частых заблуждений начинающих first appeared on Блог Ильи Житенёва.

1. Не изобретайте велосипед

В современном мире идея открытого софта (Open-source) распространена достаточно широко. Не пользоваться этим богатым опытом других разработчиков весьма глупо.

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

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

2. Выбирайте библиотеки разумно

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

Обязательно проверяйте количество звезд, посмотрите другие проекты автора, убедитесь, что они тоже достойного качества, посмотрите тикеты (issues), как открытые, так и закрытые. Убедитесь в стабильности работы этого кода и обязательно загляните “под капот”, посмотрите сам код: как он написан, эффективен ли он, можно ли доверять ему?

3. Расслабьтесь, выдохните, заварите чаю и читайте больше кода

Программисты тратят много времени не на написание кода, а на его чтение. Если вы ещё не делаете так, то начните это делать!

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

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

4. Придерживайтесь стандартов и стилей

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

5. Думайте о безопасности с самого начала

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

6. Продумайте архитектуру

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

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

7. Пользовательскому интерфейсу – особое внимание

Пользовательский интерфейс – это как шутка, если вам приходится его объяснять, это плохо!

Неизвестный автор

Если вы работаете в команде, то возможно у вас есть отдельный человек, в чью ответственность входит забота о UI\UX . Но если вы разработчик-одиночка, то не забывайте уделять внимание не только коду, но и дизайну.

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

8. Тестируйте, тестируйте и ещё раз тестируйте!

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

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

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

9. Начните использовать Git прямо сейчас!

Если вы ещё не используете Git или любую другую систему контроля версий, то начните их использовать прямо сейчас!

Делать архивы вашего проекта и бэкапы, всякий раз, когда вы собираетесь внести изменения весьма занудно. Вы можете запросто забыть это сделать. А если вы внесли несколько изменений, весьма масштабных, и что-то стало работать не так. Как узнать об изменениях, внесённых в программу? Git позволит вам следить за изменениями в коде и в случае неприятностей откатиться назад.

10. Не гонитесь за новинками

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

11. Изучите шаблоны проектирования

Разрабатывая сложный и крупный проект вы будете сталкиваться лицом к лицу с некоторыми распространёнными проблемами, которые уже были решены до вас кем-то другим, более компетентным и эти типовые решения – получили названия шаблоны проектирования (design patterns).

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

Это инвестиция, которая будет давать вам “дивиденды” вечно!

12. Настало время отдавать!

На пути программиста мы часто сталкиваемся с какими-либо проблемами и находим решение в сети Интернет. Пришло время возвращать!

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

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

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

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

The post Чему я научился за годы программирования: 12 советов разработчикам first appeared on Блог Ильи Житенёва.

Как это работает?

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

import serial
with serial.Serial(port='COM3') as s:
          s.write('Привет')
          s.write('Как дела')

Здесь мы определяем псевдоним s и используем его в контексте serial. В теле контекста может располагаться любой блок кода, в т.ч и другие контексты. Применение менеджера контекста позволяет гарантировать, что ресурс Serial будет закрыт, что удобно, например, в многопоточных приложениях, где ресурс надо быстро освобождать для возможности использования другими потоками. Или банальная ошибка программиста – забыть закрыть метод, тоже решается использованием менеджера контекста.

Зачем это нужно?

В приведённом выше примере вам не нужно вызывать функции open и close объекта serial, потому что их за вас вызовет менеджер контекста. То есть, вам не нужно беспокоится о закрытии порта после выполнения некоторых действий – это сделается автоматически.

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

import serial

s = serial.Serial(port='COM3')
s.open()
s.write('Привет')
s.write('Как дела?')
s.close()

Однако, есть тут один нюанс. Если вдруг где-то между открытием и закрытием порта произойдёт исключение (exception), то закрытие ресурса не гарантируется!

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

import serial

s = serial.Serial(port='COM3')
s.open()
try:
    s.write('Привет')
    s.write('Как дела?')
finally:
    s.close()

И да, этот код будет абсолютно функционально эквивалентен применению менеджера контекста, он также будет безопасен, но вы можете сделать его проще и лаконичнее с помощью with.

Главная ценность инструкции with это возможность абстрагироваться от функциональности распространенных шаблонов управления ресурсов, упрощая работу с ними.

Как это использовать в собственных разработках?

Возникает закономерный вопрос: “Как инструкция with узнает, какой метод вызывать при открытии контекста и при его завершении”?

Для этого используются “волшебные” методы __enter__ и __exit__ или декоратор, созданный с помощью модуля contextlib. Рассмотрим оба случая.

Собственный класс

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

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

class list:
	def __init__(self):
		self.level = 0

	def __enter__(self):
		self.level += 1
		return self

	def __exit__(self, exc_type, exc_val, exc_tb):
		self.level -= 1

	def write(self, text):
		print('    ' * self.level + '* ' + text)


with list() as l:
	l.write("Фрукты")
	with l:
		l.write("Бананы")
		l.write("Ананасы")

	l.write("Ягоды")
	with l:
		l.write("Черника")
		l.write("Малина")

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

    * Фрукты
        * Бананы
        * Ананасы
    * Ягоды
        * Черника
        * Малина

Декоратор

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

from contextlib import contextmanager
import serial

@contextmanager
def comOpen(portname):
    ser = serial.Serial()
    try:
        ser.setPort(portname)
        yield ser
    except serial.serialutil.SerialException:
        print("Ошибочка вышла!")
    finally:
        print('Закрываем порт')
        ser.close()


with comOpen('COM3') as s:
    s.write('Hello!')

И если мы выберем заранее неверный порт, то увидим на экране вывода сообщение:

Ошибочка вышла!
Закрываем порт

Реализация удалась! Менеджер контекста работает!

Резюме

• Менеджер контекста определяется инструкцией with и позволяет полностью абстрагироваться от управления ресурсами и гарантировать их освобождение при выходе из контекста
• Вы можете создавать собственные объекты, которые можно применять с менеджерами контекста
• Используя вложенность контекстов и творческих подход, можно использовать их для решения задач не связанных с владением и управлением ресурсами. Например, реализовать форматирование текста в виде список с разными уровнями вложенности

The post Менеджер контекста with в Python first appeared on Блог Ильи Житенёва.