Class object returned from dll has different size in exe
My DLL and EXE are both compiled in the same VS2005, with almost the same settings (two projects in one solution). The EXE includes the same header file used by the DLL.
I tried two ways to new
an object defined in the DLL. One is new
directly in the EXE, and the other way is a call to a static method in the DLL and use the returned pointer. Both ways have the same wrong result.
I've checked the memory and found that the start address is correct, but somewhere inside the class, its size is bigger in the EXE than in the DLL. That is, the address of a member returned in the DLL is something like 0x20000060, after assigning this object in the EXE, this address becomes 0x20000064.
All my classes used _declspec(dllexport)
, BTW.
This is the only similar question I can find, but I don't use any built-in classes in the DLL:
Struct size containing vector<T> different sizes between DLL and EXE
I don't know what information you need to figure out the problem. So just ask for anything you need, I will provide that.
c++ dll
add a comment |
My DLL and EXE are both compiled in the same VS2005, with almost the same settings (two projects in one solution). The EXE includes the same header file used by the DLL.
I tried two ways to new
an object defined in the DLL. One is new
directly in the EXE, and the other way is a call to a static method in the DLL and use the returned pointer. Both ways have the same wrong result.
I've checked the memory and found that the start address is correct, but somewhere inside the class, its size is bigger in the EXE than in the DLL. That is, the address of a member returned in the DLL is something like 0x20000060, after assigning this object in the EXE, this address becomes 0x20000064.
All my classes used _declspec(dllexport)
, BTW.
This is the only similar question I can find, but I don't use any built-in classes in the DLL:
Struct size containing vector<T> different sizes between DLL and EXE
I don't know what information you need to figure out the problem. So just ask for anything you need, I will provide that.
c++ dll
add a comment |
My DLL and EXE are both compiled in the same VS2005, with almost the same settings (two projects in one solution). The EXE includes the same header file used by the DLL.
I tried two ways to new
an object defined in the DLL. One is new
directly in the EXE, and the other way is a call to a static method in the DLL and use the returned pointer. Both ways have the same wrong result.
I've checked the memory and found that the start address is correct, but somewhere inside the class, its size is bigger in the EXE than in the DLL. That is, the address of a member returned in the DLL is something like 0x20000060, after assigning this object in the EXE, this address becomes 0x20000064.
All my classes used _declspec(dllexport)
, BTW.
This is the only similar question I can find, but I don't use any built-in classes in the DLL:
Struct size containing vector<T> different sizes between DLL and EXE
I don't know what information you need to figure out the problem. So just ask for anything you need, I will provide that.
c++ dll
My DLL and EXE are both compiled in the same VS2005, with almost the same settings (two projects in one solution). The EXE includes the same header file used by the DLL.
I tried two ways to new
an object defined in the DLL. One is new
directly in the EXE, and the other way is a call to a static method in the DLL and use the returned pointer. Both ways have the same wrong result.
I've checked the memory and found that the start address is correct, but somewhere inside the class, its size is bigger in the EXE than in the DLL. That is, the address of a member returned in the DLL is something like 0x20000060, after assigning this object in the EXE, this address becomes 0x20000064.
All my classes used _declspec(dllexport)
, BTW.
This is the only similar question I can find, but I don't use any built-in classes in the DLL:
Struct size containing vector<T> different sizes between DLL and EXE
I don't know what information you need to figure out the problem. So just ask for anything you need, I will provide that.
c++ dll
c++ dll
edited Nov 20 '18 at 3:17
Remy Lebeau
332k18251445
332k18251445
asked Nov 20 '18 at 2:11
chyj4747chyj4747
236
236
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Well, I just found the problem.
The dll is wrote by another guy and he wrote something below
#ifdef _CUSTOM_DATA
#pragma pack(push, 1)
#endif
But in my exe, the macro _CUSTOM_DATA is not defined and also not inherited from his project. Then it causes a struct to have different address after compiling.
This is one of many reasons why it is very dangerous to pass non-POD data, such as class objects, across DLL boundaries, even if the same compiler is used on both sides. Different alignments, different memory managers (even different instances of the same memory manager), etc can really wreak havoc. So just don't do it.
– Remy Lebeau
Nov 20 '18 at 3:18
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53385241%2fclass-object-returned-from-dll-has-different-size-in-exe%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Well, I just found the problem.
The dll is wrote by another guy and he wrote something below
#ifdef _CUSTOM_DATA
#pragma pack(push, 1)
#endif
But in my exe, the macro _CUSTOM_DATA is not defined and also not inherited from his project. Then it causes a struct to have different address after compiling.
This is one of many reasons why it is very dangerous to pass non-POD data, such as class objects, across DLL boundaries, even if the same compiler is used on both sides. Different alignments, different memory managers (even different instances of the same memory manager), etc can really wreak havoc. So just don't do it.
– Remy Lebeau
Nov 20 '18 at 3:18
add a comment |
Well, I just found the problem.
The dll is wrote by another guy and he wrote something below
#ifdef _CUSTOM_DATA
#pragma pack(push, 1)
#endif
But in my exe, the macro _CUSTOM_DATA is not defined and also not inherited from his project. Then it causes a struct to have different address after compiling.
This is one of many reasons why it is very dangerous to pass non-POD data, such as class objects, across DLL boundaries, even if the same compiler is used on both sides. Different alignments, different memory managers (even different instances of the same memory manager), etc can really wreak havoc. So just don't do it.
– Remy Lebeau
Nov 20 '18 at 3:18
add a comment |
Well, I just found the problem.
The dll is wrote by another guy and he wrote something below
#ifdef _CUSTOM_DATA
#pragma pack(push, 1)
#endif
But in my exe, the macro _CUSTOM_DATA is not defined and also not inherited from his project. Then it causes a struct to have different address after compiling.
Well, I just found the problem.
The dll is wrote by another guy and he wrote something below
#ifdef _CUSTOM_DATA
#pragma pack(push, 1)
#endif
But in my exe, the macro _CUSTOM_DATA is not defined and also not inherited from his project. Then it causes a struct to have different address after compiling.
answered Nov 20 '18 at 2:38
chyj4747chyj4747
236
236
This is one of many reasons why it is very dangerous to pass non-POD data, such as class objects, across DLL boundaries, even if the same compiler is used on both sides. Different alignments, different memory managers (even different instances of the same memory manager), etc can really wreak havoc. So just don't do it.
– Remy Lebeau
Nov 20 '18 at 3:18
add a comment |
This is one of many reasons why it is very dangerous to pass non-POD data, such as class objects, across DLL boundaries, even if the same compiler is used on both sides. Different alignments, different memory managers (even different instances of the same memory manager), etc can really wreak havoc. So just don't do it.
– Remy Lebeau
Nov 20 '18 at 3:18
This is one of many reasons why it is very dangerous to pass non-POD data, such as class objects, across DLL boundaries, even if the same compiler is used on both sides. Different alignments, different memory managers (even different instances of the same memory manager), etc can really wreak havoc. So just don't do it.
– Remy Lebeau
Nov 20 '18 at 3:18
This is one of many reasons why it is very dangerous to pass non-POD data, such as class objects, across DLL boundaries, even if the same compiler is used on both sides. Different alignments, different memory managers (even different instances of the same memory manager), etc can really wreak havoc. So just don't do it.
– Remy Lebeau
Nov 20 '18 at 3:18
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53385241%2fclass-object-returned-from-dll-has-different-size-in-exe%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown