C++ *

Забавный день, Хабрачеловек!

Спустя ровно год активной разработки мы — все те, кто участвовал в разработке qutIM, рады вам представить релизную версию 0.3 под кодовым именем Nolwe.
За прошедший год было исправлено огромнейшее количество ошибок, добавлены недостающие фичи и переработаны некоторые плагины.

Этот топик повествует об использовании Radix Tree на практическом примере. Radix Tree или дерево остатков — это структура данных, формируемая по принципу хранение значений в листовом узле. Промежуточные узлы представляют собой элемент конечного значения. Это может быть бит для чисел, символ для строк или цифра для номера, как в примере ниже. Приведенный алгоритм сжатия с использованием Radix Tree используется в реальной embeded системе, для хранения параметров телефонного файрвола.

Хочу поделиться небольшим опытом работы с технологией групповой передачи данных, или иначе UDP Multicast, и проблемой особенностью, которая возникает при написании кроссплатформенного кода.

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

Метод недопустимой операции:
Разделить кошку на ноль,
после чего она станет бесконечно большой,
так что её будет невозможно упустить.
[АбсурдопедиЯ]

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

Итак, имеем задачу последовательной перестановки байтов в каждом слове массива (big-endian <-> little-endian) и суммирования всех слов в одно (reduction). Оставим пока в стороне задачу распараллеливания, ибо ее решение близко к тривиальному, и для нас пока не представляет интереса.

Доброго времени суток!

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

Бегло просматривая новый стандарт C++11, решил углубить свое понимание в теме rvalue references. Все, в принципе, замечательно, но есть подводные камни, а именно: некоторая потеря обратной совместимости с С++03.

Добрый день!

Еще вчера я честно думал, что разобрался как работают rvalue references в C++11. Думал до тех пор, пока не наткнулся на грабли.

Итак, я предлагаю размять мозги и попробовать написать функцию move_if_rr. Такой себе тест на понимание: успех засчитывается за функцию, которая работает правильно при условии, что Вы ее ни разу не отлаживали. Детали задания под катом.

Сегодня ночью вышел долгожданный GCC 4.7, выпуск которого приурочен к 25-летию проекта.

Долгожданным этот выпуск является прежде всего для программистов C++, так как несет с собой обширную поддержку нового стандарта С++11.

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

Ниже я хочу рассказать о пользовательских литералах — весьма полезном средстве, хоть и не в повседневных целях.

Всем доброго времени суток!

Недавно при прототипировании одной из частей разрабатываемого нами продукта возникла одна интересная задача: нужно было проверить склейку Python и C++. Связано это было с тем, что основной код был написан на плюсах, и необходимо было подключить внешнюю библиотеку Websockets, написанную на Python (на тот момент не было соответствующей библиотеки на C++). Схема взаимодействия при такой задаче достаточно простая. Из C++ вызывается функция подключения к серверу (на python), в качестве параметра передается его адрес. Соответственно, при получении сообщния Python передавает его обратно в метод C++.

До появления gccxml, был только один способ извлечь мета-информацию из Си/С++ кода. Для начала, необходимо было написать парсер, способный справиться с грамматикой языка С++. Это не та задача, которую вы обычно решаете дома за выходные.

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

Для разбора XML данных, полученных от gccxml, пригодится библиотека pygccxml. Это не просто ридер формата gccxml — библиотека предоставляет интерфейсы для изучения собранных метаданных; в частности есть готовые функции, отвечающие на вопросы вроде «совместимы ли типы T₁ и T₂?» или «наследует ли класс C₁ от C₂?». Библиотека написана на языке Python.

Эта небольшая статья в первую очередь предназначена для начинающих C++ программистов, которые либо слышали об умных указателях, но боялись их применять, либо они устали следить за new-delete.

Итак, представьте ситуацию: у нас есть кроссплатформенный сервер который должен получать данные по UDP. Вооружившись Asio вы создаете сокет, создаете буфер для принимаемых данных и начинаете слушать.

udp::socket receiver(ios, udp::endpoint(udp::v4(), port));
char read_buf[buf_len];
udp::endpoint sender_point;
receiver.receive_from(buffer(read_buf, sizeof(read_buf)), sender_point);

