1.语言关键字.docVIP

1. 语言关键字 原版到修订版的一个大体转换是在所有关键字中去掉双下划线。举例来说，一个属性现在被声明为property而不是__property。在原版设计中使用双下划线前缀的两个主要原因是： 这是提供符合ISO-C++标准的语言扩展的方法。原版语言设计的一个主要目的就是不引入和标准语言的不兼容性，例如新的关键字和标记。这个原因很大程度上也推动了对声明托管引用类型的对象的指针语法的选择。 双下划线的使用，除了兼容性方面的原因之外，也是一个不会对有旧代码基础的用户造成影响的合理保证。这是原版设计的第二主要目的。 这样的话，为什么我们移除双下划线（并且引入了一些新的标记）？不是的，这不代表我们不再考虑和标准保持一致！ 我们继续致力于和标准一致。尽管如此，我们意识到对CLI动态对象模型的支持表现出了一种全新的强大的编程范型。我们在原版设计以及设计与发展C++语言的经验使我们确信，对这个新范型的支持需要它自己的高级关键字和标记。我们想提供一个新范型的一流表达方式，整合它并且支持标准语言。我们希望你会感到修订版语言设计提供了对这两种截然不同的对象模型的一流的编程体验。 类似的，我们很关心最小化这些新的关键字的对现有代码可能造成的冲击。这是用上下文性和分段关键字解决的。在我们着眼于实际语言语法的修订之前，让我们试试搞清楚这两个特别的关键字的风味。 一个上下文性关键字在特定的语言环境中有特殊的含义。例如，在通常的程序中，sealed被识别为一个普通标识符。但是，在一个托管引用类类型的声明部分，它被识别为类声明上下文中的一个关键字。这最小化了在语言中引入一个新的关键字的潜在影响，我们觉得这对我们的有旧代码基础的用户非常重要。同时，它允许新的功能的使用者获得一流的新增语言特色的体验——我们在觉得原版设计中缺少这些因素。我们将在2.1.2节中看到sealed的用法。 一个分段关键字是上下文性关键字的特例。字面上是一个上下文性修饰符和一个现存关键字配对，用空格分隔。这个配对被识别为一个语法单位，例如value class(示例参见2.1)，而不是两个单独的关键字。基于现实的因素，这意味着一个重新定义value的宏，如下所示： #ifndef __cplusplus_cli #define value 不会在一个类声明中去掉value。如果确实要这么做的话，不得不重新定义语法单位对，如下所述： #ifndef __cplusplus_cli #define value class class 考虑到现实的因素，这是十分必要的。否则，现存的#define可能转换分段关键字的上下文性关键字部分。(译者注：例如2003年1月份的平台SDK头文件中的#define interface struct，参见拙作/jiangsheng/archive/2004/12/17/41283.aspx)。 2. 托管数据类型 声明托管数据类型和创建以及使用这些类型的对象的语法已经被大加修改，以提高对ISO-C++类型系统的兼容性。这些更改在后面的小节中详述。委托的讨论延后到3.3节以用类的事件成员表述它们——这是第3节的主题。(关于更加详细的跟踪引用语法介绍内幕和设计上的主要转变的讨论，参见附录 推动修订版语言设计。） 2.1 声明一个托管类类型 在原版语言定义中，一个引用类类型以__gc关键字开头。在修订版语言中，__gc关键字被两个分段关键字ref class或者ref struct之一替代。struct或者class的选择只是指明在类型体中开头未明确访问级别的部分的默认公开(对于struct)或者私有(对于class)默认访问级别。 类似地，在原版语言设计中，一个引用类类型以__value关键字开头。在修订版语言中，__value关键字被两个分段关键字value class或者value struct之一代替。 在原版语言设计中，一个接口类型，是用关键字__interface指明的。在修订版语言中，它被interface class替代。 例如，下列类声明集合 // 原版语法 public __gc class Block { ... }; // 引用类 public __value class Vector { ... }; // 值类 public __interface IMyFile { ... }; // 接口类 在修订版语言设计下等价的声明如下： // 修订版语法 public ref class Block { ... }; public value class Vector { ... }; public interface class IMyFile { .