Brandon said:
It's possible I'm missing something, but I really don't see the utility of
declaring an array by value when you would have to pass it around by handle
anyways. The complaint really comes down to whether there is a caret in the
written declaration or not -- there's no semantic advantages.
It would also mean deterministic destruction of contained objects. Also
it could help to think of it as an object with no copy constructor and
assignment operator (in ISO C++ by making them private members).
We extended the syntax to allow aggregate initialization of CLR arrays. CLR
arrays are always passed by handle. In the same regard, operators work on
handles for the exact same reason. Rather than force syntax to match
automatic storage semantics (even though it doesn't make sense), we took the
approach that it should work for garbage-collection semantics.
Another way would be to make it with built in array semantics, with the
name of the array to be resolved as a handle to the first object in the
array, or a handle in general.
However the template object in the stack makes more sense.
In summary an example:
void somefunc(array<int> ^h)
{
// ...
}
// ...
array<int> ar={1,2,3,4,5};
// ...
somefunc(%ar);
// ...
// ar is destroyed at the end of its scope.
There is a big difference between the capabilities of a valarray verses an
array. First, a CLR array today (i.e. the System::Array type) does not have
copy semantics, does not physically embed in types, has the capability of
being jagged, etc. Valarrays would have different properties. I can
understand the desire to make all types super flexible, but of course that
results in less useful types in the end. Engineering types for specific
purposes with good capabilities is the right thing for language designers
and library providers to do. Choosing between a selection of types is the
job of a good developer.
Yes I am not asking about a built in valarray, Tomas mentioned it. I am
talking about the current .NET array.
Best regards,
Ioannis Vranos
