The memory address of the member variable of the objects of the argument objects when the dll function is called

Question

class SomeClass {
// some members
MemberClass one_of_the_mem_; }

I have a function foo( SomeClass *object ) inside a dll, it is called from exe.

Problem

the address of one_of_the_mem_ changes during the sending of the dll call.

More details

before the call is made (from exe):

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

after - in the dll itself:

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

The address of the object remains constant. This is only a member whose address changes to c each time.

I want some pointers regarding how I can fix this problem.

Code:

Code from Exe

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

DLL Code

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

Update 1:

I compared member offsets after Michael's instruction, and they are the same in both cases.

Update 2:

I found a way to reset the class layout and noticed the difference in size, I have to understand why this is happening.

related is the question I found to build the class layout.

Update 3:
The final update . Solved the problem, thanks to Michael Burr.

it turned out that one of the buildings used 32-bit time, _USE_32BIT_TIME_T was defined in it, and the other used 64-bit time. Thus, he generated a different layout for the object, an attached file differences.

Answer 1

Your DLL was probably compiled with a different set of compiler options (or maybe even with a slightly different header file), and as a result, the class layout is different.

For example, if one was created using debug flags, and the other did not, or even if different versions of the compiler were used. For example, the libraries used in different versions of the compiler may have slight differences, and if your class contains the type defined by the library, you can have different layouts.

As a concrete example, using iterators and containers, the Microsoft compiler are sensitive to debugging / debugging, turning on / off _SECURE_SCL and setting on / off _HAS_ITERATOR_DEBUGGING (at least, although VS 2008 - VS 2010 may have changed some of this to some extent). See http://connect.microsoft.com/VisualStudio/feedback/details/352699/secure-scl-is-broken-in-release-builds for more details.

These problems make using C ++ classes across DLL boundaries a little more fragile than using direct C interfaces. They can also occur in C structures, but it seems that C ++ libraries have these differences more often (I think that character has richer functionality).

Another problem of changing the layout, which occurs from time to time, has a different packaging option, which is valid in different compilers. One thing that can “hide” is that pragmas are often used in headers to set the packaging structure to a specific value, and sometimes you may find a heading that does this without changing it to the default value (or rather, the previous one parameter). If you have such a title, it’s easy to include it in the assembly for one module, but not another.

Answer 2

which sounds a bit strange, you have to show more code, it has to "move" if it is passed using ref, it is more like it is being copied and that it has a member function.

Perhaps the versions of the DLL are compiled against another version that you are referring to. check and make sure the header file matches the same version as the dll.

Compile the library if you can.