boost :: bind не работает в VC++ 2010 при связывании функции, которая генерирует исключения

Question

У меня есть код, который компилируется под Linux, но я пытаюсь его перенести в Windows. Я использовал подпиточный 1.50 скомпилированных бинарников от повышающего Pro, но когда я скомпилировать свой код, я получаю эту загадочную ошибку:

error C2664: 'boost::_bi::bind_t<R,F,L>::bind_t(const boost::_bi::bind_t<R,F,L> &)' : 
    cannot convert parameter 1 from 'boost::_bi::bind_t<R,F,L>' 
    to 'const boost::_bi::bind_t<R,F,L> &' 
    C:\Program Files (x86)\boost\boost_1_50\boost\bind\bind_cc.hpp [line] 50 

Ошибки наиболее бесполезна, так как он показывает глубоко в заголовочных файлах Boost, без указания где в моем коде проблема. Тем не менее, комментируя различные блоки кода, я сузил его до этого в качестве причины:

void test(int a) 
    throw (int) // removing this line makes it compile 
{ 
    return; 
} 
... 
boost::function<void(int)> fn = boost::bind<void>(test, _1); 

Это работает, если я удалю throw спецификатора в определении функции. Неважно, что я бросаю, будь то класс или просто int. Я что-то делаю неправильно, или вы не можете привязываться к функциям, которые генерируют исключения в Visual C++? Документы Boost Bind, похоже, не предлагают никаких проблем с этим, и у GCC нет проблем с ним в любом случае.

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

Answer 1

Я не знаю, почему ваш код выходит из строя на VC++. Тем не менее, в большинстве случаев спецификации лучше избегать, поскольку они могут вводить очень тонкие эффекты. Смотрите эту отличную колонку A Pragmatic Look at Exception Specifications Херб Саттер:

So here’s what seems to be the best advice we as a community have learned as of today:

Moral #1: Never write an exception specification.

Moral #2: Except possibly an empty one, but if I were you I’d avoid even that.