DLL/shared library - Revision history

Q at 15:18, 9 June 2020

2020-06-09T15:18:32Z

← Older revision		Revision as of 15:18, 9 June 2020
Line 1:		Line 1:
			{{wikify}}
	= General =		= General =

Bsvingen at 17:39, 9 February 2009

2009-02-09T17:39:43Z

← Older revision		Revision as of 17:39, 9 February 2009
Line 15:		Line 15:
	= C++ =		= C++ =

	Calling C++ classes from LabVIEW can sometimes be useful. For instance, when you would like to use a special mathematical/scientific library that is written in C++. However, since LabVIEW only can call DLLs written in plain C, a wrapper must be made that "~~translate~~" the C++ classes to C function calls. This means that you have to write some C code that LabVIEW understands, to indirectly call the C++ classes that LabVIEW doesn't understand. Since calling C++ classes from C is a rather odd thing to do (you would rather ~~simply~~ use C++ to call C++ classes), ~~there is almost no references to this on the internet~~.		Calling C++ classes from LabVIEW can sometimes be useful. For instance, when you would like to use a special mathematical/scientific library that is written in C++. However, since LabVIEW only can call DLLs written in plain C, a wrapper must be made that "translates" the C++ classes to ordinary C function calls. This means that you have to write some C code that LabVIEW understands, to indirectly call the C++ classes that LabVIEW doesn't understand. Since calling C++ classes from C is a rather odd thing to do, there is almost no references to this on the internet (you would rather normally use C++ to call C++ classes),.

	Fortunately the wrappers are strightforward to code~~, and~~ the C++ code ~~doesn't need to be touched at all~~ by making the C++ classes opaque. What you end up with is objects exactly like GOOP ~~where you get a reference to them~~, only they are made in C++.		Fortunately the wrappers are strightforward to code. There is no need to touch any of the C++ code either, by making the C++ classes ''opaque''. What you end up with is objects that behave exactly like GOOP objects, only they are made in C++.

	The wrappers must be compiled with a C++ compiler, since ~~this is~~ the ~~only way to make them~~ opaque. In C++ a struct IS a class, so making the classes opaque is simply a matter of typedef'ing the class. Making the function calls C calls instead of C++ calls is done by the extern C directive.		The wrappers must be compiled with a C++ compiler, since an ordinary C compiler will not do the trick making the classes opaque. In C++ a struct IS a class, so making the classes opaque is simply a matter of typedef'ing the class to a struct with the same name. Making the function calls C calls instead of C++ calls is done by the extern "C" directive.

	Below is a very simple example  that shows the ~~priciple~~. It can also be downloaded with source and LabVIEW vi here: [http://forums.lavag.org/C-classes-from-LV-t12905.html forums.lavag.org/C-classes-from-LV-t12905.html]. In the real world, the most difficult part may be to "translate" LabVIEW types to C types and/or the other way around, as with ordinary DLLs. ~~This~~ must also be handled by the wrapper.		Below is a very simple example  that shows the principle. It can also be downloaded with source and a LabVIEW vi here: [http://forums.lavag.org/C-classes-from-LV-t12905.html forums.lavag.org/C-classes-from-LV-t12905.html]. In the real world, the most difficult part may be to "translate" LabVIEW types to C types and/or the other way around, as is the main problem with ordinary DLLs. Any such translation must also be handled by the wrapper and/or the vi.

	<br>		<br>
Line 45:		Line 45:
	</pre>		</pre>
	The base_class.cpp (the classes)		The base_class.cpp (the classes)
	<pre>		<pre>#include "base_class.h"
	#include "base_class.h"
	#include <windows.h>		#include <windows.h>

Line 66:		Line 65:
	void base::get_x(double* x_out)		void base::get_x(double* x_out)
	{		{
	*x_out = x;}		*x_out = x;
			}

	void base::sqr_x(void)		void base::sqr_x(void)
	{		{
	x*=x;		x*=x;
	}		}
	</pre>		</pre>
	~~<br>~~		The header file for the DLL wrapper, c_dll_wrapper.h

	~~<br>~~The header file for the wrapper c_dll_wrapper.h
	<pre>#ifndef _C_DLL_WRAPPER_H_		<pre>#ifndef _C_DLL_WRAPPER_H_
	#define _C_DLL_WRAPPER_H_		#define _C_DLL_WRAPPER_H_
Line 130:		Line 128:
	LV_ref->sqr_x();		LV_ref->sqr_x();
	}		}


			/* The rest must be included in any DLL, and is not part of the wrapper */

	BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle. */ ,		BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle. */ ,

Bsvingen at 22:18, 8 February 2009

2009-02-08T22:18:00Z

