memory address of a member variable of argument ob

Question

class SomeClass {
//some members
MemberClass one_of_the_mem_; }

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

Problem

address of one_of_the_mem_ changes during the time the dll call is dispatched.

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 object remains constant. It is only the member whose address shift by c every time.

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

Code :

Code from Exe

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

Code in DLL

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

Update 1:

I compared the Offsets of members following Michael's instruction and they are the same in both cases.

Update 2:

I found a way to dump the class layout and noticed the difference in size, I have to figure out why is that happening though.

linked is the question that I found to dump class layout.

Update 3:
Final Update : Solved the problem, much thanks to Michael Burr.

it turned out that one of the build was using 32 bit time, _USE_32BIT_TIME_T was defined in it and the other one was using 64 bit time. So it generated the different layout for the object, attached is the difference file.

Answer 1

that sounds a bit wierd, you should show more code, it should 'move' if it being passed by ref, it sounds more like a copy of it is being made and that having the member function called.

Perhaps the DLL versions is compiled against a different version that you are referencing. check and make sure the header file is for the same version as the dll.

Recompile the library if you can.

Answer 2

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

For example, if one was built using debug flags and other wasn't or even if different compiler versions were used. For example, the libraries used by different compiler versions might have subtle differences and if your class incorporates a type defined by the library you could have different layouts.

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

These kinds of issues make using C++ classes across DLL boundaries a bit more fragile than using straight C interfaces. They can occur in C structures as well, but it seems like C++ libraries have these differences more often (I think that's the nature of having richer functionality).

Another layout-changing issue that occurs every now and then is having a different structure packing option in effect in the different compiles. One thing that can 'hide' this is that pragmas are often used in headers to set structure packing to a certain value, and sometimes you may come across a header that does this without changing it back to the default (or more correctly the previous setting). If you have such a header, it's easy to have it included in the build for one module, but not another.