C++ *

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

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

Некоторые трудности при написании кода библиотеки, в большей степени касающиеся «самодокументирования», можно решить с помощью «рабочих» пространств имен.

Для начала, опишем эти трудности и представим обычные способы решения.

Предположим, что библиотека реализует некоторую сущность some_class, которую она предоставляет пользователю библиотеки. Определение some_class зависит от другой сущности библиотеки detail_class, которая является частью реализации и пользователю не предоставляется. Библиотека поставляется только в виде заголовочных файлов.

Библиотека DynLib предоставляет удобные средства для разработчиков, использующих межмодульное взаимодействие (EXE<->DLL, DLL<->DLL) в своих проектах, и значительно сокращает время и количество кода.
DynLib стала неотъемлемым инструментом разработки. Под катом делимся результатами.

Вдохновившись статьёй Привет из свободного от libc мира, я так же решил проделать нечто подобное. Чтобы не заниматься этим бесцельно, я решил поставить перед собой следующую задачу. Сделать программу, выводящую какую-нибудь простую строку, вроде «ELF, hello!». Разобраться с тем, как именно она будет представлена в исполняемом файле. Ну и попутно, постараться уложиться в 100 байт.

В первой части статьи, переведенной уважаемым skb7, было рассмотрено идиому Pimpl (pointer to implementation, указатель на реализацию), ее назначение и преимущества. Во второй части будет рассмотрено проблемы, возникающие при использовании этой идиомы, а также предложены некоторые варианты их решения.

 

Я как-то никогда не задумывался над тем, что лучше использовать BOOL или BOOLEAN? Конечно же, BOOL — это и короче и во всех учебниках по Windows встречается именно BOOL. Как бы не так! Буквально вчера я битый час занимался поиском ошибки там, где ее не должно было быть.

Оказалось, что единственно истинный тип, впрямую связанный с типом bool, который определен стандартами языка С++, это именно BOOLEAN. А BOOL это не что иное, как «typedef int BOOL;» и находится в windows.h (точнее в WinDef.h, но это неважно)

Рассмотрим подробнее исходный код функции, сравнивающий два числа:

#include <stdio.h>
#include <windows.h>

bool CompareInt(int i1, int i2)
{
    if (i1==i2)
        return true; //UPD1: было TRUE
    else
        return false; //UPD1: было FALSE
}

typedef BOOL (*CallBack)(int, int);

void main(void)
{
    CallBack IsEqual = (CallBack)CompareInt;

    if ( !IsEqual(0x1234, 0x5678) )
        printf("Not equals");
    else
        printf("Equals");
}

После компилирования Visual Studio и запуска, имеем: Equals

Тогда поменяем BOOL на BOOLEAN:

typedef BOOLEAN (*CallBack)(int, int);

Компилируем, запускаем, получаем: Not equals (что и должно было получиться с самого начала)

Вывод: никогда не пользуйтесь BOOL, только BOOLEAN.

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

Цель этой статьи — заставить всех, особенно программистов на Си, сказать «я не знаю Си».
Хочется показать, что тёмные углы в Си значительно ближе, чем кажется и даже тривиальные строки кода несут в себе undefined behavior.