我正在尝试使用boost :: signal来实现回调机制，并且即使在库中最简单的用法下，我也会在boost :: signal代码中获得内存访问断言。我已将其简化为以下代码：

#include <boost/signal.hpp>

typedef boost::signal<void (void)> Event;

int main(int argc, char* argv[])
{

    Event e;

    return 0;
}

谢谢！

编辑：这是使用Visual Studio 2008 w / SP1编译的Boost 1.36.0。 Boost :: filesystem，就像boost :: signal一样，也有一个必须链接的库，而且看起来工作正常。我相信，我使用的所有其他Boost库都是仅标头的。

解决方案

我已经在系统上测试了代码，并且工作正常。我认为编译器与构建Boost.Signals库的编译器之间不匹配。尝试下载Boost源，并使用与构建代码时相同的编译器编译Boost.Signals。

仅出于我的信息，我们正在使用什么编译器(和版本)？

使用不同的堆实现进行编译时，经常会发生这种问题。在VS中，可以要求将CRT链接到(作为静态库)或者保留为动态库。

如果我们使用的库在其链接的堆上分配了内存，而程序尝试使用另一个堆来对其进行分配，则会遇到麻烦：要释放的对象不在分配的对象列表上。

我已经确认这是Microsoft博客上的Stephan T Lavavej(STL！)的问题。

具体来说，他说：

The general problem is that the linker does not diagnose all One Definition Rule (ODR) violations. Although not impossible, this is a difficult problem to solve, which is why the Standard specifically permits certain ODR violations to go undiagnosed.
  
  I would certainly love for the compiler and linker to have a special mode that would catch all ODR violations at build time, but I recognize that that would be difficult to achieve (and would consume resources that could perhaps be put to even better use, like more conformance). In any event, ODR violations can be avoided without extreme effort by properly structuring your code, so we as programmers can cope with this lack of linker checking.
  
  However, macros that change the functionality of code by being switched on and off are flirting dangerously with the ODR, and the specific problem is that _SECURE_SCL and _HAS_ITERATOR_DEBUGGING both do exactly this. At first glance, this might not seem so bad, since you should already have control over which macros are defined project-wide in your build system. However, separately compiled libraries complicate things - if you've built (for example) Boost with _SECURE_SCL on, which is the default, your project must not turn _SECURE_SCL off. If you're intent on turning _SECURE_SCL off in your project, now you have to re-build Boost accordingly. And depending on the separately compiled library in question, that might be difficult (with Boost, according to my understanding, it can be done, I've just never figured out how).

他稍后在评论中列出了一些可能的解决方法，但没有一种适合这种情况。有人报告说可以通过在boost / config / compiler / visualc.hpp中插入一些定义来在编译boost时关闭这些标志，但这对我不起作用。但是，在tools / build / v2 / user-config.jam中插入以下行VERBATIM可以达到目的。请注意，空格对于增加卡纸很重要。

using msvc : 9.0 : : <cxxflags>-D _SECURE_SCL=0 <cxxflags>-D _HAS_ITERATOR_DEBUGGING=0 ;

布莱恩，我刚刚遇到了与我们完全相同的问题。感谢我们对博客文章的回答，我将其归结为我们禁用了_HAS_ITERATOR_DEBUGGING和_SECURE_SCL。

为了解决这个问题，我手动构建了boost库。我不需要弄乱配置文件。这是我使用的两个命令行：

x86

  bjam debug release link=static
  threading=multi runtime-link=shared
  define=_SECURE_SCL=0
  define=_HAS_ITERATOR_DEBUGGING=0
  --with-signals stage
  
  x64

  bjam debug release link=static
  threading=multi runtime-link=shared
  define=_SECURE_SCL=0
  define=_HAS_ITERATOR_DEBUGGING=0
  address-model=64 --with-signals stage

这将生成以下文件：
libboost_signals-vc90-mt-1_43.lib
libboost_signals-vc90-mt-gd-1_43.lib

希望能有所帮助。