C++ *

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

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

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

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

POCO — легковесный, мультиплатформенный open-source набор библиотек и классов С++, облегчающих написание мультиплатформенного ПО.
Выпускается под Boost Software License.
Дополнительные сведения о POCO:
pocoproject.org/features.html
ru.wikipedia.org/wiki/POCO
Прекрасно организованная документация по структуре классов доступна в html-онлайн, html-оффлайн.
Документация по основным возможностям с примерами использования — в pdf: pocoproject.org/documentation/index.html

POCO имеет богатейший функционал — очень многое — всё-всё, что нужно для счастливой жизни C++ программиста! Работает инструментарий отлично, имеет продуманный API.

POCO собирается для большого числа ОС, в т.ч. Desktop Windows, Windows CE, Linux.

По своему опыту замечу, что POCO для этих ОС собирается без проблем.
Методику кроссплатформенной сборки из Windows для этих ОС постараюсь вам, уважаемые с++ разработчики, донести в своих трёх статьях «Cross-compile POCO из Windows».

Статья «Cross-compile POCO из Windows для WinCE» habrahabr.ru/post/223157

MagicClass::getInstance().getFooFactory().createFoo().killMePlease();

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

Постановка

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

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

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

Рабочий вариант с тестовым примером можно взять отсюда.

Доброго времени суток, хотел бы поделиться с сообществом своей небольшой библиотектой.
Я программирую на С/C++, и, к сожалению, в рабочих проектах не могу использовать стандарт C++11. Но вот пришли майские праздники, появилось свободное время и я решил поэкспериментировать и по-изучать этот запретный плод. Самое лучшее для изучения чего либо — это практика. Чтение статей о языке программирования научит максимум лучше читать, поэтому я решил написать маленькую библиотеку для асинхронного выполнения функций.
Сразу оговорюсь, что я знаю, что существует std::future, std::async и тп. Мне было интересно реализовать самому нечто подобное и окунуться в мир лямбда-функций, потоков и мьютексов с головой. Праздники — отличное время для велопрогулок.

Здравствуй уважаемый %username%.
Сегодня я хотел бы поделиться с тобой личным опытом в создании Web сайта на CppCMS (библиотека-шаблонизатор на с++). Можно назвать это «помощью начинающему программисту на CppCMS».

Зачем писать сайт на с++

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

Определение

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

• блокировки (mutex);
• алгоритмы без блокировки (lockless, lock-free);
• транзакционная память.

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

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

Привет, Хабрахабр!

Последнее время я не мог не обратить внимание на популярность темы Qt на хабрике, но тем не менее, в комментах продолжают встречаться люди, которые говорят откровенно лживые и непонятные вещи. Этим постом я хотел развеять малость заблуждений о Qt и рассказать, почему же ты должен пересесть со своих Java/Obj-C/.NET на мягкий и пушистый Qt.

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

Ну, что, поехали?

Меня всегда интересовали прикладные задачи обработки видеоданных в реальном времени. На Хабре я прочитал серию статей о мультимедиа фреймвоке GStreamer:

• Знакомство с GStreamer: Введение
• Знакомство с GStreamer: Источники данных
• Знакомство с GStreamer: Устройства вывода
• GStreamer: кодеки с привкусом Linux

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

Частенько нет необходимости запускать тяжеловесную IDE Visual Studio для компиляции небольших приложений, проведения каких-либо тестов кода, не требующего полномасштабной отладки. В подобных случаях можно оперативно собрать приложение в консольном режиме, используя возможности предоставляемые компилятором от Microsoft (cl.exe) и запускными модулями IDE (devenv.exe, msdev.exe). Далее приводится код файлов сценариев (cmd) интерпретатора командной строки Windows, который с небольшими изменениями каждый может настроить под себя, с учётом путей к Visual Studio в своей системе.

Программам необходимы данные. Программы выдают лишь настолько хороший результат работы, насколько полны и валидны были входные данные. Для некоторых программ входными данными являются обычные файлы или полученная из сети информация (пример — ваш браузер). Другие программы оперируют исходными кодами. Эти вторые «мета-программы» тоже нуждаются в данных. Чем они будут качественнее — тем качественнее будет и результат.

Что же за данные мы «скармливаем» таким программам? Ну, в С++ более важным чем «что?» является вопрос «когда?» (помните Морфеуса?). Программа на С++ это всего-лишь последовательность битов, которые компилятор пытается прочитать и понять. И вот в процессе этого «понимания» компилятор преобразует код на С++ в машинные инструкции и (что особенно интересно!) выполняет некоторую часть кода вашей программы. Да, мы говорим о мета-программировании на этапе компиляции.

Возвращаемся к вопросу «что?». Мы хотим иметь доступ ко всем сущностям, которые только теоретически могут быть доступны на этапе компиляции: типы, члены классов, функции, аргументы, пространства имён, номера строк кода, имена файлов — и всё это хорошо бы иметь в «чистом виде», без каких-либо странных препроцессорных хаков или использования сторонних утилит. Кроме того, хорошо бы получить и менее очевидные вещи: информацию о конвертируемости одних типов в другие, отношениям наследования и агрегации, дружественных классах и функциях и т.д.

