C++ *

Здравствуйте, уважемые хабражители!
Недавно, читая хабр, я увидел статью об Android NDK и OpenAL. А в комментариях был задан вопрос о OpenSL ES. Тогда у меня и родилась мысль написать статью об этой библиотеке. Я занимался этой темой, когда мне понадобилось добавить звуки и музыку в игру под Android, написанную на C++, под NDK. Статья не претендует на полноту, здесь будут лишь основы.

Содержание:

1. Краткое описание структур OpenSL ES
2. Инициализация механизма библиотеки и создание объекта для работы с динамиками
3. Проигрывание PCM(wav)
4. Проигрывание MP3, OGG
5. Заключение

День добрый, уважаемые Хабраюзеры!

С недавних пор занимаюсь разработкой приложений под Android, в частности разработкой игр. Так сложилось, что для одного проекта пришлось работать с Android ndk. Все трудности и нюансы работы с native рассмотреть в принципе невозможно в рамках одной статьи, решил в данной статье небольшое введение в ndk написать.
А чтобы статья была интересна не только новичкам, покажу как работать с OpenAL и форматами WAV, OGG.

Недавно заинтересовался реализацией std::string в libstdc++. Не в связи с принятием нового стандарта, а чтобы разобраться. Благо требования к строковму типу почти не изменились.

Основным средством для анализа кода несомненно является метод пристального вглядывания, но чтобы сузить область вглядывывания и сделать процедуру более захватывающей можно реализовать для строки идиому «трассер» подсмотренную в «C++ Templates: The Complete Guide». Трассировка позволяет выявлять подозрительные интересные операции над строками.

Как известно, std::string это псевдоним для

std::basic_string<char>

и нам ничего не мешает определить

std::basic_string<X>

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

std::string a(«entrails»); 

выражение

std::cout << reinterpret_cast<char*>(*((void**)(&a))); 

выведет содержимое строки. Т.е. std::string — является, по сути, указателем на char.
Вобщем, эти и другие шокирующие поднобности под катом.

Я люблю desktop-приложения. Признаваться в этом нынче, похоже, стыднее, чем в связях с иностранной разведкой, но это так. Нет, это не значит, что я не люблю интернет-технологии. Более того, некоторые я не только уважаю, а даже более-менее знаю. Но, тем не менее, я скучаю по тем временам, когда программа писалась на одном компьютере, потом компилировалась и запускалась на других, разных компьютерах. Тогда везде (почти) была одна система — Windows с одной и той же API, почти не было проблем совместимости на уровне приложений, никто не материл разработчиков браузеров — все берегли нервы на разработчиков WinAPI, которые умудрялись создавать конфликты даже внутри нее одной. Но это я, конечно, иронизирую, а если серьезно — иногда и сейчас хочется написать просто desktop-приложение, да так, чтобы работало оно на всех популярных системах. Трудно? Если подумать и покопать, то не очень.

Еще я люблю языки высокого уровня с аккуратной архитектурой и строгой типизацией. Мои фавориты — Java и C#. Оба они предоставляют разработчику множество преимуществ по сравнению с C++, оба избавляют от ряда забот. Чем приходится платить? Тем, что таскаешь за собой тяжелую колоду, которая называется Oracle JVM, .NET или mono. Все три колоды весят сотни мегабайт и лицензию имеют такую, что каждый пользователь вынужден качать эту штуку сам, не путая при этом разрядность своего компьютера, а главное — программа на Java не может быть совместима со всеми версиями JVM разом, не так ли? И вот — мы приходим к тому, что просто скинуть программку другу (или миллиону друзей) и не заботиться о том, что она у него не запустится, не выходит. Приходится делать хитрые сетапы, вбивать костыли, и это я еще не упомянул .NET — однажды я видел у друга сразу 3 установленных версии, причем все три были нужны разным приложениям…

Стоп! А давайте напишем программу на Java, но так, чтобы она не требовала установки на машину какой-либо JVM, чтобы одним касанием собиралась под Windows, Linux и OS X и чтобы при этом занимала совсем чуть-чуть; так, чтобы никто даже не понял, что она написана, скажем, не на C. Невозможно? Совсем наоборот! (И нет, я имею в виду не gcj, который лишает Java всех ее прелестей. Рефлексия будет работать и даже сторонние jar вы сможете запускать).

