C++ *

При написании библиотеки на 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#.

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

Одним из популярных и дешёвых средств реализации многопоточных вычислений на языке C++ является OpenMP.

Достоинства технологии очевидны: простота; малые, и легко отключаемые изменения в коде; поддержка от авторов самых популярных компиляторов:

• Visual C++
• GCC 4.2
• Intel C++ Compiler

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

Проходит пара лет, вы успешно мигрируете на Visual Studio 2010,… и обнаруживаете себя сидящим в луже. Если вчера обработка большого массива данных на машинах с многоядерными процессорами проходила за считанные секунды, то сегодня наличие любого фонового приложения, занимающего собственными вычислениями одно или несколько ядер, практически вешает приложение.

Почему так происходит, и как с этим бороться?

В посте речь пойдет о моем опыте встраивания XML-RPC интерфейса в утилиту, написанную на C. Интерфейс должен предоставлять доступ к статитстике и результатам работы утилиты. Одно из требований к интерфейсу — поддержка ответов в формате gzip, в целях экономии трафика. Мне очень хотелось обойтись малой кровью и вот что из этого получилось.

Доброго времени суток, уважаемое Хабрасообщество.
Недавно приходилось наблюдать дискуссию о каррировании и частичном применении. Суть этой полемики состояла в том, что лучше, для практических целей, иметь в языке программирования: встроенное частичное применение (например, как в Nemerle) или встроенное каррирование (как, например, в Haskell).

Данная cтатья вводная, рассчитана на знакомство с Qt+OpenGL для новичков, которые планируют изучать Qt (как кросс-платформенный инструментарий разработки ПО на языке программирования C++) + OpenGL (как графическую библиотеку).

Что потребуется новичку:
1) Qt Creator (имеет хорошую встроенную документацию и подсказки во время набора кода). Скчаать
2) doc.qt.nokia.com — официальная документация на английском языке
3) doc.crossplatform.ru — документация на русском языке
4) Обязательно прочесть про Qt и OpenGL
5) Отличная статья для начала изучения

Что мы будем делать
Поскольку данная статья посвящена конкретно основам, в нашей задаче будет следующее:
1) Разобрать как создается приложение
2) Как рисовать объекты
3) Как работать с указателем мыши и событиями(нажатие клавиш на клавиатуре и на мышке)
4) Работа с таймером
5) Создадим нашу первую банальную игру. Будем с помощью таймера, случайным образом перемещать квадрат. После наведения на квадрат указателя и кликнув по нему левой кнопки мышки, в случае попадания по квадрату, будем прибавлять к полученным очкам +1.

После прочтения статьи «Простейший делегат на C++», я понял лишь то, что не понял я абсолютно ничего – наглухо. Может это потому что автор апеллировал в своих мыслях к понятию делегатов в языке C#, который я знаю чуть менее чем никак. Зато я знаю objective C, в котором, делигерование встречается достаточно часто и подход к делигированию там вполне не плохо переностся на C++, а раз у людей на нем пишущих есть потребность в делегатах, то может такой подход им понравится больше. Сразу оговорка – так как в objective C связывание объекта с методом происходит полностью runtime, зделать все так же на плюсах не выйдет, но тут великий Страуструп оставил нам крохотную щель — таблицу виртуальных функций, вот через нее и просочимся.

Для начала потребно разъяснить каков подход к делегированию в objective C.

Итак, по правилам хорошего тона у нас должен быть интерфейс (@interface – некий аналог класса в плюсах, далее назовем его тоже классом), и протокол с объявлением методов-делегатов (@protocol), класс которому нужно установить делегаты должен иметь наследование от этого протокола (говоря языком «кокошников» поддерживать протокол), а класс который вызывает делегаты иметь указатель на класс с методами делегатами и реализованной поддержкой протокола (правда, из-за динамического связывания наследование вовсе не обязательно – просто копипастим имена методов протокола нужному классу, определяем что им делать – компилятор покажет warning, но все работает, а вот на C++ такое неполучится, тут нужно все выше писанное соблюдать ревностно).

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

Желание написать данную статью появилось после прочтения поста Перегрузка C++ операторов, потому что в нём не были раскрыты многие важные темы.

Самое главное, что необходимо помнить — перегрузка операторов, это всего лишь более удобный способ вызова функций, поэтому не стоит увлекаться перегрузкой операторов. Использовать её следует только тогда, когда это упростит написание кода. Но, не настолько, чтобы это затрудняло чтение. Ведь, как известно, код читается намного чаще, чем пишется. И не забывайте, что вам никогда не дадут перегрузить операторы в тандеме со встроенными типами, возможность перегрузки есть только для пользовательских типов/классов.

Ввод и вывод информации — критически важная задача, без выполнения которой любая программа становится бесполезной. В C++ для решения данной задачи традиционно применяются потоки ввода-вывода, которые реализованы в стандартной библиотеке IOStream.

Плюсами такого подхода являются:
— универсальность: не важно, с чем связан поток, — ввод-вывод с консоли, файла, сокета, процесса происходит одинаково;
— прозрачность: программисту не нужно явно указывать тип вводимого или выводимого объекта;
— расширяемость: программист может добавить поддержку ввода-вывода в поток для любого своего объекта, просто перегрузив соответствующие операторы.

В библиотеке IOStream есть также класс stringstream, который позволяет связать поток ввода-вывода со строкой в памяти. Всё, что выводится в такой поток, добавляется в конец строки; всё, что считыватся из потока — извлекается из начала строки.

Он позволяет делать весьма забавные вещи, например, осуществлять преобразование типов:

В этой небольшой заметке пойдет речь о том, как легко и просто можно убить производительность приложения с помощью библиотеки STL. Охватить всю библиотеку в рамках этого топика не возможно, поэтому будет рассмотрен только один компонент – контейнер std::string. В качестве примера будет показана цена инициализации std::string и, как следствие, продемонстрировано, к чему может привести неоптимальное использование библиотеки. Все нижесказанное особенно остро относится к области gamedev-а.