Приветствую хабросообщество!
Наверно каждый кто профессионально разрабатывает ПО или просто увлекается программированием, рано или поздно приходил к необходимости создавать пользовательский интерфейс для своей программы. И если не рассматривать нативные для платформ окружения и языки такие как C# для Windows или Objective-C для Mac OS X которые изначально содержат средства для визуализации интерфейса, то выбор оказывается не очень богатым, особенно если мы не горим желанием платить деньги за средства разработки GUI или желаем добиться кроссплатформенности.
В своем первом посте на Хабре я бы хотел рассказать о таком фреймворке как JUCE. Поиск по Хабру выдал всего 2 статьи где данный фреймворк только упоминается, но ни какой детальной информации не приводится. Думаю что тем кто только начинает осваивать кроссплатформенные GUI приложения на C++ будет интересно узнать об альтернативе таким монстрам как Qt или таким старичкам как GTK+

Не так давно в boost-1.53 появился целый новый раздел — lockfree реализующий неблокирующие очереди и стек.
Я последние несколько лет работал с так называемыми неблокируюшими алгоритмами (lock-free data structures), мы их сами писали, сами тестировали, сами использовали и втайне ими гордились. Естественно, у нас немедленно встал вопрос, переходить ли с самодельных библиотек на boost, и если переходить, то когда?
Вот тогда у меня и возникла в первый раз идея применить к boost::lockfree кое-какие из методик которыми мы испытывали собственный код. К счастью, сам алгоритм нам тестировать не придется и можно сосредоточиться на измерении производительности.
Я постараюсь сделать статью интересной для всех. Тем кто еще не сталкивался с подобными задачами будет полезно посмотреть на то что такие алгоритмы способны, а главное, где и как их стоит или не стоит использовать. Для тех кто имеет опыт разработки неблокирующих очередей возможно будет интересно сравнить данные количественных измерений. Я сам по крайней мере таких публикаций еще не видел.

Для начала расскажу немного о себе. Я студент 4 курса МАИ специальности «ЭВМ, комплексы, системы и сети», а также начинающий программист на С++/Qt. Очень давно я хотел научиться веб-разработке, но до изучения всех необходимых языков и технологий руки никак не доходили. Недавно на Хабре появилась статья о создании веб-приложений с помощью C++ библиотеки Wt, и я решил поближе познакомиться с этой библиотекой.

Вдохновившись постом про вычисление pi, решил вычислить подобным образом число e. По пути получилась функция натурального логарифма.

Source SDK — набор утилит для создания модификаций на движке Source, разработанный корпорацией Valve. Исходные коды проекта были скачаны и проверены ещё в конце 2013 года. На новогодних праздниках я планировал написать статью о результатах проверок. Но лень победила творчество, и я приступил к написанию статьи только когда вернулся на работу. Впрочем, я думаю, вряд ли за этот период что-то успело измениться в исходных кодах. Предлагаю вашему вниманию ознакомиться с подозрительными местами, которые я нашёл с помощью анализатора кода PVS-Studio.

Вас приветствуют разработчики статического анализатора кода PVS-Studio. Мы разработали новый программный продукт — CppCat. Разработан он так. Мы представили, что у нас нет PVS-Studio, но есть опыт в разработке инструментов статического анализа для языка Си/Си++. И мы с чистой головой разработали новый статический анализатор таким, каким бы хотели его видеть. Мы сделали инструмент простым и лёгким. И что многих обрадует, он будет стоить $250 за одну инсталляцию.

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

Речь пойдет об ещё одной технике безопасного освобождения памяти для lock-free контейнеров — RCU. Эта техника существенно отличается от рассмотренных ранее алгоритмов a la Hazard Pointer.

Read – Copy Update (RCU) – техника синхронизации, предназначенная для «почти read-only», то есть редко изменяемых, структур данных. Типичными примерами такой структуры являются map и set – в них большинство операций является поиском, то есть чтением данных. Считается, что для типичного map'а более 90% вызываемых операций — это поиск по ключу, поэтому важно, чтобы операция поиска была наиболее быстрой; синхронизация поиска в принципе не нужна — читатели при отсутствии писателей могут работать параллельно. RCU обеспечивает наименьшие накладные расходы как раз для read-операций.

Откуда взялось название Read – Copy Update? Первоначально идея была очень проста: есть некоторая редко изменяемая структура данных. Если нам требуется изменить её, то мы делаем её копию и производим изменение — добавление или удаление данных — именно в копии. При этом параллельные читатели работают с первоначальной, не измененной структурой. В некоторый безопасный момент времени, когда нет читателей, мы можем подменить структуру данных на измененную копию. В результате все последующие читатели будут видеть изменения, произведенные писателем.

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

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

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

Привет, Хабр!
Сегодня я расскажу о такой интересной штуке как операционная система реального времени(ОСРВ). Не уверен, что это будет интересно для бывалых программистов, но, думаю, новичкам понравится.

Что такое ОСРВ?

Если мы посмотрим в Википедию, то увидим аж 4 определения.
Если же говорить вкратце — то ОСРВ — это операционная система, реагирующая на внешние события в определенный промежуток времени. Отсюда мы и можем понять основное предназначение ОСРВ — приборы, в которых необходима быстрая реакция на события (однако ни в коем случае не путайте работу ОСРВ с прерываниями).

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

