还有什么比在真实的工程上运行C++11迁移器进行测试更好的方法么？我们已经建立起了一个持续的合成服务器去构建和运行cpp11-migrate，目前已经运行了两个工程，已经有计划运行至少三个工程。对于每个工程，目标是构建转换的代码并且运行这些工程的测试包，来确保语义没有被改变。 已经实现的： 1. LLVM3.1 2. ITK 4.3.1 计划实现的： 1. LLDB 2. OpenCV 3. Poco 在实际的代码上运行迁移器对发现缺陷很有帮助。各种项目的真实代码经常揭示转换器的实际开发和单元测试无法揭示的代码表达式。每次转换这些工程的缺陷被修复，新的测试用例都会加到回归测试包里，迁移器就会变得更加健壮。
C++11 迁移器的状态--2013年4月15日(二)
上测试
还有什么比在真实的工程上运行C++11迁移器进行测试更好的方法么？我们已经建立起了一个持续的合成服务器去构建和运行cpp11-migrate，目前已经运行了两个工程，已经有计划运行至少三个工程。对于每个工程，目标是构建转换的代码并且运行这些工程的测试包，来确保语义没有被改变。 已经实现的： 1. LLVM3.1 2. ITK 4.3.1 计划实现的： 1. LLDB 2. OpenCV 3. Poco 在实际的代码上运行迁移器对发现缺陷很有帮助。各种项目的真实代码经常揭示转换器的实际开发和单元测试无法揭示的代码表达式。每次转换这些工程的缺陷被修复，新的测试用例都会加到回归测试包里，迁移器就会变得更加健壮。
尽可能快的通过迁移真实的代码去修复缺陷，是目前高优先级的，因为我们想给尽可能多的用户带来很好的用户体验。添加更多的转换器是另外一个优先的任务，同时社区最感兴趣的转换器将会首先被添加。目前列表的最顶端是： 1. 使用标准库去替代TR1 2. 取代使用已经废弃的auto_prt类。 为了修复缺陷和添加转换器，还有一些更普遍的改进需要考虑。其中之一的改进已经正在实现，那就是去除只有源文件可以转换而它所包含的任何头文件都不转换的限制。这个限制直到现在才开始做是因为迁移器需要知道哪些头文件是可以安全转换的。系统头文件和第三方库的头文件很明显是不能碰的。
还有什么比在真实的工程上运行C++11迁移器进行测试更好的方法么？我们已经建立起了一个持续的合成服务器去构建和运行cpp11-migrate，目前已经运行了两个工程，已经有计划运行至少三个工程。对于每个工程，目标是构建转换的代码并且运行这些工程的测试包，来确保语义没有被改变。 已经实现的： 1. LLVM3.1 2. ITK 4.3.1 计划实现的： 1. LLDB 2. OpenCV 3. Poco 在实际的代码上运行迁移器对发现缺陷很有帮助。各种项目的真实代码经常揭示转换器的实际开发和单元测试无法揭示的代码表达式。每次转换这些工程的缺陷被修复，新的测试用例都会加到回归测试包里，迁移器就会变得更加健壮。