пятница, 13 июля 2012 г.

Восхождение на белуху. Первый блин комом.

Хотя блог и тематический, решил написать сообщение не по теме, ибо слишком много эмоций и переживаний (положительных) подарил мне этот поход.

суббота, 21 января 2012 г.

Secure Coding

Наша компания купила курс для программистов C, C++: "Secure Coding in C and C++". Для проведения курса был приглашен преподаватель из Carnegie Mellon University. Я попытаюсь сделать краткий обзор лекций, которые нам были прочитаны. Скажу сразу - это мое субъективное мнение.

воскресенье, 25 декабря 2011 г.

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

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

понедельник, 21 ноября 2011 г.

Что же такое 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.

вторник, 8 ноября 2011 г.

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

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

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

воскресенье, 6 ноября 2011 г.

Простая библиотека для межпроцессного взаимодействия на базе 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 сборки (на самом деле - мой любимый редактор :)).
Итак поехали

суббота, 21 мая 2011 г.

Организация сборки продуктов с помощью 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

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