В этой статье мы детально разберем атомарные операции и барьеры памяти C++11 и генерируемые ими ассемблерные инструкции на процессорах x86_64.
Далее мы покажем как ускорить работу contfree_safe_ptr<std::map> до уровня сложных и оптимизированных lock-free структур данных аналогичных по функциональности std::map<>, например: SkipListMap и BronsonAVLTreeMap из библиотеки libCDS (Concurrent Data Structures library): github.com/khizmax/libcds
И такую многопоточную производительность мы сможем получить для любого вашего изначально потоко-небезопасного класса T используемого как contfree_safe_ptr<T>. Нас интересуют оптимизации повышающие производительность на ~1000%, поэтому мы не будем уделять внимание слабым и сомнительным оптимизациям.
Читать полностью »
Рубрика «C++14» - 4
Релиз CLion 2017.1: C++14, C++17, код на дизассемблере в отладчике, Catch, MSVC и многое другое
2017-03-31 в 15:48, admin, рубрики: C, c++, C++14, c++17, Catch, CLion, disassembly view, IDE, jetbrains, MSVC, Блог компании JetBrains, ПрограммированиеПривет! Спешим поделиться радостной новостью – мы выпустили первый в этом году релиз нашей кросс-платформенной IDE для C и C++, CLion 2017.1!
Наши планы, как обычно, немного превосходят наши возможности и ресурсы. Но в этот релиз нам удалось успеть почти все из запланированного. Если вкратце:
- Поддержка C++14 (всё кроме constexpr)
- Начальная поддержка C++17 (мы начали с самой востребованной возможности – nested namespaces)
- Возможность конвертировать тип переменной в auto
- Во время отладки программы, при отсутствии файлов с исходным кодом можно переходить на код на дизассемблере (disassembly view)
- Поддержка фреймворка для юнит-тестирования Catch
- Значительное ускорение отклика редактора при печати кода (Zero Latency Typing)
- И, наконец, экспериментальная поддержка компилятора Microsoft Visual C++!
И это еще не все! Читайте подробности ниже.
Кстати, попробовать все новые возможности можно на небольшом демо-проекте, который мы специально подготовили для этих целей.
Читать полностью »
Красиво «взламываем» ООП с помощью C++14
2017-03-07 в 11:34, admin, рубрики: c++, c++11, C++14, ненормальное программирование, ооп, Программирование
Вступление
Недавно при работе над проектом учебной практики возникла потребность из своего кода порождать произвольный процесс и одновременно читать его stdout и stderr. Так как приложение пишется исключительно для linux, я решил заодно разобраться с epoll. Для запуска процесса на просторах интернета была найдена маленькая библиотека, делающая как раз то, что нужно, да еще и оборачивающая ввод-вывод в привычные потоки из стандартной библиотеки (речь о <iostream>).
Вооружившись несколькими статьями про epoll, я уже было собирался писать код, если бы не одно «но» — для epoll нужен доступ к «сырым» файловым дескрипторам, а автор библиотеки не предоставляет public-доступа к ним. Методы класса, возвращающие дескрипторы, скрыты под грифом «protected».
Что делать?
Самым простым было бы исправить код библиотеки и переместить нужные методы в public-секцию, еще лучше было бы форкнуть библиотеку и реализовать необходимый функционал самому. Но первое было бы некрасиво и сулило бы конфликтами при обновлении библиотеки, а второе заняло бы слишком много времени на разбор кода библиотеки и последующее тестирование под несколькими разными *nix-системами.
Поэтому в голову пришла безумная третья мысль: почему бы не попытаться как-то красиво «взломать» ООП и «легально» получить доступ к protected-методу без вмешательства в исходный код библиотеки? О том, какие преграды возникли на этом пути и как помог C++14 в их преодолении, и пойдет рассказ в данной публикации.
Читать полностью »
Энное время назад в одной XMPP-комнате, посвященной C++, один посетитель спросил, нет ли какого способа в современных плюсах без лишнего кода передать указатель на функцию-член класса в качестве коллбека в C API. Ну, что-то вроде
// C API
void doWithCallback (void (*fn) (int, void*), void *userdata);
// C++ code
struct Foo
{
void doFoo (int param);
};
int main ()
{
Foo foo;
doWithCallback (MAGIC (/* &Foo::doFoo */), &foo);
}
Понятно, что в качестве MAGIC можно использовать свободную функцию, статическую функцию-член или вообще лямбду (2017-й год на дворе, всё-таки), но писать соответствующую конструкцию каждый раз для каждой функции руками несколько лениво, а препроцессор, как мы все, конечно, знаем — моветон.
В этом посте мы попробуем (и, что характерно, у нас это получится) написать универсальную обёртку, а заодно посмотрим, как кое-какая фишка из C++17 поможет нам ещё сократить количество избыточного кода. Никаких крышесносных шаблонов здесь не будет, решение, на мой взгляд, достаточно тривиально, но, пожалуй, им всё равно имеет смысл поделиться (и заодно лишний раз попиарить новые возможности C++17).
dock: простая библиотека модульного тестирования кода на С++
2017-01-18 в 12:39, admin, рубрики: c++, c++ библиотеки, C++14, unit-testing, Unit-тестирование, Тестирование IT-системХотя и существуют уже библиотеки для юнит-тестирования кода на С++, например, Google Test или Bandit, но они написаны не мной здесь оно, на мой взгляд, как-то переусложнено, по сравнению с тем же JS. Там просто делаешь, например, npm i mocha assert --save-dev и можно приступать к написанию тестов, а здесь же нужно это сделать ручками, а в случае с gtest еще и собрать с помощью cmake ее. Bandit подключается просто, но не умеет в сериализацию результатов в какой-то формат данных, gtest это умеет, но его нужно собирать отдельно. А я не хочу выбирать "либо то, либо это". Мне было нужно сделать удобный и простой инструмент под мои задачи. Я хотел получить простую библиотеку без зависимостей, header-only, на несколько файлов, которую можно легко и быстро подключить к своему проекту, удобно внести в нее изменения (если это будет необходимо). Но, самое основное, мне хотелось получать удобные, машиночитаемые отчеты, причем не только в stdout (или xml, как в gtest), но и в любой другой формат, который я захочу. Далее под катом.
Универсальный конструктор Auto
2016-11-24 в 10:05, admin, рубрики: auto, c++, c++11, C++14, ПрограммированиеС приходом C++11 появилась возможность объявлять переменные с типом auto, а компилятор сам определил фактический тип переменной, на основе типа инициализируемого значения. Это удобно, когда мы хотим проинициализировать переменную тип которой слишком сложный, либо неизвестен, либо он нам не очень важен, либо просто для простоты.
Например:
auto f = [](){}; //указатель на функцию
auto r = foo(10); //тип возвращаемый функцией foo
for (auto i = 0; i < 10; i++){} … и т.д. То есть в левой части равенства у нас автоматический тип auto, а в правой части значение четко определенного типа. А теперь представим, что у нас все наоборот:
int a = auto(10);Релиз CLion 2016.3: улучшения поддержки C11, C++11 и C++14, изменения в работе с проектной моделью CMake и многое другое
2016-11-23 в 14:08, admin, рубрики: C, c++, c++11, C++14, c11, CLion, cmake, cross-platform, IDE, jetbrains, remote debug, Блог компании JetBrains, ПрограммированиеПривет! Год потихоньку подходит к концу, кто-то уже готовится к праздничным мероприятиям, а кто-то еще старается завершить все задуманное. А мы вот выпустили третий за этот год релиз нашей кросс-платформенной IDE для разработки на C и C++. Оглядываясь назад (и подводя итоги, как принято делать накануне нового года), нам кажется, что за 2016 год CLion существенно вырос и стал гораздо более зрелым:
- Как в плане языковой поддержки (variadic templates, auto-import и просто многочисленные исправления в части анализа кода),
- Так и в плане разнообразных возможностей, повышающих продуктивность разработки (новые опции кодогенерации, complete statement, рефакторинги в CMake),
- Новых языков (Python, Swift),
- Ну и, конечно, инструментов, сопутствующих разработке на C и C++ (удаленная отладка и отладка процессов, запущенных не из IDE на локальной машине, поддержка формата документации кода Doxygen, множество улучшений в работе с системами контроля версий).
Мы старались прислушиваться к нашим пользователям (насколько это было возможно) и ориентироваться на их запросы. Версия 2016.3 не стала исключением и принесла множество долгожданных улучшений:
- Помимо недостающих возможностей C++11, мы смогли, наконец, начать поддержку возможностей стандартов C++14 и C11.
- Переработанный подход к работе с проектной моделью CMake решил много сложностей, с которыми сталкивались наши пользователи (от невозможности изменить директорию, в которой запускается генерация CMake, до проблем с производительностью и потреблением памяти).
- Удаленная отладка возможна теперь и на платформе Windows.
- В редакторе появилась семантическая подсветка.
- Повышена производительность при повторной индексации проектов на базе Unreal Engine, а еще мы изучили текущее состояние стороннего плагина для генерации CMake для проектов на UE4 и написали об этом целый отдельный пост.
- Множество других улучшений и изменений.
А теперь обо всем по порядку.
Использование современного С++ для повышения производительности
2016-10-13 в 11:07, admin, рубрики: c++, c++11, C++14В данной статье я хотел бы рассказать, как использование средств современных стандартов С++ позволяет повысить производительность программ без каких-либо особых усилий от программиста.
Читать полностью »
Аналитическое вычисление производных на шаблонах C++
2016-09-20 в 12:33, admin, рубрики: c++, C++14, i am mad, делать было нечего, дело было вечером, ненормальное программирование, шаблоны c++Тут на днях писали про аналитическое нахождение производных, что напомнило мне об одной моей маленькой библиотечке на C++, которая делает почти то же, но во время компиляции.
В чём профит? Ответ прост: мне нужно было запрогать нахождение минимума достаточно сложной функции, считать производные этой функции по её параметрам ручкой на бумажке было лень, проверять потом, что я не опечатался при написании кода, и поддерживать этот самый код — лень вдвойне, поэтому было решено написать штуковину, которая это сделает за меня. Ну, чтобы в коде можно было написать что-то такое:
using Formula_t = decltype (k * (_1 - r0) / (_1 + r0) * (g0 / (alpha0 - logr0 / Num<300>) - _1)); // сама формула
const auto residual = Formula_t::Eval (datapoint) - knownValue; // регрессионный остаток
// производные по параметрам:
const auto dg0 = VarDerivative_t<Formula_t, decltype (g0)>::Eval (datapoint);
const auto dalpha0 = VarDerivative_t<Formula_t, decltype (alpha0)>::Eval (datapoint);
const auto dk = VarDerivative_t<Formula_t, decltype (k)>::Eval (datapoint);
вместо крокодилов, которые получатся, если брать частные производные функции на картинке вначале (вернее, некоторого её упрощённого варианта, но он выглядит не так страшно).
Ещё неплохо быть достаточно уверенным, что компилятор это соптимизирует так, как если бы соответствующие производные и функции были написаны руками. А уверенным быть бы хотелось — находить минимум нужно было очень много раз (действительно много, где-то от сотни миллионов до миллиарда, в этом была суть некоего вычислительного эксперимента), поэтому вычисление производных было бы бутылочным горлышком, происходи оно во время выполнения через какую-нибудь рекурсию по древообразной структуре. Если же заставить компилятор вычислять производную, собственно, во время компиляции, то есть шанс, что он по получившемуся коду ещё пройдётся оптимизатором, и мы не потеряем по сравнению с ручным выписыванием всех производных. Шанс реализовался, кстати.
Под катом — небольшое описание, как оно там всё работает.
Как избежать ошибок, используя современный C++
2016-09-15 в 9:42, admin, рубрики: C, c++, c++11, C++14, c++17, modern c++, open source, pvs-studio, static code analysis, Блог компании PVS-Studio, Компиляторы, Программирование, статический анализ кода
Одной из проблем C++ является большое количество конструкций, поведение которых не определено или просто неожиданно для программиста. С такими ошибками мы часто сталкиваемся при использовании статического анализатора кода на разных проектах. Но, как известно, лучше всего находить ошибки ещё на этапе компиляции. Посмотрим, какие техники из современного C++ позволяют писать не только более простой и выразительный код, но и сделают наш код более безопасным и надёжным.
Читать полностью »