创建一个 ImmutableArray 而不复制

Question

有没有什么方法（可能是一个肮脏的hack）来创建一个只使用指定数组而不是复制它的 ImmutableArray？

我有一个我知道不会更改的数组，我想创建一个 ImmutableArray 以允许客户端安全地访问我的数组。

看source code for ImmutableArray，我看Create方法也无济于事：

public static ImmutableArray<T> Create<T>(params T[] items)
{
    if (items == null)
    {
        return Create<T>();
    }

    // We can't trust that the array passed in will never be mutated by the caller.
    // The caller may have passed in an array explicitly (not relying on compiler params keyword)
    // and could then change the array after the call, thereby violating the immutable
    // guarantee provided by this struct. So we always copy the array to ensure it won't ever change.
    return CreateDefensiveCopy(items);
}

编辑：在 GitHub 上有一个关于此功能的请求，这也提供了最快的 hack 使用：https://github.com/dotnet/corefx/issues/28064

Answer 1

如果您知道数组的确切长度，您可以使用ImmutableArray.CreateBuilder<> 加上.MoveToImmutable()，这将在不复制Builder 的内部创建ImmutableArray<>：

var builder = ImmutableArray.CreateBuilder<int>(4);
builder.Add(1);
builder.Add(2);
builder.Add(3);
builder.Add(4);
ImmutableArray<int> array = builder.MoveToImmutable();

如果builder.Capacity != builder.Count.MoveToImmutable()方法会抛出异常

请注意，构建器的其他方法（如.ToImmutable()）将创建数组的副本。

Answer 2

还有另外两种 hacky 方法，都在这里建议：https://stackoverflow.com/a/3799030/4418060（一个在回答，一个在评论）。

1. 将一种结构类型编组为另一种。
2. 不安全地将一个转换为另一个。

第一个涉及创建一个反映 ImmutableArray 布局的新结构类型（它是单个 T[] 字段）并更改 CLR（运行时）看到的该结构的类型。结构如下所示：

public struct HackImmutableArray<T>
{
    public T[] Array;
}

1. 编组：

   static ImmutableArray<T> HackyMakeImmutable<T>(T[] array)
   {
       var arrayObject = (object)new HackImmutableArray<T> { Array = array };
       var handle = GCHandle.Alloc(arrayObject, GCHandleType.Pinned);
       var immutable = (ImmutableArray<T>)Marshal.PtrToStructure(handle.AddrOfPinnedObject(), typeof(T));
       handle.Free();
       return immutable;
   }
   

2. 不安全的铸造（好帮手written here，在this blog post 中找到）。 Casting 使用Unsafe System.Runtime.CompilerServices.Unsafe NuGet 中提供的静态类

   using System.Runtime.CompilerServices;
   
   static ImmutableArray<T> HackyMakeImmutable<T>(T[] array)
   {
       return Unsafe.As<T[], ImmutableArray<T>>(ref array);
   }
   

第二个选项“不安全”但相当安全，因为我们可以肯定地假设 ImmutableArray 的结构布局不会改变，这是一个定义特性，而且它也可能比任何其他解决方案都快得多。

Answer 3

https://github.com/dotnet/corefx/issues/28064 他们推荐最快的方法是使用 System.Runtime.CompilerServices.Unsafe：

ImmutableArray<T> im = Unsafe.As<T[], ImmutableArray<T>>(ref array);

Answer 4

这可能是个坏主意，他们可以用同样的伎俩对付你，但你可以用反射来作弊：

public static ImmutableArray<T> GetImmutableArray<T>(T[] arr)
{
    var immutableArray = ImmutableArray.Create(new T[0]);
    var boxed = ((object) immutableArray);
    var t = boxed.GetType();
    var fi = t.GetField("array", BindingFlags.NonPublic | BindingFlags.Instance);
    fi.SetValue(boxed, arr);
    return (ImmutableArray<T>)boxed;
}

然后这样称呼它：

var arr = new int[] { 1, 2, 3 };
Console.WriteLine("Arr: " + string.Join(",", arr)); //Arr: 1,2,3
var imm = GetImmutableArray(arr);
Console.WriteLine("ImmutableArray: " + string.Join(",", imm)); //ImmutableArray: 1,2,3
arr[0] = 234;
imm[0] = 235; //Compile Error
Console.WriteLine("ImmutableArray: " + string.Join(",", imm)); //ImmutableArray: 234,2,3

反射成本必须与 Array.Copy 成本进行权衡。

Answer 5

您需要ImmutableArray<T> 还是IReadOnlyList<T> 就足够了？如果是后者，您总是可以实现一个非常轻量级的数组包装器来满足您的需求：

public class ImmutableArrayWrapper<T>: IReadOnlyList<T>
{
     public static ImmutableArrayWrapper<T> Wrap(T[] array)
         => new ImmutableArrayWrapper(array);

    private readonly T[] innerArray;

    private ImmutableArrayWrapper(T[] arr) {
         if (arr == null)
             throw new ArgumentNullException();

         innerArray = arr; }

    public int Count => innerArray.Count();
    public T this[int index] => innerArray[index];

    //IEnumerable<T>...
}

现在您可以安全地将包装器传递给您的客户端。

Answer 6

ReadOnlyCollection<T> 在许多情况下可用于实现相同目的。它不提供对原始数组的访问权限——Items 属性受到保护。

不过，使用ReadOnlyCollection<T> 而不是ImmutableArray<T> 有两个缺点：

1. 发生额外分配。 ReadOnlyCollection<T> 是一个封装了IList<T> 的类，而ImmutableArray<T> 是一个封装了T[] 的结构体。
2. 集合的接收者对不变性的保证较弱。集合无法从外部修改，但创建它的人仍可能持有对原始数组的引用并可以使用它来修改集合。

可以通过文档来保证不会发生此类修改，但它仍然比技术上强制执行的保证要弱一些。