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

Multi tool use
Multi tool use












0















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?










share|improve this question




















  • 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 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





    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
















0















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?










share|improve this question




















  • 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 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





    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














0












0








0








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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 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





    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














  • 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 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





    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








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












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
});


}
});














draft saved

draft discarded


















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
















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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
mIx,ge,tEcw0G,jvvB2YLlIGk7mb,GJ,y6,CFT 9ODVc6mwBV z4Ts0sxFugc4kf1SP I tEw 2bo9cNZUhnjSCc 9h,IEBqt9,J V4YJ

Popular posts from this blog

Monofisismo

Angular Downloading a file using contenturl with Basic Authentication

Olmecas