Развлекаясь на досуге с OpenGL, решил научиться делать скриншоты средствами программы, а не системы. Довольно быстро нагуглил функцию glReadPixels, но вот с сохранением картинки вышла проблема. Вспомнил былые времена, когда полностью своим кодом сохранял в bmp, нашел функцию сохранения в tga, понял, что все эти варианты попахивают велосипедизмом и решил использовать широко распространенную библиотеку. Выбор пал на libpng.
Дальше пошли грабли.

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

По мере работы с базами данных, ознакомления с их плюсами и минусами, возникает момент, когда принимается решение миграции с одной СУБД в другую. В данном случае возникла задача переноса сервисов с MySQL на PostgreSQL. Вот небольшой перечень вкусностей, которые ждут от перехода на PostgreSQL, версии 9.2 (с более подробным списком возможностей можно ознакомится тут):

• наследование таблиц (есть ограничения, которые обещают в будущем исправить)
• диапазоны: int4range, numrange, daterange
• поддержка из коробки несколько языков для хранимых функций (PL/pgSQL, PL/Tcl, PL/Perl, PL/Python и голый C)
• оператор WITH, позволяющий делать рекурсивные запросы
• (планируется) материализованные представления (частично они доступны и сейчас — как IUD правила к представлению)
• (планируется) триггера на DDL операции

Как правило, существующие решения опираются на работу с уже готовым SQL дампом, который конвертируется в соответствии с синтаксисом целевой БД. Но в некоторых случаях (активно использующееся веб-приложение с большим объемом информации) такой вариант несет определенные временные затраты на создание SQL дампа из СУБД, его конвертации и загрузку получившегося дампа снова в СУБД. Поэтому оптимальней будет online-вариант (прямиком из СУБД в СУБД) конвертера, что может существенно уменьшить простой сервисов.

Доброго времени суток всем!
Недавно я выкладывал свою реализацию перехватчика(тут).
Получился он, чего уж греха таить, громоздким и коряво работающим. В 1 же из комментариев отписался уважаемый k_d и упомянул о своей обертке над mhook(MHook vs Zuma).
Конечно, меня заинтересовала альтернатива, работающая с перехватом не только __cdecl'а но и, более того, позволяющая ставить перехват практически в любом месте кода.
Решение понравилось и я решил переписать свою библиотеку, которую использую для различного рода перехватов, начисто, с использованием материала от k_d. Текущий вариант умеет перехватывать все, до чего дотянутся загребуще-экспериментальные ручки программиста и парсить аргументы из стека(по крайней мере, потенциально идея это все умеет. Наверное.)
Представляю Вашему вниманию то, что получилось.

На хабре уже было несколько статей про lock-free алгоритмы. Этот пост — это перевод статьи моего коллеги, которую мы планируем публиковать в нашем корпоративном блоге. По роду деятельности мы пишем огромное количество lock-free алгоритмов и структур данных, и этой статьей хочется показать, насколько это интересно и сложно одновременно.



Эта статья во многом похожа на эту статью, но в той статье рассматриваются не все проблемы, с которыми можно столкнуться, разрабатывая lock-free структуры данных, и уделяется очень мало внимания решению этих проблем. В этой статье хочется детально остановиться на некоторых решениях, которые мы используем в реальной реализации lock-free структур данных в нашем продукте, и больше внимания уделить оценке производительности.

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

Так сложилось, что работа с gSOAP на хабре описана очень слабо. Всего лишь один пост, если быть честным. Но там описано создание веб-сервиса, а как же быть с клиентскими приложениями? Не так давно передо мной встала задача организовать работу с удаленным сервером, использующим SOAP — и я решил написать небольшую статью об этом.
Т.к. предоставить wsdl-файлы, с которыми велась работа, я не могу (NDA и все такое), то я задался поиском сервисов, пригодных для тестирования. Интересными мне показались два:

http://www.webservicex.net/ValidateEmail.asmx?WSDL
http://www.webservicex.net/country.asmx?WSDL

От переводчика. Искал в интернете простой и легко применимый гайдлайн по написанию программ на C++. Мне понравился один из вариантов, и я решил его перевести и опубликовать. Если хабрапользователи хорошо встретят этот топик, могу перевести и другие связанные документы, а также гайдлайны по написанию кода от других компаний.

1 Введение

Настоящий документ содержит рекомендации по написанию программ на языке C++.

Рекомендации основаны на установившихся стандартах, собранных из различных источников, личного опыта, частных требований и потребностей определённых проектов, а также почерпнутых из источников (см. ниже).

Но для появления ещё одного списка рекомендаций, помимо указанных источников, есть несколько причин. Основная причина — их излишняя обобщённость, поскольку зачастую требуется задать частные правила (в особенности правила именования). Данный документ содержит комментарии, что делает его более удобным в использовании при проведении ревизий кода, чем другие уже существующие документы. К тому же, рекомендации по программированию обычно вперемешку содержат описания проблем стиля и технических проблем, что не совсем удобно. Этот документ не содержит каких-либо технических рекомендаций по C++, делая упор на вопросах стиля.

Эта небольшая заметка о том, как с приходом нового стандарта C++11 изменились требования стандартных контейнеров к своим элементам. В C++98 от элемента контейнера требовалось, по сути, наличие «разумных» конструктора копирования и оператора присваивания. Если, например, объект вашего класса владеет каким-либо ресурсом, копирование обычно становится невозможным (по крайней мере, без «глубокого» копирования ресурса). В качестве примера давайте рассмотрим следующий класс-обертку вокруг FILE*, написанную на C++98:

class File
{
    FILE* handle;
public:
    File(const char* filename) {
        if ( !(handle = fopen(filename, "r")) )
            throw std::runtime_error("blah blah blah");
    }
    ~File() { if (handle) fclose(handle); }
    // ...
private:
    File(const File&); //запретить копирование
    void operator=(const File&); //запретить присваивание
};

С выпуском GCC 4.8.0 разработчики набора компиляторов GNU Compiler Collection завершили переход на C++ в реализации GCC. Работа по переводу кодовой базы на C++ продолжалась c 2008 года, и теперь подошла к концу. Миграция на C++ означает, что теперь для сборки GCC из исходников обязательно требуется компилятор С++ 2003.

Ричард Столлман написал первый вариант GCC в 1985 году на непереносимом диалекте языка Паскаль. В 1987 году компилятор был переписан на языке Си, и в таком виде существовал до 2013 года.

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

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

Создание же иерархических моделей – более сложная задача. О ней и пойдет речь в этой статье.

Должно ли C++ сообщество придерживаться стандарта или отойти от него, чтобы создавать лучшие вещи с Boost?


Погодите, не та библиотека.

В марте 2011 года комитет ISO C++ утвердил финальную версию черновика новейшего стандарта C++. Языка, который официально был стандартизирован в августе того же года и стал известен как C++ 11. Теперь, по прошествии 2 лет, мы можем оглянуться назад и посмотреть на некоторые проблемы, затронувшие язык(аж с момента принятия первого международного стандарта в 1998 году) и сравнить его финальный вариант с популярной C++ библиотекой Boost.

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

В большинстве современных языков программисту уже не нужно заботиться о числах, с которыми процессор непосредственно манипулировать не может. Где-то, как в Python или Haskell, поддержка длинных целочисленных типов встроена прямо в ядро языка, где-то, как в Java или C#, реализована в виде отдельных классов. Но в стандартной библиотеке языка C++ длинные числа до сих пор не поддерживаются. Поэтому я решил написать её сам.

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

Недавно пристально посмотрел на С++ Variadic Templates и неожиданно для себя изобрел новый RAII Scoped Resource Manager.
Получилось кратко и эффектно.

Например, с C-style выделением памяти:

// Аллоцируем ресурс в блоке.
{
    ha::scoped_resource<void*, size_t> mem(::malloc, 1, ::free);

    ::memset(mem, 65, 1);
}

В конце февраля компания Intel официально объявила о выходе Intel System Studio – нового набора инструментов, адресованного разработчикам ПО для встраиваемых (embedded) систем и специализированных устройств: коммуникаторов, систем на чипе, автомобильных компьютеров, промышленных и медицинских устройств на базе х86.
Intel System Studio призвана помочь разработчикам в решении самых насущных их задач: обеспечения надежности ПО, его энергоэффективности и производительности.
Intel System Studio — это, фактически, знакомая всем серьезным разработчикам «настольных» приложений Intel Parallel Studio, но ориентированная именно на встраиваемые системы c Linux на борту.