LabVIEW Wiki - User contributions [en]

GOOP - Graphical Object Oriented Programming

2009-02-11T00:08:13Z

Bsvingen:

== GOOP - Graphical Object Oriented Programming ==

GOOP stands for Graphical Object Oriented Programming. It is a category of frameworks for non-native object-oriented programming in LabVIEW that support by reference objects with VI methods for operating on data. Some versions of GOOP support inheritance and dynamic dispatch. GOOP really hit mainstream with the release of the [http://zone.ni.com/devzone/cda/tut/p/id/3391#3 GOOP Toolkit] from [http://www.endevo.se/ Endevo] and [[National Instruments]]. OpenG even has its own version of GOOP, called [[OpenGOOP]].

With LVOOP and queues, it is very easy to create basic GOOP functionality. Examples are included in the example folder installed with LabVIEW.

GOOP is great because it allows you to build components that encapsulate their data, functionality, and behavior. Why ecapsulate?...

=== Benefits of Encapsulation ===

*Maintainable
*Scalable
*Useable (and therefore Reusable)
*Testable
*Enable Multiple Developer Collaboration

=== See Also ===

{{Portal|GOOP}}

*[[DqGOOP]]
*[[GOOP History by Mattias Ericsson]]
*[[OpenGOOP]]

=== External Links ===

*[http://zone.ni.com/devzone/conceptd.nsf/appnotebynumber/1A7B60096CE0CDA986256A9A0074E4EC?OpenDocument&node=dz52000_us App Note 143] – Graphical Object Oriented Programming (Jorgen Jehander)
*[http://zone.ni.com/devzone/devzoneweb.nsf/Opendoc?openagent&958B0EEC7BE032B986256863000A6B64 Graphical Object-Oriented Programming with LabVIEW] – NI Week 1999 Presentation by Jörgen Jehander and Stepan Riha
*[http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/5d7db42c91f392fc86256aae00463d78?OpenDocument#3Download Download GOOP Toolkits] from NI
*[http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3EB6B56A4E034080020E74861&p_node=DZ52067&p_source=external Object-Oriented Techniques in LabVIEW] – Pure G examples from LV 4.1
*[http://www.endevo.se/ Endevo] - the company that supports/develops the GOOP Toolkit
*GOOP/G++ - Robert Burke's Web Page

[[Category:GOOP]]

DLL/shared library

2009-02-09T17:39:43Z

Bsvingen:

= General =

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 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.

 

= 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 "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. 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 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 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.

 

The header file for the C++ class base_class.h and the classes themselves in base_class.cpp:
<pre>#ifndef _BASE_CLASS_H_
#define _BASE_CLASS_H_

class base
{
public:
base(double x_in);
virtual ~base(void);
void set_x(double x_in);
void get_x(double* x_out);
void sqr_x(void);

private:
double x;
};

#endif /* _BASE_CLASS_H_ */
</pre>
The base_class.cpp (the classes)
<pre>#include "base_class.h"
#include <windows.h>

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

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

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

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

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

/* building a DLL */
#define DLLIMPORT __declspec (dllexport)

#ifdef __cplusplus
extern "C" { /* using a C++ compiler */
#endif

typedef struct base base; /* make the class opaque to the wrapper */

DLLIMPORT base* create_base(double x_in);
DLLIMPORT void set_x(base* LV_ref, double x_in);
DLLIMPORT void get_x(base* LV_ref, double* x_out);
DLLIMPORT void destroy_base(base* LV_ref);
DLLIMPORT void sqr_x(base* LV_ref);

#ifdef __cplusplus
}
#endif

#endif /* _C_DLL_WRAPPER_H_ */
</pre>
And the wrapper itself, c_dll_wrapper.cpp
<pre>#include "c_dll_wrapper.h"
#include "base_class.h"
#include <windows.h>

DLLIMPORT base* create_base(double x_in)
{
return new base(x_in);
}

DLLIMPORT void set_x(base* LV_ref, double x_in)
{
LV_ref->set_x(x_in);
}

DLLIMPORT void get_x(base* LV_ref, double* x_out)
{
LV_ref->get_x(x_out);
}

DLLIMPORT void destroy_base(base* LV_ref)
{
delete LV_ref;
}

DLLIMPORT void sqr_x(base* LV_ref)
{
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. */ ,
DWORD reason /* Reason this function is being called. */ ,
LPVOID reserved /* Not used. */ )
{
switch (reason)
{
case DLL_PROCESS_ATTACH:
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}

/* Returns TRUE on success, FALSE on failure */
return TRUE;
}
</pre>

DLL/shared library

2009-02-08T22:18:00Z

Bsvingen:

= General =

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 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.

 

= 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.

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++.

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.

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.

 

The header file for the C++ class base_class.h and the classes themselves in base_class.cpp:
<pre>#ifndef _BASE_CLASS_H_
#define _BASE_CLASS_H_

class base
{
public:
base(double x_in);
virtual ~base(void);
void set_x(double x_in);
void get_x(double* x_out);
void sqr_x(void);

private:
double x;
};

#endif /* _BASE_CLASS_H_ */
</pre>
The base_class.cpp (the classes)
<pre>
#include "base_class.h"
#include <windows.h>

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

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

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

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

void base::sqr_x(void)
{
x*=x;
}
</pre>
 

 The header file for the wrapper c_dll_wrapper.h
<pre>#ifndef _C_DLL_WRAPPER_H_
#define _C_DLL_WRAPPER_H_

/* building a DLL */
#define DLLIMPORT __declspec (dllexport)

#ifdef __cplusplus
extern "C" { /* using a C++ compiler */
#endif

typedef struct base base; /* make the class opaque to the wrapper */

DLLIMPORT base* create_base(double x_in);
DLLIMPORT void set_x(base* LV_ref, double x_in);
DLLIMPORT void get_x(base* LV_ref, double* x_out);
DLLIMPORT void destroy_base(base* LV_ref);
DLLIMPORT void sqr_x(base* LV_ref);

#ifdef __cplusplus
}
#endif

#endif /* _C_DLL_WRAPPER_H_ */
</pre>
And the wrapper itself, c_dll_wrapper.cpp
<pre>#include "c_dll_wrapper.h"
#include "base_class.h"
#include <windows.h>

DLLIMPORT base* create_base(double x_in)
{
return new base(x_in);
}

DLLIMPORT void set_x(base* LV_ref, double x_in)
{
LV_ref->set_x(x_in);
}

DLLIMPORT void get_x(base* LV_ref, double* x_out)
{
LV_ref->get_x(x_out);
}

DLLIMPORT void destroy_base(base* LV_ref)
{
delete LV_ref;
}

DLLIMPORT void sqr_x(base* LV_ref)
{
LV_ref->sqr_x();
}

BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle. */ ,
DWORD reason /* Reason this function is being called. */ ,
LPVOID reserved /* Not used. */ )
{
switch (reason)
{
case DLL_PROCESS_ATTACH:
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}

/* Returns TRUE on success, FALSE on failure */
return TRUE;
}
</pre>

DLL/shared library

2009-02-08T22:05:25Z

Bsvingen:

= General =

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 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.

 

= 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.

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++.

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.

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.

 

The header file for the C++ class base_class.h and the classes themselves in base_class.cpp:
<pre>#ifndef _BASE_CLASS_H_
#define _BASE_CLASS_H_

class base
{
public:
base(double x_in);
virtual ~base(void);
void set_x(double x_in);
void get_x(double* x_out);
void sqr_x(void);

private:
double x;
};

#endif /* _BASE_CLASS_H_ */
</pre>
The base_class.cpp (the classes)
<pre>#include "base_class.h"
#include <windows.h>

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

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

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

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

void base::sqr_x(void)
{
x*=x;
}
</pre>
 

 The header file for the wrapper c_dll_wrapper.h
<pre>#ifndef _C_DLL_WRAPPER_H_
#define _C_DLL_WRAPPER_H_

/* building a DLL */
#define DLLIMPORT __declspec (dllexport)

#ifdef __cplusplus
extern "C" { /* using a C++ compiler */
#endif

typedef struct base base; /* make the class opaque to the wrapper */

DLLIMPORT base* create_base(double x_in);
DLLIMPORT void set_x(base* LV_ref, double x_in);
DLLIMPORT void get_x(base* LV_ref, double* x_out);
DLLIMPORT void destroy_base(base* LV_ref);
DLLIMPORT void sqr_x(base* LV_ref);

#ifdef __cplusplus
}
#endif

#endif /* _C_DLL_WRAPPER_H_ */
</pre>
And the wrapper itself, c_dll_wrapper.cpp
<pre>#include "c_dll_wrapper.h"
#include "base_class.h"
#include <windows.h>

DLLIMPORT base* create_base(double x_in)
{
return new base(x_in);
}

DLLIMPORT void set_x(base* LV_ref, double x_in)
{
LV_ref->set_x(x_in);
}

DLLIMPORT void get_x(base* LV_ref, double* x_out)
{
LV_ref->get_x(x_out);
}

DLLIMPORT void destroy_base(base* LV_ref)
{
delete LV_ref;
}

DLLIMPORT void sqr_x(base* LV_ref)
{
LV_ref->sqr_x();
}

BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle. */ ,
DWORD reason /* Reason this function is being called. */ ,
LPVOID reserved /* Not used. */ )
{
switch (reason)
{
case DLL_PROCESS_ATTACH:
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}

/* Returns TRUE on success, FALSE on failure */
return TRUE;
}
</pre>