LabVIEW
interface .dll - can I involve some C++ code
No you don’t but the alternatives are usually GCC based and the GCC folks always had an ambivalent feeling towards Windows.
The mentality of: a REALl programmer is just using the frigging command line or goes through the joy of installing an additional make environment is pretty strong. And that command line has to be of course Gnu based so add another extra joyful installation. And besides real programmer go Unix so don’t try to make it to pleasant for anyone insisting on using Windows!
50MB for a bare metal C compiler installation is maybe possible but don’t expect to call Windows API functions, the Windows SDK weights in at several 100 MB alone very easily! And don’t expect to do much more either! 50MB was reasonable 20 years ago, nowadays the manpages and other documentation alone will weight in with more!
Also while this C++ library doesn’t really make use of object classes with methods it is still C++ and there is no universally defined ABI that all C compiler builders adhere to. So it is never guaranteed that you can call C++ libraries from another compiler than what the library is created with, under some conditions not even different versions of the same compiler family. Welcome in the exciting world of C(++) compilers! 😀
@Steffen01 wrote:
Ok, that new dll has been just released, the olt SOAP based stuff will slowly die, still got time to somehow make a wrapper. Seems to ve very delicate business, some simple vis from the wizard even crash, only meant to put in one string and det some string in retursn, but seems was not declared as expected. Anyway, that no longer involves Labview
The Import Library Wizard is NOT a magician. But to be able to import functions perfectly from only a header file would require magic abilities or the experience of some well versed C programmer, together with knowledge that sometimes is contained in more or less cryptic documentation for the library and in absence of such documentation through trial and error with lots of crashes. That's life of a C programmer and the Call Library Node can't avoid you from feeling that pain. It only is a means to let you interface to external code in shared libraries, not a guarantee that it won't crash if you do something wrong. And without additional knowledge from information contained in prosa text in the documentation for that API, most APIs, except the really trivial ones only using scalar parameters, are not possible to call reliable.
Any VI library created with the Import Library Wizard MUST be carefully reviewed by someone who knows about C programming and the peculiarities of the involved API, to be a really reliable way of calling that API. Anything else is more or less a random crash generator!
Personally I almost never use the Import Library Wizard. It doesn't add a lot since I have to review the code and quite frequently modify it anyhow significantly and the convenience of having at least the VIs itself created automatically is of limited value since I do not like the style of the VIs and the icons it generates.
Great that you found a solution and also reported about it. I would like to give some comments. They are not meant as critique but based on many years of my own experience trying to interface to external shared libraries in LabVIEW:
1) I do not understand the comment that you need to declare the output variable in order for LabVIEW to find it. If you want to return something to the caller you have of course have to return that to the caller, either trough the function return value or a reference parameter. That's completely independent of LabVIEW as caller. The only difference is that LabVIEW does not support arbitrary function return values. The only thing it supports are strings and scalar numeric. The reason for that is memory management (and in the case of a string, the function better returns a static allocated string that remains valid for a brief time after returning to the caller. LabVIEW is not going to try to deallocate it as it does not know how to do that). Anything else can not be properly managed without resorting to calling specific memory management routines and there are generally several different ones, under Windows you have about half a dozen memory managers to choose from and then the C runtime malloc. Except that your DLL may be compiled with a different C compiler (version) than the calling LabVIEW app and then malloc() in your DLL is not working on the same heap as free() in LabVIEW, as the C runtime is typically compiler specific. So if caller and callee do not absolute perfectly agree on which memory manager to use, you can not let one allocate memory and the other deallocate it. The basic principle in C programming therefore is:
- memory should be always allocated and deallocated by the same entity, be it caller or callee and never a shared responsibility for any specific C object (any memory block in C that stores some information)
- if you want to share management of C objects, callee and caller need to perfectly agree which family and incarnation of memory management calls they will use. This can be either that the caller (such as in LabVIEW) provides a specific set of memory manager functions to use for any objects received from LabVIEW or passed back to LabVIEW. The opposite can be that the callee provides a (set of) functions to manage the objects it allocates and returns to the caller. That way it is always guaranteed that allocation and deallocation happen from the same managed heap. This is also why .Net is called managed. It has very specific rules about who is responsible for allocation and deallocation of memory objects and what runtime functions are to be used to do that. LabVIEW in that sense is also managed but its management contract is substantially different to .Net (and predates .Net by at least 15 years).
2) The only difference in your original DLL and the LabVIEW specific wrapper is that your original DLL is compiled as C++ module and your wrapper declares the function explicitly as extern "C". So the wrapper only really serves as a means to export an explicitly C style function without C++ name mangling. That's not strictly necessary as the Call Library Node is perfectly able to let you select the name mangled function too. Yes the Import Library Wizard will most likely not like the C++ ism in the header file but to write a wrapper just to be able to let the Import Library Wizard import your functions is a very roundabout way to do business.
3) I have found that the use of pch.h is almost always causing more trouble than it solves. I always remove that from a project and disable precompiled header use in the project compiler settings. Unless you compile a project with several 100 or 1000 header files, it also doesn't really give you much of a measurable performance improvement.
4) As to your problem about the wrapper not finding the dependency DLL. Read up on the LoadLibrary() function, where Windows searches for DLLs when trying to resolve dependencies. There are only very specific locations it will search for and it is usually best to try to resolve to these locations or implement your own dependency loader in your own DLL (this is however a very advanced programming topic). I'm not sure what declaring a DLL as friend exactly does, but my guess is that it somehow adds a manifest to the DLL, that declares what other DLLs and/or their locations it wants to have found (maybe limited to its own directory). It's a possibility but another complication in the build tool chain that can eventually go wrong.
@Steffen01 wrote:
But if you put that into Labview, you have 2 inputs but no outputs in the caller node. So instead I have to make it int sumAB(int a, int b, int out). But this is what I got given, supplier will not do something just for me
Look again!
