Visual Studio在调试过程中如何显示System.Double？

问题描述

尝试调试以下简单程序，并在每个步骤（或添加观察中 x x >或任何）。

Try debugging the following simple program, and mouse over x in each step (or "Add Watch" for x or whatever).

using System;
using System.Globalization;

static class Program
{
  static double x;

  static void Main()
  {
    x = 2d;

    // now debugger shows "2.0", as if it has used
    // x.ToString("F1", CultureInfo.InvariantCulture)

    x = 8.0 / 7.0;

    // now debugger shows "1.1428571428571428", as if it had used
    // x.ToString("R", CultureInfo.InvariantCulture)
    // Note that 17 significant figures are shown, not the usual 15.

    x = -1e-200 / 1e200;

    // now debugger shows "0.0"; there is no indication that this is really negative zero
    //

    Console.WriteLine(1.0 / x); // this is negative infinity
  }
}

所以，显然VS有以自己的方式显示一个 System.Double 。为此目的使用哪种方法？有没有办法可以通过编程方式获得相同的字符串表示？

So, apparently VS has its own way to display a System.Double. Which method does it call for this purpose? Is there a way I can get the very same string representation programmatically?

（使用Visual Studio 2010 Professional试用）。

(Tried this out with Visual Studio 2010 Professional.)

推荐答案

他们的核心是C＃和VB.Net EE使用 _ecvt_s 函数来格式化 double 转换成字符串。

At their core both the C# and VB.Net EE's use the _ecvt_s function for formatting a double into a string.

• http://msdn.microsoft.com/en-us/library/ehz2dset(v=vs.80).aspx

两个对结果字符串进行一点清理，使显示更多的C＃和VB喜欢，并处理一些角落的情况更好一点。或者，$ code> _ecvt_s 函数或清理代码可能会对您所看到的差异负责。很难说一目了然

Both do a little bit of cleanup on the resulting string to make the display more C# and VB like and handle some corner cases a bit nicer. Either the _ecvt_s function or the cleanup code could be responsible for the differences you see. Hard to tell at a glance

有些人可能会问为什么我们会经历所有这些麻烦，而不是说只需调用 ToString 的价值和显示。有几个原因我们不这样做。

Some may ask why we would go through all of this trouble instead of saying just calling ToString on the value and displaying that. There are a couple of reasons we don't do this.

第一个只是函数评估，甚至 ToString ，是EE可以承担的单一最昂贵的行动。常见的实际情景简介显示，超过98％的时间用于做功能评估。任何时候我们都可以避免我们所做的func eval，因为性能的影响。

The first is simply that function evaluation, even ToString, is the single most expensive action the EE can undertake. Profiles of common real scenarios show that over 98% of our time was spent doing function evaluation. Any time we can avoid a func eval we do because of the performance implications.

第二个原因只是功能评估并不总是可用。有许多情况下，func eval不可用，但人们仍然希望看到原始类型的显示，如 double ， int 等等，把他们带走，实际上会杀死调试的经验。因此，我们需要解决这个问题，而不需要 ToString 支持。

The second reason is simply that function evaluation isn't always available. There are a number of cases where func eval is unavailable yet people still expect to see a display for primitive types like double, int, etc ... Taking them away would essentially kill the debugging experience. Hence we need to solve this problem without ToString support.

这篇关于Visual Studio在调试过程中如何显示System.Double？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！