Что произойдет если в полученной дейтаграмме будет больше данных, чем вы выделили для буфера?

C++ слишком сложен?

Иногда почитываю хабр. И когда заметил пост http://habrahabr.ru/blogs/cpp/111403/, честно признаюсь, он задел меня за живое. Я использую язык C++ как основной много лет. Еще раз честно признаюсь: так и не знаю его полностью. Вряд-ли я смог бы сотворить что-либо подобное Boost::MPL, Boost::Spirit или Boost::Xpressive. Но повод ли это говорить о сложности языка? Да, стандарт языка C++ раза в два больше стандарта C#. Но посмотрите на содержание: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf и http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf. Разница заметна? Подсказываю, что для полноты использования языку C# не хватает очень многого из того, что является частью .NET. Вообще-то C++ тоже можно использовать без STL и даже без run-time части вообще. В молодости даже ОС начал писать, где загрузчик был на ассемблере, а все остальное на C++. То, что STL включена в стандарт и подробно описана, в отличии от .NET, является большим плюсом языку C++ и большим минусом C#. Именно поэтому, хотя я и посматриваю с небольшой долей зависти на новости о C#, но применять не планирую. Моя основная ОС – Linux и проект Mono не кажется мне решением проблемы с .NET.

Любой язык программирования сложен до тех пор, пока не найдешь время разобраться с ним. Или кто-то считает, что есть идеальные полноценные языки с полным описанием на 10 страничек и абсолютно без подводных камней? Я о таких не слышал. Зато много лет подряд слышу о том, что C++ уже мертв или медленно умирает, советы обходить его труп стороной. Всяческие рейтинги показывают, что на первом месте у нас то-ли Java, то-ли C#. Но вы присмотритесь к содержимому жесткого диска, где там большая часть ПО на Java или C#? Да сами Java и C# написаны на C++ (ну по крайней мере так было раньше).

Недавно завершилась конференция GoingNative’2012, организованная компанией Microsoft. Она проходила 2 и 3 февраля в Редмонде, и главной темой был C++11. Мне показалось, что это замечательное событие недостаточно полно освящено, и захотел исправить ситуацию.

«C++11 feels like a new language» Bjarne Stroustrup
«We’re all learning C++11» Herb Sutter
«We broke every single book on the planet, and we broke every single programmer on the planet» Herb Sutter

Герб Саттер во вступительном слове посвятил конференцию Деннису Ритчи, создателю языка C, и ключевому разработчику операционной системы UNIX.

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

В продолжение темы расширения функциональности готовых программ хотелось бы рассказать об ещё одном способе изменения логики работы уже скомпилированной программы, который не требует делать изменений в самом исполняемом файле. Это может пригодиться при распространении вашей модификации в США, где прямое вмешательство в исполняемый файл строго осуждается. Речь пойдёт о создании крошечной прокси-dll (всего ≈4 килобайта) для подмены используемой приложением библиотеки на примере ddraw.dll.

Тема отображения текущей раскладки беспокоила хабрасообщество уже не раз. Я опробовал множество существующих решений, но по разным причинам они меня не устроили. Чтобы подобрать для себя наиболее удобный вариант отображения текущей раскладки, я написал небольшое приложение на C++, которое при нажатии на левый Shift отображает язык в системном курсоре редактирования текста. Менее 100 строк кода и около 4 килобайт в скомпилированном виде — на основе этого вы можете достаточно просто реализовать свой взгляд на то, как на самом деле должна выглядеть индикация текущей раскладки.

Речь пойдет о стандартной библиотеке шаблонов STL. Будут рассмотрены существующие типы итераторов и их классификация, а также будут предложены несколько новых обёрток над итераторами. Которые позволят в некоторых случаях избежать лямбда-выражений, которых до С++11 как бы и нет.

Данный текст является обзором библиотеки математических вычислений для OpenGL – GLM. Создан обзор дабы по мнению автора залатать брешь в информационном вакууме и направить умы несознательные по пути верному.

Математический функции в OpenGL никогда не были на высоте, а с приходом новых стандартов OpenGL 3(4,ES), математики не стало вообще. И что самое обидное, нам ничего не дали в замен. Как же теперь крутить кубы и торосы, в условиях безграничной свободы шейдерного программирования?