I am using C++ 2019 with std:c++/latest and have been able to create a module and import it within the same executable (it is a DLL library).
I want to use this module from another executable. How can I do this?
I have tried __declspec(dllexport) but I get a linker error.
dlls can be shared across programs, yes, as can libs.
exes cannot share code but you can call the exe one from another if you must, or start both and have process communications. I don't think you want this from what you said.
You might want to investigate the topic - IPC - Inter-Process Communication. A fundamental design of modern processors and operating systems is to keep processes seperate. That's why you are having difficulties with this. There are ways to do it, but you are going to have to jump through quite a few hoops. Better perhaps to think up another coding architecture for whatever it is you are trying to do.
I am talking about modules here. I figured one way to share them is to place them in LIBs and then having EXEs statically bind to the LIBs. I have rejected the idea of using DLLs as module containers so any __declspec(dllexport)/__declspec(dllimport) are out of the question.
I am talking about C++ 20 --- not the Microsoft extensions for DLLs. Standard C++ 20 gives us modules and the question becomes how can we package these modules for reuse. I first thought about DLLs but the more I think about it the more I realize LIBs are the best device to hold modules in C++ 20.
I don't exactly follow all the stuff about modules and C++ 20, but using COM (Component Object Model) technology we've been using binary code in 'In Process Servers', 'Out Of Process Servers', and 'Remote Servers' since circa 1995 or so.
For example, Microsoft Excel runs as a 'stand alone' executable. However, I can build an exe of my own which connects with Excel as an 'Out Of Process' COM server and I can call functions (Object Methods) within Excel and get the results back in my Exe. Alternately, I can load a COM object within my address space itself in the form of an 'In Process' COM Server. In that case it would be packaged within a Dll. Using that technology there is no need for __declspec(dllimport). Don't know if that helps. Just brainstorming here.