06-07-2006 05:57 AM
07-21-2006 07:55 PM
07-22-2006 02:43 AM
07-23-2006 03:04 PM
This is not really a bug but a performance optimization.
@Tomi M wrote:
If I remeber correctly, the problem is illustrated by the code below. The example is for 1D array, but I encountered it with multidimensional arrays. The problem occurs if the array dimension sizes are set before the call to NumericArrayResize as it seems NumericArrayResize relies on the information on the dimSize or dimSizes parameter to find out how large the array is currently. This behaviour is ok, if it would just be documted.
#include "extcode.h"
/* Typedefs */
typedef struct {
int32 dimSize;
int32 elt[1];
} Array;
typedef Array **ArrayHdl;
long ResizeArray(ArrayHdl arg1,const long newsize)
{
/* This fails, array is not resized by NumericArrayResize. No error is returned either. */
(*arg1)->dimSize=newsize;
NumericArrayResize(iL,1,&arg1,newsize);
return noErr;
}
long ResizeArray(ArrayHdl arg1,const long newsize)
{
/* this works */
NumericArrayResize(iL,1,&arg1,newsize);
(*arg1)->dimSize=newsize;
return noErr;
}
07-24-2006 02:03 AM
07-24-2006 03:30 PM - edited 07-24-2006 03:30 PM
Consider the C API of LabVIEW as some sort of legacy remainder. They can't get rid of it for compatibility reasons but are not spending much time into it either. If they could they would simply drop it. Solves the trouble of documenting it, and even more troublesome supporting it to people outside of the company.
@Tomi M wrote:
Thanks Rolf,
Could NI just please consider documenting all the exceptions in the behaviour of the LabVIEW C interface.
I was trying write very optimized code when I encountered the issue. In the case of my code it would have been more efficient to set the dim sizes before the call to ResizeNumericArray and not after, I won't go into detail why. It was quite hard to find the problem that made LabVIEW to crash, since the code I wrote was literally correct according to LabVIEW documentation. The array I passed to the function was never NULL, so there always was an valid array handle present before I tried to modify the dimsizes.
Message Edited by rolfk on 07-24-2006 10:31 PM
07-24-2006 03:51 PM
07-24-2006 04:11 PM
I think you are pointing out the wrong examples. Match Regular Expression is a built in node of LabVIEW. It does use internally the PCRE library and you are free to do so too. The only thing you can't do is automatic type adaption and resizing and to the best of my knowledge that are things you can only add in the source code of LabVIEW itself. Allowing to do that for external users would mean opening up almost the entire object interface of LabVIEW, documenting a few hundred extra APIs and in general publishing the LabVIEW source code may be simpler solution. That the last isn't going to happen soon is probably clear to anybody.
@Tomi M wrote:
If what you say Rolf is true, I must say that it's kind of weird. The C interface, even though not used by most of LabVIEW developers, allows those few developers using it to build outstanding LabVIEW products. Integrating C and LabVIEW can bring valauable missing functionality into LabVIEW. Those using this integration can develop LabVIEW toolkits that can extend the capabilities of LabVIEW and in such a way bring LabVIEW more customers that would otherwise choose some other solution for their problem.
This is a bit off topic, but I have been quite disapointed in the way NI is developing some tools only for internal use and never even plan to release those. This gives NI a strategic advantage over other LabVIEW developers. NI can develop LabVIEW toolkit products that other LabVIEW developers cannot, since they don't have access to the same technology. For example developers outside NI cannot develop VIs similar to "Match Regular Expression" or "Storage" VIs since NI doesn't give access to technology used to develop these features anybody outside NI. Since LabVIEW is for quite a small niche market, NI would benefit if there were better products available that would utilize LabVIEW. A more open LabVIEW would bring more developers, more products and more users in the end. I have wondered if NI is using it's near a monopoly position in data-acquisition software development environment according to U.S. and E.U. legistlation. Microsoft has been sued multiple times over similar kind of protectionism in Windows.
07-24-2006 04:38 PM
Well it is used by extremely few people, and not because it is badly documented (it is actually quite well documented) but because most people that would know how to use it would not start to use LabVIEW, and those that use LabVIEW do not care to learn the exponential bigger complications of C programming in comparison to LabVIEW.
@Tomi M wrote:
If what you say Rolf is true, I must say that it's kind of weird. The C interface, even though not used by most of LabVIEW developers, allows those few developers using it to build outstanding LabVIEW products. Integrating C and LabVIEW can bring valauable missing functionality into LabVIEW. Those using this integration can develop LabVIEW toolkits that can extend the capabilities of LabVIEW and in such a way bring LabVIEW more customers that would otherwise choose some other solution for their problem.
07-24-2006 04:44 PM - edited 07-24-2006 04:44 PM
Message Edited by Tomi M on 07-25-2006 12:47 AM