Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++ MFC
The host exe load a DLL and invloke a function in it,The function return a memory allocated on heap and return the pointer to host exe.when the deallocated the memory.It will be a error.
 
DLL
void DoSth(int *& pInt){
  pInt =new int[10];
}
 
Exe
 
void Main(){
  int * pArray=0;
  // invoke the DLL function
  DoSth(pArray);
  //this line will error 
  delete[] pArray;
}
 
I use VS2008 SP1. windows 7 32bit.
 
What's the problem?
Posted 24-Jun-13 17:00pm
Comments
Sergey Alexandrovich Kryukov at 24-Jun-13 22:32pm
   
Why won't you just return the pointer from DoSth? :-)
—SA
nv3 at 25-Jun-13 3:12am
   
Are you running exactly the code you are showing in your question? I doubt it, because your main function should be called "main" with a lower case 'm' and not "Main". From what I can see, your example should work if compiled with the same compiler settings for the DLL and EXE. Both should be operating on the same heap managed by the C++ runtime library.
H.Brydon at 25-Jun-13 21:07pm
   
Also, OP didn't say what the error was either...

1 solution

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

I have always held the practice that "memory allocation and deletion shall occur in the same execution unit." This allows you to solve a number of issues before they happen. You can "ship" a DLL and use it in mixed debug/release environments, you can mix compilers and compiler versions and you can mix languages. You can call your C++ code from C or Fortran.
 
The way to use this technique is to put your array in a class, and provide allocation and deletion APIs in the class, exported with public access. If you want to use a non-OOP language to call the code, export short stub functions that call the create/delete code in the class.
 
There are several concepts here but none are terribly complicated or complex.
  Permalink  
Comments
pwasser at 24-Jun-13 23:23pm
   
Well put.
jiazhiqiang at 25-Jun-13 0:25am
   
yes! Exactly!
But could you tell me the sample code I write above,It's MUST be error? and why?
If I use same version and same language and same compiler swiths.
In my perspective,the Dll is just affiliated to Exe.
 
thanks
pwasser at 25-Jun-13 3:25am
   
The answer given in this solution is the approach to take. A small redesign will solve your problem. There is no way anyone can debug your dll and exe without access to both projects. This is obvious from the comment by nv3.
 
http://stackoverflow.com/questions/4031249/dll-memory-management
nv3 at 25-Jun-13 3:42am
   
Harvey, I fully agree that the philosophy you describe in your solution is the way to go. But it doesn't explain why OP's code is failing. From what I see it should actually work, although it is not a good practice to allocate things in one load module and deallocate it in another.
H.Brydon at 25-Jun-13 10:06am
   
It could fail or at least cause problems if the .exe and .dll were built with different compilers or different versions of the same compiler product. Or if one is built with Debug settings and one is built with Release settings. One execution unit could also override operator new() but not the other. There are probably several other failure mechanisms I haven't thought of off the top of my head.
nv3 at 25-Jun-13 10:40am
   
That right. What made me curious is that OP promised to have compiled both with the same compiler switches. In that case it should actually run. I suspect that the real cause is some code that he did not post in his question. For example, some other code could meanwhile have corrupted the heap and when he does the delete[] in main, the heap corruption is what really throws back. Anyway, your answer got my 5.
H.Brydon at 25-Jun-13 21:09pm
   
Thanks - I have returned the favor and I'm sure will do so again. I like your answers...

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 562
1 Sergey Alexandrovich Kryukov 484
2 Maciej Los 325
3 DamithSL 233
4 Mathew Soji 195
0 OriginalGriff 7,168
1 Sergey Alexandrovich Kryukov 6,377
2 DamithSL 5,461
3 Manas Bhardwaj 4,876
4 Maciej Los 4,450


Advertise | Privacy | Mobile
Web04 | 2.8.1411023.1 | Last Updated 24 Jun 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100