Историческое

По старой памяти установил DevPartner на VS 2010.

Это даже не УГ, это намного хуже.

А когда-то вполне себе рулезная штуковина была.

Оптимизированные грабли

Тут на днях коллеги подложили нам свинью.

#define true false    // happy debugging!

Не совсем такую, но несколько человеко-дней Щасливой отладки доставили. Дело в том, что хотя коллеги и подложили свинью, оптимизатор компилятора сделал все возможное, чтобы нам не было скучно ее искать.

Система наша не то чтобы старая. Политкорректно выражаясь, можно сказать, что она имеет историю. И, как в приличных домах, состоит из ядра и множества внешних компонентов, поставляющих данные в систему. Компоненты эти общаются с ядром через свой собственный несложный API и могут быть написаны вообще кем угодно и на чем угодно. Что и случалось раньше и даже по сей день случается.

(more…)

Паттерн “observer” на tr1::function или почти настоящие делегаты

Про C++ делегаты на основе boost::function (tr1::function) я уже писал. В отличие от стандартного варианта обсервера для C++, который подразумевает фиксированный контракт (интерфейс) для подписчиков, вариант с функциональными объектами обладает определенными весомыми преимуществами (все они перечислены в посте по ссылке).

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

class Subject
{
   public:
       typedef std::tr1::function<void (const MyData&)> typeDelegate;

       void Subscribe(typeDelegate);
       void Unsubscribe(typeDelegate);
}

Реализация метода Subscribe() вопросов не вызывает. А вот с отпиской возникает проблема. В случае с классическим обсервером в оба метода передается голый указатель на интерфейс подписчика. А указатели можно сравнивать без хитростей, поэтому отписка превращается в банальное удаление элемента из контейнера.

Function сравнивать нельзя. В tr1 этот класс не определяет операторы сравнения, да и сама идея сравнивать функции в общем виде выглядит несколько нелепо. Идея подобного функционального объекта состоит в том, чтобы единожды его создав, скрыть его внутренности от всех остальных, при этом предоставив возможность создавать копии и выполнять как функцию с предопределенной сигнатурой. Эта идея не подразумевает возможности сравнивать, так как непонятно, что тут вообще можно сравнить. В бусте вроде пытались сделать оператор равенства для функций, но ничего хорошего из этого не вышло.

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

Делать так можно. Только это кривовато сразу по нескольким статьям. Поэтому нам нужно пойти другим путем.

Вышеозначенный делегат можно создавать динамически и заворачивать в умный указатель. А умные указатели уже можно сравнивать! Значит, получим

class Subject
{
   public:
       typedef std::tr1::function<void (const MyData&)> typeDelegate;
       typedef std::tr1::shared_ptr<typeDelegate> typeDelegatePtr;

       void Subscribe(typeDelegatePtr);
       void Unsubscribe(typeDelegatePtr);
}

Теперь, чтобы подписаться на события субъекта, подписчик должен сначала динамически создать объект типа typeDelegate, завернуть его в shared_ptr, а затем уже этот умный указатель использовать для подписки и отписки:

// Somewhere in subscriber's constructor, for example
Subject::typeDelegatePtr m_Delegate(
    new Subject::typeDelegate(bind(&Subscriber::Process, this, _1))
    );
//...
//   Subscribe for events on _pSubject
_pSubject->Subscribe(m_Delegate);
//
//
//   Unsubscribe from _pSubject
_pSubject->Unsubscribe(m_Delegate);

При этом реализация методов подписки и отписки субъекта становится очевидной, поэтому о них больше ни слова.

Как видно, если у объекта есть необходимость отписки, он должен сохранять оригинал делегата для этих целей. Если отписка не требуется (а такое бывает часто), локальная копия m_Delegate не нужна – временный экземпляр его можно будет создать при вызове Subscribe().

