I am a beginner, so, please bear with me, if this sounds too trivial.When i searched over the net for this, i got results showing how to do it. My question is why we do it in the first place ?
This is specific to the Windows platform, when you're developping C++ DLLs.
You have to use the __declspec(dllexport) modifier in order for your class and its methods to appear on the exported symbol list for your DLL.
This way, executables using your DLL can instanciate and call methods in these classes.
However you have to make sure that the executable and the DLL are compiled by the same version of the same compiler, because C++ symbols are exported using a relatively complex name mangling encoding (you can see that using depends.exe), which format varies from one compiler to another.
You don't need to export anything, unless you're creating a DLL. In that case, you can use the dllexport attribute as an alternative to the "old school" way of using .def files.
Technically you cannot export a class, only functions.
However you can designate on a class level that all functions be exported.
Exporting a function means that that function can be called from outside of the current executable.
This is needed when you are writing a dll for example which is a separate entity.
Related
I'm trying to import C++ functions from an instrument SDK into LabVIEW, and I'm running into issues with function decorations. I have a header file, the dll, a lib, and a .exp file. Unfortunately, I only have the function declarations in the header. If I had the definitions, I'd recompile the dll using the "extern C" flag I've read about.
I feel like I should be able to wrap the SDK's dll in some way using a definitions file or something to translate the compiled function names and effectively "unmangle" them for LabVIEW. Something (very loosely) like:
myFunc(arg){
?myFunc#Class#namespace##otherstuff(arg);
}
However, I haven't been able to find any discussion about this anywhere I've looked. It's entirely possible that it's abstracted enough that I don't recognize it when I see it, but I feel like it's more likely there's a reason this isn't done.
So, that's my question: can [referencing one dll from another] be done, since I've never seen dll imports combined with exports, and could I do that to get around the need to recompile the dll from the original code?
I'm guessing no, but I'd love to be wrong.
Say I have a bunch of functions exported in a C++ DLL.
A customer asks for some code implementation which uses only some of the functions in the DLL.
I'd like to give the customer a DLL with the relevant functions only (because full DLL is too big, I dont want to send code he doesnt need to see, etc..).
Is there any way to export only part of the functions easily (e.g. without adding/removing "__declspec dllexport" declarations everytime)?
Perhaps "hide" function from full DLL or re-compile slimmer DLL (but control which functions included in a clean way).
Thanks!
currently I am writing on a cpp-DLL. Afaik I have to put the functions into a class and a namespace if another cpp-program wants to use them. But I want to use the DLL with Labview too. Labview only recognizes the functions if they are free, e.g. neither in a namespace nor in a class. How can I implement this in my DLL? At the moment, I have set a #define-variable. If this variable is set, the functions are enclosed in a namespace and a class, if not, then they are free, but I have to compile the whole thing twice and I get two separate DLL files. So, what can I do if I only want one DLL file for both applications? (Please don't tell me to write the functions twice, the administrative outlay is even worse, I have tried this before).
Or do I simply have to call the DLL via LoadLibrary() when not using namespaces?
Thank you very much!
Afaik I have to put the functions into a class and a namespace if another cpp-program wants to use them.
This is plain wrong. You do not need to do this at all. On the contrary, DLL were originally introduced as libraries of C functions. C++ uses mangled names to represent namespace/class and types of parameters. There is no standard on this. Different compilers use their own scheme.
To summarize:
If you export simple C function from your dll, this will always work.
If you export classes or something from a namespace, this will
definitely work if other .exe/.dll is compiled with the same version of the
compiler. If not - this depends.
Regarding the LoadLibrary: it should be used when you do not know the name of the DLL or a name of the function in this DLL ahead or when you do not want to load this DLL at the beginning of your process. Otherwise (simple case) link your executable with implib for that DLL. This perfectly works for simple c-functions. LoadLibrary should be used when direct linking is not good for some reason.
When creating a Windows DLL one can easily choose exported symbols (using dllexport). In such situation symbols not exported are not visible outside the library. How can one get the same functionality on Linux?
In other words:
Let's say I have 10 functions in a project. Three of them should be exported, and the remaining 7 are helper functions that should not be usable from library API. How do i create SO file in such way, that lets me achive that?
On Linux/GCC by default everything is exported (depending on language rules, of course: something in an anonymous namespace will never be exported).
If you want to stop a symbol from being exported, you can use __attribute__((__visibility__("hidden"))). For example:
__attribute__((__visibility__("hidden"))) void myPrivateFunction();
I have a C++ DLL which was written in 1998, and I want to view the members (properties, fields, methods, constructors etc). I am of the understanding that the company who wrote the DLL is no longer about, but it is still used.
If I have only the DLL, is this possible? Or do you have to just know what is inside the DLL to work with it. If it is possible how would I go about this?
I am looking to work with the DLL from .Net via P/Invoke.
Get this: http://www.dependencywalker.com/ , use depends.exe to open the DLL, then activate "Undecorate C++ Functions" in the "View" menu. I mainly use it to find dependencies, but it also exposes entry points of DLLs.
This is not fool proof, because a DLL that exposes a class doesn't have to export its methods. For example, pure virtual method layout is sufficiently uniform that you can expose your instances as interface pointers with maybe a factory function. But it might solve your problem.
And regardless, you need a copy of dependency walker. :)
You can use a tool like IDA to dissasemble the binary and try to make out function names, but this can be hard. Why do you only have the DLL? It would be much easier to get the info from the export table of the associated lib or, even better, header files.
you can use VS Command prompt
a simple command is:
dumpbin /exports <nameofdll>
NirSoft offers 'DLL Export Viewer'
https://www.nirsoft.net/utils/dllexp.zip
Convinient UI application which can display dll members.