LabVIEW and C++ Pointers

[Soroush]

Hi,

About the first limitation that I've declared, I think even feeding an empty array won't help in not duplicating the data.

What really frightened me was pointers to pointers! Does anybody know how to manipulate this case? I'm coming to the point that this can not be handled by LabVIEW. Disappointing!

Hope someone can help!

[falkpl]

The only way I have seen to get around the pointer to pointer issue is to make a function in c which returns the structure in a more labview friendly form, like a flat structure.  This is  hard work and there should be a better method for dealing with this in labview.  Since the memory management is mostly concealed in labview pointers, dereferencing and memory allocation is hard stuff (like it wasnt already the most difficult issue with traditional languages such as c).  I wish I had more to contribute but I have been stumpt more on this topic than any other in labview.

Paul

[Lycangeek]

Wow - I'm coming in late to this discussion...While it seems that the main question has been answered, I thought I throw in a few observations...

1. Pointer casting in LabVIEW

The basic summary answer - you can't - is correct. The problem is that LabVIEW always has type information (metadata) associated with any memory pointer. However, this type information is an internal implementation detail of LabVIEW and you can't take a C++ class or interface and turn it into the type info we use. This is sort of like compiling a C++ program with RTTI (runtime type information) so that you can use features such as dynamic_cast<>.

The big issue (which is probably what you run into with the "why can't LV do XYZ") is that LabVIEW is not a graphical C language. The entire way it approaches data, memory and execution is different from the C family of languages (and I include Java and .NET in this). When dealing with .NET, we have been able to provide better intergration because it to uses the concept of metadata and so we can use its type information. However, C++ doesn't have such a concept (even RTTI is a minor subset of true metadata). It is easy to think that C++ does have type information - but it is only at compile time. Once compiled, C++ keeps no type information around - it's just been told what memory offsets to access for a given pointer.

BTW - this is why Microsoft needed to create the extra concept of type libraries to get COM to work in Visual Basic. Type libraries are the metadata for COM - and is why we can provide better support to COM/ActiveX.

The general solution to this class of problem is always the wrapper functions accessed via external code interface (CIN, DLL Nodes, .NET, ActiveX). And Joe is right - .NET provides the best integration options for the above reasons.

2. Pre/Post Binding

It is kinda correct that LabVIEW does not support Post Binding (aka Late Binding), which is a common feature of VisualBasic. However, we do support it in the same way that C# and C++.NET support it - through reflection. This is actually what is going on in VB.NET, it is just that the compiler and VB support libraries generate the code for you automatically. So if you are interested in doing this, check out the MSDN docs for the System.Reflection namespace, especially System.Reflection.MethodInfo.

3. Pointers to pointers/Copying data

Yes, trying to get complex C-types into LabVIEW is a difficult task. Again the fundamental problem is the difference in "philosophy" about data. In C, you have a block of memory and then every access it. Thus in a multi-threaded world you are responsible for knowing what you can and can't access, semaphores/mutex, etc. LabVIEW takes a complete different track - it looks at who is doing what with the data and then creates copies when needed for different branches of the wire. This is actually a very sophisticated and optimized algorithm, but it does mean that you never need to worry about it. This is why LV developers get multithreaded support for free in most cases. At the basic concept of data, C/C++ and LabVIEW are on different fields.

The best solution for this sort of integration is to give a reference to the external memory object and provide access methods to manipulate the data, given full type information about it...wait a second, that is our .NET and COM integration... 🙂

[Joe_Gerhardstein]

Thanks, Brian.  I guess we always try to use our favorite tool in our toolbox, and it is always hard to remember and accept that there are different tools with different capabilities (e.g., a hammer and a screwdriver can both be used to put a screw into a wall, but one is a bit more messy than the other).  I have been happily using LabVIEW for so long that I just expect it to be able to do everything any other language can.  The expanded support for .NET in LabVIEW 8 will be greatly appreciated!


