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

Здравствуйте, коллеги.
Хочу рассказать о SFINAE, интересном и очень полезном (к сожалению*) механизме языка C++, который, однако, может представляться неподготовленному человеку весьма мозгоразрывающим. В действительности принцип его использования достаточно прост и ясен, будучи сформулирован в виде нескольких чётких положений. Эта заметка рассчитана на читателей, обладающих базовыми знаниями о шаблонах в C++ и знакомых, хотя бы шапочно, с C++11.
* Почему к сожалению? Хотя использование SFINAE — интересный и красивый приём, переросший в широко используемую идиому языка, гораздо лучше было бы иметь средства, явно описывающие работу с типами.

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

bool foo(int important, int& pOut, int sometimes = 1, int occasionally = 2, int rarely = 3)
{
//...
}

Проблемы здесь могут быть следующие

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

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

Так уж сложилось, что в наших проектах ведение технической документации полностью лежит на плечах разработчиков, по принципу: внес изменения в код проекта — актуализировал документацию. Сама документация представляла собой набор Word’овских документов, которая хранилась вместе с исходным кодом под VCS. Данный подход к организации разработки существовал долгое время, но пару лет назад мы решили озаботиться возможностью ведения документации проекта отличными от MS Office средствами.

Анимированные GIF’ы до сих пор часто используются в интернете. Хотя это древний формат, но даже в нём остаётся место для инноваций. На сайте Tumblr пополняется коллекция 3D GIF, в которых трёхмерный эффект создан путём простого добавления двух вертикальных белых линий. Странно, но такой простой трюк действительно работает, и без всяких 3D-очков.

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

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



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

Но обо всем по порядку.

Понимание роли мозга

Нет невежества страшнее, чем невежество по отношению к самому себе.

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

Данная статья является продолжением первой части.
Продолжаем мучить Boost.Python. В этот раз настала очередь класса, который нельзя ни создать, ни скопировать.
Обернём почти обычную сишную структуру с необычным конструктором.
И поработаем с возвращением ссылки на поле объекта C++, так чтобы сборщик мусора Python его не удалил ненароком. Ну и наоборот, сделаем альтернативный вариант, чтобы Python прибрал мусор после удаления того, что ему отдали на хранение.
Поехали…

Boost.Python во всех отношениях замечательная библиотека, выполняющая своё предназначение на 5+, хотите ли вы сделать модуль на С++ для Python либо хотите построить скриптовую обвязку на Python для нативного приложения написанного на С++.
Самое сложное в Boost.Python — это обилие тонкостей, поскольку и C++ и Python — два языка изобилующие возможностями, и потому на стыке их приходится учитывать все нюансы: передать объект по ссылке или по значению, отдать в Python копию объекта или существующий класс, преобразовать во внутренний тип Python или в обёртку написанного на C++, как передать конструктор объекта, перегрузить операторы, навесить несуществующие в C++, но нужные в Python методы.
Не обещаю, что в своих примерах опишу все тонкости взаимодействия этих фундаментальных языков, но постараюсь сразу охватить как можно больше частоиспользуемых примеров, чтобы вы не лазили за каждой мелочью в документацию, а увидели все необходимые основы здесь, или хотя бы получили о них базовое представление.

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

(с) xkcd

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

• FT, DTF, DTFT — в чем отличия и как совершенно разные казалось бы формулы дают столь концептуально похожие результаты?
• Как правильно интерпретировать результаты быстрого преобразования Фурье (FFT)
• Что делать если дан сигнал из 179 сэмплов а БПФ требует на вход последовательность по длине равную степени двойки
• Почему при попытке получить с помощью Фурье спектр синусоиды вместо ожидаемой одиночной “палки” на графике вылезает странная загогулина и что с этим можно сделать
• Зачем перед АЦП и после ЦАП ставят аналоговые фильтры
• Можно ли оцифровать АЦП сигнал с частотой выше половины частоты дискретизации (школьный ответ неверен, правильный ответ — можно)
• Как по цифровой последовательности восстанавливают исходный сигнал

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

