C++ *

Предшествующая статья про исключения в С++ оставила кучу тёмных мест,
главное, что осталось непонятным — так как же всё-таки осуществляется
передача управления при возбуждении исключения?
С SJLJ всё понятно, но, утверждается, что эта технология практически
вытеснена некоторым без-затратным (при отсутствии исключений) табличным механизмом.
А вот что это за механизм такой и как он устроен, будем разбираться под катом.

На конференции CppCon, которая проходит прямо сейчас, команда разработчиков компилятора Visual C++ заявила, что в следующем обновлении (Visual Studio 2015 Update 1) в компилятор С++ от Microsoft будет добавлена экспериментальная возможность из нового (ещё не утверждённого) стандарта С++ — поддержка модулей!



Для тех, кто не в курсе в чём эпохальность данного события: так уж сложилось, что механизм использовани компонентов в программах на С++ придумывался где-то лет 35 назад. Его нельзя назвать удобным: если вы хотите создать библиотеку — вам нужно сделать заголовочный файл и распространять с ним либо код, либо скомпилированную версию библиотеки. При этом возникает куча проблем:

• Заголовочный файл и библиотека — отдельные файлы, один из них может потеряться, либо они случайно могут рассинхронизироваться.
• Заголовочный файл включается в код директивой препроцессора #include, что во-первых, замедляет компиляцию, а во-вторых добавляет влияние всего, что написано в заголовочных файлах друг на друга и на конечный код. Нередки случаи, когда заголовочные файлы нужно включать в определенном порядке или определять некоторые макросы чтобы код нормально собрался.

В итоге в инфраструктуре С++ отсутствуют понятия «сборок» или «пакетов» и, в отличии от С# или Python, где установка компонентов тривиальна, в С++ подключение каждой новой библиотеки может нести свои неожиданности. Предлагаемый механизм модулей в С++ призван убрать данную проблему, отказаться от директивы препроцессора #include и ссылаться на компоненты, как на некоторую сущность, состоящую из кода и метаданных, целостную и легко подключаемую. В итоге мы вскоре можем получить существенное ускорение внедрения новых компонентов в проект, появления полноценных менеджеров пакетов, установка новой библиотеки сведется к выполнению одной строки или нескольким кликам мышью. Это ли не счастье!

Под катом будут примеры использования и ссылки на документацию.

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

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

Такая ситуация меня не устроила, и было принято решение написать программу для генерации звукового кода Морзе из некоторого текста с настройкой скорости и возможностью добавления кодов динамически. Решение получилось достаточно оригинальным и гибким (ИМХО, конечно же). И я решил поделиться программой с общественностью: возможно, она будет кому-то полезна или покажется интересной.

В качестве инструмента реализации идеи был выбран С++ в связке с Qt.

Проверять проекты интересно, проверять известные проекты интересно вдвойне, особенно если пользуешься ими сам. Ещё интереснее было бы проанализировать проект с высоким качеством кода. Тогда удалось бы одним выстрелом убить двух зайцев — проверить сам проект, подтвердив или опровергнув качество его кода, так и посмотреть, насколько хорошо справился анализатор. Немного поразмыслив, я пришёл к выводу, что для этого отлично подойдёт популярный мессенджер Telegram.

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

Аннотация

1. Есть страдание.
2. Есть причина страдания.
3. Есть прекращение страдания.
4. Есть путь, ведущий к избавлению от страданий.

4 благородные истины буддизма

Настоящая статья содержит описание раннего прототипа, который вводит понятие реплицируемого объекта (replicated object) или сокращённо replob. Такой объект является дальнейшим переосмыслением борьбы со сложностью кода, возникающего при программировании распределённых систем. Replob устраняет зависимость от стороннего сервиса и реализует согласованное изменение любых пользовательских объектов, представляющих соответствующие данные и функциональность. Эта идея основана на использовании выразительности языка C++ и объектно-ориентированного подхода, что позволяет использовать сложную логику внутри распределённых транзакций. Это позволяет значительно упростить разработку отказоустойчивых приложений и сервисов. Последующие статьи будут более детально объяснять развиваемый подход.

Введение

ПРЕДУПРЕЖДЕНИЕ. Почти все методы, указанные в статье, содержат грязные хаки памяти и ненормальное использование языка C++. Так что, если вы не толерантны к таким извращениям, пожалуйста, не читайте эту статью.

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

Приветствую Хабр!

