C++ *

Как вы наверное знаете, мы уже достаточно давно работаем над 8й версией ReSharper — в процессе разработки мы улучшили навигацию, расширили поддержку XAML, добавили свой собственный механизм просмотра зависимостей между проектами, и добавили еще много нового и интересного функционала.

Но сейчас я хочу рассказать про нечто за гранью наших планов по 8-ке: уже несколько месяцев часть нашей команды работает над чем-то абсолютно новым, чего уже годы просили наши пользователи — поддержкой в ReSharper языка программирования C++.

Программисты допускают невероятное количество опечаток, простых логических ляпов и делают ошибки благодаря Copy-Paste. Приглашаю отпробовать их. Приятного аппетита.

Программисты часто думают, что ошибки, отнимающие больше всего времени очень сложные и коварные. А простые ошибки они не делают.

Зачем это нужно

Мы хотим общение с API сервером написать на C++, а дальше использовать написанную библиотеку во всех наших приложения под различными платформами. Конечно мы хотим, чтобы работало под android.

Libcurl — это библиотека интерфейса API для передачи, которую разработчики могут встроить в свои программы; cURL действует как автономная обёртка для библиотеки libcurl. libcurl используется, чтобы обеспечить возможность передачи файлов (адресуемых с помощью URL) многочисленным приложениям (как открытым, так и коммерческим). (wikipedia)

Для iOS можно скачать готовый пример подключения и использования cURL с сайта разработчика. И с iOS всё просто.

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

И вообще говоря под android заставить работать cURL оказалось немного сложнее чем хотелось бы.

Как-то раз я решил написать игру. Для себя и в своё удовольствие. Передо мной стоял выбор – использовать всё готовенькое ака Box2D или написать для неё физику самому. Второй вариант показался мне более интересным, и я принялся выискивать в просторах сети информацию, которая помогла бы мне написать всё необходимое. Выискал. Как результат получился очень гибкий(как для игры) и простой физический движок. Основой движка стал метод численного интегрирования Верле.

Вступление

Добрый вечер хабровчане. В данной статье хочу описать проблемы работы в многопоточной среде, с которыми я встретился и пути их решения. Более пяти лет я занимаюсь разработкой игровых проектов на С++ / Objective C++, в оснвоном под платформу iOS. 2 года назад решил попробовать себя в «нативной» разработке используя только Objective-C. Примерно в тоже время меня заинтересовала технология GCD от Apple (как раз после просмотра очередного WWDC). В первую очередь, в этой технологии меня привлекла гибкая возможность делегирования операций между потоками. Довольно распространненой задачей является загрузка каких-либо игровых ресурсов в низкоприоритетном потоке. Но довольно нетривиальной задачей является смена потока по окончанию операции загрузки на главный поток с целью дальнейшей загрузки в VRAM. Конечно можно было закрыть глаза на эту проблему и использовать Shared Context для графического контекста, но ростущий в то время во мне перфикционизм к собственному коду и решениям проектирования графических систем, не позволил поступить так. В общем было принято решение опробовать GCD на «пет» проекте, которым я как раз в то время занимался. И получилось довольно не плохо. Кроме задач решающих загрузку игровых ресурсов я стал использовать GCD там где это было уместно, ну или мне казалось, что это было уместно.

Прошло много времени и вот появились компиляторы полноценно поддерживающие C++11 стандарт. Так как работаю я в текущий момент в компании, занимающейся разработкой компьютерных игр, то особое требование ставится именно к разработке на С++. Большинству сотрудников чужд Objective-C. Да и сам я не питаю особой любви к этому языку (может быть только кроме его обьектной модели построенной по принципам языка Smalltalk).

Почитав спеки по 11 стандарту, проштудировав множество буржуинских блогов я решился написать свой велосипед схожий с Apple CGD. Конечно я не ставлю себе за цель обьять необьятное и ограничился лишь реализацией паттерна «Пул потоков» и возможностью выйти в любой момент из контекста второстепенного потока на контекст главного потока, и наоборот.

