Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

Форум на CrossPlatform.RU _ boost _ Boost и MSVS 2010

Автор: Iron Bug 20.8.2010, 21:22

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

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

Автор: niXman 25.8.2010, 5:42

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

Автор: Iron Bug 25.8.2010, 13:47

Цитата(niXman @ 25.8.2010, 8:42) *
приведите пример кода, и сообщения компилятора. а так же, версию boost.

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

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

Автор: niXman 26.8.2010, 16:04

Цитата
последний, 43-й.

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

Автор: Iron Bug 26.8.2010, 17:28

Цитата(niXman @ 26.8.2010, 19:04) *
последний - 1.44.0.

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

Автор: Iron Bug 27.8.2010, 11:50

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

Автор: Litkevich Yuriy 27.8.2010, 19:33

Цитата(Iron Bug @ 27.8.2010, 15:50) *
надо ещё дома под линюксом собрать новый буст и проверить пару вещей.
хватит трудоголить, в отпуск иди :)

Автор: Iron Bug 28.8.2010, 0:05

Цитата(Litkevich Yuriy @ 27.8.2010, 22:33) *
хватит трудоголить, в отпуск иди :)

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

Автор: niXman 30.8.2010, 0:14

Цитата
фича interprocess'а: фьюча (future).

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

Цитата
(future). даёт несомненное преимущество по скорости

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

Цитата
даже по сравнению с использованием бустовских мьютексов (хотя это странно, но факт).

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

Цитата
может, потом опубликую результаты тестов.

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

Автор: DEADHUNT 30.8.2010, 21:55

Цитата(niXman @ 30.8.2010, 1:14) *
в boost.interprocess нет класса future. вы о чем? :acute:

тоже не понравилось когда прочитал.
Цитата(niXman @ 30.8.2010, 1:14) *
boost.thread.future<> не имеет никакого отношения к механизмам синхронизации. это просто обертка над boost.thread, создающая объект владеющий потоком, в котором "живет" boost.thread :)

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

Автор: BRE 30.8.2010, 22:25

Цитата(DEADHUNT @ 30.8.2010, 22:55) *
boost::thread::future это скорее обёртка над mutex, wait_condition.

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

Автор: DEADHUNT 30.8.2010, 22:57

Цитата(BRE @ 30.8.2010, 23:25) *
IMHO, не совсем.
http://blog.emptycrate.com/node/290

имелось ввиду unique_future/shared_future(http://www.boost.org/doc/libs/1_44_0/doc/html/thread/synchronization.html#thread.synchronization.futures), а что это там за шаблон future? я такого в boost не видел, и тем более там внизу написано что это fake.

Автор: BRE 30.8.2010, 23:38

Цитата(DEADHUNT @ 30.8.2010, 23:57) *
Цитата(BRE @ 30.8.2010, 23:25) *
IMHO, не совсем.
http://blog.emptycrate.com/node/290

имелось ввиду unique_future/shared_future(http://www.boost.org/doc/libs/1_44_0/doc/html/thread/synchronization.html#thread.synchronization.futures), а что это там за шаблон future? я такого в boost не видел, и тем более там внизу написано что это fake.

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

Автор: niXman 31.8.2010, 0:53

Цитата
а что это там за шаблон future?

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

Автор: DEADHUNT 31.8.2010, 10:10

Цитата(niXman @ 31.8.2010, 1:53) *
смотри std::future<>

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

Автор: Iron Bug 1.9.2010, 0:55

Цитата(niXman @ 30.8.2010, 3:14) *
если вы все же имели ввиду boost.thread.future<>, то никакого прироста производительности он не дает.

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

Автор: DEADHUNT 1.9.2010, 11:26

Цитата(Iron Bug @ 1.9.2010, 1:55) *
я сравнивала мьютексы, условные переменные, прерывания потока

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

Автор: Iron Bug 1.9.2010, 20:54

Цитата(DEADHUNT @ 1.9.2010, 14:26) *
как можно сравнивать производительность объектов предназначенных для различных целей? естественно то что эти объекты эффективнее использовать для того, для чего они предназчены.

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

Форум Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)