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), математики не стало вообще. И что самое обидное, нам ничего не дали в замен. Как же теперь крутить кубы и торосы, в условиях безграничной свободы шейдерного программирования?

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

C/C++ позволяют выполнить проверки константных выражений ещё на этапе компиляции программы. Это дешёвый способ избежать проблем при модификации кода в будущем.
Я рассмотрю работу с:

• перечислениями (enum),
• массивами (их синхронизацию с enum),
• switch-конструкциями,
• а так же работу с классами, содержащими разнородные данные.

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

Мой опыт работы включает в себя несколько лет разработки под разные встроенные системы, где производительность постоянно приходится учитывать при написании кода (системы реального времени, обрабатывающие большой объём информации — скорости процессора и памяти там никогда не бывало «много»). Соответственно, в этой среде программисты обычно достаточно хорошо представляют себе, какие накладные расходы несёт (или не несёт) та или иная возможность, предоставляемая языком С++. К примеру,

Здравствуйте!

Оптимизировал я однажды критический участок кода, и был там boost::shared_ptr… И понял я: не верю я библиотекам, хоть и пишут их дядьки умные.

Детали под катом.

Просматривая материалы конференции GoingNative 2012 (которую всем программистам на С++ очень советую посмотреть), я обратил внимание на один пример кода:

#include <iostream>
struct  S { int  n; };
struct  X { X(int) {} };
void f(void*) {
    std::cerr << "Pointer!\n";
}
void f(X) {
    std::cerr << "X! \n";
}
int  main() {
    f(S().n);
}

Сможете ли вы, не подглядывая в ответ, сказать, что напечатает эта программа и самое главное, почему?

Под катом — предположение разработчика Clang из Google о том, почему этот код работает так, как он работает. Еще раз, кто не уловил: разработчик компилятора С++ из Google не знает этого точно, у него всего-лишь есть предположение.

Для кого эта статья

Вряд ли опытные C++ разработчики найдут что-нибудь новое и интересное в этой статье. Максимум банальную команду
gcc -c -x c++ -I ./ */*/*/*/*.h
которую они и так знают.
А вот если Вы — разработчик начинающий, или только в первый раз строите документацию по своему проекту, или пробовали это однажды, но увидев тот бред, что сгенерировал doxygen, удалили его и забыли как страшный сон, добро пожаловать под кат, скорее всего Вы найдете дальше парочку полезных мыслей.

Вступление

В данной статье рассмотрен тест производительности заполнения (push_back) контейнеров объектами, содержащими разные типы указателей на разные типы данных. Тест комплексный, сочетающий в себе типичные задачи создания указателя на объект, копирование объекта, заполнение контейнера, освобождение выделенной под объект памяти средствами умного указателя и стандартным оператором delete. Будут протестированы три контейнера стандартной библиотеки шаблонов – vector, list, deque, три вида указателей – std::shared_ptr, std::auto_ptr и простой указатель. В качестве испытуемых типов данных (на которые будут создаваться указатели) использованы long, std::string, char, произвольный класс.

Описание теста

Исходный код написан в среде MS Visual Studio 2010, и требует от компилятора поддержку лямбда функций.
Пусть некоторый класс содержит описание указателя T на тип данных Type.

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

В данной статье речь пойдет о том, как можно реализовать размещение элементов библиотеки по файлам. Также будут затронуты вопросы подключения элементов библиотеки в пользовательском коде, и, конечно же, как «рабочие» пространства имен могут помочь в реализации библиотеки.

Мне очень хочется показать, что в многопоточности С++ «очень быстро» не исключает «очень безопасно». А значит можно писать эффективные и стабильные программы со сколь угодно большим количеством потоков и при этом избегать траты кучи времени на отладку многопоточности. Если Вам интересно, как мне удаётся не выстрелить себе в ногу, и чем я за это плачу, добро пожаловать

Profile-guided optimization (далее PGO) — техника оптимизации программы компилятором, нацеленная на увеличение производительности выполнения программы. В отличии от традиционных способов оптимизации анализирующих исключительно исходные коды, PGO использует результаты измерений тестовых запусков оптимизируемой программы для генерации оптимального кода.

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