C++ *

Awesomium — это библиотека, для интеграции браузера на базе Chromium в своё приложение. Вся прелесть Awesomium состоит в том, что его можно интегрировать в приложение практически любого типа (есть примеры интеграции в 3D игры на базе Unity3D), он обладает широким набором возможностей для разработчика и, честно говоря, с ним просто приятно работать.

Но, к сожалению, библиотека имеет довольно скромную документацию, практически отсутствуют примеры и комюнити (это касается разработки под C++, дотнетчикам повезло больше). Некоторые моменты мне приходилось по крупицам собирать с разных источников, а к другим понимание приходило после серии проб и ошибок.

И вот накопив некоторые знания я решил ими поделится. Уверен, что я не первый и не последний, кто будет проходить этот путь.

Освоение стандарта C++11 — процесс, который не может происходить скачкообразно. Изучение новой языковой конструкции требует не только заучивания синтаксиса, но и осмысления её предназначения и типичных способов применения. Важным подспорьем в обучении является похорошевшая STL, которая зачастую может открыть глаза на существование весьма интересных и нужных возможностей. А уж зная, что какая-то вещь возможна и реализована в STL, докопаться до способа реализации нетрудно.

Об одном из любопытных примеров, связанном с обновлённым и улучшенным классом pair, и пойдёт речь в статье.
Новый стандарт добавил такой, казалось бы, простой вещи, как pair, удобства и универсальности. Если раньше к типам, входящим в состав пары, предъявлялись достаточно суровые требования, то сейчас слепить в пару можно практически что угодно. В частности, снято ограничение на конструирование таких типов. Теперь необязательно применять операции копирования или даже перемещения, возможно создание пары непосредственным конструированием членов (такая операция называется emplace, «размещение», и в C++11 поддерживается контейнерами STL), с применением нетривиальных конструкторов.

Для тех, кто не следит пристально за развитием Clang/LLVM, сообщаю — состоялся релиз версии 3.3. LLVM продолжает развиваться семимильными шагами и новый релиз, как заявлено, первым поддерживает все фичи C++11, добавлена поддержка целой пачки новых таргетов и появилось несколько интересных тулов, основанных на инфраструктуре LLVM. Также продолжает развиваться оптимизатор — появился автовекторизатор, который работает по умолчанию на -O3, много сделано для улучшения уже существующих оптимизаций. Кому интересны подробности — добро пожаловать под кат.

Во многих языках программирования существует возможность объявлять объекты и переменные константными. И, соответственно, существуют рекомендации делать так, если Вы не собираетесь менять их значения. С приходом нового стандарта, в С++ появилась рекомендация возвращать объекты из функций по значению, потому что даже без RVO можно повысить производительность программы, за счет использования семантики перемещения. Что же будет, если использовать эти две рекомендации вместе: вернуть константный объект по значению? Попробуем разобраться далее.

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

Дело №1

Мы хотим изменять размер сцены и объектов в ней согласно размеру отображаемого окна. В доке сказано:«QGraphicsView takes ownership of the viewport widget». Ну что-ж, создадим простейшим проект и напишем следующее:

Читая посты на Хабре, наткнулся на такой вопрос. В комментариях были предложены решения, но ни одно не подходило автору в виду накладных расходов на вызовы функций. И тогда я задумался, а действительно почему бы не использовать обычный switch, рассчитывая из двух параметров один хеш, который и использовать в switch. Но глянув на пример автора вопроса внимательнее я понял, что такой вариант просто так не пройдет, так как надо отлавливать default вложенных switch'ей.

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

Сегодня в программе:

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения

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

Постановка задачи

Один из алгоритмов, который я реализовывал, имел интересные особенности при работе с памятью:

• Могло выделяться огромное количество, до десятков и сотен миллионов небольших объектов одного типа.
• Объекты представляли собой POD- типы.
  
  POD

  A Plain Old Data Structure in C++ is an aggregate class that contains only PODS as members, has no user-defined destructor, no user-defined copy assignment operator, and no nonstatic members of pointer-to-member type.
• Заранее было неизвестно какое количество объектов понадобится, могло так случится, что потребуется сотня, а может и сто миллионов.
• Объекты никогда не удаляются по одному, в какой-то момент они становятся не нужны все сразу.
• Алгоритм хорошо распараллеливается, по этому выделением объектов занимается одновременно несколько потоков, по количеству ядер процессора(ов).

Использование в таких условиях стандартного new – delete приводит к очень большим потерям времени на удаление объектов. Если без отладчика удаление происходило хотя бы за несколько секунд, то в присутствии отладчика освобождение памяти замедляется примерно в 100(!) раз, и отладка проекта становится просто невозможной. Кроме того из-за большого количества выделенных объектов достаточно ощутимым становился перерасход памяти на внутренние данные распределителя памяти.
Для решения задачи выделения огромного количества объектов одного типа, и их пакетного удаления, был сделан lock-free контейнер MassAllocator. Код компилируется Visual Studio 2012. Полный код проекта выложен на github.

Это простой пример использования библиотеки libqrencode от FUKUCHI Kentaro для генерации bmp-файла с QR-кодом для какого-то текста. В интернете полно ссылок на эту библиотеку, но ни одного примера ее использования. libqrencode поддерживает QR Code model 2, описанный в JIS (Japanese Industrial Standards) X0510:2004 или ISO/IEC 18004. В настоящее время не поддерживаются режимы ECI и FNC1 QR Code model 1.

Для более полного понимания этой статьи, рекомендуется прочитать ее первую часть, где основное внимание было уделено потокам и блокировкам, в ней объяснено много моментов (терминов, функций и т.д.), которые без пояснения будут использованы здесь.
В данной статье будут рассмотрены условные переменные…

Прочитал статьи про комбинаторную кодогенерацию на С++ в контексте линейного поиска в базе данных: Возможности оптимизации в языках C и C++ и Скорости разработки и исполнения не достижимые на С. Попробуем достигнуть скоростей разработки и исполнения на C?

После того, как я запустил компиляцию С++ кода из второй статьи, мне стало интересно — успею ли я написать аналог на С, который будет работать быстрее, пока код… компилируется? Не успел, код скомпилировался через 5 минут, а аналог на С писался все 15.

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

В первой части этой статьи основное внимание будет уделено потокам и блокировкам в С++11, условные переменные во всей своей красе будут подробно рассмотрены во второй части…

Существует мнение, что C++ имеет заметные накладные расходы по сравнению с C и поэтому он медленнее. Помимо этого, даже, существуют статьи показывающие преимущества в скорости языков с компиляцией налету (JIT — Just-in-time compilation), таких как Java и C#. Сравнить последние мы оставим тем, кто считает их быстрыми, но мы объясним почему это не так. А C и C++ мы сравним на примере задачи поиска данных.
Задача поиска данных часто встречается в: веб-сервисах, системах управления баз данных (СУБД), гео-поиске и аналитике.
Сначала для простоты объяснения поставим задачу поиска элементов полным проходом по массиву из 10 000 000 элементов (структур), содержащих 5 полей с диапазонами значений: amount_of_money(0-1000000), gender(0-1), age(0-100), code(0-1000000), height(0-300). А в следующих статьях добавим в решение индексный поиск.
Мы будем писать кроссплатформенно под MSVC11(MSVS2012) и GCC 4.7.2, и использовать в них частично реализованный стандарт C++11.

В продолжении статьи о кроссплатформенной и кросс-аппаратной оптимизации, на примере задачи поиска полным проходом по таблице из 5 полей и 10 000 000 строк, и неизбежности этой задачи даже при индексном поиске, я покажу как ускорить такой поиск в 3.5-5.3 раза с использованием C++ независимо от аппаратной платформы.
В предыдущей статье нам удалось ускорить поиск в 1.3 раза: GitHub.com
Мы не будем банально описывать конструкции языка, а покажем преимущества C++ при решении одного из этапов реальной задачи.
Мы по-прежнему пишем кроссплатформенно под MSVC11(MSVS2012) и GCC 4.7.2, и используем в них C и частично реализованный стандарт C++11.
Для упрощения понимания мы все ещё пишем без индексного поиска, но это решение в дальнейшем будет использоваться при индексном поиске.

На мой взгляд Qt Graphics Scene FrameWork — мощный инструмент, незаслуженно обделенный вниманием на Хабре. Я попытаюсь исправить ситуацию, посвятив ему цикл статей. И в этой, пилотной, статье покажу как можно программировать с помощью этого замечательного фреймворка на примере более-менее реальной задачи.

Перевод статьи Аллана О’Доннелла Learning C with GDB.

Исходя из особенностей таких высокоуровневых языков, как Ruby, Scheme или Haskell, изучение C может быть сложной задачей. В придачу к преодолению таких низкоуровневых особенностей C, как ручное управление памятью и указатели, вы еще должны обходиться без REPL. Как только Вы привыкнете к исследовательскому программированию в REPL, иметь дело с циклом написал-скомпилировал-запустил будет для Вас небольшим разочарованием.

Недавно мне пришло в голову, что я мог бы использовать GDB как псевдо-REPL для C. Я поэкспериментировал, используя GDB как инструмент для изучения языка, а не просто для отладки, и оказалось, что это очень весело.

Часть 1: Введение
Часть 2: Многопоточность
Часть 3: Рендеринг (Прим. пер. — в процессе перевода)
Часть 4: Doom classic — интеграция (Прим. пер. — в процессе перевода)

Движок для Doom III был написан в период с 2000 по 2004 год, в то время, когда большинство ПК были однопроцессорными. Хотя архитектура движка idTech4 разрабатывалась с учетом поддержки SMP, это закончилось тем, что поддержка многопоточности делалась в последнюю минуту (см. интревью с Джоном Кармаком).

Преподаватель из Стэнфордского университета Кит Шварц (Keith Schwarz) уже несколько лет пополняет свой архив интересного кода — образцы самых лучших алгоритмов и структур данных, когда-либо изобретённых человечеством (Шварц весьма амбициозно оценивает свою коллекцию).

Примеры на сайте преимущественно закодированы в C++, поскольку STL предоставляет прекрасную базу для выражения алгоритмов, работающих с различными типами данных. Структуры данных реализованы на Java.

Кит Шварц дает разрешение использовать свой код всем желающим без всяких ограничений.

30 мая вышел Qt Creator 2.8 beta, в котором реализовано много новых функций и исправлено большое количество ошибок.

Все нововведения и исправления в одном посте уместить будет весьма трудновато, поэтому попытаюсь выделить только несколько основных моментов.