从C语言过渡到C++应该注意的一些问题

         C语言给予了C++许多好处，如果C++不是基于C语言的句法，它很难吸引早期的使用人员；如果C++没有保持C语言对运行时有效性的强调，C++会在发展过程中失掉其适用性。虽然C++起源于C，但是C和C++分别拥有非常不同的语法习惯和模式。人们通常会这样错误认为对C语言的了解必然会使我们理解C++，反之亦然，同时对其中一种语言的经验能指导我们在另外一种语言下掌握最优化下的编程能力。例如，拥有纯C编程经历的程序员喜欢在C++编程中使用C结构，但其实C++中拥有更加安全或讲究的替代。当然这并不是说C程序员的编程能力不如C++程序员，只是C程序中一些根深蒂固的模型与C++设计目标不兼容。

         以下总结了十种C++反对或不安全的C模式惯例。

 

Tip 0: 选择streams而不是stdio.h

         C++的标准库中包含C运行时库，所以所有以前C包含在<stdio.h>中的I/O函数现在都包含在C++的<cstdio>头文件中。虽然你仍然可以在C++中通过printf和scanf完成输出和输入，但是基于这些函数固有的不安全性强烈建议不要使用。考虑如下的C代码：

char myString[1024] = {'\0'};
int  myInt;
printf("Enter an integer and a string: ");
scanf("%d %1023s", &myInt, myString);
printf("You entered %d and %s\n", myInt, myString);

在这里我们提示用户输入一个整型和一个C字符串，如果用户输入正确则回显它们。这段代码似乎没有问题，但是考虑如下代码中加亮的部分：

charmyString[1024] = {'\0'};

int  myInt;

printf("Enteran integer and a string: ");

scanf("%d %1023s",&myInt, myString);

printf("You entered %d and %s\n", myInt, myString);

考虑到缓存的大小为1024。当读取用户输入时，如果没有显示的指出我们希望读取的输入最大为1023，则我们留下了一个缓存溢出的危险，其可能破坏内存中的栈空间并导致一个危及整个系统的攻击。更严重的是缓存声明的空间大小以及用于读入的字符数量之间如果不匹配，编译器不提供警告。实际上我们只有通过非常仔细的阅读这段代码检查是否有这种类型的错误，或者运行一个先进的工具重复检查代码的一致性，才能发现这类错误。

类似的考虑如下加亮的部分：

charmyString[1024] = {'\0'};

int  myInt;

printf("Enteran integer and a string: ");

scanf("%d %1023s", &myInt, myString);

printf("Youentered %d and %s\n", myInt,myString);

可以注意到当从用户读入变量值或者将变量值写到控制台时，我们必须显式的提及变量的类型。myInt是int型和myString是char*型对于printf和scanf还不足够；我们必须在读入时将int与%d关联，将字符串与%s关联。如果我们忽略这些，程序会存在能通过编译的bug。另一个让人苦恼的地方是scanf的参数列表—我们必须传递指向myInt的地址的指针，但是可以直接传递myString。

 

C语言I/O库的问题是它们完全忽略了类型系统。回忆printf和scanf的用法：

int printf(const char* formatting, ...);
int scanf (const char* formatting, ...);

上面省略号意味着调用者能够传递任意多数量任意类型的参数，这也表明C/C++编译器不能做任何类型分析以验证你的参数是否正确。千万不要认为C或C++是类型安全的，其实不然，但是C/C++拥有的静态类型系统被设计用于防止运行时错误的发生。如果不遵循printf和scanf的使用规则，系统容易导致一些特别恶心的错误。

 

在纯C中，上述代码是规范的，但是在C++中我们使用如下代码：

int myInt;
string myString;
cout<<"Enter an int and a string: ";
cin>>myInt >> myString;
cout<<"You entered " << myInt << " and "<<myString << endl;

我们能看到，只需要在myInt和myString声明的地方提及它们的类型，当读或者写myInt和myString时，C++能自动的推断出调用哪个版本的操作符>>和<<以执行合适的I/O，因此避免了读字符串到整型等类型不匹配的问题。而且由于我们使用了C++类型的字符串，所以不存在缓存溢出的问题。简单的说C++streams库比<stdio.h>要安全。

 

Tip1：使用C++字符串取代C类型字符串

