Программистам на заметку: новая студия Microsoft Visual Studio 2010 не дружит с бустом.
Проблема в перекрытии некоторых стандартных внешних макросов и функций, объявленных в базовых библиотеках буста и добавленных в новые стандартные библиотеки студии.
Например, перекрываются определения pair, из-за чего не работают многие бустовские фичи, алгоритмы, bind, лямбда-функции, фьючи(futures) в интерпроцессе. Вероятно, проблем куда больше и пока не понятно, как их решать. Если дело касается одного-двух применений - можно локально написать макросы или указать явно область видимости. Но когда начинается применение перекрытых новой студией определений где-то внутри используемых библиотек - это заставляет отказаться от идеи скрещивания буста и студии 2010.
Разработчики буста в курсе проблемы, но пока что изменений нет.

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

приведите пример кода, и сообщения компилятора. а так же, версию boost.

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

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

последний - 1.44.0.

ну, значит, я чуть опоздала: недели две назад был ещё 43-й.
да, изменения касательно студии 2010 в логе есть, но я не думаю, что они так бодро решили все проблемы: там было много проблем из-за новой студии и в разных библиотеках. если завтра будет время на работе - посмотрю 44-й. просто завтра у меня последний день на работе перед отпуском и куча дел, как обычно. а дома венды нет. боюсь, что завтра на работе будет просто не до буста.

выкроила время, чтобы собрать 44-й буст и проверить его с 2010 студией.
вроде тех ошибок, которые раньше лезли, нет.
надо ещё дома под линюксом собрать новый буст и проверить пару вещей.

хватит трудоголить, в отпуск иди

ну, типа уже отпуск начался: весь вечер сижу, собираю линь из сорцов с нуля
а за сегодняшний день на работе я успела кой-чего про оптимизацию механизмов синхронизации потоков в бусте выяснить. это мне нужно было, чтобы заложить в новую систему контроля железяк самый быстрый метод из возможных вариантов. написала тестовую программку, чтобы выяснить, какие методы синхронизации самые шустрые. самой быстрой под вендой оказалась недавно появившаяся фича interprocess'а: фьюча (future). даёт несомненное преимущество по скорости, даже по сравнению с использованием бустовских мьютексов (хотя это странно, но факт). может, потом опубликую результаты тестов. вдруг кому пригодится. ещё бы хотелось это на разных системах протестировать. я тестировала под вендой, под линём (с gcc и icc), а макоси у меня тут нет, к сожалению.

в boost.interprocess нет класса future. вы о чем?


если вы все же имели ввиду boost.thread.future<>, то никакого прироста производительности он не дает.


boost.thread.future<> не имеет никакого отношения к механизмам синхронизации. это просто обертка над boost.thread, создающая объект владеющий потоком, в котором "живет" boost.thread


угу. дико любопытно понять, о чем вы все же

тоже не понравилось когда прочитал.

boost::thread::future это скорее обёртка над mutex, wait_condition.