blinnov’s blog

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++ от Майкрософта нужно отрезать кончик хвоста. По самую голову.

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

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

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

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

I just spent two days tracking this problem down.

I received my new development machine with Windows7 x64 only a week ago. It all was just pefect – quad core CPU could compile the world in almost no time, and brand new Visual Studio 2010 was just as good as it gets. By the way, I am the Linux guy and prefer vim, automake and gcc any other IDE, so if I call Visual Studio perfect, it means something.

Neverthless, everything good has an end. Yesterday I tried to build bcp.exe tool I needed to dissect boost, and I faced very nasty and very unclear problem. I simply could not. Every time I started the build process, it would fail with the most weird message I ever seen:

\Microsoft was unexpected at this time

Well, I mentioned I am the Linux guy, but I am not a religious fanatic. I just thought that there was a problem of some sort in the boost’s build script and used another machine to build bcp.

Next day I became really concerned. I realized that I could not use “Visual Studio Prompt” from VS 2010 and VS 2008. Every time I tried to start them, they would have that message about unexpected microsoft on them; and environment variables were not set. So I could not build anything! Sadly, this was rather a major problem for me as we had quite a few makefile projects and not being able to set the correct environment for build process was that kind of present I could happily live without.

I spent next four hours to find that this or similar problem was already mentioned several times; but nobody offered a solution that would work and nobody explained what was causing that. Some said that Windows SDK installation could break the batch file vcvars32.bat; some thought there was a bug in the batch file itself. Strangely,  it all worked perfectly on the the neighbor’s machine. I even compared the files and found no difference at all.

The solution came at the end of the day when all my hopes were gone. One guy mentioned that the problem was caused by the parentheses in vcvars32.bat:

@if not "%WindowsSdkDir%" == "" (
	@set "PATH=%WindowsSdkDir%bin\NETFX 4.0 Tools;%WindowsSdkDir%bin;%PATH%"
	@set "INCLUDE=%WindowsSdkDir%include;%INCLUDE%"
	@set "LIB=%WindowsSdkDir%lib;%LIB%"
)

He mentioned that as he found out, one of the directories where SDK was had braces in the name as well, and that broke the statement above completely as batch processor would find nested parentheses in the folder’s name and consider them as the end of the statement.

Needless to mention, may machine had some paths that had braces in them. C:\Program Files (x86). And, needless to mention, it is exactly where Visual Studio is installed. And it also exists in %PATH% environment variable.

By itself, it does not break the script. As I mentioned, it worked perfectly on the other machine which was the biological twin of my PC. But, what if one of the PATH’s members is encolsed in double quotes? (to check how your PATH looks like, type echo %PATH% in command prompt). I checked and that’s what I found:

c:\winutils;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
c:\Program Files (x86)Microsoft SQL Server\100\Tools\Binn\;
c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;
c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;
"C:\Program Files (x86)Microsoft Visual Studio 9.0\Common7\IDE\";
C:\Program Files (x86)Microsoft Team Foundation Server 2010 Power Tools\;
C:\Program Files (x86)Microsoft Team Foundation Server 2010 Power Tools\Best Practices Analyzer\;
c:\cygwin\bin

Bingo! I found that one entry of PATH was indeed enclosed in double quotes. And, not surprisingly, it had that nasty (x86) in it. It was pointing somewhere inside VS 2008 installation tree, so I think one of VS 2008 tools I have installed recently indeed screwed this up.

So, I simply removed those double quotes. Immediately after that, both VS 2010 and VS 2008 command prompts were fixed.

So, the fist thing you should do if you’re having the same problem: look at your %PATH% environment variable and check if anything is enclosed in double quotes.

Finding this just cost me two days of work, and I hope it it helps you sorting it out much faster.

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

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

Just moments after installing VS 2010 I found very nasty bug in its implementation of TR1 libraries:

            typedef struct sTestStruct
            {
                char* pName;
                char* pOtherName;
                sTestStruct* pNext;
            } sTestStruct;

            sTestStruct Struct1 = {"blah", "mlah", 0};

            char* pChar = bind(&sTestStruct::pName, _1)(&Struct1);            // Compiler is happy here

            bind(_stricmp, "blah", bind(&sTestStruct::pName, _1))(&Struct1);  // bang happens here

The error message is simply astonishing:

\microsoft visual studio 10.0\vc\include\functional(447): error C2440: ‘return’ : cannot convert from ‘char *’ to ‘char *&’

What is interesting, should I switch C++ toolset to version 9.0 (essentially switching back to VS 2008), the problem went away.

If I could I would suggest that something went horribly wrong when MS were working on rvalues (or were they lvalues?) references business, but there is simply no point guessing around. I just wonder how long will it take MS to fix the problem. Obviously, problems like this could mean that this new version of VS 2010 is not ready to be used in production yet.

Also, reporting bugs to MS has always been not so easy quest.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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