Архивы: software development

Открытие дня

Только что с прискорбием узнал, что Build Events в Visual Studio не агрегируются и поэтому не наследуются из Property Sheets. Потомушта это «simple property, not the aggregate one» (пруф).

Пичаль.

Рабоче-крестьянские зарисовки

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

Читать далее »

Паттерн «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-й. Забавный получился комбайн, надо сказать, но это уже совсем другая история.

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

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

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

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

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

Рабоче-некрестьянское

А однажды мне пришлось реализовывать стек протокола.

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

Просто в этот раз протокол оказался что надо! Индустриальный (тут должно быть нецензурное междометие)!

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

По крайней мере в теории. Как мы знаем, в теории разницы между теорией и практикой нет. На практике же…

На практике же сначала оказывается, что индустриальный (а стало быть, практически обязательный к исполнению, если хочешь, чтобы пацаны уважали) стандарт сначала нужно купить. За большие деньги, но дело даже не в этом, а в том, что процедура покупки набора PDF зачастую превращается в квест почище второго Ларри. Затем, по получению документов, может оказаться, что разобраться в ЭТОМ без применения веществ смогут только очень альтернативно одаренные пассажиры. Например, стандарт может оказаться представлен полутора десятком слабо связанных друг с другом PDF, орагнизованными таким образом, что каждый абзац каждого из них будет ссылаться на различные абзацы из всех других PDF (и еще одного отсутствующего) как минимум один раз, причем понять смысл абзаца без прочтения всего материала, на который они ссылаются, будет решительно невозможно. Сами же PDF  будут минимум наполовину состоять из «словарей терминов» и аббривеатур, которые сами по себе ничего не значат, но тем не менее постоянно используются повсюду, в результате чего к прыжкам по ссылкам добавятся постоянные попытки расшифровать, что де эта двенадцатибуквенная аббривеатура означает. Потом, даже если Вам посчастливится разобраться в хитросплетении перекрестных вовсе не гиперссылок, приправленных аббривеатурами и сокращениями, нигде более во Вселенной не встречающимися, понимания, откуда что берется, куда что уходит, зачем нужен вот тот параметер не прибавтися. Зато желание сменить профессию вот прямо сейчас заметно усилится. Соусом послужит непременный набор совершенно противоречивых данных о той или иной фиче, причем противоречия зачастую можно найти в одном и том же предложении.

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

В особо пикантных случаях оказывается, что все доступные реализации протокола (читай — устройства и программы, с которыми Ваша софтина должна уметь общаться) были написаны людьми, веществ не принимающих. Поэтому на некоторые особо туманные особенности протокола, которые в стандарте могут быть иногда помечены как опциональные, может быть сложен бааальшущий такой болт. С резьбой. Как Вы можете себе представить, разные реализации могут счесть совершенно разные как необязательные, как и обязательные фичи действительно необязательными к исполнению, в результате чего Вам придется поддерживать вообще все возможные фичи. Даже те, которыми никто не пользуется (то ли потому что никто так и не понял, как ими пользоваться, то ли потому что никто не догнал, зачем).

Вот так и работаем. А что делать?

5 посетителей онлайн
2 гостей, 3 bots, 0 зарегистрированных
Максимум сегодня:: 20 в 02:44 am UTC
В этом месяце: 40 в 06-04-2017 04:12 pm UTC
В этом году: 50 в 02-12-2017 07:56 am UTC
За все время: 130 в 10-22-2014 11:16 pm UTC