C++ *

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

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

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

Оптимизировал я однажды критический участок кода, и был там 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.

Вышла новая версия знаменитой уже карты мира С++ от Алёны Сагалаевой и Джима. На карте отражены последние изменения, пришедшие к нам со стандартом С++11 — обратите внимание на хамелеона auto, Пресловутые Врата Анонимности, руины крепости std::auto_ptr и новые боевые юниты STL. Наслаждайтесь!



Оригинальный размер (18 Мб)
Зеркало
P.S. Сама Алёна не против использования карты в любых целях, правда, часть исходных картинок взята из интернета, а значит за полную чистоту копирайта никто вам поручаться не будет.

 

Service Control Manager (SCM)

SCM — это сервер, реализованный в Windows, для удаленного управления сервисами (вызовом процедур).

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

Постановка задачи

Написать буферный класс позволяющий упростить работу SCM в C#.
Сам внешний вид этого класса можно обознать очень просто:

public ref class ServiceControlManager : public IDisposable
{
public:
	ServiceControlManager(void);
	void AddDriver(String^ ServiceName, String^ BinaryPathName);
	void DeleteDriver(String^ ServiceName);
	void StartDriver(String^ ServiceName);
	void StopDriver(String^ ServiceName);
protected:
	~ServiceControlManager();
	!ServiceControlManager();
private:
	SC_HANDLE SCMHandle;
};

Конструктор, деструктор, финализатор, основные методы, из атрибутов только HANDLE объекта SCM. Из этого следует, что экземпляр объекта этого класса будет содержать в себе созданный объект SCM, а методы упрощают с ним работу. Класс является буферным, и поскольку он реализован в C++/cli он будет автоматически масштабируем для работы в среде .NET, соответственно и в C#.