← Older revision		Revision as of 22:18, 8 February 2009
Line 45:		Line 45:
	</pre>		</pre>
	The base_class.cpp (the classes)		The base_class.cpp (the classes)
	<pre>#include "base_class.h"		<pre>
			#include "base_class.h"
	#include <windows.h>		#include <windows.h>


	base::base(double x_in)		base::base(double x_in)
	{		{
	x = x_in;		x = x_in;
	}		}

	base::~base ()		base::~base ()
	{		{
	/* clean up */		/* clean up */
	}		}

			void base::set_x(double x_in)
	void base::set_x(double x_in)
	{		{
	x = x_in;		x = x_in;
	}		}

	void base::get_x(double* x_out)		void base::get_x(double* x_out)
	{		{
	*x_out = x;		*x_out = x;}
	}

	void base::sqr_x(void)		void base::sqr_x(void)

Bsvingen at 22:05, 8 February 2009

2009-02-08T22:05:25Z

Show changes

Rolfk at 07:38, 7 May 2008

2008-05-07T07:38:20Z

← Older revision		Revision as of 07:38, 7 May 2008
Line 1:		Line 1:

	The first question would be if you really need to do this. While it is a powerful tool it is also tedious work to have to interface to external code through DLLs/shared libraries.		The first question would be if you really need to do this. While it is a powerful tool it is also tedious work to have to interface to external code through DLLs/shared libraries.

Line 8:		Line 7:
	The shared library interface in all OSes so far was designed for and around what C needs and can provide. Therefore one needs to know some basic principles about C and for more complex interfaces also relatively intimate knowledge about how a C compiler actually puts up things in memory and such. This is a very steep learning curve for someone not already familiar with C.		The shared library interface in all OSes so far was designed for and around what C needs and can provide. Therefore one needs to know some basic principles about C and for more complex interfaces also relatively intimate knowledge about how a C compiler actually puts up things in memory and such. This is a very steep learning curve for someone not already familiar with C.

	An extra difficulty is that the shared interface has none of the more modern features like automatic type checking and parameter validation like what ActiveX and .Net provide for instance. This means that one single error in the configuration of the Call Library Node or a bug in the shared library itself can and usually will have fatal consequences sooner or later. This can in the best case show as a Protection fault error dialog at runtime of that function, but can also cause so subtle damage that LabVIEW will only crash at some later point when trying to access information that was destroyed earlier on. One possibility is for instance that it will often crash when you try to close LabVIEW since it tries to deallocate resources that have been destroyed by a misbehaving shared library or configuration thereof earlier on.		An extra difficulty is that the shared library interface has none of the more modern features like automatic type checking and parameter validation like what ActiveX and .Net provide for instance. This means that one single error in the configuration of the Call Library Node or a bug in the shared library itself can and usually will have fatal consequences sooner or later. This can in the best case show as a Protection fault error dialog at runtime of that function, but can also cause so subtle damage that LabVIEW will only crash at some later point when trying to access information that was destroyed earlier on. One possibility is for instance that it will often crash when you try to close LabVIEW since it tries to deallocate resources that have been destroyed by a misbehaving shared library or configuration thereof earlier on.

Rolfk: New page: The first question would be if you really need to do this. While it is a powerful tool it is also tedious work to have to interface to external code through DLLs/shared libraries. For th...

2008-05-07T06:56:14Z

New page: The first question would be if you really need to do this. While it is a powerful tool it is also tedious work to have to interface to external code through DLLs/shared libraries. For th...

New page

The first question would be if you really need to do this. While it is a powerful tool it is also tedious work to have to interface to external code through DLLs/shared libraries.

For the rest of this text I will refer to shared libraries but this should be always read to mean DLLs too, which is the term Windows uses for shared libraries.

With the Import Library Wizard in LabVIEW 8.2 a lot of the actual work of interfacing has been automated but this is just an automatic tool and it can not do everything for you. Especially for more complex shared library interfaces it simply has to fail for particular functions and those are also the ones that are likely to take up hours and hours of fiddling, testing and learning about how a C compiler actually puts variables into memory.

The shared library interface in all OSes so far was designed for and around what C needs and can provide. Therefore one needs to know some basic principles about C and for more complex interfaces also relatively intimate knowledge about how a C compiler actually puts up things in memory and such. This is a very steep learning curve for someone not already familiar with C.

An extra difficulty is that the shared interface has none of the more modern features like automatic type checking and parameter validation like what ActiveX and .Net provide for instance. This means that one single error in the configuration of the Call Library Node or a bug in the shared library itself can and usually will have fatal consequences sooner or later. This can in the best case show as a Protection fault error dialog at runtime of that function, but can also cause so subtle damage that LabVIEW will only crash at some later point when trying to access information that was destroyed earlier on. One possibility is for instance that it will often crash when you try to close LabVIEW since it tries to deallocate resources that have been destroyed by a misbehaving shared library or configuration thereof earlier on.