Можно еще сделать следующий финт ушами – слегка изменить интерфейсы и в субъект передавать не shared_ptr, а weak_ptr, образованный от оригинального умного указателя на делегат, который является членом класса-подписчика. При этом бесплатно решается проблема курицы и яйца: иногда требуется обеспечить, чтобы объект-подписчик автоматически отписывался при удалении, но никакой гарантии, что субъект еще жив, нет и быть не может. Достаточно лишь обеспечить, чтобы субъект проверял, не протухли ли “слабые” указатели (или делал им lock()) перед вызовом делегата, а подписчик владел оригинальным shared_ptr<typeDelegate>. При этом удаление подписчика будет вызывать инвалидацию всех инстанций weak_ptr, образованных от этого указателя, тем самым делая невозможным вызов убитого объекта через делегат, что и даст нам такую вожделенную возможность подписчика замести все свои следы даже без информации о том, на события каких объектов он подписан и живы ли они еще.

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

Fuck the standards!

TR1 уже давно вышел. Это хорошо. Студия 2008 и 2010 уже включают его по умолчанию. Это просто отлично.

Стандарт (а TR1 – это де-факто уже стандарт) – это всегда хорошо. Больше нельзя называться C++ программистом и закатывать истерики при виде безобидного bind. Теперь нужно либо напрячь мозги и таки освоить основы функциональщины, либо идти заниматься гуевой мышевозней.

А еще стандарты – это плохо. Потому что любое, даже самое разумное и оправданное изменение стандарта превращается в процесс перемещения и горы и Магомета к единому стандартизированному месту встречи. И стандартно занимает до чертиков времени, да и других восполнимых и не очень ресурсов тоже дофига требует.

Вот включили они bind в стандарт. И чо (что, шо, So what, нужное подчеркнуть)? А перегруженные операторы не включили! Бо не было их еще в бусте на момент подачи черновиков в стандарт. В итоге в TR1 вот так вот не сделать:

vector<Person> myVector;
//
// Some stuff here
//
vector<Person>::iterator iter = find_if(
myVector.begin(),
myVector.end(),
bind(&Person::GetLastName, _1) == "Pupkin");

А все из-за того, что тот bind, что в TR1, не перегружает оператор “==”, сцуко такой! В итоге, чтобы сделать то же самое, что на куске кода вверху, нужно городить двухуровневый bind с equal_to посередине, от вида которого даже у привычных к boost пассажиров может случится истерика:

vector<Person>::iterator iter = find_if(
myVector.begin(),
myVector.end(),
bind(equal_to<string>, "Pupkin", bind(&Person::GetLastName, _1)));

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

Нинавижу.

А следующего стандарта еще 10 лет ждать.

Околорабочее

По окончанию длинного и жаркого code review, наполненного спорами о сферичности коней в вакууме, коллега вздохнул с облегчением.

Затем сделал заявление: “My life sucks”.

И ушел.

Мораль тут простая – даже истинные приверженцы XP, agile и scrum не всегда могут ограничить итерацию одним днем и минимизировать размер check-in’а.

Крещение ежа ужом

В надежде выполнить и перевыполнить план текущего sprint, коллега вчера заработался крепко за полночь. До трех часов.

В итоге, когда оказалось, что функциональный объект, созданный с помощью boost::bind, нельзя подсунуть как делегат в управляемый код, он послал нафиг scrum, этот самый функциональный объект, управляемый код и неуправляемый код тоже, Майкрософт, Билла Гейтса и Страуструпа со Столлменом на всякий случай и ушОл спать (тоже на всякий случай).

Морали здесь две.

Первая – от работы кони дохнут.
Вторая – за managed C++ от Майкрософта нужно отрезать кончик хвоста. По самую голову.

Workaround day

В 2010 студии M$ столько всего напеределывали, что создание новго проекта превратилась в поиск воркэраунда к воркэраунду. Например, зачем-то напрочь переделали определение custom build tool, причем гуй для его создания и редактирования привинтить забыли. В результате сегодня нашел, что сами  M$ рекомендуют проекты, которые используют custom build tool (ну, мало ли, вам Yacc’нуть чего надо или еще чего страшного натравить на исходники) создавать сначала в 2008 студии, а потом конвертировать в 2010.

Воистину, стоя и в гамаке. Еще и в противогазе.

К чести Студии, конвертирует она проекты без запинки.

Продолжаем есть кактус.

A day at the work. Untold story about good, bad and boost.

Ух, планов у меня сегодня было громадье. И то сделать хотел, и это и еще вон то. Как всегда, сработал закон Мерфи – чем больше задумаешь, тем меньше сделаешь.

