Setting up and reading an array of .NET structs in LabVIEW - labview

I have a .NET struct containing floats and ints, and I have a method that returns an array of that struct.
How do I initialize a reference to an array of .NET structs in LabVIEW, so that I can read out the floats and ints?

Can't you use the .NET structs method (GetArray)? That would return an array of .NET objects, that you could read in a for loop for instance.
Could you show your code?
If you want to initaite the .NET struct you would need to create a .NET constructor for you object.

Related

Bridging between incompatible types in Swift using memory rebind

I have been trying to solve a problem in my app. I get an NSArray from an Objective-C API and need to read it as an array of double values in the Swift app.
So the bridging needed is between NSArray in Objective-C and a Double Array in Swift.
NSArray ----> Double array
I don't want to typecast the array using as [Double] since this array is huge and thus the process of typecasting is time consuming.
The array needs to be consumed using Accelerate framework functions, so just need to rebind the memory to Double.
I have tried rebinding the memory to Double but the application behaves unexpectedly. I am not sure if this is because bridging can only happen between compatible types.
What is the right way to bridge two incompatible types in an optimized way?
Is it even possible or O(N) is the only way?

Swift's Array type is bridged to Foundation's NSArray class, how?

In Swift Language Guide we read the following:
Swift’s Array type is bridged to Foundation’s NSArray class.
How can Swift's Array be bridged to Foundation's NSArray class when the first is a value type and the latter is a reference type? Doesn't bridging mean having an interface in a language to use a code in a different language?
The value/reference distinction here is a bit of a red herring.
Bridging is (maybe surprisingly) straightforward. There's an internal protocol, _ObjectiveCBridgeable, that describes a type which can be cast between an ObjC and a Swift type. The compiler replaces, e.g., your mySwiftArray as NSArray with a call to _bridgeToObjectiveC().
You can see Array's conformance to the protocol in Foundation. It's simple Swift code: each method just constructs an instance of the appropriate bridged type.
So there's not really any relation to the fact that the native Swift Array is a value type.
As for that piece; while externally a "value", Swift.Array actually has an internal pointer to its own storage. If you think about it for a second, this is the only sensible way to make it work. You don't want to be moving the 101 things in an array every time you assign it to a new variable. Just a nice quick copy of a pointer. (Of course you need to do the copy if you want to change something, but it's delayed as long as possible.)
You can see basically the same behavior in a C struct with a field that's a reference to some allocated memory:
typedef struct _Array {
void * payload;
} Array;
Array c;
c.payload = malloc( /* Whatever */ );
Array d = c;
Assigning to d makes a copy of the pointer to the storage, but there's only one chunk of allocated memory, which hasn't moved or been copied. (And to extend this backwards, you can "bridge" this to NSArray in the same way Swift.Array does: by providing an appropriate function that does the transformation.)
We can reason how this is might be supported without watching a video, though do that as well!
Doesn't bridging mean having an interface in a language to use a code in a different language?
Well a bridge in general is just a means of connection...
How can Swift's Array be bridged to Foundation's NSArray class when the first is a value type and the latter is a reference type?
... which doesn't preclude conversion as part of the process.
To subclass an NSArray just requires overriding two methods count and objectAtIndex:. To bridge a Swift array to an Objective-C one a subclass of NSArray can be defined which contains (a copy of) the Swift array, i.e. stored in an instance variable.
This subclass would implement the two required Objective-C methods in terms of the corresponding methods on the wrapped Swift array, doing any additional processing necessary; e.g. during indexing to wrap a Swift value as an opaque Objective-C object or convert it to a corresponding Objective-C object. Such a process would be "lazy", individual elements in the Swift array only being converted to Objective-C objects when, and if, they are accessed. Once converted values can be cached to avoid re-conversion.
The actual implementation will be optimised and probably take advantage of private information. However as the above shows there is nothing to prevent a bridge presenting a value type in Swift as a reference type in Objective-C, and vice-versa.
HTH

How does CFBridgingRelease act on objects retained in a Core Foundation container?

I'm creating a CFMutableArray and populating it dynamically with CFStrings.
If I'm bridging this CFMutableArray over as a NSMutableArray using CFBridgingRelease, what happens to its children?
When I access entries in the array afterwards, can I treat them as ARC-managed NSStrings or should I do something fancy in the CFArrayCallbacks struct to handle that transfer automatically?
If I'm bridging this CFMutableArray over as a NSMutableArray using CFBridgingRelease, what happens to its children?
Likely, nothing. Of course, this depends on what you've put into the CFArray you're casting. If you have put C-types that aren't toll-free bridged to Objective-C types (some parts of CoreFoundation are still not bridged to anything yet), then the behavior of the resulting NS-type is undefined.
When I access entries in the array afterwards, can I treat them as ARC-managed NSStrings or should I do something fancy in the CFArrayCallbacks struct to handle that transfer automatically?
You shouldn't need to do anything if you're dealing with bridged types in a bridged array. The values contained within the array will already have been retained (so they should not get sent anymore -retain's by the array), and should be fine to just pull out and use.

C array vs Obj-C array

When an array is created in Objective-C using alloc init, how is the memory managed when objects are added to the array?
I would like to know how this relates to C when you create an array and malloc, the allocated size needs to be the size of the expected array or the array memory needs to be reallocated.
How do these relate or what is a good way to understand the way the C code works.
Does the objective-c arrays memory get handled internally when objects are added or how does this work?
An Objective-C array follows the same memory management rules as other Objective-C objects. If you allocate it, you'll need to release it.
C arrays and Objective-C arrays are similar in concept, but implemented quite differently. A C array is a contiguous block of memory with very little other than a language construct governing how you use it. Objective-C arrays are objects with significant built-in functionality. They dynamically resize themselves (if they're mutable) to accomodate added elements. They properly retain and release the objects that they store. They can sort themselves, filter themselves, insert objects, delete objects, etc. You should make no assumptions about how they're implemented.
Apple's documentation should give you a much better idea of what's possible with Objective-C arrays (and while you're at it, look at the other collection classes too). Start reading here:
Collections Programming Topics
NSArrays (And by extension NSMutableArrays) retain the objects added to them, and send them all release messages when the array itself is deallocated.
The upshot of this is that a common pattern is to alloc an object, initialize it, hand it to the array, and then release it. Since the array retains it for itself, it'll last as long as the array itself does, or until you instruct the array to get rid of it. You will never need to send it another release message, the array machinery takes care of that.
I'd guess that the Mutable arrays are implemented as something like a linked list, so they can be easily expanded and contracted later. It's just a list of pointers, and maybe a little metadata. Since it doesn't create any objects handed to it, just puts it's own leash on them, all it needs to do it have a place for the pointer to the object.

Can I restrict the NSMutableArray object type?

I want the NSMutableArray only store "MyObject" only... ...instead of any objects. How can I do this? thz.
There is no concept like C# Generics or C++ Templates in Objective-C, as discussed here before, but you could create a class which exposes an array and has add and remove-methods which take only your object type (see here).