Padding clusters to match C structures

[rolfk]

Well, NI ETS and Win32 are the same as far as such details are concerned. LabVIEW uses always byte packing on these platforms. So if your DLL is compiled for default alignment you will have to make sure that you create clusters with proper padding built into.

For 64-bit platforms it always uses the default alignment for that platform, which as far as I know is 8 byte for all systems you can run LabVIEW on nowadays (Windows 64-bit, Linux 64-bit, Mac OSX 64-bit). For these platforms you should not need any special padding in the clusters to make it work with your DLL. Incidentally the padded clusters should also work on these platforms since Win32 default alignment is also 8 byte.

The only one I'm not sure about is Linux 32-bit and Mac OSX 32-bit. But for the latest versions of LabVIEW they are not supported anymore so it is kind of a moot point already.

[drjdpowell]

---

@schddc wrote:
I was hoping there was a better way to do this.

---

There is, as I originally told you.  Write a clean and simple API so interfacing with your dll is easy from any wrapper in any language.  Do not require those wrappers to deal with “packing”.  

[Yamaeda]

---

@drjdpowell wrote:

If you are the developer if this c dll then I suggest you provide functions to write/read parts of your structure, then only handle the structure in LabVIEW as an integer pointer passed between these functions.  Then details about packing never come up.

---

I take it you mean instead of sending function(*struct), you send function(part1, part2 ... partn)? That's a solid and easy solution.

/Y

[drjdpowell]

---

@Yamaeda wrote:

---

@drjdpowell wrote:

If you are the developer if this c dll then I suggest you provide functions to write/read parts of your structure, then only handle the structure in LabVIEW as an integer pointer passed between these functions.  Then details about packing never come up.

---

I take it you mean instead of sending function(*struct), you send function(part1, part2 ... partn)? That's a solid and easy solution.

/Y

---

Oh, you can and should use function(*struct), just never expect the wrapper code to modify or read the parts of struct.  They should just pass a pointer between your API functions.   So, for example, one can have:

GetParam(*struct)

Setting=ReadMySetting(*struct)

SetMyOtherSetting(*struct,OtherSetting)

Implemented in LabVIEW, *struct would just be a pointer-sized Integer.  So GetParam(Int32 or Int64)

[schddc]

I don't have to much flexibly to change the C dll anymore as it's already been released and in use. I can add new APIs but I prefer not to have any breaking changes if possible.

I only have 1 function which has a prototype of GetCapabilities(int, *struct) . The structure has several nested structures. The C dll provides an interface to physical hardware. This function returns all of the device capabilities. It's something an end user would call once and then they would make conditional checks based on the number of channels and types of features of their specific hardware model.

[drjdpowell]

---

@schddc wrote:

I don't have to much flexibly to change the C dll anymore as it's already been released and in use. I can add new APIs but I prefer not to have any breaking changes if possible.

I only have 1 function which has a prototype of GetCapabilities(int, *struct) . The structure has several nested structures. The C dll provides an interface to physical hardware. This function returns all of the device capabilities. It's something an end user would call once and then they would make conditional checks based on the number of channels and types of features of their specific hardware model.

---

Simple then.  Just get going and add the API functions that do those "checks".  They would be very simple functions and don't involve any breaking changes.