小编ign*_*tec的帖子

假设我们想通过以下方式声明const成员函数typedef:

typedef int FC() const;
typedef int F();

struct A
{
   FC fc;         // fine, we have 'int fc() const'
   const F fc;    // not fine, 'const' is ignored, so we have 'int fc()'
};

由于const被忽略,程序编译得很好.为什么const忽略功能？既然我们可以用这种方式形成const指针,我唯一能想到的就是"C传承".标准是否对此有所说明？

据我所知,在C++中,在函数参数列表中声明的类会自动转到封闭范围:

void f(struct A *p) {}

void g() { A *p; f(p); }

相当于:

struct A;

void f(A *p) {}

void g() { A *p; f(p); }

C++标准中的哪个部分指定了这种行为？C怎么样？

好吧,我猜C在这种情况下不遵循C++.Visual Studio不编译此代码是C模式:

void g(struct A { int a; } a);

struct A a;     // 'a' uses undefined struct 'A'

可以在包含声明命名空间的命名空间中定义命名空间成员:

通过定义名称的显式限定(3.4.3.2),也可以在该命名空间外定义命名空间的成员,前提是已定义的实体已在命名空间中声明,并且定义出现在命名空间中的声明点之后包含声明的命名空间.

void f();

namespace N { void ::f() {} }       // illegal for definition

namespace N { void ::f(); }         // what about redeclaration?

可以在包含声明命名空间的命名空间中定义类:

如果class-head-name包含嵌套名称说明符,则类说明符应引用先前在嵌套名称说明符所引用的类或命名空间中直接声明的类,或者在该命名空间的内联命名空间集(7.3.1)(即,不仅仅是由using-declaration继承或引入),并且类说明符应出现在包含前一个声明的命名空间中.在这种情况下,定义的类头名的嵌套名称说明符不应以decltype-specifier开头.

struct A;

namespace N { struct ::A {}; }      // illegal for definition

namespace N { struct ::A; }         // what about redeclaration?

我们对成员函数定义和静态数据成员定义也有相同的规则.

所以我的问题是重新声明(不是定义)在没有包含原始声明的命名空间中是否合法？

C++标准是否允许extern定义静态数据成员和成员函数的关键字(假设链接匹配)？例如:

struct A
{
    static int a;    // external linkage
    void f();        // external linkage
};

extern int A::a;
extern void A::f() {}

C标准说：

对于在该标识符的先前声明可见的范围内使用存储类说明符 extern 声明的标识符，31) 如果先前声明指定内部或外部链接，则后面声明中标识符的链接与先前声明中指定的链接。如果没有可见的先前声明，或者如果先前声明没有指定链接，则标识符具有外部链接。

不清楚的是，要考虑的先前标识符是否必须具有相同的类型（注意：C++ 标准明确表示“具有相同名称和类型的实体”）。例如：

static int a;   // internal linkage

void f()
{
    float a;      // no linkage, instead of 'int a' we have 'float a'

    {
        extern int a;     // still external linkage? or internal in this case?
        a = 0;            // still unresolved external?
    }
}

我尝试使用不同的编译器对其进行测试，但似乎链接主题不是非常团结的主题。

据我所知,GPU供应商定义了OS开发人员用于与其特定驱动程序通信的标准接口.所以DirectX和OpenGL只是该接口的包装器.当OS开发人员决定创建新版本的Graphic API时,GPU供应商会扩展他们的界面(新的例程更快,而旧的例程留给兼容性问题),OS开发人员使用这个新的界面部分.
因此,当说厂商对DirectX的支持优于OpenGL时,它是否仅仅意味着GPU供应商主要考虑微软未来的开发DirectX API结构的计划,并根据他们的需求调整该接口的未来发展？或者之前有一些技术原因？