Sharing a structure between a console application and a static library
-
We have a console application to represent a process plant model. This application has several functions for doing plant calculations. We have defined a structure and a global object for maintaining the data and doing calculations, which is initialized in one of the function. We assign and calculate values for the members of the object by using it in all the corresponding functions. For Eg: struct plantDB { short IMISC_I [300]; char LL1_I [300]; char LL2_I [300]; char MALF_I [300]; char REMP_I [300]; float REM_I [300]; float NXS [30][600]; float VAR_I [1500]; float VART_I [300]; float VRAMP_I [300]; . . . }; plantDB *ETest = new PlantDB; Sample of the function: float EULER(int N,int K,int TYPE,float DER,float MAX,float MIN,float FLAG) { float FACTOR = 0.0 ; float EULER; if ( FLAG ) ETest->VAR_I = 51.0 ; } We have defined a number of functions as shown above which changes the value of each of the members of ETest. Now our requirement is to identify and separate the functions to create a library to abstract it from users of the application. Now, when I create a static library application and add the files with all the functions, and add the lib in my original application to use the functions, the functions still need to use the same object ETest, which is used in the main application as well. Is there any way to share the structure between the main application and the static library. Can I use the createfilemapping for creating a shared memory to assign values in the main app as well as the static library?
you don't need to do anything special for this. static libs (as opposed to DLLs) get linked directly into your app so they'll use the same memory your main app does.
-
you don't need to do anything special for this. static libs (as opposed to DLLs) get linked directly into your app so they'll use the same memory your main app does.
-
A DLL gets mapped into the main application's address space, so it effectively has full access also.
yeah, you're right. i should've phrased that better; i was thinking more along the lines of dynamic CRT, which complicates new/delete.
-
you don't need to do anything special for this. static libs (as opposed to DLLs) get linked directly into your app so they'll use the same memory your main app does.
Chris Losinger wrote:
static libs (as opposed to DLLs) get linked directly into your app so they'll use the same memory your main app does.
dlls also get loaded into the process address space and therefore share app memory too. :)
-
Chris Losinger wrote:
static libs (as opposed to DLLs) get linked directly into your app so they'll use the same memory your main app does.
dlls also get loaded into the process address space and therefore share app memory too. :)
they won't share CRT memory management, however (which is really what i was trying to say).
-
they won't share CRT memory management, however (which is really what i was trying to say).
Doesnt this depend on the version of CRT you used to build them?
-
yeah, you're right. i should've phrased that better; i was thinking more along the lines of dynamic CRT, which complicates new/delete.
-
I don't see how, it is just allocating space on the heap which is part of the data sections in the address space. If this were an issue then hardly any DLL code would work properly.
a DLL with it's own copy of the CRT could be using a different version of the CRT than the main app uses. and that will lead to problems if you try to delete/free memory in one place that was allocated in the other. Allocating and freeing memory across module boundaries – The Old New Thing[^]
-
Doesnt this depend on the version of CRT you used to build them?
-
a DLL with it's own copy of the CRT could be using a different version of the CRT than the main app uses. and that will lead to problems if you try to delete/free memory in one place that was allocated in the other. Allocating and freeing memory across module boundaries – The Old New Thing[^]