Ну, обо всем по порядку. Нужен нам в проекте умный указатель. Так нужен, что аж спать не можем. Только едим, да. Еще нужны bind и function до кучи. Что хорошо, контора наконец-то переросла подростковое желание переизобрести велосипед, поэтому вумный указатель писать сами в этот раз не стали, а решили взять готовый. Из TR1, буста у нас почему-то боятся как огня, несмотря на присутствие в конторе автора boost::asio.

Одна загвоздка – проект на VS 2005, для которого TR1 выпущен не был. Что плохо. А компилировать проект в итоге мы будем именно 2005 студией по множеству причин, которые к делу не относятся. Для нас это означало известного размера геморрой при портировании кода прототипа с 2010 Студии на 2005.  Знаю, это  все уже начинает походить на прямую трансляцию из театра абсурда. Кто-то из архитекторов даже предложил добавить в пьесу еще один акт. Сказал, что фигня вопрос, мы просто скопируем нужные хедеры из 2008 и дело в шляпе.

В общем, с позаимствованием smart pointer проблем и правда не возникло. Проблемы возникли с заимствованием bind – компилятор 2005-й байнд, писаный явно для 2008-й, ниасиливал. Причем ниасиливал хитро – некоторые конструкции проблем не вызывали, но кое-где он явно не догонял, что передается указатель на параметер, а не объект, и пытался копировать интерфейс с закономерно печальным некрологом в билд логе. Не будь у нас привычки писать йунит-тесты, мы бы об этом узнали не сегодня, а где-нить через месяц. Мне до сих пор от одной мысли об этом становится несколько хреновато.

Подумали мы, порисовали фломастерами на доске и таки решили вживить в проект буст. Не весь сразу, а лишь нужные куски.

Кто работал с бустом, поймет, что это означает скачивание буста, его сборку и натравливание на него тулзень под названием bcp для вычленения нужных кусков. Нам повезло – нужные нам библиотеки header only, и собирать там нечего. Зато вот bcp собрать как раз надо было.

Вот с этим и вышли баааальшие такие деццкие грабли. Оказалось, что скрипты сборки в бусте не работают на 64-битной Винде. Не работают давно и конкретно. Там очень древний и глупый косяк, вызваный скобками в строке “C:\Program Files (x86)\”. Судя по интернетам, этот баг известен с 2006 года, и никто пока даже не почесался его исправить.

Следующие два часа поисков вариантов быстрой правки скриптов или уже собраного bcp.exe принесли твердые отрицательные результаты. Под конец дня пришлось пойти на экстренные меры – найти старую девелоперскую машину с 32-битной Виндой и собрать bcp там. Нужно ли говорить, что после выполнения этого несложного квеста все нужные заголовки были включены в проект уже через две минуты, а еще через минуту проект весело собрался и радостно отрапортовал 0 errors 0 warnings.

Ах, да, еще немного про театр абсурда: между делом я еще сегодня заставил 2010 студию использовать компилятор 2005-й. Забавный получился комбайн, надо сказать, но это уже совсем другая история.

Кто о чем, а я о работе

M$ заботливо обеспечили C++ программистов годовым запасом грабель. Точнее, даже граблей – таких же кривых, как само это слово.

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

Подробности позже телеграфом тчк.

Технологии – вперде! Redux (c)

Совсем забыл рассказать.

Как я уже упоминал, недавно оказалось, что C#, .NET и все, что с ними связано, я знаю довольно неплохо, to my surprise. Потом оказалось, что и Питон тоже знаю, но дело не в этом.

На прошлой неделе получил от всей из себя managed программы на 3.5 фреймворке вполне такой unmanaged Access Violation во всю морду. Мастерство, как говорится, не пропьешь.

Довольный собой, ушел домой. А что? Там же безопасный код и сборщик мусора, а моя хата с краю!

9 visitors online now
9 guests, 0 members
Max visitors today: 9 at 05:13 am MST
This month: 30 at 09-01-2010 12:31 am MST
This year: 41 at 01-23-2010 03:43 am MST
All time: 41 at 01-23-2010 03:43 am MST