Наша команда FlyElephant продолжает проведение вебинаров и я хочу пригласить всех 28 сентября в 17.00 на вебинар, на котором мы рассмотрим основы распараллеливания С/С++ программ при помощи OpenMP, познакомимся с функционалом FlyElephant и освоим на примерах принципы работы с платформой. Поговорим о программе бета-тестирования и новом функционале, который будет доступен в ближайшее время.

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

Зарегистрироваться на вебинар можно здесь.

Утром 21 сентября, на открывающем докладе CppCon Бьерн Страуструп официально анонсировал C++ Core Guidelines [ссылка на GitHub проекта][ссылка на слайды] — старт нового open source-проекта по разработке современных авторитетных гайдлайнов по написанию кода на C++. Гайдлайны создаются таким образом, чтобы быть современными, машинно-проверяемыми, а также открытыми для использования в сторонних компаниях — такими, чтобы любая желающая организация могла взять их и включить в свои собственные корпоративные стандарты кодирования.

В качестве авторов-инициаторов проекта выступили Бьерн Страуструп и Герб Саттер; гайдлайны создавались при участии экспертов из CERN, Microsoft, Morgan Stanley и еще нескольких организаций. Сейчас гайдлайны достигли версии 0.6, и Страуструп призывает всех желающих активно контрибьютить в проект.

Страуструп в своем выступлении сказал следующее: «Вы можете писать программы на С++, которые будут статически типобезопасными, и в которых не будет утечек ресурсов. Вы можете делать это без потери производительности и без ограничения выразительной мощи С++. Все это служит поддержкой основного тезиса о том, что сборка мусора не является как необходимой, так и достаточной частью качественного программного обеспечения (garbage collection is neither necessary nor sufficient for quality software). Наши новые гайдлайны делают написание кода более простым, чем это было в старых стилях программирования на С++, а его безопасность может быть проверена инструментами, которые вскоре будут доступны в open source».

Недавно вышло большое обновление Intel® Parallel Studio XE 2016, и вместе с ним Intel® Threading Building Blocks 4.4. В новой версии появилось несколько интересных дополнений:

• Глобальный контроль для управления ресурсами, в первую очередь, количеством рабочих потоков.
• Новые типы узлов Flow Graph: composite_node и async_node. Кроме того, во Flow Graph была улучшена функциональность сброса (reset).
• Больше фишек из С++11 для лучшей производительности.

Третьего дня, во время сортировки старых закладок, попалась мне на глаза блок-схема с алгоритмом выбора STL-контейнера. «Почему же для контейнеров есть, а для стандартных алгоритмов нет? — подумал я. — Это необходимо исправить». Подумано — сделано. Сперва планировалось за пару часов нарисовать нечто простенькое, но в дальнейшем обнаружилось, что алгоритмы никак не хотят умещаться в простенькую схему. Я слегка увлекся, и спустя два вечера схема вобрала в себя 84 алгоритма, а также немного дополнительной информации. Под катом можно увидеть, что получилось в итоге.

Здравствуйте, уважаемые читатели!

Жизнь не стоит на месте, и вот в «O'Reilly» задумались об издании первой фундаментальной книги о языке программирования Rust:



Заинтересовавшись этой темой, мы решили вынести на обсуждение перевод обзорной статьи о языке Rust, вышедшей в декабре 2014 года. Статья немного сокращена с учетом того, что некоторые ее отрывки уже устарели, однако автор хорошо рассматривает этот язык в контексте существующих альтернатив, подчеркивает его (безусловные) достоинства и (условные) недостатки.

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

Предисловие

Данная статья выросла из проблемы, которую мне относительно недавно пришлось решить: скорость кода, предназначенного для работы одновременно в нескольких потоках, резко упала после очередного расширения функционала, но только на Windows XP/2003. С помощью Process Explorer я выяснил, что в большинство моментов времени исполняется только 1 поток, остальные находятся в ожидании, причём TID активного потока постоянно меняется. На лицо явная конкуренция за ресурс, и этим ресурсом оказалась куча по умолчанию (default heap). Новый код активно использует динамическое выделение/высвобождение памяти (копирование строк, копирование/модификация STL контейнеров большого размера), что собственно и привело к возникновению данной проблемы.

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

Как известно, аллокатор по умолчанию (default allocator) для STL контейнеров и std::basic_string (std::allocator) выделяет память из кучи по умолчанию, а операции выделения/высвобождения памяти в ней являются блокирующими (косвенное подтверждение). Исходя из этого, при частых вызовах HeapAlloc/HeapFree мы рискуем намертво заблокировать кучу для других потоков. Собственно это и произошло в моём случае.