生命是短暂、难以琢磨和粗野的（注：吐个槽要这么严重吗），如果是要考虑C字符串的话就会更糟。C字符串很难正确使用，它拥有一个含有模糊的API，能导致各种种类的安全问题。另一方面C++字符串非常优雅、漂亮同时很难错误使用（不会吧）。如果你试图通过一个非法的索引调用erase截断C++string，字符串会抛出一个异常而不是引发内存故障。如果你给C++字符串附加数据，你不需要担心重新分配内存—对象会自动帮你完成。简单的说，C字符串很难正确使用，而C++字符串很难错误使用。但是我们会想C字符串是低级别的，所以其性能优于C++字符串。这个完全正确—因为C字符串是如此的暴露，我们能够灵活的控制C字符串的内存管理和后台的具体操作。但是是否值得这么做呢？以下总结了C字符串容易出现的一些例子：

1，缓存溢出，导致内存中其他数据被破坏，同时带来其他安全问题。

2，忘记内存释放，导致内存泄露。

3，可能覆盖终止符，导致运行时的错误或者不可理解的程序输出

C字符串的确比C++字符串快速，但是有时值得为了系统的安全性牺牲少量的速度。

 

Tip2：使用C++类型转换替代C类型转换

C和C++都有静态类型系统，假如你使用的类型与所期望的类型不相同，编译器会报错。C和C++都允许进行类型转换，但类型转换不一定安全。

C只有一种称为“C风格”的类型转换。C风格的类型转换非常强大。整型与浮点型之间的转换句法和不安全的操作如指针转换为整型、整型转换为指针、常值变量转换为非常值以及一种类型的指针转换为另一种类型的指针都相同。所以在执行类型转换时很容易得到你不想要的结果。例如，我们想将char*转换为int*，因为我们是手动的操作内存块，我们写了如下的代码：

const char* myPtr = /* ... */
int* myIntPtr = (int *)myPtr;

上面的类型转换将const char*转换为int*，改变了const属性。这种方式是经过深思熟虑的吗？它是否为产生一个错误？由于类型转换并不管它试图做哪种类型转换因此由以上代码我们无法回答这些问题。我们是否要去除const属性，将char*转换为int*？

 

C++提供了四种类型转换操作（const_cast，static_cast，dynamic_cast，reinterpret_cast）用于阐明你的代码试图执行哪种类型转换。具体是每次执行一个函数并在错误使用时产生编译时错误。例如前述的代码我们只是想转换const char*到const int*而保持const属性，我们应该这样书写：

const char* myPtr = /* ... */
const int* myIntPtr = reinterpret_cast<const int*>(myPtr);

现在如果我们在类型转换时不管const属性，在const char*转换为int*使会产生编译错误。正确的使用如下：

const char* myPtr = /* ... */
int* myIntPtr= const_cast<int*>(reinterpret_cast<const int*>(myPtr));

这种用法与C版本的相比比较长和庞大，但是它可以显式的指出正在做何种类型转换。同时由于编译器可以检测类型是否使用正确，相比C版本的更加安全。

 

Tip3：相比malloc和free优先使用new和delete

在C++中可以使用new和delete或者malloc和free完成内存分配和释放。如果你习惯使用C编程，你可能偏爱使用malloc和free，但是由于new和delete与malloc和free的使用不相同会导致一些非常微妙的错误。考虑如下代码：

string* one = new string;
string* two = static_cast<string*>(malloc(sizeof string));

我们在这里通过堆创建了两个string对象—一个使用new另一个使用malloc。但不幸的是通过malloc分配的string就像一个定时炸弹。为什么会这样？答案是这两种分配惯例之间具有一个微妙但是决定性的差异。

当你写new string时，C++执行以下两步。第一，通过堆请求给新建的string对象分配内存。第二，在新分配的内存所在处调用string的构造函数初始化string的数据成员。但是你采用malloc（sizeof string）时，只是执行了内存分配任务。以上例子说明通过第二种方式two拥有与string对象相同大小的空间，但是它并没有指向一个string，因为所分配空间的数据成员没有被合适的设置。如果你试图通过two来使用string，由于对象数据成员是垃圾状态你会得到一个危险的崩溃。为了防止这里的问题我们通过new而不是malloc分配对象。

如果通过new和malloc分配的对象使用结束，确保释放内存时采用合适的解分配函数。也就是说不要free通过new分配的对象，不要delete通过malloc分配的对象。malloc和new不相同，new和delete、malloc和free要配对使用。否则会导致一些让人纠结的没有定义行为。

四种类型转换的用法：

const_cast，字面上理解就是去const属性。

static_cast，命名上理解是静态类型转换。如int转换成char。

dynamic_cast，命名上理解是动态类型转换。如子类和父类之间的多态类型转换。

reinterpret_cast，仅仅重新解释类型，但没有进行二进制的转换。

去const属性用const_cast。

基本类型转换用static_cast。

多态类之间的类型转换用dynamic_cast。

不同类型的指针类型转换用reinterpret_cast。

 

Tip4：避免使用void*指针

纯C代码中大量使用void*指针，特别是在函数需要使用任意类型的数据时，例如，C库函数qsort的原型如下：

void qsort(void* elems, size_t numElems, size_t elemSize,
              int (*cmpFn)(const void*,constvoid*));

这个地方非常巧妙，使用了三次void*--一次用于输入数组，另外两次用于比较函数。在这个地方使用void*的原因是C缺乏对泛型编程语言级别的支持，因此用于操作任意数据的算法必须满足最小公分母—原始比特和字节。

当使用C’s qsort，你必须非常小心以确保所有传递的参数都正确。当对一个int型的数组进行排序时，你必须实例化elemSize的大小为sizeof(int)，同时你的比较函数知道将其参数的指针解释为int型指针。在比较函数中传递其他类型的参数会导致运行时错误，错误实例化数组元素会导致错误的行为或者总线错误。

将以上的C’s sort与C++’s sort算法对比：

template<typenameRandomAccessIterator, typename Comparator>
void sort(RandomAccessIterator begin, RandomAccessIterator end, Comparator c);

C++’ssort中编译器能通过查看作为传递参数的迭代器类型决定什么类型的元素存放于range[begin,end]。编译器能自动识别range中元素的size。而且当Comparator中参数类型与range元素中参数类型不匹配时，会得到一个指向特定模板实例的编译时错误而不是难以诊断的运行时错误。

这个例子突出了void*指针的关键不足—它完全颠覆了C/C++的类型系统。当使用void*时，就是告诉编译器忘记所指内容的所有类型信息，这使的操作者需要显式的跟踪所有相关的类型信息。如果出错编译器无法捕获，只能到运行时进行诊断。对比C++的模板系统，C++模板是强类型的，编译器需要确保所有的类型检查。如果有一个类型错误，编译不会通过，我们能够在运行程序之前诊断并修复问题。

当你想着C++编程中使用void*时，要确保这是你想要的。似乎总是能找到办法通过模板替换void*，但是如果你想操作原始比特和字节，void*仍然是最优选择。

有一点需要注意：在纯C中可以将void*隐式转换成任意类型的指针。在C++中可以将任意类型隐式转换为void*，但是反之必须显式转换，如C代码：

int* myArray = malloc(numElems * sizeof(int));

在C++中不能通过编译，因为malloc返回void*，所以要采用如下代码：

int* myArray = (int *)malloc(numElems * sizeof(int));

或者更好采用C++ static_cast，如下：

int* myArray = static_cast<int *>(malloc(numElems * sizeof(int)))

 

Tip5：相比原始数组优先采用vector

数组是就是相同数据类型的元素按一定顺序排列的集合，它们不同于变量，无法采用一个数组对另一个数组进行赋值，也不同于指针，无法改变它们所指的对象。数组不会记录它们的大小，但是静态数组通过sizeof可以获得它所占用的空间大小。操作数组的函数要么猜测数组的大小要么依赖与调用者提供数组大小，总之，C和C++中使用数组有点笨。

将C++vector与之对比，vectors能够准确的知道自身的大小，作为变量可以相互赋值，不能隐式转换为指针。作为一个对象其负责自身的行为，我们不需要担心vectors内部的内存管理。vectors不仅比普通的数组要安全，而且可读性更强。如

 
void MyFunction(intsize)
{
    int* arr = malloc(size * sizeof(int));
    memset(arr, 0, size * sizeof(int));
    /* ... */
    free(arr);
};
 
//Comparethis to the equivalent C++ code:
void MyFunction(intsize)
{
    vector<int> vec(size);
    /* ... */
};

C++不需要计算每个元素的大小，不需要在结束时调用清理函数，不需要memset。而且由于vector在其作用结束时自动完成内存清理，编译器能确保没有内存泄露。

 

Tip6：避免 goto

       通过多年的观察我发现程序员的能力是一个与他们写的代码中goto语句频率呈递减趋势的函数。最近我发现了为什么goto语句会有如此灾难性的影响，我开始确信所有的高级别编程语言都应该禁止使用goto语句（除了机器语言）

                                                                                                        -EdsgerDijkstra[Dij68]

