C++ *

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

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

enum Suit { Spades, Hearts, Diamonds, Clubs };

Обычно решение данной задачи базируется на дублировании значений, например, внутри switch-а:

switch(value)
{
    case Spades:   return "Spades";
    case Hearts:   return "Hearts";
    case Diamonds: return "Diamonds";
    case Clubs:    return "Clubs";
    default:       return ""
};

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

Поэтому я постарался найти путь, который вообще не требовал бы дублирования, но при этом полностью справлялся бы с поставленной задачей. Думаю, у меня получилось.

Далее в статье я опишу способ, позволяющий организовать рефлексию для enum-ов. Кому интересно — добро пожаловать под кат.

Имеется типична ситуация:

• кем-то написанное приложение на Qt;
• пользователи жалуются, что программа во время работы жрем много CPU;
• профилировщик и strace указывают на то, что происходит насилование базы.

В такой ситуации хочется посмотреть что за запросы, их количество, время выполнения. Если в PostgreSQL есть pg_stat_statements и pgBadger, то для SQLite пришлось написать свой самокат. Самокат представляет из себя вызов sqlite3_profile для каждого соединения, запись полученной информации в журнал.

Многие считают, что неопределённое поведение программы возникает из-за грубых ошибок (например, запись за границы массива) или на неадекватных конструкциях (например, i = i++ + ++i). Поэтому для многих является неожиданностью, когда неопределенное поведение вдруг проявляет себя во вполне привычном и ничем не настораживающем коде. Рассмотрим один из таких примеров. Программируя на C/C++ никогда нельзя терять бдительность. Ад ближе чем кажется.

Выбор инструмента

Проблема профилировки рано или поздно встает перед любым проектом, претендующим на роль лучшего в своей области. Какой инструмент выбрать — всегда большой вопрос. Одни инструменты показывают одну часть картины, другие другую. И рано или поздно начинаешь писать свой тул (англ. tool — орудие\инструмент), который отвечает на насущные проблемы именно данного конкретного проекта. Однако время на написание своего «орудия» всегда приходится вычитать из времени отведенного на сам проект.
Поэтому серьезный профайлер написать не получается…

Но как получить все и сразу? (Тут мне почему то вспоминается песня Queen «I want it all»)

Unity продолжают совершенствовать технологию IL2CPP, а мы публикуем перевод статьи о том, как она работает.

17 сентября 2015 в Москве состоялась очередная ежегодная конференция Intel Software Conference. Программа конференции включала общие выступления (вступительное слово, обзор технологий компании для разработчиков, истории успеха клиентов Intel) и две параллельные сессии: первая была посвящена оптимизации кода и параллельным вычислениям, вторая касалась вопросов мобильной разработки и медиа.

По итогам посещения первой сессии, наибольший интерес у меня вызвал доклад на тему «Векторизуем код с Intel Advisor XE». Помимо демонстрации возможностей инструмента по оптимизации кода, рассматривались общие вопросы векторизации, давались рекомендации к написанию векторизуемого кода, а также разбирались примеры конструкций, препятствующих автоматической векторизации, и давались советы по их устранению. Но давайте обо всём по порядку.

Microsoft выложила в открытый доступ исходный код инструментов, которые используются в компании для ускорения разработок в области искусственного интеллекта: набор Computational Network Toolkit теперь доступен на Github. Разработчикам пришлось создать собственное решение, так как имеющиеся инструменты работали слишком медленно. Давайте же взглянем на результаты проверки этого проекта статическим анализатором кода.

В данной статье описывается стандарт JSON Schema и его использование для проверки соответствия заданному формату на языке C++ средствами библиотеки valijson.

Немного истории

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

Здравствуйте, дорогие читатели!

У нас активно расходится третий доптираж крайне успешной книги «Изучаем C++ через программирование игр». Поэтому сегодня вашему вниманию предлагается перевод интересной статьи на одну из узких тем, связанных с программированием игр на C++. Также просим вас поучаствовать в опросе

В статье рассмотрена полная интеграция C++ библиотеки в managed окружение с использованием Platform Invoke. Под полной интеграцией подразумевается возможность наследования классов библиотеки, реализации её интерфейсов (интерфейсы будут представлены в managed коде как абстрактные классы). Экземпляры наследников можно будет «передавать» в unmanaged окружение.

По работе пришлось сделать несколько своих компонентов на Wt: визард, диалог выбора каталогов и файлов на устройстве. Решил выложить на GitHub, может кому-нибудь понадобится. Под катом будет простой диалог выбора файлов на Wt+Boost.

Несколько недель назад я наткнулся на сравнительный анализ Rust, D и Go от Андрея Александреску. Андрей, уважаемый член сообщества C++ и главный разработчик языка программирования D, нанес Rust сокрушительный удар под конец своего повествования, высказав нечто, что выглядит довольно проницательным наблюдением:

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

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