Joe

[Lycangeek]

No problem.

BTW - After talking about how to do reflection I realized it would be easier to just show it. Attached is a LV 7.1 VI that uses reflection to call a method on a .NET refnum of type System.Object. Note that the object created is a System.ArrayList but I cast it down to System.Object to show reflection at work...

[Joe_Gerhardstein]

Thanks -- that clears some things up!

Okay, I've learned my new thing for today.  Can I go home now?

Message Edited by Joe Gerhardstein on 08-09-2005 10:56 AM

[tst]

Brian, great explanation. 5 stars, thanks.

Was the icon in the example you posted created by you or is that the default icon for 8.0?

BTW, how about turning the URL in your signature to a link?

[Lycangeek]

Thanks - and good suggestion...I'm am now HYPERLINKED..KED...KED...ED...ED...D...

Boy, nothing slips past you, huh? Yes, that is the icon from a Constallation VI. I then did a Save For Previous to get the 7.1 support so I could post it...

[BartSchroder]

A related question:

I have an asynchronous data acquisition system. A DLL function expects a pointer to an allocated byte array, and returns immediately. After some time the byte array is filled with values. Another DLL function is used to determine when the data has been placed into the byte array. I can easily allocate a byte array (say as a shift register in a while loop), and pass a reference to it into the DLL. However, because no DLL function explicitly passes data back to the shift register (it being normally done in the background by the DLL asynchronously), I cannot find a mechanism which allows the normal Labview dataflow structure to see that data has been passed into the array, and how to let the array know how many values are in it. Does anyone know how to solve this problem?

All the references I have looked at have the dll pass the data to the shift register directly by wiring the output of the DLL CIN to the shift register.

The DLL is a third party one. I guess I could write a wrapper in CVI, but that means learning a bit more C, which I would like to avoid right now!

[rolfk]

---

@falkpl wrote:

I have found talking to pointers from labview to be one of the most difficult problems when developing with labview.  There is almost always to do it but this problem requires much more work than other issues that arise in labview.  Since memory management is shielded from the developer (to some extent) pointers seem foreign to Labview.  I have had some trouble when using WIN32 calls which take a pointer to a pointer, usually in the form of an object referenced as a handle which contains a pointer or an array.  The only work-around I have found is to write a dll library in c++ which acts as a accessor function, taking the handle to the object and returning a copy of the value stored (or the location of) the data needed.  This is time consuming and not all that elegant.  I too am interested in similar issues with both .net and c++ interfacing with labview.  Sorry if this doesn't answer your question but this discussion topic is of great interest to me.

---

It's not really much more difficult than using pointers in C. The problem here is that almost everything else is so much easier in LabVIEW than when using C, that this particular issue stands out like the Eiffel tower. And yes, the whole idea of LabVIEW to not make the programmer worry about memory allocation, that makes so many things really easy to do even for non-programmers, creates this huge gap. However there is really not so much LabVIEW can do to make it easier, since the whole interface simply gives not enough information to LabVIEW to do it on its own. A pointer can have many important but completely invisible specifics that depend on the envorinment for which it is and also about the programmer that made the software you want to interface and quite often even if this programmer already had his morning coffee and how well it tasted.

This leaves the user to know how it should be done, how the various translations and difficulties should be dealt with. LabVIEWs Call Library Node for instance does give quite some possibilities to configure pointers and covers with this the most common cases that happen with a standard C interface. There is however no-one preventing a programmer to use his own freaky scheme and create troubles here. On the other hand .Net has a whole slew of new types of pointer types, some of which can be automatically converted, some are at least managed and can be properly although explicitedly dealt with and then you have the ones that you have to do everything on your own. I for one do understand quite a lot about C interfacing, but would never attempt to give advice in something like what the original poster asked with .Net, since I simply do not know enough about .Net to really understand that (and honestly I do hope I can keep it that way for some time in the future ;-).

Rolf Kalbermatter