自从Dijkstra在1968年发表“Go To Statement ConsideredHarmful”，goto关键字被广泛的批评，但是goto仍然在C和接下来的C++中有所使用。虽然goto语句非常简单，但是由于其固有的非过程性会导致各种编程恶梦。由于goto语句能够随意的跳转导致各种非直观或与直观相反的代码，如下：

int x = 0;
start:
    if (x == 10) goto out;
    printf("%d\n", x);
    ++x;
    goto start;
out:
printf("Done!\n");

这段代码等价于以下可读性更强的代码：

for(int x= 0; x < 10; ++x)

       printf("%d\n", x);

 

goto语句虽然名声不好，现代C程序仍然适合在一些场合使用它。首先，goto能在多级循环嵌套中用作“super break”操作，跳到任意地方。另外，goto能用于在错误条件下执行必要的清理工作。例如：

/*Returns a string of the first numChars characters from a file or NULL in an
 * error case.
 */
char* ReadFromFile(constchar* filename, size_t numChars)
{
    FILE* f;
    char* buffer;
    /* Allocate some space. */
    buffer = malloc(numChars + 1);
    if(buffer == NULL) return NULL;
    /* Open the file, abort on error. */
    f =fopen(filename, "rb");
    if(f == NULL)
        goto error;
    /* Read the first numChars characters,failing if we don't read enough. */
    if(fread(buffer, numChars, 1, f) !=numChars)
        goto error;
  
    /* Close the file, null-terminate the string,and return. */
    fclose(f); 
    buffer[numChars] = '\0';
    return buffer;
    /* On error, clean up the resources we opened.*/
error:
    free(buffer);
    if(f != NULL)
        fclose(f);
    return NULL;
}
 

以上代码中有两个错误情况需要清理临时的buffer并且关闭打开的文件。采取的办法不是复制清理代码而是采用goto跳转到错误处理程序。

这在纯C代码中很完美，但是C++有更好的替代办法，可以通过异常处理来完成：

/*Returns a string of the first numChars characters from a file.
 * Throws a runtime_error on error.
 */
char* ReadFromFile(constchar*  filename, size_t  numChars)
{
    FILE* f;
    char* buffer = NULL;
    try
    {
        /* Allocate some space.  This will throw on error rather than returning
         * NULL.
         */
        buffer = new char[numChars + 1];
        /* Open the file, abort on error. */
        f = fopen(filename, "rb");
        if(f == NULL)
            throw runtime_error("Can't open file!");
        /* Read the first numChars characters,failing if we don't read enough. *
        if(fread(buffer, numChars, 1, f) !=numChars)
            throw runtime_error("Can't read enough characters!");
  
        /* Close the file, null-terminate the string,and return. */
        fclose(f);
        buffer[numChars] = '\0';
        return buffer;
    }
catch(...)
    {
        /* On error, clean up the resources we opened.*/
        delete [] buffer;
        if(f != NULL)
            fclose(f);
        throw;
    }
}

通过异常处理代替goto，使得代码可读性增强同时能够让调用者知道额外的错误信息。

一个更加好的方案是使用ifstream和string完成以上的功能。由于ifstream和string类型有自己的析构函数，我们不需要显式清理内存，如下：

/*Returns a string of the first numChars characters from a file.
 * Throws a runtime_error on error.
 */
string ReadFromFile(const char*  filename, size_t numChars)
{
    string buffer(numChars);
    /* Open the file, abort on error. */
    ifstream input(filename);
    if(input.fail())
        throw runtime_error("Can't open the file!");
    /* Read the first numChars characters,failing if we don't read enough. */
    input.read(&buffer[0], numChars);
    if(input.fail())
        throw runtime_error("Couldn't read enough data");
    return buffer;
}

这个版本非常清晰和简明，由于对象析构函数负责清理工作，我们不需要自己去完成这些工作。

 

 

Tip7：使用C++的bool类型

在C99之前，C程序没有标准的bool类型，通常使用如下惯例：

enum  bool {true,false};

//or

#define bool int

#define true 1

#define false 0

 

类似的，为了达到无限循环，通常采用如下写法：

while(1){
       /*…*/
}
//or
for(;;){
       /*…*/
}

在C++中定义自己的常规bool类型是很危险的因为常规类型不能与模板和重载等语言特性正确交换。类似的、虽然上面的代码在C++中合法，但与如下代码相比缺乏可读性和简洁性。

while(true)

{

   /* ... */

}

如果你以前没有用过bool型，建议当你使用C++时采用bool。当然你可以通过int型模拟bool型的功能，但是这样做会模糊你的意图并导致各种问题。如采用int模拟bool的功能，两个不相同非零int变量都能表示true，但是它们在对比时不相同，这回将你带入难以琢磨的困境。但是bool型就不会有这种情况。

 

Tip8：避免“typedef struct”

在纯C代码中我们可以这样定义结构体：

struct pointT

{

    int x, y;

};

然后通过声明一个变量以创建结构体的实例：

struct pointT myPoint;

在C++中不需要这样使用struct。老练的C++程序员会暂停并思考这个代码的意思。大多数C程序员也不喜欢这种句法，为了防止每次声明都要带上struct可以通过如下办法解决：

typedef struct pointT_

{

    int x, y;

}pointT;

 

这种句法在C++中是合法的，但是完全没必要而且会导致代码的可读性下降。更严重的是即时对象的名字能被称为pointT，如果想在struct中加构造或析构函数，你必须使用名字pointT_作为它们的函数名。这会让代码可读性下降并且可能给对象的使用者造成困扰。出于简明性的考虑，在C++中避免使用这种类型的typedef

 

Tip9：避免使用memcpy和memset

在纯C代码中以下表述完全正确：

struct pointT
{ 
    int x, y;
};
struct pointT myPoint;
memset(&myPoint,0,sizeof(pointT));

在这里调用memset将pointT中的变量都初始化为0。由于C缺乏构造和析构这种办法能够很好的保证pointT在使用之前被初始化。

因为C++吸收了C的标准库，memeset、memcpy等类似的函数在C++中都可以正常使用。但是使用这些函数会导致微妙但是危险的错误，这些错误会引发各种类型的运行时问题。例如，考虑如下代码：

string one = "This is a string!";
string two = "I like this string more.";
two=one;
memcpy(&one,&two,sizeof(string)); // Set one equal to two – does this work?

我们使用memcpy设置one让其等于two。初始的这似乎能够工作，但不幸的是memcpy会导致一个未定义的行为，几乎可以确定会引起运行时崩溃。分析原因可知string对象包含指向动态分配内存的指针，当使用memcpy将two的数据复制给one时，会让这两个对象中的指针指向相同内存。当每个指针超出作用域时，它们都尝试去回收内存，内部的string buffer会指向两次删除操作而引发问题。更糟糕的是如果程序没有立即崩溃，由于one的数据成员在未清理之前被重写，会导致内存泄露的问题。

在C++中对象的赋值操作应如下：

string one = "This is a string!";
string two = "I like this string more.";
two=one;

就是调用string的分配操作符，其设计用于安全的执行一个深拷贝。

总的来说在C++类中使用memcpy会带来各自问题。大多数类的数据成员和其引用的内存中保持着一些复杂的常量，如果采用memcpy给这些数据成员复制其他数据会破坏那些常量。memcpy无法识别public和private，因此它会完全破坏C++强调的封装保护措施。

 

但是问题远没这么浅显，假设我们试图通过一个多态类表示二叉树结点：

class BinaryTreeNode
{
public:
    BinaryTreeNode();
    virtual ~BinaryTreeNode(); // Polymorphicclassesneed virtual destructors
    /* ... etc. ... */
private:
    BinaryTreeNode* left, *right;
};
 

我们想实现构造器将left和right设置为NULL，指示这个结点没有孩子。初始的我们认为以下代码是安全的：

BinaryTreeNode::BinaryTreeNode()
{
    /* Zero out this object.  Is this safe? */
    memset(this, 0, sizeof(BinaryTreeNode));
}

由于空指针的值为零，以上代码似乎能正常工作—毕竟如果我们将整个对象都重写为0，我们能够让指针数据成员为空指针。但是由于这个类不仅仅只有left和right两个指针，以上代码会带来灾难性的后果。在学习虚函数时我们知道类的虚函数使用一个在类的开头部分分配的虚函数表指针来实现。如果我们使用memset清理对象，我们会将虚函数表指针的值重写为NULL，这意味着任何对这个对象虚函数的调用都会导致空指针解引用使程序崩溃。

 

memset和memcpy的关键问题是它们完全颠覆了C++提供的用于增加程序安全性的抽象。封装能防止客户破坏关键的类组成部分，自动的生成对象能让程序员摆脱显式的操作低级别的机制。但是memset和memcpy会移除这些限制，使你直面C++没有的底层危险。

 

但这并不是说memset和memcpy在C++中完全没有—只是说它们不像在纯C代码中那样被显著考虑。当你试图使用低级别操作惯例时，要确信C++无法提供完成相同目标更好的方法。

 

摘自斯坦福大学CS106L Course Reader