Введение

В былые времена я увлекался компьютерной графикой, как 2х так и 3х мерной, в том числе математическими визуализациями. Что называется just for fun, будучи студентом, написал программу визуализирующую N-мерные фигуры, вращающиеся в любых измерениях, хотя практически меня хватило только на определение точек для 4-D гиперкуба. Но это только присказка. Любовь к геометрии осталась у меня с тех пор и по сей день, и я до сих пор люблю решать интересные задачи интересными способами.
Одна из таких задач попалась мне в 2010 году. Сама задача достаточно тривиальна: необходимо найти, пересекаются ли два 2-D отрезка, и если пересекаются — найти точку их пересечения. Более интересно решение, которое, я считаю, получилось достаточно элегантным, и которое я хочу предложить на суд читателя. На оригинальность алгоритма не претендую (хотя и хотелось бы), но в сети подобных решений я найти не смог.

В свое время я написал для журнала «Хакер» цикл статей для рубрики «Академия С++», в котором описывал интересные возможности использования C++. Цикл давно завершён, но меня до сих пор часто спрашивают, как именно работает эмуляция динамической типизации из первой статьи. Дело в том, что когда я начинал цикл, не знал точно, что нужно, а что нет, и упустил в описании ряд нужных фактов. Зря! В обучающем материале не бывает ничего лишнего. Сегодня я в деталях изложу, как именно получается красивый высокоуровневый API в терминах самого обычного C++: просто классы, методы и данные.

Прислали мне как то тестовое задание. Надо написать шахматы на Qt с использованием C++ и QML. QML до этого не изучал, только слышал и читал про него, поэтому решил что напишу только с использованием C++ и библиотеки Qt. Написал, отправил, возвращают и просят графическую часть переписать на QML. Делать нечего, сел за изучения сего чуда и переписал графическую часть. Теперь хочу поделиться приобретённым опытом.

Весь процесс написания шахмат описывать не буду, опишу только процесс постижения QML. Думаю эта статья будет в помощь начинающим в QML.

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

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

Ни один из известных нам сервисов не строил маршрут из точки А до точки Б там, где нет тропинок и тротуаров, зато полно заборов и домов причудливых очертаний.

2ГИС решил эту проблему. Мы научились строить маршруты для пешеходов по растеризованной карте местности. Карта формально представляется графом с вершинами на регулярной решётке в местах, где пешеход может находиться физически.

Принято считать, что такой способ строить маршруты неприемлем, потому что съедает много ресурсов. Под катом — как мы с этим справились.

Преамбула

Использование динамически связываемых библиотек (DLL), как известно, предполагает один из двух способов подключения: связывание во время загрузки (load-time linking) и связывание во время выполнения (run-time linking). В последнем случае нужно использовать предоставляемый операционной системой API для загрузки нужного модуля (библиотеки) и поиска в нем адреса необходимой процедуры. Существует множество оберток, но, к сожалению, все встречавшиеся мне сильно усложнены и перегружены лишним кодом. Предлагаемое решение изначально предназначено для вызова функций, хранящихся в DLL из исполняемых модулей (EXE), отличается относительной простотой реализации, и (что гораздо более важно) простотой использования в клиентском коде.

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

В этой статье рассказывается, как писать синтаксические анализаторы с помощью этой небольшой библиотеки на с++.

Обычно, текст на машинном языке состоит из предложений, те — из подпредложений, а те, в свою очередь, из подподпредложений, и так вплоть до символов.

Например, элемент xml состоит из открывающего тега, содержимого и закрывающего тега. —> Открывающий тег состоит из '<', имени тега, возможно пустого списка атрибутов и '>'. —> Закрывающий тег состоит из '</', имени тега и '>'. —> Атрибут состоит из имени, знаков '=', '"', строки символов и снова '"'. —> Содержимое в свою очередь тоже может содержать элементы. —> И т.д. Таким образом, после разбора получается синтаксическое дерево.

Такие языки удобно описывать формой Бэкуса-Наура (БНФ), где каждый нетерминал соответствует некоторому предложению языка. Когда мы пишем программы, мы обычно разбиваем их на функции и подфункции, и раз мы собрались писать синтаксический анализатор, пусть каждому нетерминалу БНФ соответствует одна функция нашего анализатора, и пусть каждая такая функция:

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

Например для БНФ вида expr ::= expr1 expr2 expr3 будем писать такую функцию: