зоопарк.xml

Недавно добавил в текущий проект pugixml. Внешне либа выглядит симпатично, хотя внутри там местами адЪ и израилЬ (видно, что писал сишник, ибо setjmp/longjmp в плюсовом коде). Но работает шустро и без глюков.

Фишка в том, что в проекта уже используется TinyXml, а под виндой гуй использует и MSXML.
Так что теперь у меня в проекте 3 библиотеки, делающих одно и то же.

Еще одно "веселье" в том, что обе либы (и pugi, и tiny) пришлось патчить.

в первом случае(TinyXml) -- потому-что генерируемый файл должен быть human-readible и может содержать яваскрипт -- так что крайне нежелательно экранировать переводы строк и одиночные кавычки, как в pcdata, так и в значениях атрибутов.
Во втором(pugi) -- наоборот, софт, обрабатывающий выходной файл, игнорирует неэкранированные переводы строк в pcdata.
И ведь и в пуги, и в тайни есть класс "принтер", позволяющий настроить сохранение. Но всё, что они могут -- только задать перенос строк и индент. Эскейпинг сделан статической функцией.

И после этого вы говорите, что Xml спасет мир?

нашел неожиданное применение для continue

Есть в С/С++ такой частый паттерн, как цикл без тела.

while (*dest++ = *src++);
while (i != end && *i++ < 5);

Он заслуженно считается антипаттерном -- если забыть точку с запятой, можно огрести. Кроме того, сама фраза звучит как-то неокончено. Альтернативные варианты этих циклов выглядят как то громоздко:

while (*dest = *src) {
  ++dest; ++src;
}
while (i != end)
  if (!(*i++ < 5))
     break;

Нашел альтернативу:

while (*dest++ = *src++)
  continue;
while (i != end && *i++ < 5)
  continue;

И выглядит закончено (пока что-то делается, продолжать), и забытая точка с запятой приведет к синтаксической ошибке.

Дай списать

bitfield
а %CONCURENTNAME% нас давно забанили? после той ссоры?
beta-tester
ога. ну прокси никто не отменял. хо почитать их форум?
beta-tester
можно считать что они нам язык показали обидевшись, забанив айпишник
bitfield
да я хотел им баг зарепортить...
beta-tester
зачем? они ж пофиксят
bitfield
тогда я б узнал, как его фиксить .. а так прийдется его фиксить мне, а они потом у меня "спишут" 

параллельная сборка в MSVC

При сборке проекта из-под 2005/2008 msvc, добавьте в Configuration Properties -> C/C++ -> Command Line-> Additional options строчку /MP.
Это аналог -j у make/boost.build.

ЗЫ. В 2010 вроде для этого есть параметр в гуе, но не проверял.
ЗЗЫ. Tools->Options->Projects and Solutions -> Build and Run -> maximum number of parallel project build задает кол-во параллельно собираемых проектов, но не количество параллельно компилируемых файлов.

Hate speach about BCG!

Ненавижу BGCPControlBar.
Одна из самых "индусокодных" библиотек, не смотря на то, что написана русскими.
Мега-функции на пару тысяч строк. Невиртуальность тех функций, которые следовало бы сделать виртуальными.
Типичный стиль работы с ней -- отнаследоваться, переопределить одну-две функции, ПОЛНОСТЬЮ скопировав их тела из исходников, а потом подправить одно-два условия.
У нас в конторе есть даже особый мем --"багабецеже".
А теперь эту гадость включили в состав нового MFC в 2008й и 2010й студиях.

Вот и сегодня поправил багу у них, из-за которой мой софт грузился на 6 секунд! дольше. Буст с 16 до 10 секунд -- вполне заметный прирост.

Суть баги -- CBCGPShellTree долго строит дерево папок. Если надо показать c:\users\bitfield\desktop, то делает оно это 8 секунд! Логи показали, что 6 секунд оно строит список файлов для папки Computer, а вернее, 5-6 секунд висит на GetAttributesOf у первого элемента, пытаясь узнать, есть ли в нем подпапки.
Догадались?
Первый элемент -- конечно же A:, но дисковода у меня нет физически. Добавил проверку на removable и вуаля, эта ветка дерева строится уже за 0.5 секунды.

Посмотрел исходики в MFC 2008|2010. (файл AfxShellTreeCtrl.cpp). Там эта бага не исправлена.

Автоматическое обновление svn:externals

В текущем проекте через svn:externals подключается 25 либ, причем не в единый корень, а в нескольких местах (в 5 или 6 местах).
Написал тут скрипт, который автоматически выставляет экстерналы на нужные ревизии.

[boost.build][trick] Ускорение сборки в boost.build

boost.build всем хорош, кроме скорости.

К примеру, анализ того, какие файлы надо пересобрать, на моем проекте (30+ либ + boost) занимает 42 секунды.
Оказывается, решение было найдено полтора года назад.

http://lists.boost.org/boost-build/2009/04/21734.php

Человек переписал стандартный анализатор инклюдов так, чтоб тот игнорировал файлы по регекспу.
добавив "в игнор" стандартные хедеры (у них нет расширения) и хедеры буста (^boost/) - получил время анализа в 22 секунды.

Уже можно жить...

рабочее

Бета-тестер: кста что интересно оказалось
ты собираешь инсталлятор foo_bar.exe
я его переименовываю для вебщиков в foo_bar_baz.exe
а они его для сайта переименовывают в foo_bar.exe