Raider's Programming Blog

Unicode: life-hack

2009-11-02T20:46:00.003+03:00

Мой обычный сценарий при создании новых файлов в проекте:
1. right click в Windows explorer на папке, где нужно создать файл
2. выбор Create/"New Text File.txt"
3. ввод имени файла
4. right click на файле
5. SVN/Add
6. Перетаскивание файла в IDE

Небольшой лайф-хак позволяет сразу создавать файлы в UTF-8:

Файл создается с BOM для UTF-8.

Yo!

2009-10-21T16:57:00.005+04:00

Отсортировать строки по алфавиту очень просто - все необходимые сведения о порядке символов есть в классе std::locale. Остается только надеяться что std::locale не подведет. А, как оказалось, она может. Вот пример:

struct lexicographical_order
{
    std::locale Locale;

    lexicographical_order(std::locale Locale) : Locale(Locale)
    {
    }

    bool operator()(std::wstring const &lhs, std::wstring const &rhs) const
    {
        return boost::ilexicographical_compare(lhs, rhs, Locale);
    }
};

int main()
{
    std::vector v;
    v.push_back(L"яблоко");
    v.push_back(L"апельсин");
    v.push_back(L"банан");
    v.push_back(L"персик");
    v.push_back(L"ёжик");
 
    std::locale Locale(""); // используем текущую локаль системы
    std::cout << Locale.name() << std::endl;
    std::sort(v.begin(), v.end(), lexicographical_order(Locale));

    _setmode(_fileno(stdout), _O_U16TEXT);
    std::copy(v.begin(), v.end(), std::ostream_iterator(std::wcout, L"\n"));
    return 0;
}

Под русской Windows получаем:

Russian_Russia.1251
ёжик
апельсин
банан
персик
яблоко

Буква "ё" явно пользуется у данной локали большей популярностью, чем все остальные. Ну прям хоть свою локаль пиши...

Boost Tuple Serialization

2009-08-28T19:41:00.003+04:00

Сложно поверить, но в Boost-е нет сериализации для tuple.

Видимо вся фигня в том, что при сериализации кортежей нужно написать сериализацию для кортежей 0..N элементов, а это можно сделать:
а) руками: написать вручную сериализацию для 0, 1, 2 и т.д. элементов, что совсем не кошерно;
б) препроцессором: использовать boost preprocessor - тоже считается не очень кошерно;
в) компилятор: но тут вся загвоздка как я понял в том, что это нельзя сделать используя публичный интерфейс tuple, можно только зная особенности реализации (details), что тоже вроде бы не очень кошерно.

В результате был выбран списоб "г" - вообще не писать сериализацию для tuple. Что я считаю полным бредом.

PS. Если что - есть готовая реализация через препроцессор.

Sorting by several fields

2009-07-19T00:24:00.007+04:00

Как вы сортируете по нескольким критериям?

struct foo
{
    A a; B b; C c; D d;
    X x; Y y;
};

// нужно отсортировать по a, затем по b, затем по c, ну а затем еще и по d
// по x и y сортировать не нужно
bool s(foo const &l, foo const &r)
{
    if (l.a < r.a) return true;
    if (l.a > r.a) return false;
    if (l.b < r.b) return true;
    if (l.b > r.b) return false;
    if (l.c < r.c) return true;
    if (l.c > r.c) return false;
    return l.d < r.d;
}

std::vector<foo> f;
std::sort(f.begin(), f.end(), s);

Признаюсь, я примерно так раньше и сортировал. Хотя по сути-то [a,b,c,d] - это ж по-сути обычный кортеж, а для них уже есть готовые библиотеки. И операции сравнения кортежей там должны быть, в этих библиотеках. Нужно просто загнать l и r в кортежи (только для скорости - не в [A,B,C,D], а в [const&A,const&B,const&C,const&D]), и сравнить:

#include <boost/tuple/tuple_comparison.hpp>

bool s(foo const &l, foo const &r)
{
    return boost::tie(l.a, l.b, l.c, l.d) < boost::tie(r.a, r.b, r.c, r.d);
}

Static member definition

2009-07-16T22:31:00.002+04:00

Интересно, что статический член класса нельзя определить прямо в декларации класса:

class foo
{
    static std::string s('hello world');
};

А иногда сильно этого хочется - например в декларации шаблона. Или просто в каком-нибудь header-only классе. Самое интересное, что внутри функции такое провернуть можно. Поэтому можно сделать финт ушами - сделать доступ к статическому члену через member-функцию:

