Setting up a call library node for a DLL

[wiebe@CARYA]

---

@rolfk wrote:

---

wiebe@CARYA wrote:

---

@rolfk wrote:

---

It doesn't just require you to know C programming. It also requires you to know what a C compiler does when putting data structures and pointers to buffers into memory in order to be able to decide which option you need to use.

---

But you need to know that anyway, because you want to communicate with it!

Well if you write C code some of that complexity is not really important to know! For instance:

typedef struct
{
    char myInlineString[25];
    char *myStringPointer;
} DataRec;

DataRec dataRec;

dataRec.myStringPointer = malloc(25);
sprintf(dataRec.myInlineString, "Hallo World");
sprintf(dataRec.myStringPointer, "Hallo World");

is syntactically correct. The C compiler takes care about creating the right code to simply take the pointer for the myStringPointer variable and create code to create a reference to the offset in the dataRec structure to the first byte of the myInlineString. If you want to access these variables from an environment like LabVIEW these two things are totally different!

Doesn't that only apply if you use the same compiler?

The argument earlier was that there was no way to tell how the compiler would deal with arrays.

[wiebe@CARYA]

---

@rolfk wrote:

For the inlined (fixed size) array, no Flatten is needed at all as shown in this thread. I would say that the Flatten solution only makes the whole thing more complex. You feel like the convert to cluster is a bad thing, but logically it is the right thing. C only does it different since it is so much easier to write:

struct
{
    int32 data[256];
};

instead of:

struct
{
    int32 data1;
    int32 data2;
    int32 data3;
    int32 data4;
    ........
    int32 data255;
    int32 data256;
};

Logically this would be more correct!! But I bet you that every C programmer would have been throwing his computer out of the window after having writting such a definition for the second time.

The Array to Cluster isn't a bad thing. I was just exploring options...

[rolfk]

---

wiebe@CARYA wrote:

---

Doesn't that only apply if you use the same compiler?

The argument earlier was that there was no way to tell how the compiler would deal with arrays.

---

No, I never said anything that it was compiler depending!

Arrayhandling is pretty standard both for fixed size and pointers. The only thing that can vary is alignment but that is not so much compiler dependent than more what the programmer configured for his project or with a pragma in the code.

Another thing is who has to allocate the memory and who deallocates it but that is depending on the programmer too. Most easiest is to have the caller do it but that has a problem that usually for return buffers the caller can't know how big the buffer must be. Solution here is either to require a minimum size or the API allows to query the size by passing in the first run a NULL pointer for the output. The problem there is that the function needs to calculate the whole buffer then twice, once to return the required size and once more to then fill in the buffer. And there is a chance that the required buffer my need to be bigger the second time as the underlaying information has changed. Many problems even here.

Things get more complicated when the memory is aligned inside the function and passed back and the caller then somehow has to deallocate it. This has nothing with compilers to do really except that you can't just call free() in the caller and hope the buffer gets properly deallocated but the only solution for that is to have the DLL also export a memory deallocation routine as it is the only entity that can make sure to call the correct memory manager routines. 

[torresh87]

Hello All,

I was away from my computer for the holiday and came back to a full thread.

Seems this topic is very complicated. Playing with the vi before heading home Wednesday I noticed that the the array to cluster node was setup to 128 element size. I changed the value to 256 and made a vi that I could call the library over the long weekend. It has now ran over 30k calls without a crash. 

As some of you have mentioned, in particular rolfk mentioned that: 

"A two small buffer is almost the only thing that could occasionally crash for this function. If the calling convention was wrong it would crash at every call!"

It seems he was correct. I will keep you all posted if anything changes. 

I have included my vi and dll for you reference 

[wiebe@CARYA]

---

@rolfk wrote:

---

wiebe@CARYA wrote:

---

Doesn't that only apply if you use the same compiler?

The argument earlier was that there was no way to tell how the compiler would deal with arrays.

---

No, I never said anything that it was compiler depending!

Arrayhandling is pretty standard both for fixed size and pointers. The only thing that can vary is alignment but that is not so much compiler dependent than more what the programmer configured for his project or with a pragma in the code.

Never mind, that was a remark about memory allocation, not how arrays are passed.