C++0x、编译器钩子(Hook)和硬编码语言特性

Question

我对 C++0x 的一些新特性有点好奇。特别是range-based for loops和 initializer lists .这两个功能都需要用户定义的类才能正常运行。

我遇到了 this post ，虽然最佳答案很有帮助。我不知道它是否完全正确(我可能完全误解了，请参阅第一个答案的第 3 条评论)。根据current specifications对于初始化列表， header 定义了一种类型:

template<class E> class initializer_list {
public:
    initializer_list();

    size_t size() const; // number of elements
    const E* begin() const; // first element
    const E* end() const; // one past the last element
};

您可以在规范中看到这一点，只需 Ctrl + F 'class initializer_list'。

为了= {1,2,3}隐式转换为 initializer_list类，编译器必须了解 {} 之间的关系和 initializer_list .没有接收任何东西的构造函数，所以据我所知，initializer_list 是一个包装器，它绑定(bind)到编译器实际生成的任何内容。

与for( : )相同循环，它也需要一个用户定义的类型才能工作(尽管根据规范，更新为不需要数组和初始化列表的任何代码。但是初始化列表需要 <initializer_list> ，所以这是代理的用户定义代码要求) .

我是否完全误解了这里的工作原理？我认为这些新功能实际上非常依赖用户代码并没有错。感觉好像这些特性是半生不熟的，而不是将整个特性构建到编译器中，它是由编译器完成一半，在包含中完成一半。这是什么原因？

编辑:我输入的是“严重依赖编译器代码”，而不是“严重依赖用户代码”。我认为这完全摆脱了我的问题。我感到困惑的不是编译器中内置的新功能，而是依赖于用户代码的编译器中内置的东西。

Answer 1

I'm not wrong in thinking that these new features do infact rely extremely heavily on compiler code

它们确实非常依赖编译器。无论您是否需要包含 header ，事实是在这两种情况下，语法对于今天的编译器来说都是解析错误。 for (:) 不太符合今天的标准，其中唯一允许的结构是 for(;;)

It feels as if the features are half-baked, and instead of building the entire feature into the compiler, it's being half-done by the compiler and half done in includes. What's the reason for this?

支持必须在编译器中实现，但您需要包含系统的 header 才能使其工作。这可以用于几个目的，在初始化列表的情况下，它将类型(编译器支持的接口(interface))带入用户的范围，以便您可以使用它的方式(想想 va_args 在 C 中的方式)。对于基于范围的 for (这只是语法糖)，您需要将 Range 纳入范围，以便编译器可以执行它的魔法。请注意，该标准将 for ( for-range-declaration : expression ) statement 定义为等同于 ([6.5.4]/1 in the draft):

{ 
   auto && __range = ( expression ); 
   for ( auto __begin = std::Range<_RangeT>::begin(__range), 
         __end = std::Range<_RangeT>::end(__range); 
         __begin != __end; 
         ++__begin ) { 
      for-range-declaration = *__begin; 
      statement 
   } 
} 

如果你只想在数组和 STL 容器上使用它，可以在没有 Range 概念的情况下实现(不是 C++0x 意义上的)，但如果你想将语法扩展到用户定义的类(你自己的容器)编译器可以很容易地依赖于现有的 Range 模板(你自己可能的特化)。依赖于定义的模板的机制等同于要求容器上有一个静态接口(interface)。

大多数其他语言都朝着需要常规接口(interface)(例如 Container 等)并在其上使用运行时多态性的方向发展。如果要在 C++ 中完成，则整个 STL 将不得不进行重大重构，因为 STL 容器不共享公共(public)基础或接口(interface)，并且它们不准备多态使用。

如果有的话，当前标准在发布时不会underbaked。