class foo
{
    static std::string &s()
    {
        static std::string impl('hello world');
        return impl;
    }
};

Синтаксис при обращении немного поменяется - s() вместо s, но часто оно того стоит.

Fast parsing

2009-06-23T00:15:00.005+04:00

Чем вы парсите всякую "мелочёвку" типа целочисленных значений и прочее? Самописными парсерами с приправами вроде boost::tokenizer, boost::lexical_cast или даже atoi, etc.? Я обычно использовал boost::regex + lexical_cast. А тут недавно посмотрел презентацию Spirit-а с BoostCon-а, даже немного проникся. Раньше как-то я к Спириту более равнодушен был.

Описывать грамматику на C++ и потом давать компилятору [несколько минут] это компилировать - это, конечно, большой изврат. Но весьма забавно. И, говорят, работает потом очень быстро. Даже если нужно просто число распарсить - говорят быстрее всех парсит.

std::string buffer("1234");
int value = 0;

using namespace boost::spirit;
bool r = qi::parse(buffer.begin(), buffer.end(), int_, value);
assert(r && value == 1234);

Visual Studio debug visualizers

2009-06-14T03:16:00.003+04:00

Начиная с Visual Studio 2005 можно писать свои правила для отображения значений в отладчике. Более подробнее об этом можно почитать в блоге virtualdub.

Правила для Boost-овских типов можно найти на Boost Wiki. Единственное, не нашел там то, что искал — для boost::variant. Набросал на коленке:

boost::variant<*,*,*,*,*,*,*,*,*,*,*> {
    preview (
        #(
            #switch($c.which_)
            #case 0 ( *($T1 *)&($c.storage_.data_) )
            #case 1 ( *($T2 *)&($c.storage_.data_) )
            #case 2 ( *($T3 *)&($c.storage_.data_) )
            #case 3 ( *($T4 *)&($c.storage_.data_) )
            #case 4 ( *($T5 *)&($c.storage_.data_) )
            #case 5 ( *($T6 *)&($c.storage_.data_) )
            #case 6 ( *($T7 *)&($c.storage_.data_) )
            #case 7 ( *($T8 *)&($c.storage_.data_) )
            #case 8 ( *($T9 *)&($c.storage_.data_) )
            #case 9 ( *($T10 *)&($c.storage_.data_) )
        )
    )
    children
    (
        #(
        value:
            #switch($c.which_)
            #case 0 ( *($T1 *)&($c.storage_.data_) )
            #case 1 ( *($T2 *)&($c.storage_.data_) )
            #case 2 ( *($T3 *)&($c.storage_.data_) )
            #case 3 ( *($T4 *)&($c.storage_.data_) )
            #case 4 ( *($T5 *)&($c.storage_.data_) )
            #case 5 ( *($T6 *)&($c.storage_.data_) )
            #case 6 ( *($T7 *)&($c.storage_.data_) )
            #case 7 ( *($T8 *)&($c.storage_.data_) )
            #case 8 ( *($T9 *)&($c.storage_.data_) )
            #case 9 ( *($T10 *)&($c.storage_.data_) )
        )
    )
}

Container with a preallocated buffer

2009-05-23T21:10:00.003+04:00

STL-ные контейнеры - замечательная вещь, вот только хранят они все на куче. А иногда ведь так хочется, чтобы они использовали какой-нибудь буфер внутри объекта. Что-то типа такого:

template <typename T, size_t N>
struct Container
{
   size_t size; // сколько элементов в контейнере
   T storage[N]; // заранее выделенный буфер для объектов
};

Такой контейнер будет полезен, например, когда создается временный контейнер на стеке, максимальное количество элементов в нем предполагается известным. Или, например, когда нам нужен контейнер на небольшое нефиксированное количество элементов. Ну правда, стоит ли из-за контейнера на 1-2 небольших элемента заниматься выделением-освобождением памяти на куче (что довольно затратно по времени)?

Есть похожие на это контейнеры:
- boost.array, но он хранит только фиксированное количество элементов, для переменного количества не подойдет
- boost.optional - это почти то, что нужно, но если нужно хранить не более 1 элемента ;)

Нужный мне контейнер есть в стандартной библиотеке C++, которая поставляется с Visual C++, называется он basic_string. В этой реализации (возможно и в каких-то других) он имеет буфер на небольшое количество символов - чтобы для небольших по размеру строк не лазить на кучу. Однако, размер буфера там не регулируется "снаружи", да и нет смысла полагаться на конкретную реализацию - в другой стандартной библиотеке может быть все по-другому, да и эта может "изменить" в любой момент.