В чем подвох?

На первый взгляд задача кажется тривиальной: скачиваем keil, создаем проект… Но все не так просто. Все среды программирования(keil, IAR, Atolic) поддерживают максимум ARM9.У нас же ARM11. Это связано с негласным правилом, что на голом железе пишут до ARM9, а после на Линуксе. Но все-таки есть одна лазейка: arm-none-eabi-gcc поддерживает любой ARM.
Вторая проблема заключается в том, что под данный процессор(BCM2835) нет никаких конфигурационных файлов, header'ов и т.д. Здесь нам на помощь придет загрузчик Raspberry Pi. И ничего, что он пропритетарный. Он выполняет две функции: инициализирует процессор и его периферию, а также передает управление ядру kernel.img. Мы просто замаскируем свою программу под ядро и загрузчик её запустит.

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

Есть такой чудный сайт выходного дня, как codeeval.com. На котором неплохая коллекция небольших алгоритмических задачек и удобная система проверки, позволяющая занимательно провести вечер скучающим программистам. Как правило в качестве входных данных используется файл с тестовыми данными. Однако мне попалась одна задача, в которой тестовые данные известны заранее. Загружать программу, которая будет просто выводить правильный ответ не спортивно, а вот вычислять его на этапе компиляции — самое то.

Что из этого получилось можно посмотреть внутри.

Считанные часы остались до Нового 2014-го года, в котором в числе прочего всем нам был обещан новый стандарт C++14. Однако он будет не большим самостоятельным обновлением, а лишь доработкой C++11, багфиксом, который придаст текущей версии языка завершенный вид. На этом фоне Уильям Вонг (англ. William Wong) от ресурса electronicdesign.com взял интервью у Бьерна Страуструпа (дат. Bjarne Stroustrup), создателя C++. Беседа затронула несколько тем: от истории разработки C++ и особенностей стандарта C++11 до проблемы обучения этому языку программирования.

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

Исторически так сложилось, что руководство желает, чтобы задача была выполнена быстро. Для этого программисты сохраняют красоту и чистоту кода. Этот пост появился как напоминание о редкоиспользуемых нововведениях в C++11 – смарт-поинтерах, позволяющих указывать функтор для освобождения ресурсов.
Для примера возьмем файловый поток FILE из stdio.h, который любят за простоту и скорость, попробуем добавить ему красоту и базовую гарантию при исключениях:

unique_ptr<FILE, decltype(&fclose)> my_file(fopen("test.txt", "w"), &fclose);
if(my_file)
  fwrite("test", 4, 1, my_file.get());

В результате код зависит только STL и требует небольшой модификации обращений к файлу, пишется быстро, выглядит современно. Вот так получился RAII в чистом виде.

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

Проведено сравнение производительности ядер HTTP-серверов, построенных с использованием семи C/C++ библиотек, а также (в познавательных целях) — других готовых решений в этой области (nginx и node.js).

HTTP-сервер — это сложный и интересный механизм. Есть мнение, что плох программист, не написавший свой компилятор, я бы заменил «компилятор» на «HTTP-сервер»: это и парсер, и работа с сетью, и асинхронность с многопоточностью и много чего еще....

Тесты по всем возможным параметрам (отдача статики, динамики, всевозможные модули шифрования, прокси и т.п.) — задача не одного месяца кропотливой работы, поэтому задача упрощена: будем сравнивать производительность ядер. Ядро HTTP-сервера (как и любого сетевого приложения) — это диспетчер событий сокетов и некий первичный механизм их обработки (реализованный в виде пула потоков, процессов и т.п.). Сюда же можно отнести парсер HTTP-пакетов и генератор ответов. На первый взгляд, все должно свестись к тестированию возможностей того или иного системного механизма обработки асинхронных событий (select, epoll и т.п.), их мета-обёрток (libev, boost.asio и др.) и ядра ОС, однако конкретная реализация в виде готового решения дает существенную разницу в производительности.

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

Хотите получить представление о том, как устроен boost::function, boost::any “под капотом”? Узнать или освежить в памяти, что скрывается за непонятной фразой “стирание типа”? В этой статье я постараюсь кратко изложить мотивацию, стоящую за этой идиомой и ключевые элементы реализации.

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

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

Что вас ждёт под катом:

• Избегаем вызовов макросов вместо функций, на примере max/min.
• Вызываем оптимальную функцию, на примере std::swap и её специализации в разных пространствах имен.
• Ускоряем вставку в std::vector.
• Деструкторы в C++11.

Эта статья является перевод статьи OpenGL in Qt 5.1 — Part 1 и Part 2

Часть 1

---

Эта статья является первой в серии. Она покажет, как использовать OpenGL в Qt 5. В этой статье будет краткий экскурс в историю поддержки OpenGL в Qt. Затем мы перейдем к описанию первой части новых возможностей, которые вошли в Qt 5.1. Последующие статьи будут содержать описание большего количества возможностей, а так же будут приведены несколько простых примеров того, насколько легко можно использовать Qt для работы с OpenGL.

Новый стандарт языка принят относительно давно и сейчас уже, наверное, нет программиста, который не слышал о новых ключевых словах auto и decltype. Но как почти с любым аспектом С++, использование этих новых инструментов не обходится без нюансов. Некоторые из них я постараюсь осветить в этой статье.