problem in classes with same name and parent in DLL and EXE but with different implementation

Multi tool use
I have a class with name Menu and this class compiled with both dll and exe. i have another class with name ChildMenu that inherit from Menu and this class compiled with both dll and exe too.
i have a function in dll that create ChildMenu and return it as Menu.
extern "C"
{
Menu* createMenu();
}
and with implementation of
Menu* createMenu()
{
return new ChildMenu();
}
when I change the behavior of ChildMenu class in dll and recompile it but not in the exe, the behavior of the class not changed until i change the behavior of the class in exe and recompile it too.
ChildMenu has override one of Menu methods.the behavior change happend in overridden method.
i created the ChildClass in dll but its behavior comes from exe class.
why this happend?
c++ dll shared-libraries
|
show 9 more comments
I have a class with name Menu and this class compiled with both dll and exe. i have another class with name ChildMenu that inherit from Menu and this class compiled with both dll and exe too.
i have a function in dll that create ChildMenu and return it as Menu.
extern "C"
{
Menu* createMenu();
}
and with implementation of
Menu* createMenu()
{
return new ChildMenu();
}
when I change the behavior of ChildMenu class in dll and recompile it but not in the exe, the behavior of the class not changed until i change the behavior of the class in exe and recompile it too.
ChildMenu has override one of Menu methods.the behavior change happend in overridden method.
i created the ChildClass in dll but its behavior comes from exe class.
why this happend?
c++ dll shared-libraries
1
This looks more like a design issue to me. Perhaps your DLL shouldn't have anything to do with yourChildMenu
class at all?
– Some programmer dude
Dec 31 '18 at 7:26
1
It happens because you have two different implementations of the class. While the executable and the DLL are built separately, it's still breaks the One Definition Rule, and lead to undefined behavior.
– Some programmer dude
Dec 31 '18 at 7:30
1
Yes, and the DLL doesn't know anything about the definition in the EXE, and the EXE doesn't know anything about the definition in the DLL. Why are you even surprised that two different implementations of a class behaves differently?
– Some programmer dude
Dec 31 '18 at 7:49
1
That's not how it works. You should look at the DLL as a completely separate program. The code in the EXE and the DLL have nothing in common once built. All the EXE have is a pointer to what it believes is aChildMenu
object, an instance of its ownChildMenu
class. Which is totally separate and different from anyChildMenu
class in the DLL. The two differentChildMenu
classes might not even be related at all!
– Some programmer dude
Dec 31 '18 at 7:56
1
Assuming your goal is to separate interface and implementation, that's laudable and good. But you separate implementation from a different implementation. Either you move all of theChildMenu
class into the DLL, or move it all into the EXE. You can't have it both ways.
– Some programmer dude
Dec 31 '18 at 7:58
|
show 9 more comments
I have a class with name Menu and this class compiled with both dll and exe. i have another class with name ChildMenu that inherit from Menu and this class compiled with both dll and exe too.
i have a function in dll that create ChildMenu and return it as Menu.
extern "C"
{
Menu* createMenu();
}
and with implementation of
Menu* createMenu()
{
return new ChildMenu();
}
when I change the behavior of ChildMenu class in dll and recompile it but not in the exe, the behavior of the class not changed until i change the behavior of the class in exe and recompile it too.
ChildMenu has override one of Menu methods.the behavior change happend in overridden method.
i created the ChildClass in dll but its behavior comes from exe class.
why this happend?
c++ dll shared-libraries
I have a class with name Menu and this class compiled with both dll and exe. i have another class with name ChildMenu that inherit from Menu and this class compiled with both dll and exe too.
i have a function in dll that create ChildMenu and return it as Menu.
extern "C"
{
Menu* createMenu();
}
and with implementation of
Menu* createMenu()
{
return new ChildMenu();
}
when I change the behavior of ChildMenu class in dll and recompile it but not in the exe, the behavior of the class not changed until i change the behavior of the class in exe and recompile it too.
ChildMenu has override one of Menu methods.the behavior change happend in overridden method.
i created the ChildClass in dll but its behavior comes from exe class.
why this happend?
c++ dll shared-libraries
c++ dll shared-libraries
edited Dec 31 '18 at 8:32
nader
asked Dec 31 '18 at 7:21
nadernader
5219
5219
1
This looks more like a design issue to me. Perhaps your DLL shouldn't have anything to do with yourChildMenu
class at all?
– Some programmer dude
Dec 31 '18 at 7:26
1
It happens because you have two different implementations of the class. While the executable and the DLL are built separately, it's still breaks the One Definition Rule, and lead to undefined behavior.
– Some programmer dude
Dec 31 '18 at 7:30
1
Yes, and the DLL doesn't know anything about the definition in the EXE, and the EXE doesn't know anything about the definition in the DLL. Why are you even surprised that two different implementations of a class behaves differently?
– Some programmer dude
Dec 31 '18 at 7:49
1
That's not how it works. You should look at the DLL as a completely separate program. The code in the EXE and the DLL have nothing in common once built. All the EXE have is a pointer to what it believes is aChildMenu
object, an instance of its ownChildMenu
class. Which is totally separate and different from anyChildMenu
class in the DLL. The two differentChildMenu
classes might not even be related at all!
– Some programmer dude
Dec 31 '18 at 7:56
1
Assuming your goal is to separate interface and implementation, that's laudable and good. But you separate implementation from a different implementation. Either you move all of theChildMenu
class into the DLL, or move it all into the EXE. You can't have it both ways.
– Some programmer dude
Dec 31 '18 at 7:58
|
show 9 more comments
1
This looks more like a design issue to me. Perhaps your DLL shouldn't have anything to do with yourChildMenu
class at all?
– Some programmer dude
Dec 31 '18 at 7:26
1
It happens because you have two different implementations of the class. While the executable and the DLL are built separately, it's still breaks the One Definition Rule, and lead to undefined behavior.
– Some programmer dude
Dec 31 '18 at 7:30
1
Yes, and the DLL doesn't know anything about the definition in the EXE, and the EXE doesn't know anything about the definition in the DLL. Why are you even surprised that two different implementations of a class behaves differently?
– Some programmer dude
Dec 31 '18 at 7:49
1
That's not how it works. You should look at the DLL as a completely separate program. The code in the EXE and the DLL have nothing in common once built. All the EXE have is a pointer to what it believes is aChildMenu
object, an instance of its ownChildMenu
class. Which is totally separate and different from anyChildMenu
class in the DLL. The two differentChildMenu
classes might not even be related at all!
– Some programmer dude
Dec 31 '18 at 7:56
1
Assuming your goal is to separate interface and implementation, that's laudable and good. But you separate implementation from a different implementation. Either you move all of theChildMenu
class into the DLL, or move it all into the EXE. You can't have it both ways.
– Some programmer dude
Dec 31 '18 at 7:58
1
1
This looks more like a design issue to me. Perhaps your DLL shouldn't have anything to do with your
ChildMenu
class at all?– Some programmer dude
Dec 31 '18 at 7:26
This looks more like a design issue to me. Perhaps your DLL shouldn't have anything to do with your
ChildMenu
class at all?– Some programmer dude
Dec 31 '18 at 7:26
1
1
It happens because you have two different implementations of the class. While the executable and the DLL are built separately, it's still breaks the One Definition Rule, and lead to undefined behavior.
– Some programmer dude
Dec 31 '18 at 7:30
It happens because you have two different implementations of the class. While the executable and the DLL are built separately, it's still breaks the One Definition Rule, and lead to undefined behavior.
– Some programmer dude
Dec 31 '18 at 7:30
1
1
Yes, and the DLL doesn't know anything about the definition in the EXE, and the EXE doesn't know anything about the definition in the DLL. Why are you even surprised that two different implementations of a class behaves differently?
– Some programmer dude
Dec 31 '18 at 7:49
Yes, and the DLL doesn't know anything about the definition in the EXE, and the EXE doesn't know anything about the definition in the DLL. Why are you even surprised that two different implementations of a class behaves differently?
– Some programmer dude
Dec 31 '18 at 7:49
1
1
That's not how it works. You should look at the DLL as a completely separate program. The code in the EXE and the DLL have nothing in common once built. All the EXE have is a pointer to what it believes is a
ChildMenu
object, an instance of its own ChildMenu
class. Which is totally separate and different from any ChildMenu
class in the DLL. The two different ChildMenu
classes might not even be related at all!– Some programmer dude
Dec 31 '18 at 7:56
That's not how it works. You should look at the DLL as a completely separate program. The code in the EXE and the DLL have nothing in common once built. All the EXE have is a pointer to what it believes is a
ChildMenu
object, an instance of its own ChildMenu
class. Which is totally separate and different from any ChildMenu
class in the DLL. The two different ChildMenu
classes might not even be related at all!– Some programmer dude
Dec 31 '18 at 7:56
1
1
Assuming your goal is to separate interface and implementation, that's laudable and good. But you separate implementation from a different implementation. Either you move all of the
ChildMenu
class into the DLL, or move it all into the EXE. You can't have it both ways.– Some programmer dude
Dec 31 '18 at 7:58
Assuming your goal is to separate interface and implementation, that's laudable and good. But you separate implementation from a different implementation. Either you move all of the
ChildMenu
class into the DLL, or move it all into the EXE. You can't have it both ways.– Some programmer dude
Dec 31 '18 at 7:58
|
show 9 more comments
0
active
oldest
votes
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%2f53984709%2fproblem-in-classes-with-same-name-and-parent-in-dll-and-exe-but-with-different-i%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
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%2f53984709%2fproblem-in-classes-with-same-name-and-parent-in-dll-and-exe-but-with-different-i%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
ao P8oOkdVkq01bPMXK1BlDopKEdzcB3m1Z9R11YcyYUGW0n3w
1
This looks more like a design issue to me. Perhaps your DLL shouldn't have anything to do with your
ChildMenu
class at all?– Some programmer dude
Dec 31 '18 at 7:26
1
It happens because you have two different implementations of the class. While the executable and the DLL are built separately, it's still breaks the One Definition Rule, and lead to undefined behavior.
– Some programmer dude
Dec 31 '18 at 7:30
1
Yes, and the DLL doesn't know anything about the definition in the EXE, and the EXE doesn't know anything about the definition in the DLL. Why are you even surprised that two different implementations of a class behaves differently?
– Some programmer dude
Dec 31 '18 at 7:49
1
That's not how it works. You should look at the DLL as a completely separate program. The code in the EXE and the DLL have nothing in common once built. All the EXE have is a pointer to what it believes is a
ChildMenu
object, an instance of its ownChildMenu
class. Which is totally separate and different from anyChildMenu
class in the DLL. The two differentChildMenu
classes might not even be related at all!– Some programmer dude
Dec 31 '18 at 7:56
1
Assuming your goal is to separate interface and implementation, that's laudable and good. But you separate implementation from a different implementation. Either you move all of the
ChildMenu
class into the DLL, or move it all into the EXE. You can't have it both ways.– Some programmer dude
Dec 31 '18 at 7:58