Для этого мне понадобились следующие новшевства С++11 — std::function, variadic templates и конечно работы с std::thread. (std::shared_ptr используется лишь для чувства собственного успокоения). Конечно еще одна цель, которую я поставил перед собой — это кроссплатформенность. И очень был разочарован, когда узнал, что компилятор от Microsoft, укомплектованый в VS 2012, не поддерживал variadic templates. Но, поштудировав немного stackoverflow, я увидел, что и эта проблема решается установкой допольнительного пакета «Visual C++ November 2012 CTP».

Мы отправили разработчикам TortoiseSVN на некоторое время бесплатный ключ для анализатора PVS-Studio. Пока они не успели им воспользоваться, я решил быстро скачать исходные коды TortoiseSVN и самостоятельно выполнить анализ. Цель понятна. Очередная небольшая статья для рекламы PVS-Studio.

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

Да, можно сослаться на большое количество низкоквалифицированного персонала, зарплата которого зависит от количества написанных строк кода или от умения долго смотреть на монитор, не моргая. Но такие сотрудники есть практически во всех отраслях. Строители имеют более низкую квалификацию, чем архитекторы, но это не мешает зданиям в большинстве своем быть пригодными для полноценного использования без дополнительных «заплаток».

На мой взгляд, основных причины здесь две. С первой ничего не поделать. Это время, или, как чаще говорят, постоянные изменения. При разработке программного продукта, даже если он соответствует всем требованиям заказчика, в дальнейшем потребуются доработки, часто неожиданные для исполнителя. Они практически неминуемы и не всегда вписываются в архитектуру системы. Со временем программный комплекс приходит в негодность. Но время разрушало вещи и крупнее – удивляться нечему.

Вторая причина гораздо более прозаична. Невнимание к мелочам. Особенно в начале проекта. И чем моложе команда, тем эффект катастрофичнее. Конечно, гораздо интереснее обсуждать перспективы использования мультиметодов [1], чем следить за тем, чтобы операторы отделялись пробелами. Да и к конечной функциональности подобные мелочи особого отношения не имеют. Не лучше ли сначала сконцентрироваться на первоочередных требованиях, ведь время проекта и бюджет ограничены…

Введение

Данная статья является продолжением цикла статей: Использование паттерна синглтон [1], Синглтон и время жизни объекта [2], Обращение зависимостей и порождающие шаблоны проектирования [3], Реализация синглтона в многопоточном приложении [4]. Сейчас я хотел бы поговорить о многопоточности. Эта тема настолько объемна и многогранна, что охватить ее всю не представляется возможным. Здесь я заострю внимание на некоторых практичных вещах, которые позволят вообще не думать о многопоточности, ну или думать о ней в крайне минимальном объеме. Если говорить точнее, то думать о ней только на этапе проектирования, но не реализации. Т.е. будут рассмотрены вопросы о том, как сделать так, чтобы автоматически вызывались правильные конструкции без головной боли. Такой подход, в свою очередь, позволяет значительно уменьшить проблемы, вызванные состояниями гонок (race condition, см. Состояние гонки [5]) и взаимными блокировками (deadlock, см. Взаимная блокировка [6]). Этот факт уже сам по себе представляет немалую ценность. Также будет рассмотрен подход, который позволяет иметь доступ к объекту из нескольких потоков одновременно без использования каких-либо блокировок и атомарных операций!

Многие эксперты С++ агитируют использовать интеллектуальные указатели, утверждая, что из современного С++, явное использование new должно вообще исчезнуть (ну, по крайней мере, когда в С++14 пофиксят отсутствие std::make_unique). Все динамические выделения памяти должны быть инкапсулированы или в стандартную библиотеку, или контейнеры типа std::vector, или интеллектуальные указатели.

Смарт-указатели стандартной библиотеки могут быть настроены так, чтобы они сами занимались освобождением занимаемой ими памяти. Эта возможность и заложена в основу ответа на вопрос, поставленного в заголовке статьи.

Объект является пересекающим границу динамической библиотеки, если он инициализируется в одном блоке, а используется в другом. Это происходит, когда, например, в dll инициализируется объект и возвращается указатель на него.

Предположим, одна библиотека (или исполнимый модуль) связывается с другой библиотекой, используя фабрику для динамической инициализации объекта и получения указателя на него. Блок, который использует этот указатель, может удалить указатель для освобождения области памяти, на которую он указывает. Если библиотека, которая выделяет память и блок, работающий с указателем, используют различные версии динамического выделения памяти ОС (CRT в Windows), то возникнет ошибка. Пример этой проблемы (в случае с Windows):

Node.js развивается, и, вполне уже можно экспериментировать с написанием графических приложений либо каких-то консольных утилит и сервисов. В процессе разработки может возникнуть необходимость использовать какие-то системные вызовы, например, к WMI (к WMI нельзя обратиться напрямую из node.js, и запросы WMI могут быть долгими, что заблокирует event loop, и, например, если связь у Вас через веб-сокеты, связь может оборваться). Тут существует несколько вариантов. Можно воспользоваться модулем (например, node-ffi) и попробовать поиграться с ним. Есть ещё способ, точнее, костыль. В Windows существует так называемый WScript (Windows Script Host) — это компонент Windows, предназначенный для запуска, например, JScript, VBScript. JScript может обращаться к WMI напрямую, так что мы имеем возможность запустить child_process, в котором будет работать JScript, и получать от него данные (формировать, например, JSON и отправлять его строкой), но это костыль, бессмысленный и беспощадный. И третий способ — это нативный модуль. Я не буду описывать, как получить данные от WMI, а опишу что-нибудь менее ёмкое. Кому интересно — прошу под кат.

Начав свой путь, мы не останавливаемся и продолжаем изучать темные стороны документации. Где-то они могут быть характерны для всего Qt, а где-то присущи только Graphics View. Но так или иначе встреча с ними не всегда проходит безболезненно.

Просто хотел Вас предупредить: С++14 не будет обратно совместим с C++11 в одном аспекте constexpr функций.

В С++11, если Вы определите constexpr функцию-член, то она неявно получит спецификатор const:

// C++11
struct NonNegative
{
  int i;
  constexpr int const& get() /*const*/ { return i; }
  int& get() { return i; }
};

Первое объявление функции get получит спецификатор const, даже если мы не укажем это явно. Следовательно, эти две функции являются перегруженными: const и не-const версии.

В С++14 это будет уже не так: оба объявления будут определять одиннаковую, не-const версию функции-члена с различающимися возвращаемыми значениями — это приведет к ошибке компиляции. Если Вы уже начали использовать constexpr функции и надеетесь на неявный спецификатор const, то я советую Вам начать добавлять его явно, чтобы Ваш код продолжал компилироваться, если Вы решите перейти на компиляторы С++14.

В качестве языка программирования здесь используется C++, но перенести этот код на другой язык программирования будет не так уж сложно.
Код написанный ниже далёк от идеала, но новичкам он может пригодится.
Не так давно у меня была проблема с генерацией карты высот для ландшафта.

В последнее время появилось множество online IDE с возможностью компиляции и запуска в том числе и native-приложений. Естественно, возникает вопрос о безопасности таких сервисов. Скомпилированные программы запускаются в песочнице, а вот сама компиляция зачастую происходит в незащищенной среде.

GCC + GAS

GCC позволяет с помощью директивы asm вызывать GAS, у которого есть замечательная инструкция incbin. С ее помощью на этапе компиляции можно включить файл в качестве данных. Тогда exploit для С++ выглядит следующим образом:

#include <stdio.h>

extern "C"

asm(
     ".global _data\n"
     ".data\n"
     "_data:\n"
     ".incbin \"/etc/passwd\"\n"
     ".byte 0"
);

extern const char _data;
const char* data = &_data;

int main() {
    printf("%s", data);
}

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'ей.