1.2 关键词所带来的差异 (A Keyword Distinction)
假设不是为了努力维护与C之间的兼容性。C++能够比方今更简单。举个样例，假设没有八种整数须要支持的话，overloaded function的解决方案将会简单得多。相同的道理。假设C++丢掉C的声明语法。就不须要推断以下这一行事实上是pf的一个函数调用操作(invocation)而不是声明：
// 不知道以下是个declaration还是invocation // 直到看到整数常量1024才干确定 int (*pf)(1024);
而在以下这个声明中，像上面那样的"向前预览(lookahead)"甚至起不了作用：
// meta-language rule: // pq的一个declaration，而不是invocation int (*pq)();
当语言无法区分是一个声明还是一个表达式(expression)时，须要一个超越语言范围的规则。而该规则会将上述表达式推断为一个"声明".
相同地。假设C++并不须要支持C原有的struct。那么class的观念能够借由关键词class来支持。但令人吃惊的是，从C迁移到C++。除了效率。还有一个最常被程序猿询问的问题就是：什么时候应该在C++程序中以struct代替class？
关键词的困扰
关键词struct本身并不一定要象征其后随之声明的不论什么东西，能够使用struct取代class，但仍然声明 public、protected、private 等等存取区段。以及一个全然 public 的接口，以及 virtual functions，以及单一继承、多重继承、虚拟继承等等。
在C++中，选择struct或class作为关键词。用以导入ADT的理由是希望代码健全。
在C所支持的struct和C++所支持的class之间，有一个观念上的重要差异。重点在于：关键词本身并不提供这样的差异，假设使用以下的定义类型，能够说这是一个class.
// struct名称(或class名称)临时省略
{
public:
virtual void foo();
protected:
static int object_count;
};
其实能够它是一个struct，也能够说它是个class，这两种声明的观念上的意义取决于对"声明"本身的检验。
真正的问题并不在于全部"使用者自己定义类型"的声明是否必须使用同样的关键词，问题在于使用class或者struct关键词能否够给予"类型的内部声明"以某种承诺。
策略性正确的struct (The Politically Correct Struct)
C程序猿的巧计有时候却成为C++程序猿的陷阱。比如把单一单元的数组放在一个struct的尾端，于是每一个struct objects能够拥有可变大小的数组：
struct mumber {
/* stuff */
char pc[1];
};
// 从档案或标准输入装置中取得一个字符串
// 然后为struct本身和该字符串配置足够的内存
struct mumble *pmumbl = (struct mumble *)
malloc(sizeof(struct mumble) + strlen(string) + 1);
strcpy(&memble.pc, string);
假设改用class来声明，而该class是：
指定多个access sections,内含数据
从还有一个class派生而来
定义有一个或多个virtual functions
那么也许能够顺利转化。也许不行。
C++中凡处于同一个access section的数据。必然保证以声明次序出如今内存布局其中，然而被放置在多个access sections中的数据，排列次序就不一定了。
相同的道理，base classes和derived classes的data member的布局也没有谁先谁后的强制规定。
vitual function的存在也会使前面转化的有效性成为一个问号。
假设须要一个相当复杂的C++ class的某部分数据。使它拥有C声明的那种样子。那么那一部分最好抽取出来成为一个独立的struct声明，将C与C++组合在一起的作用就是，从C struct中派生C++的部分：
struct C_Point {...};
class Point : public C_point {...}
于是C和C++两种使用方法都可获得支持：
extern void draw_line(Point, Point); draw_line(Point(0, 0), Point(100, 100)); draw_rect(Point(0, 0), Point(100, 100));
这样的习惯使用方法现已不再被推荐，由于某些编译器在支持virtual function的机制中对于class的继承布局做了一些改变。组合(composition)，而非继承，才是把C和C++结合在一起的唯一可行方法(conversion运算符提供了一个十分编译的萃取方法)：
struct C_point {...};
class Point {
public:
operator C_point() { return _c_point; }
private:
C_point _c_point;
};
C struct在C++中的一个合理用途。是当须要传递"一个复杂的class object的所有或部分"到某个C函数中去时，struct声明能够将数据封装起来，并保证拥有与C兼容的空间布局，然而这项保证仅仅在组合(composition)的情况下才存在。假设是"继承"而不是"组合"。编译器会决定是否应该有额外的data members被安排到base struct subobject中。