Support for abstract data types from a C DLL in LV?

[Brian Hall]

I have been asked by a LV user if I can provide a C DLL that will give him access to a C++ library I have developed for measurement uncertainty calculations. The central feature of the C++ library is that it defines a new abstract data type.

I think I can write C functions to interface to my C++ code. These functions would include: factory functions to create new instances of an abstract data type;and functions to do arithmetic and simple math on instances of the same abstract data type.

I would use a pointer to a C struct in the C function prototypes as a way to wrap the underlying C++ object references.

My question is: Is it going to be possible to make a LV interface to such a DLL? As far as I can see, LV
does not really support abstract data types: it does not seem to allow overloading of arithmetic operators, for example (is that correct?) and I saw somewhere that it is not happy with pointers to C struct types in calling functions from a DLL.

Does this project seem too ambitious for LV? If not, I would appreciate some pointers (sic) in the right direction.

[Greg_McKaskle2]

> My question is: Is it going to be possible to make a LV interface to
> such a DLL? As far as I can see, LV does not really support abstract
> data types: it does not seem to allow overloading of arithmetic
> operators, for example (is that correct?) and I saw somewhere that it
> is not happy with pointers to C struct types in calling functions from
> a DLL.
>
> Does this project seem too ambitious for LV? If not, I would
> appreciate some pointers (sic) in the right direction.

The way to integrate it is to build LV subVI wrappers around your type,
much like you will find written for the imaq image, the waveform
datatype, the SQL connections, etc. If your methods into your C++ class
have simple signatures, you can probably hook directly into it. If
the
signature isn't something you can map directly into LV, you can write a
wrapper function that simplifies the parameter list.

An alternative, if your object has all public data members, is to copy
it into a LV cluster or array, but it sounds like you want to keep the
members protected, so just expose your interface. The operators like +
are not overloadable at the moment, but since you can make an icon that
looks just like it and put it in your own palette, it is pretty similar.

Greg McKaskle

[rolfk]

Brian Hall wrote:

> I have been asked by a LV user if I can provide a C DLL that will give
> him access to a C++ library I have developed for measurement
> uncertainty calculations. The central feature of the C++ library is
> that it defines a new abstract data type.



> I would use a pointer to a C struct in the C function prototypes as a
> way to wrap the underlying C++ object references.
>
> My question is: Is it going to be possible to make a LV interface to
> such a DLL? As far as I can see, LV does not really support abstract
> data types: it does not seem to allow overloading of arithmetic
> operators, for example (is that correct?) and I saw somewhere that it
> is not happy with pointers to C struct types in calling functions from
> a DLL.

I'm
sure it is possible. I would probably start in treating the abstract
data type as an opaque pointer from the caller and in the case of LaVIEW
make a refnum out of it. The easiest way to create refnums is to use a
datalog refnum and drop an enum with a meaningful single name item
inside. This is then in fact a 32bit container which can be the pointer
to your data. It is a good idea to also create some sort of verifier
either inside each method wrapper itself or by a separate exported
function which takes such a pointer and verifies that it is a valid
object (not zero and not random value). In LabVIEW I would always call
this verifier before actually passing the refnum to the actual method if
this verification is not included in the wrapper already.
This is handy as LabVIEW is often used in a prototype environment and it
is easy to execute a VI with non intialized front panel controls and in
that way pass a 0 value (or a previously deallocated pointer) to the
underlying inte
rface, which if not protected will usually crash.

Rolf Kalbermatter