参数对象的成员variables的内存地址在调用dll函数时发生变化

class SomeClass {
//一些成员
MemberClass one_of_the_mem_; }

我有一个函数foo( SomeClass *object )在一个DLL中,它是从一个EXE调用。

问题

one_of_the_mem_地址在调用dll调用期间发生变化。

详情

呼叫之前 (从EXE):

  '&(this).one_of_the_mem_' - `0x00e913d0` 

之后 – 在dll本身:

  '&(this).one_of_the_mem_' - `0x00e913dc` 

对象的地址保持不变。 每次只有地址移动的成员。

我想要一些关于如何解决这个问题的指针。

代码:

来自Exe的代码

stat = module-> init(this,object_a,&object_b,object_c,con_dir);

在DLL中的代码

 Status_C ModuleClass( SomeClass *object, int index, Config *conf, const char* name) { _ASSERT(0); //DEBUGGING HOOK ... 

更新1:

我根据迈克尔的指示比较了成员的抵消,在两种情况下他们都是一样的。

更新2:

我find了一种方法来转储类的布局,并注意到大小的差异,我必须弄清楚为什么会发生。

链接是我发现转储类布局的问题。

更新3: exe和dll之间的类布局差异,但不知道为什么呢
最终更新 :解决了这个问题,非常感谢Michael Burr。

原来其中一个版本使用32位时间, _USE_32BIT_TIME_T被定义在其中,另一个使用64位时间。 所以它为对象生成了不同的布局,附加的是差异文件。

由于time_t的大小而导致在两个类中的差异

Solutions Collecting From Web of "参数对象的成员variables的内存地址在调用dll函数时发生变化"

你的DLL可能是用不同的编译器选项集合编译的(或者甚至可能是一个略有不同的头文件),并且类布局因此而不同。

例如,如果一个是使用调试标志构建的,而另一个则不是,或者即使使用不同的编译器版本。 例如,不同编译器版本使用的库可能会有细微的差别,如果您的类包含由库定义的类型,则可能会有不同的布局。

作为一个具体的例子,对于微软的编译器来说,迭代器和容器对于释放/调试,_SECURE_SCL on / off和_HAS_ITERATOR_DEBUGGING开关设置都很敏感(至少VS 2008 – VS 2010可能已经在某种程度上改变了这一点) 。 有关详细信息,请参阅http://connect.microsoft.com/VisualStudio/feedback/details/352699/secure-scl-is-broken-in-release-builds

这些类型的问题使得跨DLL边界使用C ++类比使用直接C接口更脆弱。 它们也可以出现在C结构中,但似乎C ++库更经常地具有这些差异(我认为这是具有更丰富功能的本质)。

另一个不时发生的布局变化问题是在不同的编译中有不同的结构打包选项。 有一件事可以“隐藏”这一点,就是头文件经常使用编译指示来设置结构打包到一定的值,有时候你可能会遇到这样的头文件,而不会把它改回缺省值(或者更正确的说,前面的设置)。 如果你有这样一个头文件,很容易将它包含在一个模块的构建中,而不是另一个。

这听起来有点奇怪,你应该显示更多的代码,如果被ref传递,它应该“移动”,这听起来更像是它的副本,并且调用成员函数。

也许DLL版本是针对您所引用的不同版本进行编译的。 检查并确保头文件是与dll相同的版本。

重新编译图书馆,如果可以的话。