Из последних извращений

struct Node {
  typedef bool ExpandFn(/*some args here*/); 
  virtual ExpandFn expand_group;
  virtual ExpandFn expand_file;
};

bool Node::expand_group(/*some args here*/) {
  ...
}

bool Node::expand_file(/*some args here*/) {
  ...
}

Обнови лося

Обновления

Обновление завершено
Эти обновления успешно обновлены и готовы к работе

(c) см. предыдущий пост

adobe

"У Adobe нет программистов. У них на территории есть колодец в преисподнюю, откуда есть выход Абсолютному Злу. Это Зло, проходя через специально расставленные компьютеры, генерирует Код, который, будучи скомпилированным, рождает программные продукты Adobe.."
(с) veter_r_r via belnetmon

Яростно плюсую!

зоопарк.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). Там эта бага не исправлена.