В boost-е планируется к review нужный контейнер - auto_buffer. Его еще немного допилят по интерфейсу, но пользоваться уже можно смело. В добавок он может, как и basic_string, расти в кучу, если нужно.

Presentations from BoostCon 2009

2009-05-06T18:42:00.001+04:00

Доступны для скачивания презентации с BoostCon 2009.

Range concatenation

2009-04-08T23:56:00.003+04:00

В библиотеках для работы с итераторами (Boost.Iterators, Boost.Range, RangeEx) куча полезных вещей, но почему-то нигде не нашел механизма "склеить" два диапазона в один. Такого, чтобы можно было сделать вот так:

template <class Range> void process_range(Range const &);

std::vector<foo> v = ...;
std::list<foo> l = ...;
process_range(concat(v, l));

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

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

С использованием boost::variant все получилось достаточно компактно, хотя не максимально эффективно:

template <class TIterator1, class TIterator2, ...>
class ConcatIterator : public boost::iterator_facade<...>
{
public:
    reference dereference() const
    {
        return boost::apply_visitor(DereferenceVisitor<reference>(), It);
    }

    void increment()
    {
        boost::apply_visitor(IncrementVisitor(), It);
        StabilizeForward();
    }

    void decrement()
    {
        StabilizeBackward();
        boost::apply_visitor(DecrementVisitor(), It);
    }

    bool equal(const ConcatIterator& lhs) const
    {
        return (Range == lhs.Range) && (It == lhs.It);
    }

private:
    size_t Range; // 0 for the first range, 1 for the second range
    boost::variant<TIterator1, TIterator2> It, End1, Begin2;
};

PS. Нет худа без добра. Мой велосипед вдохновил разработчиков Boost.Range добавить объединение диапазонов в RangeEx.

Unexpected side effect

2009-04-04T06:02:00.005+04:00

У каждого windows-процесса есть такая "глобальная переменная" - текущая директория. Её можно прочитать функцией GetCurrentDirectory() и изменить функцией SetCurrentDirectory().

Вот чего я не ожидал, что её меняют кто попало. Например, она может изменится после вызовов GetSaveFileName(), GetOpenFileName(). В их документации такое поведение описано и дана возможность его отключить. Но другое дело, что она может измениться внутри... функции StartDoc(). Это такая функция, которая "The StartDoc function starts a print job.", вобщем начинает печать.

И вот почему такое может происходить: драйвер принтера Microsoft Office Document Image Writer - поставляется с Microsoft Office и "печатает" в TIFF-файлы. При получении новой задачи он спрашивает куда же нужно сохранить создаваемый файл. Делает он это, я полагаю, с помощью GetSaveFileName(). Та, в свою очередь, меняет текущую директорию. Я бы сказал что врядли рядовой программист будет ожидать такие побочные эффекты от функции StartDoc().

Мораль (кроме той, что нужно драйвер подправить, добавив флажок OFN_NOCHANGEDIR) - старайтесь не менять глобального окружения кроме случаев, где это будет очевидно.

RangeEx

2009-03-27T16:22:00.002+03:00

Концепция итераторов в STL - замечательная вещь. Можно сказать это C++-ная замена С-шным указателям, причем обратно совместимая с последними. Но вот в реальной жизни пользоваться только итераторами не настолько удобно - чаще больше подходят более высокоуровневые концепции - диапазоны (ranges) и контейнеры. Чаще бывает удобнее писать copy(from, to), чем copy(from.begin(), from.end(), make_back_inserter(to)). Да и вернуть диапазон вместо пары итераторов гораздо удобнее:

encode(substring());

вместо

pair<iterator, iterator> sub(substring());
encode(sub.first, sub.second);

Помню как-то читал как Александреску в языке D активно продвигает диапазоны вообще на замену итераторам. Можно так критично не относиться к итераторам, но я при написании кода вовсю стараюсь специализировать алгоритмы не только для итераторов, но и диапазонов. Алгоритмы в Boost, кстати, тоже очень range-friendly.

И очень правильный шаг в этом направлении - [Boost.]RangeEx. Эта библиотека позволяет сильно упростить код, который до этого использовал итераторы. Конечно, раньше кое-как спасал Boost.Iterators, но код был не в пример этому:

boost::copy(rng |
    boost::adaptors::filtered(pred) |
    boost::adaptors::unique,
    out)

Синтакис очень знаком:

ls | grep ".xml" | wc -l

Вобщем, я очень проникся и вам советую попробовать.

Прибирайте за собой

2009-03-12T20:46:00.002+03:00

Довольно просто на стороне клиента открыть полученный с сервера файл в его родном приложении: ShellExecute(..., FileName, ...)

Единственное, перед этим нужно сохранить файл на диск. Например, во временную папку. Вопрос только - когда его удалять? Сразу же после вызова ShellExecute() это делать вряд ли разумно - запущенное приложение может не успеть еще забрать данные из файла. А может успеть открыть файл, и оставить его заблокированным на время просмотра.

Ничего красивее чем MoveFileEx(FileName, NULL, MOVEFILE_DELAY_UNTIL_REBOOT) в голову не приходит. Правда до ближайшего ребута может быть много лет, но на клиентских машинах такое редко бывает. С другой стороны - многие вообще не прибирают за собой временные файлы, так что это лучше чем ничего.

Интересно, есть ли более элегантное решение?

Container as a stream

2009-02-18T15:03:00.003+03:00

Как быть, если есть данные в контейнере, а нужно получить доступ к нему в виде стандартного потока (basic_iostream)? Например, данные лежат в памяти, а нужно скормить их какой-нибудь функции из third party библиотеки, которая принимает iostream?

typedef std::deque<char> container;
container c;

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

#include <boost/../libs/iostreams/example/container_device.hpp>

typedef boost::iostreams::example::container_device<container> device;
boost::iostreams::stream<device> stream(c);

stream << "hello, world";
stream >> variable;

Different libraries

2009-01-17T14:39:00.005+03:00

На новогодних праздниках нашлось время посмотреть разные C++ библиотеки. А то несправедливо — люди во всю стараются, делают всякие удобные, мощные, гибкие, быстрые и стабильные библиотеки со вкусными лицензиями, а я тут сижу велосипеды изобретаю.

Краткий список того, что нашел для себя интересного.

Futures
В C++0x будет замечательная вещь — futures. Коротко говоря — это лениво-вычисляемые функции. Причем их можно "отправить" вычисляться на другой тред, а потом просто забрать результат. А еще можно организовать обмен сообщениями между тредами. Парочка реализаций futures уже предлагается для включения в Boost, в том числе и версия от Anthony Williams, по которой и писался стандарт C++0x в части futures (доступна также полностью соответствующая стандарту C++0x библиотека threads).

Boost.MPI
Библиотека для взаимодействия между процессами с крайне удобным интерфейсом. Приведенные примеры использования вдохновляют.

Any Iterator
Давно подумывал написать обертку для итераторов, которая преобразует статический полиморфизм STL-ных итераторов в динамический. Например, если вы хотите иметь интерфейс с парочкой виртуальных функций RangeBegin() и RangeEnd(), то какой тип они будут возвращать? std::vector<T>::iterator или std::list<T>::iterator? Или даже boost::transform_iterator<...>? Вам не нужно знать какой конкретно тип итераторов будет использовать та или иная реализация интерфейса. Вместо этого вы делаете тип возвращаемого значения RangeBegin() и RangeEnd() как any_iretator<T>, а внутри реализации автоматически преобразовываете свой std::deque<T>::iterator или my::whatever<T>::iterator к этому типу. Подробнее — в статье, там же ссылка на саму библиотеку.

UUID
Кроссплатформенная библиотека для работы с UUID-ами. Правда, я ожидал от нее быстрых преобразований св строку и обратно, однако там это сделано через потоки ввода-вывода, что видимо будет по производительности далеко от идеала.

unique_ptr
Для тех кто уже понял чем unique_ptr лучше auto_ptr (первый заменяет собою второй в C++0x), но еще пользуется компиляторами без поддержки C++0x — готовая библиотека эмуляции unique_ptr. Да, кстати, а в Boost будет эмуляция rvalues для "старых" компиляторов.

Traversal
Boost.Iterators предоставляют хорошие возможности по трансформации итераторов, однако по иерархическим структурам с помощью них бегать достаточно трудновато. Как-то я писал STL-style итераторы для MS XML и MS DOM, так вот там бы пригодилась новая библиотека Traversal — позволяет итерироваться по иерархиям.

this == NULL. WTF?

2008-12-25T18:53:00.004+03:00

Что вы подумаете, если встретите код типа такого:

if (this == NULL)
    ...;

Нормально ли что this может быть нулевым, ведь при этом даже к членам класса обратиться нельзя, не то что вызвать виртуальную функцию.
Однако тех, кого не удивляет конструкции вида delete this;, не удивит и проверка this на NULL. В самом деле, this - это обычный указатель, и как любой другой указатель он может быть равен NULL:

class foo {
public:
    bool am_i_alive() { return this != NULL; }
};

foo *p = NULL;
assert(!p->am_i_alive());

Но не разумнее ли, спрашивается, проверять указатель на NULL "снаружи" класса (в данном примере - проверять p на NULL), а не внутри его. То есть не вызывать методы объекта, если указатель на него нулевой. И так действительно будет разумнее:

void foo(Bar &bar, IFilter *filter = NULL)
{
    if (filter)
        filter->init(bar);

    for (auto b : bar)
        if (!filter || filter->is_accepted(b))
            out.insert(b);
}

Единственное преимущество внесения проверки внутрь класса - сокращение вызывающего кода, немного повышающее его написание и читаемость. То есть по сути "синтаксический сахар":

void foo(Bar &bar, IFilter *filter = NULL)
{
    filter->init(bar);

    for (auto b : bar)
        if (filter->is_accepted(b))
            out.insert(b);
}

Но ценой этого будет то, что вызываемые функции не должны быть виртуальными, то есть придется каждую виртуальную функцию "обернуть" примерно так:


class IFilter
{
public:
    void init(Bar& bar) { if (this) init_impl(bar; }
    bool is_accepted(Bar::value_type b) { return !this || is_accepted_impl(b); }
private:
    virtual void init_impl(Bar&) = 0;
    virtual bool is_accepted_impl(Bar::value_type) = 0;
};

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


class IFilter
{
public:
    virtual void init(Bar&) = 0;
    virtual bool is_accepted(Bar::value_type) = 0;
};

class NullFilter
{
public:
    virtual void init(Bar&) {}
    virtual bool is_accepted(Bar::value_type) { return true; }
};

void foo(Bar &bar, IFilter &filter = NullFilter())
{
    filter.init(bar);

    for (auto b : bar)
        if (filter.is_accepted(b))
            out.insert(b);
}

В качестве члена какого-нибудь класса это может выглядеть так:

class Foo
{
public:
    Foo() : filter(new NullFilter) {}
    void set_filter(auto_ptr<IFilter> f) { filter = f; }
    void use_filter()
    {
        // можно смело использовать конструкции filter.get()->xxx()
    }
private:
    auto_ptr<IFilter> filter;    
};

Единственное, что может заставить не послушаться книжку по рефакторингу, так это профайлер ;)

Logical XOR operator in C++

2008-12-17T00:33:00.005+03:00

Понадобилось использовать оператор logical XOR и... поначалу не нашел я его в С++. В смысле не нашел оператора, на котором написано "logical XOR". А вообще оператор есть: !=.

The magic of shared_ptr

2008-11-18T21:07:00.004+03:00

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

struct A { ~A() { cout << "~A()" << endl; } };
struct B : public A { ~B() { cout << "~B()" << endl; } };

А теперь создадим объект класса B и поместим его в контейнер указателей на A:

{
    auto_ptr<B> b(new B);
    ptr_vector<A> x;
    x.push_back(b);
}

{
    auto_ptr<B> b(new B);
    vector< shared_ptr<A> > x;
    x.push_back(b);
}

В случае контейнера, хранящего только указатели (в данном случае - boost::ptr_vector) - получим при разрушении объекта вызов только ~A(), а в случае с shared_ptr будет вызван ~B(), так как shared_ptr немного умнее обычного указателя.

Storing dynamicly created objects in a container

2008-11-17T21:45:00.008+03:00

Хранение полиморфных объектов в контейнере - классика жанра:

class A { ... };
class B : public A { ... };
std::vector<A*> BunchOfObjects;
BunchOfObjects.push_back(new B);

Главное - не забыть уничтожить удаляемые из контейнера объекты. И если делать это через оператор delete - еще про виртуальный деструктор у базового класса не забыть бы.

Хотя... другое классическое решение позволяет обойтись и без первого и без второго:

std::vector< boost::shared_ptr<A> > BunchOfObjects;
BunchOfObjects.push_back(boost::shared_ptr<A>(new B));

Наличие виртуального деструктора в таком случае не принципиально - shared_ptr запоминает как нужно удалять объект, по умолчанию это будет оператор delete для нужного типа. Таким образом можно хранить, например, список динамически созданных окон - предков ATL::CWindow. Более того, если от хранимых объектов нужна лишь возможность их в нужный момент удалить, то можно вообще не задумываться от их типе используя boost::shared_ptr<void>.

Wake me up tomorrow

2008-11-13T21:40:00.004+03:00

Функции WinAPI, которые можно использовать в качестве "будильника" - SetTimer(), WaitForSingleObject(), и прочие принимают время относительное, а не абсолютное. Нельзя сказать "Разбудите меня завтра!". Только "Пните меня через 13786 миллисекунд".

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

void SetTimerToTommorrow()
{
    using namespace boost::posix_time;
    using namespace boost::gregorian;

    ptime Now(second_clock::local_time()), Tomorrow(Now.date() + days(1));
    SetTimer(..., (Tomorrow - Now).total_milliseconds() + 1, ...);
}

Fading instead of cutting

2008-10-14T18:06:00.006+04:00

Если текст не влезает в отведенное ему пространство на экране, можно просто его отрезать по краю области. Однако часто будет непонятно что текст обрезан - не очень очевидно что за "Пушкин" скрывается обрезанная "Пушкинская". Решение получше - добавить в конце троеточие: "Пушки...". Но тоже иногда забавно смотрится.

Красивый вариант - уходить в полупрозрачность:

Реализовать можно довольно просто:

перед отрисовкой текста запоминаем тот фрагмент фона, на котором текст будет уходить в полупрозрачность
после отрисовки текста выводим этот фрагмент с учетом полупрозрачности.

Для удобства использования этих двух процессов (который "перед" и который "после") вынесем первый в конструктор класса Fader, второй в деструктор. Использование будет такое:

{
    Fader fader(dc, rect); // выполняется то, что "перед"
    SomeDrawing(dc, rect); // непосредственно отрисовка текста
    // выполняется то, что "после" - в деструкторе ~Fader()
}

Сама реализация предельно проста:

class Fader
{
public:
    Fader::Fader(CDCHandle DC, const CRect& ClientRect) : DC_(DC), FaderRect_(ClientRect)
    {
        // опеределяем область, в которой будем уходить в полупрозрачность
        const int FaderWidth = 32;
        FaderRect_.left = max(FaderRect_.right - FaderWidth, 0);

        // создаем bitmap
        BYTE *Bits = static_cast(CreateBGRABitmap(Bitmap_, DC, FaderRect_.Size()));
        if (!Bits)
            return;

        // копируем фон в bitmap
        BitmapDC_.CreateCompatibleDC(DC);
        BitmapDC_.SelectBitmap(Bitmap_);
        BitBlt(BitmapDC_, 0, 0, FaderRect_.Width(), FaderRect_.Height(), DC, FaderRect_.left, FaderRect_.top, SRCCOPY);

        // уводим в полупрозрачность
        GdiFlush();
        for (int Line = FaderRect_.Height(); Line; --Line)
            for (int Pos = 0; Pos < FaderRect_.Width(); ++Pos, Bits += 4)
            {
                BYTE Alpha = Pos << 3; // как удачно, что FaderWidth является степенью двойки ;)
                ApplyAlpha(Bits[0], Alpha);
                ApplyAlpha(Bits[1], Alpha);
                ApplyAlpha(Bits[2], Alpha);
                Bits[3] = Alpha;
            }
    }

    Fader::~Fader()
    {
        // накладываем полупрозрачный bitmap с фоном
        if (BitmapDC_)
            AlphaBlend(DC_, FaderRect_, BitmapDC_, CRect(CPoint(0, 0), FaderRect_.Size()));
    }

private:
    HDC DC_;
    CRect FaderRect_;
    CBitmap Bitmap_;
    CDC BitmapDC_;
};

PS. Парочка helper-ов, которые используются выше:

void *CreateBGRABitmap(CBitmap& Bitmap, HDC DC, CSize Size, bool UpsideDown)
{
    BITMAPV5HEADER bi;
    memset(&bi, 0, sizeof(bi));
    bi.bV5Size = sizeof (BITMAPV5HEADER);
    bi.bV5Width = Size.cx;
    bi.bV5Height = UpsideDown ? Size.cy : -Size.cy;
    bi.bV5Planes = 1;
    bi.bV5BitCount = 32;
    bi.bV5Compression = BI_BITFIELDS;
    bi.bV5RedMask   = 0x00FF0000;
    bi.bV5GreenMask = 0x0000FF00;
    bi.bV5BlueMask  = 0x000000FF;
    bi.bV5AlphaMask = 0xFF000000;
    void *Bits = NULL;
    Bitmap.CreateDIBSection(DC, (BITMAPINFO*)&bi, DIB_RGB_COLORS, &Bits, NULL, 0);
    return Bits;
}

void ApplyAlpha(BYTE& Value, BYTE Alpha)
{
    Value = ((unsigned)Value * Alpha) >> 8;
}

Animated GIFs using GDI+

2008-09-10T20:19:00.003+04:00

GDI+ как-то поздновато появилась. Именно такой по архитектуре нужно было делать GDI (которая без плюса) изначала. Но, так как изначально GDI сделали как сделали - получили кучу извращений для простой операции - отобразить картинку на экране.

А с GDI+ даже анимированные гифы рисовать - как два пальца. В кратце расскажу как.

Для начала абстрагируемся от GDI+, мало ли потом захотим использовать другую библиотеку. Создадим небольшой интерфейс:

class CImage
{
public:
    virtual CSize Size() const = 0;
    virtual void Draw(HDC DC, const CRect& DestRect, const CRect& SrcRect) const = 0;
    virtual ~CImage() {}

    virtual size_t GetFrameCount() const = 0;
    virtual void SelectActiveFrame(size_t Frame) = 0;
    virtual int /*ms*/ GetFrameDelay(size_t Frame) const = 0;
};

Создадим реализацию этого интерфейса на основе GDI+:

class CGdiPlusImage : public CImage {...}

Уже можно рисовать! Image.Draw(...) и вперед ;) Не забыть только вызвать в нужный момент SelectAcriveFrame() - и все заанимируется сразу.

Один товарисч из Объединенного Королевства предлагает создавать отдельный поток, чтобы там можно было через WaitEvent() дожидаться наступления следующего фрейма. Но зачем нам по отдельному потоку на каждую анимацию? Мы сделаем по-русски - через SetTimer(). Заведем будильник на время, когда нужно будет следующий фрейм отрисовать - и по WM_TIMER отрисуем. Сделаем небольшой helper-класс для этого:

class CAnimation
{
public:
    // all time/reriods are in ms
    CAnimation(CImage& Image, DWORD Time = timeGetTime());

    typedef std::pair<size_t /*current frame*/, DWORD /*period till next frame*/> TInfo;
    TInfo CurrentInfo(DWORD Time = timeGetTime());

    size_t FrameByTime(DWORD Time = timeGetTime());
    DWORD PeriodTillNextFrame(DWORD CurrentTime = timeGetTime());

private:
    size_t nFrames_;
    DWORD Start_;
    typedef std::vector<DWORD> TFrameEnds;
    TFrameEnds FrameEnds_;
};

Этот helper выдаст нам:
1) какой фрейм показывать на такой-то момент времени (чтобы в любой момент времени при отрисовке мы знали какой фрейм рисовать)
2) сколько осталось до показа следующего фрейма (чтобы знать на сколько нам будильник заводить).
Выдаст нам это либо по-отдельности, либо сразу (в виде TInfo).

Осталось реализовать получение этого самомго TInfo. Для этого в самом начале посчитаем когда какой фрейм заканчивается:

DWORD LastEnd = 0;
for (size_t nFrame = 0; nFrame < nFrames_; ++nFrame)
{
    LastEnd += Image.GetFrameDelay(nFrame);
    FrameEnds_[nFrame] = LastEnd;
}

тогда потом легко найдем нужный фрейм простым двоичным поиском:

DWORD FullCyclePeriod = FrameEnds_.back();
DWORD NormalizedTime = (Time - Start_) % FullCyclePeriod;
TFrameEnds::iterator Current(std::upper_bound(FrameEnds_.begin(), FrameEnds_.end(), NormalizedTime));
return TInfo(Current - FrameEnds_.begin(), *Current - NormalizedTime);

И все! Теперь при старте заводим будильник на начало второго фрейма, а при звоне будильника делаем invalidate и заводим будильник на начало следующего фрейма - и т.д. по кругу:

void OnCreate()
{
    SetTimer(TimerId, Animation.PeriodTillNextFrame());
}

void OnTimer()
{
    CAnimation::TInfo AnimationInfo(Animation.CurrentInfo());
    Image.SelectActiveFrame(AnimationInfo.first);
    SetTimer(TimerId, AnimationInfo.second);
    Invalidate();
    return 0;
}

Полный код примера.zip

Debugging using binary search

2008-08-22T18:53:00.003+04:00

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

Решение такой проблемы на корню: обвешивание всего кода юнит-тестами и прогон всех тестов после каждого коммита. Однако не всегда это реализуемо. Либо тесты писать времени нет, либо очень сложно их писать (например, для GUI).

В таком случае можно прибегнуть к двоичному поиску. У нас есть репозиторий и можно получить функцию от номера ревизии - воспроизводится ли данный баг в этой ревизии или нет. Например, в 500-ой его не было а сейчас 1030-ая и он есть. Делим отрезок ревизий [500,1030] пополам, попадаем где-то в 765-ую, апдейтимся до нее, ребилдим проект, смотрим воспроизводится ли баг. Не воспроизводится? Значит он где-то в отрезке [765,1030]. Делим его пополам, и т.д пока не найдем отрезок длинной в один коммит, например [897,898]. Значит 898-ой коммит вызвал появление бага. Смотрим этот коммит и разбираемся в чем дело, выясняем какие изменения привели к багу.

Если коммиты небольшие по объему (а я рекомендую именно так и делать), то довольно быстро можно понять где вылез баг и пофиксить его.

Typedefs

2008-08-08T23:42:00.003+04:00

Кстати, о typedef-ах. Typedef не создает новый тип - только его псевдоним. В этом можно убедиться на простом примере:

template <typename T> class foo {};
template <> class foo<char> {};
typedef char bar;
template <> class foo<bar> {} // compile error

В последней строке получим ошибку, говорящую нам что шаблон foo для типа char уже определен.

Кстати, на счет типов. Как думаете, что выдаст следующий код:

template <typename T> struct foo { static const int x = 1; };
template <> struct foo<signed char> { static const int x = 2; };
template <> struct foo<unsigned char> { static const int x = 3; };
cout << foo<char>::x;

Единицу. Char, signed char и unsigned char - три разных типа. В зависимости от настроек компилятора char ведет себя как signed или unsigned, но это отдельный тип.

String parameters

2008-08-08T18:50:00.003+04:00

Пытался установить Visual Studio 2005 Service Pack 1 на машине, у которой всего полтора гигабайта свободного места на диске. Думаете получилось? Нифига - места на диске не хватило!

Этот сервис пак представляет собой .exe размером 500Mb, внутри которого .msp, а внутри .msp видимо все обновляемые файлы лежат. То сначала распаковывается содержимое .exe в Temp, потом туда же распаковывается содержимое .msp, и видимо там дальше еще что-то распаковывается... Вобщем, красота.

К чему это я - к тому как часто передаются строки в качестве параметров. Строка в C++ - чаще всего std::basic_string:
void foo(const std::string& Param);
Если у нас строка хранится не в std::string, а например в const char*, то получим неявное копирование строки в конструкторе std::string.

void foo(const char* Param);
Уже лучше - можем передать string.c_str(), можем что угодно другое, где есть null terminator. А если у нас строка (или даже большой текст) загружен из ресурсов и есть const char* data() и size_t size(), но нет замыкающего нуля - снова придется делать копию. И это не единственный вариант, когда есть data()/size() - если хотим передать подстроку (внутреннюю часть какой-либо большой строки), то возникнет та же проблема.

void foo(const char* Param, size_t Size = strlen(Param));
Уже намного лучше. Правда если строка в другой кодировке или вообще, читается с потока - опять нужно складывать копию в память, а потом только вызывать foo().

А хорошая альтернатива - это парочка итераторов (a-la STL) или контейнер (a-la Boost):

template <typename T>> void foo(T First, T Last);
template <typename T>> void foo(const &T String);

Конструкции почти эквивалентны, т.к. у контейнера легко можно взять String.begin() и String.end(), а пару итераторов - скормить boost::make_iterator_range(). Так что скорее вопрос вкуса, какой вариант выбрать - я за контейнер.

С таким интерфейсом мы можем взять свести копирование к минимуму. Например, пришли данные в urlencode, да еще в win1251:
char* data = "q=%EF%F0%E8%E2%E5%F2&a=%EC%E5%E4%E2%E5%E4";

Парсим все в указатели:

typedef std::pair<char*, char*> substr;
typedef std::pair<substr, substr> item;

Делаем итератор для декодирования urldecode ("%EF%F0%E8%E2%E5%F2" -> "привет") - и его operator* и operator++ будут делать всю работу "на ходу". (Тут можно призвать на помощь boost::iterator_facade). Нужно конвертировать в utf-8? - еще один итератор ;) И все это скормим нашей foo().

PS. Подробности такого подхода - в boost.iterator, boost.range, boost.string algo.