Программистам на заметку: новая студия 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.

IMHO, не совсем.
http://blog.emptycrate.com/node/290

имелось ввиду unique_future/shared_future(ссылка), а что это там за шаблон future? я такого в boost не видел, и тем более там внизу написано что это fake.

По мне, это не просто обертка над какой-то синхронизацией, а скорее объект позволяющий выполнить некую операцию в отдельном потоке и по готовности отдать результат. Хотя методы синхронизации так конечно используются.

смотри std::future<>

это переименованный boost::thread::unique_future, точно также как в boost::scoped_ptr, а в std его назвали unique_ptr.
последнее время не использую C++0x, т.к. могут возникнуть проблемы с компиляцией под различные ОСи, и с запуском под линуксом без соответствующего stdlibc++

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

как можно сравнивать производительность объектов предназначенных для различных целей? естественно то что эти объекты эффективнее использовать для того, для чего они предназчены.

вполне даже можно. задача была - синхронизировать выполнение разных потоков. это можно сделать очень разными способами. меня интересовал наиболее быстрый из них.