C++ *

Вступление

Уже около двух лет я участвую в OpenSource проекте SourceAnalyzer, и вот появилась необходимость написать парсер для языка Python, который должен уметь строить граф вызовов (Call Graph) и граф зависимостей классов (Class Graph Dependency). Если точнее, граф строится с помощью других инструментов, а парсер должен лишь подготовить для этих инструментов данные.

Процесс работы над парсером был довольно занятным и мне бы хотелось поделиться с вами приобретенным опытом, а также поведать о некоторых подводных камнях, которые встретились на этапе разработки.

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

Продолжение вот этой статьи habrahabr.ru/post/131212, где я собирался показать, как «и ошибки удобно обрабатывать и exceptions при этом не использовать», да всё руки не доходили.

Итак, будем считать, что у нас ситуация, что «настоящие C++ exceptions» использовать нельзя — например, языком разработки является C или компилятор С++ для нашей платформы не поддерживает exceptions (или формально поддерживает, а реально этим пользоваться нельзя). Это, конечно, нетипично для desktop приложений, но вполне обычно для embedded разработки.

Представьте себе архитектуру типичного приложения:

Есть рабочий поток движка, выполняющий какую-то функциональность, допустим копирование файлов (архивирование, поиск простых чисел). В общем что-то длительное.
Данный поток должен периодически сообщать информацию о текущем копируемом файле, а также уметь обрабатывать ошибки, допустим ошибка нехватки места на диске.

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

Казалось бы, как можно допустить ошибку в такой простой ситуации?

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

Спустя ровно год активной разработки мы — все те, кто участвовал в разработке 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++, во многом определяющие его развитие. Доклады очень интересные, и я вынес для себя много нового. Дальше идёт обзор всех докладов и сессий вопросов и ответов.