在C＃中，包装原始值的结构是否为零成本抽象？

有时我想在原始双打中添加更多的类型安全。一个想法很多，会增加单位信息与类型。例如，在C＃中，包装原始值的结构是否为零成本抽象？

struct AngleRadians { 
    public readonly double Value; 
    /* Constructor, casting operator to AngleDegrees, etc omitted for brevity... */ 
}

在类似上面的情况下，仅存在一个单一的场，将在JIT能够优化掉这种抽象在所有情况下？与使用未包装的double类似的代码相比，哪些情况（如果有的话）会导致额外生成的机器指令？

提及任何过早的优化将被downvoted。我有兴趣了解基本事实。

编辑：要缩小问题的范围，这里有几个特别感兴趣的情景......

// 1. Is the value-copy constructor zero cost? 
// Is... 
var angleRadians = new AngleRadians(myDouble); 
// The same as... 
var myDouble2 = myDouble; 

// 2. Is field access zero cost? 
// Is... 
var myDouble2 = angleRadians.Value; 
// The same as... 
var myDouble2 = myDouble; 

// 3. Is function passing zero cost? 
// Is calling... 
static void DoNaught(AngleRadians angle){} 
// The same as... 
static void DoNaught(double angle){} 
// (disregarding inlining reducing this to a noop

这些都是一些我能想到的把我的头顶部的东西。当然，像@EricLippert这样出色的语言设计师可能会想到更多的场景。因此，即使这些典型的用例是零成本的，我仍然认为知道是否有任何情况下JIT不会将一个结构保存为一个值，并将展开后的值作为等价物，而不列出每个可能的代码段，因为它自身的问题

来源

2017-07-12 Zachary Burns

你为什么不尝试做一些测试？ –

如果你想知道两匹马中的哪一匹马速度更快，你会问网上的陌生人，还是你比赛马匹？你想知道拟议计划的成本，然后**运行程序**，很快你就会知道它的成本！ –

撇开性能的问题，我建议有类型'AngleDegrees'，'AngleRadians'，'AngleGradians'等是一个坏主意。有一个'Angle'类型，它具有属性'AsDegrees'，'AsRadians'等等，工厂'FromRadians'等等。你的类型的实现细节只是：实现细节。通过将实现细节嵌入到类型的名称中，可以限制您的创新能力并降低抽象级别。 –

我没有发现显著的性能差异在调试模式下运行DoNaught的十亿试验与优化开启。有时候，双赢，有时包装赢了。

来源

2017-07-13 17:05:46 hoodaticus

在C＃中，包装原始值的结构是否为零成本抽象？

回答

相关问题