R
rtischer8277
Guest
Motivation: IMO, the declspec(dllexport) and declspec(dllimport) constructs have always been a very powerful feature of the MS dev platform. In contrast to other dev platforms, they let the developer pick and choose types and static data they want to put into their libraries and have reused at compile or runtime. There is no doubt that c++19/20 will incorporate and improve this feature in their modules construct.
Background and Question: My apps have a main EXE and numerous DLLs plus one other EXE app. My apps also use IPC constructs like pipes, TCP sockets, COM and multi-thread mutexing. But what I now am asking about is why, in some cases, I cant simply import a particular struct that is exported in the main EXE app and gets imported in the DLLS and other EXE using the declspec construct? My question doesnt involve data transfer at runtime (hence no need for IPC), but simple code reuse/explicit/implicit instantiation either at compile time for static EXEs or dynamically? My particular focus for this posting is importing an exported struct into an EXE from another EXE or DLL which fails at runtime for variables that allocate heap.
Sample Code: My sample programs show that if I try to use any kind of variable that either explicitly or implicitly allocates heap, then the import fails. The simple case is new wchar_t[100]. But implicit cases like std::make_shared and even instantiation of std::random_device from the <random> stl library also fail because of implicit heap allocation. The question is old, but IMO not really answered. I have created two very small win32 console apps, AllocFailExport and AllocFailImport, that illustrate the problem. These can be downloaded from this link: AllocFail. Compile the former first (I used VS2015). Then compile and run the latter. Then uncomment out the various lines that exercise the different kinds of allocation in the latter, and recompile to see the error.
IMO this code should work.
RT
Continue reading...
Background and Question: My apps have a main EXE and numerous DLLs plus one other EXE app. My apps also use IPC constructs like pipes, TCP sockets, COM and multi-thread mutexing. But what I now am asking about is why, in some cases, I cant simply import a particular struct that is exported in the main EXE app and gets imported in the DLLS and other EXE using the declspec construct? My question doesnt involve data transfer at runtime (hence no need for IPC), but simple code reuse/explicit/implicit instantiation either at compile time for static EXEs or dynamically? My particular focus for this posting is importing an exported struct into an EXE from another EXE or DLL which fails at runtime for variables that allocate heap.
Sample Code: My sample programs show that if I try to use any kind of variable that either explicitly or implicitly allocates heap, then the import fails. The simple case is new wchar_t[100]. But implicit cases like std::make_shared and even instantiation of std::random_device from the <random> stl library also fail because of implicit heap allocation. The question is old, but IMO not really answered. I have created two very small win32 console apps, AllocFailExport and AllocFailImport, that illustrate the problem. These can be downloaded from this link: AllocFail. Compile the former first (I used VS2015). Then compile and run the latter. Then uncomment out the various lines that exercise the different kinds of allocation in the latter, and recompile to see the error.
IMO this code should work.
RT
Continue reading...
