自从 Stan Lippman 被 MS 的 Visual C++ 项目组挖去之后,偶就一直期待着已经 n 年没有发生变化的 VC++ 编译器能够早日跟上 C++ 标准的发展步伐。在一个过渡性的 VC 7.0 之后, Lippman 果然给我们带来了令人心动的 VC 7.1 编译器。虽然对 C++ 最新标准还是无法完全兼容,但起码不用再看着 VC 6 中那些动辄出现的编译器内部错误发呆了。
不过 Lippman 在 MS 中最大的动作,恐怕还是在 Whidbey 中开始针对 Managed C++ 需求,调整已经稳定多年的 C++ 语法了。随着 Whidbey 的多个测试版本发布,以及最新语法规范草稿的发布,崭新的 C++/CLI 已经呼之欲出了。
C++/CLI Language Specification Standard
最近 Lippman 更是在 MSDN 发表了 STL.NET Primer 一文,介绍 Whidbey 中提供的 STL 的 .NET 移植版本。
从原本 1.0/1.1 中的 System::Collections 库,到增加泛型支持的 2.0 中的 System::Collections::Generic 库,再到移植的 STL.NET 库,Whidbey 中的 Managed C++ 使用者将面对三套使用完全不同的容器机制,呵呵
Systems::Collection 使用现有的基于单根继承模型的容器支持库,通过 IList 等容器接口以及对 Object 的操作来实现:
System::Collections::Generic 则基于泛型特性支持,通过 Collection<T> 基类直接对目标类型 T 进行操作来实现:
STL.NET 则使用 STL 类似语法,通过包装来获取底层实现的效率和高层优秀可移植性等优势:
通过上面例子可以看到,STL 中容器、迭代器和算法三大部件一个都不少,只不过用法上加上了一点点 Managed C++ 的特色。大量使用的 “^”,让我又回忆起当年在 Borland Pascal for Windows 里面跟 Windows 3.1.1 搏斗的时光,呵呵。
通过 STL.NET 的支持,可以很容易获得 STL 架构的优秀扩展性、现有 C++ 代码的可移植性,以及 STL 最吸引人的类型安全的高效率实现。我想等 Whidbey 正式推出时,我的最爱大概就是 STL.NET 了吧,哈哈
不过 Lippman 在 MS 中最大的动作,恐怕还是在 Whidbey 中开始针对 Managed C++ 需求,调整已经稳定多年的 C++ 语法了。随着 Whidbey 的多个测试版本发布,以及最新语法规范草稿的发布,崭新的 C++/CLI 已经呼之欲出了。
C++/CLI Language Specification Standard
最近 Lippman 更是在 MSDN 发表了 STL.NET Primer 一文,介绍 Whidbey 中提供的 STL 的 .NET 移植版本。
从原本 1.0/1.1 中的 System::Collections 库,到增加泛型支持的 2.0 中的 System::Collections::Generic 库,再到移植的 STL.NET 库,Whidbey 中的 Managed C++ 使用者将面对三套使用完全不同的容器机制,呵呵
Systems::Collection 使用现有的基于单根继承模型的容器支持库,通过 IList 等容器接口以及对 Object 的操作来实现:
|
System::Collections::Generic 则基于泛型特性支持,通过 Collection<T> 基类直接对目标类型 T 进行操作来实现:
|
STL.NET 则使用 STL 类似语法,通过包装来获取底层实现的效率和高层优秀可移植性等优势:
|
通过上面例子可以看到,STL 中容器、迭代器和算法三大部件一个都不少,只不过用法上加上了一点点 Managed C++ 的特色。大量使用的 “^”,让我又回忆起当年在 Borland Pascal for Windows 里面跟 Windows 3.1.1 搏斗的时光,呵呵。
通过 STL.NET 的支持,可以很容易获得 STL 架构的优秀扩展性、现有 C++ 代码的可移植性,以及 STL 最吸引人的类型安全的高效率实现。我想等 Whidbey 正式推出时,我的最爱大概就是 STL.NET 了吧,哈哈