И снова про синтаксические особенности C++

В C++ очень сложный и неоднозначный синтаксис (гораздо сложнее, чем в том же C). На эту тему было написано немало статей, книг. Ниже я приведу несколько особенностей, на которые я натолкнулся недавно, причем, на некоторые я наступаю не в первый раз.

Что же такое type erasure?

В данном случае мне кажется, что проще привести пример, который обрисует проблему. Итак, предположим, нам необходим список, содержащий функции со следующей сигнатурой:

typedef int (* nullary_function_returning_int_t)();

_Winnie C++ Colorizer

Окей, скажем мы:

typedef std::list<nullary_function_returning_int_t> func_list_t;

_Winnie C++ Colorizer

Но, что если мы хотим хранить не только функции, но и объекты у которых есть оператор (), возвращающий int. В таком случае, мы могли бы сделать базовый класс:

class nullary_function_base { public:  virtual ~nullary_function_base(){} virtual int operator() () = 0; }; typedef std::list<nullary_function_base * > func_list_ptr_t;

_Winnie C++ Colorizer

Но в таком случае мы ограничены только теми объектами, которые являются наследниками класса nullary_function_base. Как быть с функторами, которые получаются, например, в результате использования std::bind1st и пр.? Ведь в этом случае мы уже не можем сделать его наследником nullary_function_base. Или если используется обобщенное программирование и тип функтора просто неизвестен (например, внутри шаблонного класса, функции)?
Вот как раз для решения такой проблемы и используется type erasure.

std::auto_ptr vs boost::scoped_ptr vs std::unique_ptr

Что такое smart pointer я думаю известно, на всякий случай о них можно прочитать в Википедии. Существуют различные виды умных указателей, и каждый из них имеет свою область применения, но одно у них общее - они обеспечивают управление (в том или ином виде) сроком жизни сырого (raw) указателя.

В данном примере мы рассмотрим три вида smart pointer. Все они предоставляют практические одинаковые возможности по управлению raw pointer. Также мне бы хотелось разобраться почему в новом стандарте C++11 auto_ptr объявлен устаревшим, что нужно использовать вместо него, и какие возможности есть в компиляторах не поддерживающих новый стандарт.

Простая библиотека для межпроцессного взаимодействия на базе boost.interprocess

Я давно хотел более подробно разобраться с механизмом IPC, но как-то руки не доходили. Но буквально позавчера я посетил конференцию agilecamp, и после данной конференции у меня возникло желание что нибудь пописать, также хотел попробовать новую штуку - TDD. В общем - одним выстрелом убиваем несколько зайцев.
Для работы нам потребуется:

• Boost - я использовал версию 1.47.0 (самосборная, на базе gcc-4.4.5)
• CMake - версия 2.8.2 (из репозитория Debian squeeze)
• gtest - версия 1.5.0 (из репозитория Debian squeeze)
• gmoсk - версия 1.4.0 (из репозитория Debian squeeze)
• QtCreator - версия 2.3.0 (Вручную инсталлированный) - он имеет plugin для поддержки CMake сборки (на самом деле - мой любимый редактор :)).

Итак поехали

Организация сборки продуктов с помощью CMake

На работе мы используем CMake для сборки продуктов. При этом собираются различные конфигурации  (Release, Debug), с помощью разных компиляторов (msvc-2008, mingw-gcc-4.4.0, sparc-sunos-gcc-3.4.6, прочие компиляторы для различных устройств: iar, arm-gcc, vrxcc).

Примерная иерархия директорий со сборками выглядит так:

\---buildroot
    \---win32
        +---mingw-gcc-4.4.0
        |   +---Debug
        |   \---Release
        \---msvc-2008
            +---Debug_Dynamic
            +---Debug_Static
            +---Release_Dynamic
            \---Release_Static

Для поддержки такой иерархии написаны скрипты для автоматизации конфигурирования и сборки проекта.