C++ 20: How can I use an exported struct in another executable?

Hi,

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.

For example:

1
2
export struct __declspec(dllexport) CSV_File {//......
}


This does not work.

How to share modules from different executables?

Regards,
Juan
I was able to use the struct by placing it in a static LIB. The question remains as to whether code can be shared from DLLs and EXEs...
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 need of courst both: dllexport and dllimport. When you create a dll _WINDLL is defined (or you define one yourself). Then you may write:

1
2
3
4
5
6
7
8
#ifdef _WINDLL
#define DLL_PORT __declspec(dllexport)
#else
#define DLL_PORT __declspec(dllimport)
#endif

struct DLL_PORT CSV_File {//......
}
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.

Sorry for the confusion..

Thanks for your feedback!
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.
I found this:

https://accu.org/journals/overload/28/159/sidwell/

It talks about compiling to object files before any importing is allowed. It also talks about situations where there is binary incompatibility.

Hope it helps !! :+)
Topic archived. No new replies allowed.