Компилятор языка С++ уже имеет всю эту информацию! Но, к сожалению, не в доступной для мета-программирования форме. Получается странная такая ситуация — мы можем выполнить кое-какой код на этапе компиляции — но вот большинства данных у нас нет. Ну и здесь было бы логично задаться вопросом «А как же мы можем эти данные получить?».

Применительно к с++03 существует “правило трех”, с появлением с++11 оно трансформировалось в “правило 5ти”. И хотя эти правила по сути являются не более чем неформальными рекомендациями к проектированию собственных типов данных, но тем не менее часто бывают полезны. “Правило ноля” продолжает ряд этих рекомендаций. В этом посте я напомню о чем, собственно, первые 2 правила, а также попробую объяснить идею, стоящую за “правилом ноля”.

Всем привет.

В прошлую субботу — 19 апреля прошла очередная встреча C++ User Group. На этот раз мы встречались в Нижнем Новгороде.
На встречу пришло 82 человека, причём участники были не только из Нижнего Новгорода: Санкт-Петербург, Москва, Рязань, Саратов, Чебоксары, Екатеринбург, Великий Новгород. Меня немного пугает, что зарегистрировался, но не приехал участник из Иркутска. Надеюсь, с ним всё хорошо.

Мы постоянно проверяем открытые проекты на языке Си/Си++. Но почти всегда, это проекты, разрабатываемые в Visual Studio. А вот Embarcadero C++ Builder мы как-то обделили вниманием. Нужно исправляться и сегодня мы проверили проект WinSCP.

Захотелось, наконец-то(!), попробовать variadic templates, так как до сих пор привязан к 10й студии, где ничего этого нету. А чтобы долго не думать, где же можно бесполезно использовать variadic templates, пришла идея попробовать, как будет выглядеть Typelist. Для тех, кто ещё не знает, что это такое, я постараюсь объяснять по ходу дела, а тем, кому это скучно — может сразу пролистать вниз — попробуем написать подобие крестиков-ноликов с использованием Typelist.
Итак, TypeList:

В этой статье я объясню, как подключить к нашим индикаторам аргументы (часть1, часть2). За аргументы в динамической библиотеке MSX DLL программы Metastock отвечают две служебные функции: MSXNthArg и MSXNthCustomString.

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

struct deferred;
struct deadline;
struct disable;

template<class T, class Deferred = disable, class Deadline = disable>
struct some_container

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

typedef some_container<int, disable, deadline> deadline_container;
<source>
А хотелось бы 

<source lang=cpp>
typedef some_container<int, deadline> deadline_container;

А ещё лучше, что бы даже порядок задания не имел значение и следующие два, были бы эквивалентны

typedef some_container<int, deferred, deadline> full_container1;
typedef some_container<int, deadline, deferred> full_container1;

Но мы прекрасно понимаем, что как только мы поменяли два параметр у нас получится совершенно не то чего мы ожидали (это вам не tuple где порядок указание не имеет значении)
Думаю многие уже подумали о том, что всего этого можно добиться добавив прослойку между нашим типом и пользователем, для которой написать все возможные специализации. Если у вас только 2 шаблонных параметр то да, если 3 то уже сложно, а если добавится 4, 5 то пиши пропало. Да и как правило добавление нового параметра приводит к переделыванию всех предыдущих специализаций (так как в специализации мы не можем увеличивать число шаблонных параметров, а можем их только уменьшать).
Если вас заинтересовало, прошу под кат, я покажу вам как добиться этого

В этой статье будут подробно рассмотрены наша функция (часть1, часть3), правила получения данных из Metastock’а, их обработки и возврата результата обратно в Metastock. Эта информация поможет избежать ошибок в работе MSX DLL.

Metastock – наверное, самая известная программа для технического анализа рынка. Данная программа может подключать внешние библиотеки DLL, написанные пользователями для создания своих торговых стратегий, используя полную мощь традиционных языков программирования, таких как C или Паскаль.
Занявшись поиском в интернете, с удивлением обнаружил полное отсутствие информации по данной теме. Единственная статья, которая оказалась достойной внимания: “Что такое Metastock Developer's Kit?” (mdk), где описывается коротенький пример на Delphi, там же можно скачать MDK.
В данной статье я постараюсь заполнить этот пробел и описать процесс создания библиотеки внешних функций Metastock (MSX DLL) по шагам на языке C/C++. Все примеры писались в среде Visual Studio 2010 (часть2, часть3).

Как вы, наверное, догадались, эта статья посвящена lock-free очередям.

Очереди бывают разные. Они могут различаться по числу писателей (producer) и читателей (consumer) – single/multi producer — single/multi consumer, 4 варианта, — они могут быть ограниченными (bounded, на основе предраспределенного буфера) и неограниченными, на основе списка (unbounded), с поддержкой приоритетов или без, lock-free, wait-free или lock-based, со строгим соблюдением FIFO (fair) и не очень (unfair) и т.д. Подробно типы очередей описаны в этой и этой статьях Дмитрия Вьюкова. Чем более специализированы требования к очереди, тем, как правило, более эффективным оказывается её алгоритм. В данной статье я рассмотрю самый общий вариант очередей — multi-producer/multi-consumer unbounded concurrent queue без поддержки приоритетов.