На прошлой неделе компания Qt Company (подразделение Digia) обновила текст соглашения с организацией KDE Free Qt Foundation и объявила о новой политике лицензирования Qt.

Организация KDE Free Qt Foundation была основана в 1998 г. с целью защиты Qt как свободного ПО. Между организацией и компанией Trolltech был заключен договор, позволяющий в случае прекращения разработки свободной версии Qt, выпустить Qt под лицензией типа BSD (или любой другой свободной). Договор обновлялся, по мере того, как права на Qt переходили к Nokia, а затем к Digia.

Подробности новой лицензионной политики Qt под катом.

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

Праздники отгремели, зима в полном разгаре, кто-то уже выкинул новогоднюю елку, а кто-то ждет потепления. А мы упорно трудимся над новыми версиями наших C++ продуктов. Так, например, с декабря открыта программа раннего доступа (Early Access Program) CLion — нашей кросс-платформенной IDE для C/C++.



Там очень много всего нового и интересного:

В декабре 2015 года на конференции JSConf US разработчики объявили, что планируют открыть исходный код ключевых компонентов JavaScript-движка Chakra, работающего в Microsoft Edge. Недавно исходный код ChackraCore под MIT лицензией опубликовали в соответствующем репозитории на GitHub. В статье я расскажу, что удалось найти интересного в проекте с помощью статического анализатора PVS-Studio.

Введение

ChakraCore это базовая составляющая Chakra, высокопроизводительный движок JavaScript, который запускает приложения Microsoft Edge и Windows, написанные на HTML/CSS/JS. ChakraCore поддерживает JIT-компиляцию на JavaScript для x86/x64/ARM, сборку мусора и широкий спектр самых последних возможностей JavaScript.

PVS-Studio — это статический анализатор для выявления ошибок в исходном коде программ, написанных на языках С, C++ и C#. Инструмент PVS-Studio предназначен для разработчиков современных приложений и интегрируется в среды Visual Studio 2010-2015.

Приветствую всех!

Сегодня я расскажу о возможностях платформы FlyElephant для ученых и инженеров, которые в своей работе проводят различные вычисления на C++, R, Python или Octave. Это могут быть научные расчеты, анализ данных, моделирование или другие задачи. 22 января я буду проводить вебинар “Введение в FlyElephant”, на котором детально расскажу о платформе FlyElephant, а сегодня в общих чертах познакомлю вас с ней и покажу процесс проведения расчетов.

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

В нашей статье мы покажем, как Intel Tamper Protection Toolkit позволяет защитить критически важные участки кода и ценные данные в утилите шифрования Scrypt против статического/динамического реверс-инженеринга и изменений. Scrypt – наиболее новая и безопасная функция выработки ключа по паролю, широко применяемая на практике. Однако существует угроза фальсификации параметров функции scrypt, что приведет к появлению уязвимостей пароля пользователя. Инструментарий позволяет уменьшить эти угрозы. Мы определяем модель угроз для рассматриваемого приложения, объясняем как провести его рефакторинг для дальнейшей защиты, учитывая особенности применения инструмента Tamper Protection к приложению.
Основной целью этой статьи является демонстрация возможностей Intel Tamper Protection Toolkit по защите от атак на критически важные участки кода и ценные данные, находящиеся в реальных приложениях. Инструментарий позволяет противодействовать статическому и динамическому реверс-инженерингу путем обфускации и препятствовать внесению изменений в защищаемое приложение путем контроля целостности во время выполнения.

В переводе представлен новый подход к модульному тестированию огромной базы унаследованного кода на C++, плохо реагирующей на тесты.

В данной статье я бы хотел рассказать о собственном опыте оптимизации выполнения множества регулярных выражений при помощи системы hyperscan. Так вышло, что при разработке своего спам-фильтра rspamd я столкнулся с необходимостью портировать большой объем старых правил, написанных для spamassassin за несколько лет работы. Моим первым решением было написать плагин, который бы читал эти правила и строил из них синтаксическое дерево. Затем на этом дереве выполнялись различные оптимизации, чтобы сократить общее время выполнения (об этом я даже делал небольшую презентацию).

К сожалению, в ходе эксплуатации выяснилось, что pcre все равно являются узким местом, и на больших письмах этот набор правил работает слишком медленно. Выяснилось, например, что на письме размером в мегабайт pcre проверяет около гигабайта (!) текста. Различные трюки, вроде ограничения количества текста для регулярных выражений, оказывали негативное влияние на срабатывания правил, а оптимизации pcre путем интенсивного использования jit fast path через pcre_jit_exec оказались слишком опасными — некоторые старые выражения были откровенно некорректными и в сочетании с некорректным входным текстом, например, содержащим «битые» UTF8 символы, приводили к воспроизводимым багам с повреждением стека программы. Однако на конференции highload мы поговорили со Вячеславом Ольховченковым, и он мне посоветовал посмотреть на hyperscan. Далее я перейду к сути и расскажу, что из этого получилось.