Good writeup of the current situation. Let me explain why the array
issue is the way it is, and hopefully you'll agree with where we are
going...
For the case (2a in the document)
void foo(int[] a)
There are two issues to consider. The first is that while the array
object is passed in by value, the value is the "pointer" to the array.
Thus I can't change which instance the parameter pointers to (at least
as far as the caller is concerned), but I am completely free to change
the data in the array. The classic example is
int Read(char[] buffer)
In this case, you're going to read into a pre-allocated buffer until
either the stream is empty or the buffer is full. If this was an input
only terminal on an invoke node, you wouldn't be able to see the
results. This leads into two issues...
1. The memory used to hold onto the array in LV and .NET are different,
but not only in address. LV is a native app with it's own memory
manager. .NET is a garbage-collected system. Thus there is no way for
an array in LV and an array in .NET to share memory (assuming LV is the
caller, which is the case here). This means we need to do data copies.
Given that, we have to copy the data back out of .NET in order for the
LV user to see it.
2. LV is a data flow language. This is a very subtle, but a very
important distinction. The impact in this case is to realize that there
are no variables in LV (ignoring the "added" concept of local and
global variable nodes). The wire is a representation of data flowing
from one control point to another. Once the data "gets off the wire",
it has to get onto another wire to "exist". Thus, as far as LV is
concerned, there isn't any difference between an
int[] and an
int[]&.
Internally, we know the difference and do the right thing with .NET,
but to the LV code, they are the same. The fact that the callee can't
change the size of the array in the first case and can in the second
case doesn't matter - LV is always prepared for changes in the data, so
the output wire is always the "right size".
Result: The way we handle arrays in 8.0.1 is how we plan to continue handling them
For the case (2b and 2c in the document)
Here we agree - for the same reasons as above, the fact that there is a
& doesn't matter to LV. We are fixing that oversight.
To answer the question,
void foo(ref int[] data)
or
void foo(out int[] data)
is the C# syntax. The & notation is for C++ and is also how it's
represented internally by the CLR. When I write examples, I often use
C# since more people are familiar with that, but when you see it in LV,
it's an & because that is what .NET wants to see.
And the Magic 8 Ball Says
I'm afraid that only marketing knows what the next version of LV is
called. To be absolutely safe, all I can say is that Europa is the code
base we are currently planning to be the next release, and is the one
with the dereference fix
🙂
Since I can't say any more than that, I must recommend that you talk to
your local sales rep to see what they can tell you about the release
and/or the beta.
In case you're curious
Because it's often confused people, let me explain the difference between
ref and
out (or in C++, the
[InAttribute] and the
[OutAttribute]). As far as the CLR is concerned, there is no difference - the C++ syntax is the closest to the true form.
void foo(int[]& foo)
That is the same "digital" signature for both cases. Like most
attributes in .NET, they are merely decoration stored in the meta data of the assembly and ignored by the CLR during execution. The
out or
OutAttribute
is simply a hint to whomever is interested that any information passed
in that argument is ignored. This is important for clients like LV (we
don't provide an input) or .NET remoting (it doesn't need to waste
network bandwidth sending the starting state across).