Обмен сообщениями достаточно фундаментальная вещь в науке Computer Science. Будем рассматривать её в приближении к событийно-ориентированному программированию (event-driven). Терминология, возможности и реализации могут отличаться: события (events), сообщения (messages), сигналы/слоты (signals/slots) и callbacks. В целом суть, что с приходом события запускается ответная реакция.
Сама система обмена сообщениями в статье послужила демонстрацией вольной, но допустимой интерпретации ссылок/указателей, упрощающей код. Получившаяся система тривиальна и умеет только регистрировать обработчик на определённый код сообщения и посылать сообщения с таким кодом.
Допустим что обработчики нетривиальные, а сообщений немного. И что мы сами генерируем сообщения и они не приходят нам по сети, например. В таком случае хочется иметь что-то более удобное с явными объявлениями переменных в сообщении. Например, нечто подобное:

StringMessage* str_message = ...;
send(my_message);
...
void handle_message(const Message* message) {
	assert(message);
	const StringMessage* str_message = dynamic_cast<const StringMessage*>(message);
	assert(str_message);
	std::cout << str_message->message ...
}

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

void handle_message(const StringMessage& message) {
	...
}

Как осуществить задуманное и поддержать другие возможные классы сообщений?

Сайт devdocs.io — проект французского программиста Тибо Курубля. Здесь собрана и упорядочена документация по наиболее популярным веб-технологиям, фреймворкам и API, и многим другим средствам разработки. DOM, HTML, JavaScript, jQuery, Node.js, PHP, Ruby, Python, Git, Angular, Backbone, CoffeScript, Less, Sass, Redis и много чего ещё… Всё оформлено в едином стиле, по всей базе документации работает поиск, в том числе нечёткий. Есть возможность выбрать только необходимые технологии, по которым надо искать. Вообще, интерфейс DevDocs радует — ничего лишнего, всё очень понятно и функционально, доступно множество клавиатурных сокращений.

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

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



О процессе разработки сервиса и расскажу.

Совсем о Julia не говорим тут. Один пост двухлетней давности от Ализара, и всё. Исправляем ситуацию.

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

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

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

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

template <class T>
bool someFunc(T t)
{
	if (t.someCheck()) {
		t.someAction(0);
	}
}

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

Рассмотрим код:

std::multiset<int> set0, set1;
for (auto it = set0.begin(); it != set0.end(); ++it) {
	// длинная
	// обработка
	// *it
}
for (auto it = set1.rbegin(); it != set1.rend(); ++it) {
	// длинная
	// обработка
	// *it
}

Обработка в телах циклов — одинаковая, иными словами требуется одинаково обработать элементы двух мультимножеств: первого — в прямом порядке, второго — в обратном.

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

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

Недавно я наткнулся на блог “OpenMP 3.0 tasking model: as smooth as Cilk?”. После чего я решил проверить, как хорошо распараллеливаются рекурсивные функции с OpenMP 3.0 task. Напомню, что до третьего стандарта не было поддержки динамического или иррегулярного параллелизма(к примеру, циклы с while или рекурсивные функции).

Я надеюсь, что эта статья станет началом цикла заметок о lock-free структурах данных. Я хочу поделиться с хабрасообществом своим опытом, наблюдениям и размышлениями о том, что такое lock-free структуры данных, как их реализовывать, подходят ли концепции контейнеров стандартной библиотеки STL к lock-free контейнерам, и когда стоит (и стоит ли вообще) применять lock-free структуры данных.

Не так давно в boost-1.53 появился целый новый раздел — lockfree реализующий неблокирующие очереди и стек.
Я последние несколько лет работал с так называемыми неблокируюшими алгоритмами (lock-free data structures), мы их сами писали, сами тестировали, сами использовали и втайне ими гордились. Естественно, у нас немедленно встал вопрос, переходить ли с самодельных библиотек на boost, и если переходить, то когда?
Вот тогда у меня и возникла в первый раз идея применить к boost::lockfree кое-какие из методик которыми мы испытывали собственный код. К счастью, сам алгоритм нам тестировать не придется и можно сосредоточиться на измерении производительности.
Я постараюсь сделать статью интересной для всех. Тем кто еще не сталкивался с подобными задачами будет полезно посмотреть на то что такие алгоритмы способны, а главное, где и как их стоит или не стоит использовать. Для тех кто имеет опыт разработки неблокирующих очередей возможно будет интересно сравнить данные количественных измерений. Я сам по крайней мере таких публикаций еще не видел.