50

下面的“修复”让我很困惑；这里的场景是根据大小有条件地决定是使用堆栈还是租用缓冲区 - 这是一个非常利基但有时是必要的优化，但是：使用“明显”的实现（第 3 号，推迟明确的分配，直到我们真正想要分配它），编译器向 CS8353 抱怨：

'Span<int>' 类型的 stackalloc 表达式的结果不能在此上下文中使用，因为它可能暴露在包含方法之外

简短的复制（完整的复制如下）是：

// take your pick of:
// Span<int> s = stackalloc[0]; // works
// Span<int> s = default; // fails
// Span<int> s; // fails

if (condition)
{   // CS8353 happens here
    s = stackalloc int[size];
}
else
{
    s = // some other expression
}
// use s here

我在这里唯一能想到的是，编译器确实在标记stackalloc正在转义stackalloc发生事件的上下文，并且挥舞着一个标记说“我无法证明这在该方法的后面是否安全” ，但是通过stackalloc[0]在开始时，我们将“危险”上下文范围推得更高，现在编译器很高兴它永远不会逃脱“危险”范围（即它实际上从未离开方法，因为我们正在声明在顶部范围内）。这种理解是否正确，就可以证明的内容而言，这只是编译器的限制？

（对我来说）真正有趣的是，从根本上讲，无论如何= stackalloc[0]都是无操作的，这意味着至少在编译后的形式中，工作数字 1与失败的数字 2 相同。= stackalloc[0]= default

完整再现（也可在 SharpLab 上查看 IL）。

using System;
using System.Buffers;

public static class C
{
    public static void StackAllocFun(int count)
    {
        // #1 this is legal, just initializes s as a default span
        Span<int> s = stackalloc int[0];
        
        // #2 this is illegal: error CS8353: A result of a stackalloc expression
        // of type 'Span<int>' cannot be used in this context because it may
        // be exposed outside of the containing method
        // Span<int> s = default;
        
        // #3 as is this (also illegal, identical error)
        // Span<int> s;
        
        int[] oversized = null;
        try
        {
            if (count < 32)
            {   // CS8353 happens at this stackalloc
                s = stackalloc int[count];
            }
            else
            {
                oversized = ArrayPool<int>.Shared.Rent(count);
                s = new Span<int>(oversized, 0, count);
            }
            Populate(s);
            DoSomethingWith(s);
        }
        finally
        {
            if (oversized is not null)
            {
                ArrayPool<int>.Shared.Return(oversized);
            }
        }
    }

    private static void Populate(Span<int> s)
        => throw new NotImplementedException(); // whatever
    private static void DoSomethingWith(ReadOnlySpan<int> s)
        => throw new NotImplementedException(); // whatever
    
    // note: ShowNoOpX and ShowNoOpY compile identically just:
    // ldloca.s 0, initobj Span<int>, ldloc.0
    static void ShowNoOpX()
    {
        Span<int> s = stackalloc int[0];
        DoSomethingWith(s);
    }
    static void ShowNoOpY()
    {
        Span<int> s = default;
        DoSomethingWith(s);
    }
}
4

2 回答 2

54

该Span<T> / ref特性本质上是一系列关于给定值可以通过值或引用转义到哪个范围的规则。虽然这是根据方法范围编写的，但将其简化为以下两个语句之一会很有帮助：

  1. 该值不能从方法返回
  2. 该值可以从方法返回

跨度安全文档详细介绍了如何为各种语句和表达式计算范围。不过，这里的相关部分是关于如何处理本地人的。

主要的收获是，本地是否可以返回是在本地声明时计算的。在声明局部变量时，编译器检查初始化器并决定局部变量是否可以从方法返回。如果有初始化程序，那么如果能够返回初始化表达式，则本地将能够返回。

您如何处理声明了本地但没有初始化程序的情况？编译器必须做出决定：它可以返回还是不能返回？在设计该功能时，我们决定默认为“它可以返回”，因为这是对现有模式造成最小摩擦的决定。

这确实给我们留下了一个问题，即开发人员如何声明一个不能安全返回但又缺少初始化程序的本地。最终我们确定了= stackalloc [0]. 这是一个可以安全优化的表达式，也是一个强有力的指标，基本上是一个要求，即本地返回是不安全的。

知道这解释了您所看到的行为：

  • Span<int> s = stackalloc[0]：返回是不安全的，因此后者stackalloc成功了
  • Span<int> s = default：这是可以安全返回的，因为default可以安全返回。这意味着后者stackalloc失败，因为您分配的值不能安全返回到标记为安全返回的本地
  • Span<int> s;：这是安全的返回，因为这是未初始化的本地人的默认值。这意味着后者stackalloc失败，因为您分配的值不能安全返回到标记为安全返回的本地

该= stackalloc[0]方法的真正缺点是它仅适用于Span<T>. 这不是ref struct. 在实践中，尽管对于其他类型来说这不是什么大问题。有一些关于我们如何使它更普遍的猜测，但没有足够的证据证明在这一点上这样做是合理的。

于 2021-04-27T20:09:11.360 回答
20

不是“为什么”的答案；但是，您可以将其更改为三元运算符，将数组分配的结果切片到 Span：

public static void StackAllocFun(int count)
{
    int[] oversized = null;
    try
    {
        Span<int> s = ((uint)count < 32) ?
            stackalloc int[count] :
            (oversized = ArrayPool<int>.Shared.Rent(count)).AsSpan(0, count);

        Populate(s);
        DoSomethingWith(s);
    }
    finally
    {
        if (oversized is not null)
        {
            ArrayPool<int>.Shared.Return(oversized);
        }
    }
}
于 2021-04-27T19:21:53.883 回答