Changing class size between application and exe

Question

I have a console application that creates an instance of a class (say class X ). The class is defined in dll -> X.dll. When I print the class size in the application and inside one of the class functions (which is called when the application is called), I notice a change in size.

I am using VS 2010 and the application prints the class size as 6304 and the function prints it as 6352. I compiled exe and dll in Release | Win32 Both have WIN32 and _WINDOWS . But they do not have WIN64 .

What I noticed more is when I type sizeof(time_t) in exe, it prints 4, and the function in dll prints 8. Think this might be the problem.

Any idea where I should check?

Answer 1

I agree that this can be a problem if the DLL and EXE do not agree on the location of the data types .

However, I see no other explanation, except that you should use different project settings between two projects.

To find the culprit, mark both projects in the solution ( Ctrl + left click), then call the properties dialog. Now in the dialog box only those properties that are the same for both projects in the selected configuration will be displayed. Although the dialog at first glance looks modal, you can click one of the projects to see only its properties, and you can also mark both of them so that you can switch between them views . Until now, I usually found a problem using this technique.

If this fails, you can always compare the project files . However, they are quite common XML files make this more difficult.

Answer 2

Alignment problem ?

I already had to deal with such different sizes of the same class.

This leads at best to crashes (since your code will try to read / write outside the actual class data), and in the worst case, to strange errors (for example, set the value of a member variable to 42 and, when reading, see the value instead 1376256 or something like that.)

The reason was usually related to alignment problems.

here what you can do to find out if your problem is an alignment problem:

Before defining a class (or after) add the following line:

 #pragma pack(show) 

In the compilation output, you should see something like:

1>. \ Test_align.cpp (59): warning C4810: pragma pack (show) value == 8

This will show alignment when compiling the header. This will be displayed every time the header is included in the CPP file. This value should always be the same, both in compiling a DLL and in compiling an EXE.

If they are different, even once, then you have a problem with incorrect alignment ...

Default Struct Alignement for the project?

Perhaps your DLL has a default alignment of 1 by default, while the EXE has a different value. Please check the properties of both projects: Section "C / C ++", subsection "Generation of code", property "member alignment Struct".

For everything to work correctly, both projects must have the same value.

If the EXE and the DLL have different values, you should fix this (the default value is usually used: select "inherit from parent or project value").

Pragma package?

There is another way to break the alignment, i.e. using the #pragma pack statements. For instance:

 #pragma pack(show) // this will show the default value, ie 8 on my project struct Data8 // the sizeof this struct is 8 bytes { bool m_bValue ; int m_iValue ; } ; #pragma pack(push, 1) #pragma pack(show) // this will show the now current value, ie 1 struct Data1 // the sizeof this struct is 5 bytes, thanks to the packing { bool m_bValue ; int m_iValue ; } ; #pragma pack(pop) #pragma pack(show) // this will show again the default value, ie 8 

So, find the #pragma pack statements and make sure that they are always correctly installed and not set (if you have a click without a pop file, you may have an error).

Does the class have the same alignment for both projects?

If you did not find a problem in your class, perhaps the problem is that in one of the / struct classes that it inherits from or has as a member variable.

So check them out the same way you checked the main class.

Answer 3

In VS 2010, the time_t type must be a 64-bit value (whether the build target is 32-bit or 64-bit). You can override this for 32-bit target builds by specifying _USE_32BIT_TIME_T - so you need to make sure that it is not defined in your application assembly (or if you need to define it there, you also need to define it for your DLL or use the __time32_t type in the class definition DLL).

I also made sure that you do not have different packaging options set for the DLL and application build (note that the packaging configuration can be changed in poorly written header files). Find the /Zp compiler option in the build logs and / or #pragma pack in the headers without the corresponding #pragma pack() , which is reset to the default value.