Re: exporting data from a dll - unresolved externals
"2b|!2b==?" <user@domain.invalid> wrote in message
news:5umdnS5_I5NEPB7anZ2dnUVZ8qydnZ2d@bt.com...
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).
You said the class definition is in the implementation file. Therefore the
other project, having only the header file, doesn't see it.
If that is not accurate then rework your snippet to show where the class
definition is.
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.
What assumptions are you referring to here?
The DLL is a shared memory library - consequently, I cannot use any
virtual functions - as vtable fptrs will be meaningless in another process
space.
Separate your shared data from your code. The code pointers are valid
between the exe and dll, and should be kept out of the shared memory segment
itself.
You are using file mappings for shared memory, and not .SHARED sections,
correct?