В процессе своей деятельности мы ежедневно сталкиваемся с проблемой определения приоритетов развития. Учитывая высокую динамику развития IT индустрии, постоянно возрастающую востребованность со стороны бизнеса и государства к новым технологиям, каждый раз, определяя вектор развития и инвестируя собственные силы и средства в научный потенциал нашей компании, мы следим за тем, чтобы все наши исследования и проекты носили фундаментальный и междисциплинарный характер.
Static analysis methodology involves various technologies. One of them is preprocessing files right before analyzing them. Preprocessed files are created by the compiler that runs in a special working mode. Unfortunately, our long-standing experience of developing a static analyzer shows that this mode is not great for testing. In this note, I'll give the example of a fresh bug in the C++ compiler from Microsoft.
Читать полностью »
В методологии статического анализа применяются разные технологии. Одна из них — препроцессирование файлов непосредственно перед их анализом. Препроцессированные файлы создаёт компилятор, запускаемый в специальном режиме работы. К сожалению, этот режим не очень хорошо тестируется, как показывает наш многолетний опыт разработки статического анализатора кода. В этой заметке приведу пример свеженайденного бага в С++ компиляторе от Microsoft.
Читать полностью »
Современный мир C++ серьёзно отличается от того, что был привычен нам во времена C++ 98. Кто-то этим восхищается, кого-то это раздражает, но факт остаётся фактом. Вот какие темы будоражат умы разработчиков сегодня:
Меньше чем через месяц пройдёт конференция, которая старается ответить на эти вопросы: C++ Russia 2019. Давайте коротко взглянем, как это у неё получится.
Привет!
Осенью прошлого года на Kaggle проходил конкурс по классификации нарисованных от руки картинок Quick Draw Doodle Recognition, в котором среди прочих поучаствовала команда R-щиков в составе Артема Клевцова, Филиппа Управителева и Андрея Огурцова. Подробно описывать соревнование не будем, это уже сделано в недавней публикации.
С фармом медалек в этот раз не сложилось, но было получено много ценного опыта, поэтому о ряде наиболее интересных и полезных на Кагле и в повседневной работе вещей хотелось бы рассказать сообществу. Среди рассмотренных тем: нелегкая жизнь без OpenCV, парсинг JSON-ов (на этих примерах рассматривается интеграции кода на С++ в скрипты или пакеты на R посредством Rcpp), параметризация скриптов и докеризация итогового решения. Весь код из сообщения в пригодном для запуска виде доступен в репозитории.
Когда речь заходит о любимых языках, я обычно говорю, что при прочих равных предпочитаю C++ для числодробилок и хаскель для всего остального. Полезно периодически проверять, насколько такое деление обосновано, а тут ещё недавно возник один праздный и очень простой вопрос: как себя будет вести сумма всех делителей числа с ростом этого самого числа, скажем, для первого миллиарда чисел. Эту задачу просто запрогать (аж стыдно называть получившееся числодробилкой), так что она выглядит как отличный вариант для такой проверки.
Кроме того, я всё ещё не владею навыком точного предсказания производительности хаскель-кода, так что полезно пробовать заведомо плохие подходы, чтобы посмотреть, как будет деградировать производительность.
Ну и вдобавок можно легонько выпендриться более эффективным алгоритмом, чем лобовой поиск делителей для каждого числа от 
до 
.
… Работаете вы, например, над очень большим проектом. Проект реально очень большой, написан на C или C++, и его билд «с нуля» может занять несколько часов, да и сборка после каких-то фиксов или патчей тоже требует немало времени, особенно если изменения коснулись чего-то фундаментального или много где используемого. Вы запускаете компиляцию на своем десктопе, все ядра загружены, вентиляторы крутятся как бешенные, и при этом вокруг вас еще десяток машин ваших коллег, которые по сути дела простаивают. Нехорошо.
Читать полностью »
Привет! Эта статья — прямое продолжение статьи Искусство парсинга или DOM собственными руками, где мы разобрали HTML-документ и построили на его основе абстрактное синтаксическое дерево (AST) с доступом к любому элементу через индексацию при помощи лишь стандартной библиотеки C++, проще говоря, научились самостоятельно парсить XML-подобные штуки. Напомню, что процесс парсинга, или синтаксического анализа/разбора состоит из двух этапов: лексического разбора (разбора текста на токены) и построения AST. Если первый мы рассмотрели очень подробно, с примерами и исходниками, то описание второго похоже на пустую куколку бабочки, у которой есть только оболочка, а прекрасное содержимое автор извлёк перед публикацией. На то была причина, для HTML построить дерево действительно просто, нужно всего 4 класса: пустой тег, блок, текстовый узел и корень документа, наследуемый от блока. Сегодня мы оставим такую простоту позади и построим дерево, где свойства элементов, и пустых, и блочных, будут содержаться не в атрибутах тегов, а непосредственно в классах, а для этого классов придётся создать много. Действительно много. Строить будем не из простых известных языков разметки, а создадим свой, с правилами, показанными на изображении под катом. Плюс в конце ещё переведём, или, говоря правильнее, транслитируем документ с предыдущей статьёй, размеченной нашим языком, в HTML, а в качестве бонуса я отвечу начинающим программистам C++ на тривиальный, но труднонаходимый вопрос: как включать классы «друг в друга»?
Читать полностью »
23 марта 2019 года пройдет четырнадцатый слет IT-сообществ Санкт-Петербурга IT Global Meetup 2019. Весенний слет петербургских IT-сообществ стартует в субботу! На островках сообществ можно будет ознакомиться с их деятельностью и принять участие в активностях. ITGM — не форум, не конференция. ITGM — встреча, созданная самими сообществами со свободой действий, докладов и активностей.
Язык C++ открывает обширные возможности для того, чтобы обходиться без макросов. Так давайте попробуем использовать макросы как можно реже!
Сразу оговорюсь, что я не являюсь фанатиком и не призываю отказываться от макросов из идеалистических соображений. Например, когда речь заходит о ручной генерации однотипного кода, я могу признать пользу от макросов и смириться с ними. Например, я спокойно отношусь к макросам в старых программах, написанных с использованием MFC. Нет смысла воевать с чем-то вроде этого:
BEGIN_MESSAGE_MAP(efcDialog, EFCDIALOG_PARENT )
//{{AFX_MSG_MAP(efcDialog)
ON_WM_CREATE()
ON_WM_DESTROY()
//}}AFX_MSG_MAP
END_MESSAGE_MAP()Существуют такие макросы, да и ладно. Они действительно были созданы для упрощения программирования.
Я говорю о других макросах, с помощью которых пытаются избежать реализации полноценной функции или стараются сократить размер функции. Рассмотрим несколько мотивов избегать таких макросов.
Читать полностью »