大家好，我是Jim Springfield. 我要开始解释我们的计划，关于从根本上改变C / C + +的智能感知和代码浏览功能的工作方式。最近vs2005的GDR和vs2008的变化是很重要的，但他们并没有将这些特点的真正实现。这个文章涵盖了这个功能的历史，并帮助我们解释智能感知如何在vc10(VS2008的下一个Release)完成的情况。
大部分的摘要都是源自我记忆中的事件和安装所有这些Visual C + +旧版本的经验。
获取C或C + +程序的结构信息在微软的产品里已经有很长的一段时间了. 之前，甚至在Visual C + + 1.0 ，编译器就支持通过.SBR和.BSC文件生成程序信息。（注：编译器在Visual C + + 1.0已经是第8版，所以命令行工具已经存在一段时间了。） 。SBR文件包含编译时产生的一个单一转换单元的参考和定义。接下来用BSCMAKE工具将这些文件组合在一起生成BSC文件。这个文件可以用来研究程序的许多不同方面：参考，定义，调用-被调用的关系图，宏等。
自Visual C + +产品成立以来的，我们已经剖析C + +代码和它以某种形式为IDE使用的储存的信息。这个分析器已经从单独的命令行编译分离，因为IDE有很多功能需要基于对代码的理解，这种要求将在这些情况下带来沉重的负担。举例来说，在许多代码编辑的阶段，代码根本不是在一个可编译的状态，所以需要编译是不会被执行的。最早的IDE使用clw （类向导）文件来存储这方面的资料。这些文件结构和一个INI文件类似，常用在Windows的注册表被开发之前的16位系统上。这些只能提供最低限度的信息，如Class的定位和一些资源信息。用一个很简单的分析器产生这些clw文件，它没有处理模板或ANSI / Unicode的问题。此外，在文件里标示着注释的特殊位置不能修改。它在有效的时间里最低的支持类向导的要求，但它没有提供一个程序充足的信息。
在Visual C + + 4.0看到了一个新的功能： ClassView。 ClassView中显示的信息包括所有的类，类的成员，和全局变量。clw文件不能提供足够的信息，所以建立了一个新的分析器将信息存在一个新的NCB文件里。NCB是“no compile browse”的缩写。它提供了一些在建立BSC文件时需要的信息，但不是全部。
Visual C + +6.0为NCB文件的建立引入了新的分析器（ feacp ）。在内部被叫做“ YCB ”是因为“yes compile browse”的简称，尽管它仍然产生NCB文件。它被称为“yes compile browse” 是因为这个修改后的版本实际上在编译后产生的NCB。C + +语言随着加入与命名空间，模板，异常等变得越来越大，维护多个解析器并不是理想状况。clw的分析器至今仍在用来产生clw文件，VC6.0也引进的第一个“智能感知”功能，如自动完成和列出参数信息。
NCB文件非常类似BSC的文件，是为pdb文件基于一个多流制定的格式。NCB文件被加载到内存中并在内存里修改，关闭时再保存到NCB里。数据以层次结构存在内存和磁盘上，大多数查找都需要遍历这些数据结构。
在Visual C + + .net（即7.0 ）里clw文件和相关的分析文件最后被删除，类向导功能放在NCB文件里实现。在7.1 ， 8.0（Whidbey） ， 9.0 （ orcas ） 里，没有太大的改变。在Whidbey里看到的最大的变化，是我们去掉了为库和SDK建立的预处理NCB文件，提供对宏更好地支持，并允许64K的文件在一个NCB里。这些都是增量改进，但总体结构保持不变。
随着NCB文件加入越来越多的功能，它成为IDE中一个核心的技术。如果其不正常，很多IDE的功能都不能用。feacp需要去处理大型的，复杂的，互相关联的文件和潜在不正确代码。当一个项目中一个共同的头文件被改变后，所有依赖它的文件都将reparsed来产生正确的信息。
注： feacp只会解析头文件本身，但所有依赖的cpp文件将reparsed，用来收集有用的信息。在这期间的问题总称为“multi-mod”（多模块引用），当一个头文件被多个模块使用时就会发生。
对大型工程项目而言，reparsing可能需要一段时间。最初，作为解析的UI线程会发生在前台，这造成了IDE被冻结。这个在更高版本用一个后台线程来解决。不过，也有一些情况下，前台用户界面需要显示结果，这时不管用什么方法都会冻结住。此外，这种频繁reparsing使用了大量的CPU和内存，用了太多的资源，仍然造成用户界面的问题。最终的调整是通过在一定程度上运行较低的线程优先级和延时到Idle时才reparsing来解决。另一种解决办法新增三种优先序列来排队工作，它可以让更多的重要工作第一时间处理。其他问题发生的原因是由于NCB文件无效或错误，导致在编译时不能从该文件获取有用信息。也有一些问题与NCB数据在内存中的并发和锁定有关。加入基于一个简单的查询快速地找到信息的能力是非常困难的，并要求更改代码。扩充NCB文件格式添加模板支持， C + +/ CLI，和其他的语言特点也被证明是困难的。
所有这些问题在更大，更复杂的项目都被加剧了。需要加以reparsed文件数目可能相当大而且reparsing的频率可能很高。此外， “间歇性”的失败在项目规模上升时更可能发生。所有这些问题已经看过随着时间的推移和一些渐进的修复已有所改善，但根本性的问题依然存在。
下一次，我将介绍这些问题在vc10的处理方式 ，这是我们当前工作的内容。
谢谢,Jim
原始链接
http://blogs.msdn.com/vcblog/archive/2007/12/18/intellisense-history-part-1.aspx
