Re: exporting data from a dll - unresolved externals
Ben Voigt [C++ MVP] wrote:
"2b|!2b==?" <user@domain.invalid> wrote in message
news:_9udncYmgLGlah_anZ2dnUVZ8uWdnZ2d@bt.com...
I have a DLL project that I need to export a data variable from. I have
defined the variable in a .cpp file in the project like this
//C++ file (DLL Project)
class MYPROJ_API data_type
{
//Impl here ...
};
MYPROJ_API data_type exported_data;
//header file (project that consumes DLL)
extern MYPROJ_API data_type exported_data ;
It looks to me like the type is incomplete here, because the class
declaration isn't seen from the header file.
Not so. I kept the snippet simple for brevity sake. All other things
like library paths, pre-processor defines etc are taken as assumed -
(otherwise I will end up posting code for entire soln).
where MYPROJ_API is amacro that handles declspec import/export
dllexport of C++ classes is a bad idea. Optimally DLLs should only export
functions. You can pass around pointers to objects as long as they are
accessed through virtual functions (the client should only see an interface
definition with pure virtual functions and no data). Also memory should
always be freed in the same module that allocated it.
Once again, your assumptions are wrong. I kept the code snnipet I posted
here to a bare minimum for the previouslt stated reasons. the library is
much more 'complicated' than I let on - what I pasted here was the bare
bones that represented the salient features of the problem.
The DLL is a shared memory library - consequently, I cannot use any
virtual functions - as vtable fptrs will be meaningless in another
process space.