QML технология красивая и радует глаз. Меня она очень заинтересовала, и я решил ее освоить. Но не тут то было, ибо я оказался тупым и беспомощным. Нигде в сети не нашел примера «для чайников» (наверно плохо искал), чтобы с нуля построить простейшее приложение QML и C++ в связке. Везде чего-то не хватало: или не учитывался Qt Creator, или код выдавал ошибки, или отсутствовали целые моменты, которые пользователи должны были сами знать. Официальная документация и примеры здесь на хабре также были с этими недостатками. Вот и решил после долгих попыток и ошибок написать такую статью для начинающих с подробнейшим описанием.

Задача. Нужно написать программу QML в связке с С++, где
1. На форме располагается кнопка, строка ввода, и поле вывода.
2. Требуется считать из строки ввода число, прибавляется 1, и ответ выводится в поле вывода.
3. Интерфейс написан на QML.
4. Функционал на С++, то есть нам нужно обеспечить взаимосвязь между QML и C++: кнопка QML вызывает С++ функцию, а функция меняет свойства QML объектов.

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

    Эта статья расскажет о том, как обработать данные, полученные после pipeline, выходом которого будет sam/bam файл[1], создать несложный bed graph файл (http://genome.ucsc.edu/FAQ/FAQformat.html) и просмотреть его с помощью UCSC genome browser[2]. Очень сложно решиться, на чем писать программы, ибо уже есть огромное количество чужих наработок и совсем не хочется сочинять колесо там, где этот этап уже пройден. Долго мучаясь, я решил остановиться на C++, хотя phyton и R рассматривались на равных. Также сохранилась идея, что может понадобиться графика, да ещё и под Linux, поэтому к С++ прибавилось Qt. Надеюсь, в этой статье я расскажу достаточно подробно о всем выше перечисленном, чтобы ответить на вопрос, заданный мне в начале пути и озвученный в первой части повествования.

Service Control Manager (SCM)

SCM — реализованный в Windows сервер удаленного управления сервисами (вызова процедур).

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

Постановка задачи

Наисать буферный класс позволяющий упростить работу SCM в C#.
Сам внешний вид этого класса можно обознать очень просто:

    public ref class ServiceControlManager
	{
	public:
		ServiceControlManager(void);
		void AddDriver(String^ ServiceName, String^ BinaryPathName);
		void DeleteDriver(String^ ServiceName);
		void StartDriver(String^ ServiceName);
		void StopDriver(String^ ServiceName);
	protected:
		~ServiceControlManager();
	private:
		SC_HANDLE SCMHandle;
	};

Конструктор, деструктор, основные методы, из атрибутов только HANDLE объекта SCM, из чего следует, что экземпляр объекта этого класса будет содержать в себе созданный объект SCM, а методы упрощают с ним работу. Класс является буферным, и поскольку он реализован в C++/cli он будет автоматически масштабируем для работы в среде .NET, соответственно и в C#.

Когда-то мне пришлось осваивать работу на С++ с майнфреймом, и возникла проблема как разобраться, в каком месте программа падает и в чем причина. Сразу оговоюсь, что все относится к программированию на майнфреймах под операционной системой z/OS в USS. С одной стороны получается элементарщина, но найти все это в документации IBM не так просто. Кроме того, нужно хотя бы уметь читать HLASM.

В нижеприведенном документе я попробую описать, как по CEE дампу найти строку в которой программа падает.

В посте речь пойдет о моем опыте встраивания XML-RPC интерфейса в утилиту, написанную на C. Интерфейс должен предоставлять доступ к статитстике и результатам работы утилиты. Одно из требований к интерфейсу — поддержка ответов в формате gzip, в целях экономии трафика. Мне очень хотелось обойтись малой кровью и вот что из этого получилось.

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

В статье «Трудности сравнения анализаторов кода или не забывайте об удобстве использования» [1] говорится о том, что сравнить между собой два инструмента не так просто как кажется, потому что помимо собственно технических характеристик анализаторов очень большое значение имеет такой параметр как удобство использования.

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

В статье показаны ошибки, выявленные с помощью статического анализатора кода, встроенного в Visual Studio 2010. Исследование проводилось на пяти open source проектах. Эти же проекты были проверены с помощью PVS-Studio. Приведены результаты сравнения этих двух инструментов.

Мой перевод:


Оригинал:

Мой перевод:


Оригинал: