下面的“修复”对我来说非常混乱;这里的场景是根据大小有条件地决定是否使用堆栈和租用的缓冲区-这是一个相当小的范围,但有时是必要的优化,然而:对于“明显的”实现(第3个,将确定的赋值推迟到我们真正想要赋值),编译器向cs8353抱怨:
“span”类型的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]
基本上是一个no-op,意思是至少在编译的形式中工作数字1 = stackalloc[0]
与失败的数字2相同 = 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);
}
}
2条答案
按热度按时间uelo1irk1#
这个
Span<T> / ref
特征本质上是一系列规则,关于给定值可以通过值或引用转义到哪个范围。虽然这是根据方法作用域编写的,但简化为两个语句中的一个是有帮助的:无法从方法返回值
可以从方法返回值
span safety doc非常详细地介绍了如何计算各种语句和表达式的作用域。不过,这里的相关部分是关于如何处理本地人的。
主要的收获是在本地声明时计算本地是否可以返回。在声明local时,编译器检查初始值设定项并决定是否可以从方法返回local。如果存在一个初始值设定项,那么如果能够返回初始化表达式,则本地值将能够返回。
如何处理声明了local但没有初始值设定项的情况?编译器必须做出一个决定:它能不能返回?在设计特性时,我们决定默认值为“it can return”,因为这个决定对现有模式造成的摩擦最小。
这确实给我们留下了一个问题,即开发人员如何声明一个不能安全返回但又缺少初始值设定项的local。最终我们决定了
= stackalloc [0]
. 这是一个可以安全地进行优化的表达式,也是一个很强的指标,基本上是一个要求,即本地不安全地返回。知道这可以解释你所看到的行为:
Span<int> s = stackalloc[0]
:这是不安全的返回,因此稍后stackalloc
成功Span<int> s = default
:返回是安全的,因为default
安全返回。这意味着后者stackalloc
失败,因为您正在将不安全的值指定给标记为可安全返回的本地值Span<int> s;
:这是安全的,因为这是未初始化的局部变量的默认值。这意味着后者stackalloc
失败,因为您正在将不安全的值指定给标记为可安全返回的本地值真正的不利因素
= stackalloc[0]
方法是它只适用于Span<T>
. 这不是一个普遍的解决办法ref struct
. 实际上,对于其他类型的人来说,这并不是什么大问题。有人猜测,我们如何才能使它更普遍,但没有足够的证据来证明在这一点上这样做。snvhrwxg2#
不是“为什么”的答案;但是,您可以将其更改为三元运算符,将数组赋值的结果切片为一个范围: