ruby 语言 C++的反思[转](5)

– 整套 C++异常处理系统是 “fundamentally broken”。特别对于编写内核而言。

– 任何语言或编译器喜欢在你背后隐藏行为（如内存分配）对于开发内核并不是一个好选择。

– 任然可以用 C来编写面向对象代码（比如文件系统），而不需要用 C++写出一坨屎来。

总得来说，对任何希望用 C++来开发内核的人而言，他们都是在引入更多问题，无法象 C一样清晰的看到自己到底在写什么。

C++粉丝们在C++最火热的时候试图将 C++引入系统层开发，但是从来没有成功过。所以不管是嵌入式，还是操作系统，在靠近硬件底层的开发中，都是清一色的 C代码，完全没有 C++的立足之地。

应用层的反思

STL出来后，给人一种 C++可以方便开发应用层逻辑的错觉。由于很多语言层不严密的事情，让STL来以补丁的方式完成，于是很多以为可以象写 java一样写 C++的初学者落入了一个个的坑中。比如 list.size()，在 Windows下vc的 stl是保存了 list的长度的，size()直接 O(1)返回该变量，而在gcc的 stl中，没有保存 list长度，size()将搜索所有节点，O(n)的速度返回。

由于语言层不支持字符串，导致 std::string实现十分不统一，你拷贝构造一个字符串，有的实现是引用，才用 copy-on-write的方法引用。有的地方又是 new，有的实现又是用的内存池，有的实现线程安全，有的实现线程不安全，你完全没法说出同一个语句后面到底做了些什么（见孟岩的《Linux之父话糙理不糙》）。

再比如说我想使用 hash_map，为了跨平台（当你真正编写跨平台代码时，你很难决定目标编译器和他们的版本，想用也用不了 unordered_map），我很难指出一种唯一声明 hash_map的方法，为了保证在不同的编译器下正常的使用 hash_map，你不得不写成这样：

#ifdef __GNUC__

#ifdef __DEPRECATED

#undef __DEPRECATED

#endif

#include <ext/hash_map>

namespace stdext { using namespace __gnu_cxx; }

namespace __gnu_cxx {

template<> struct hash< std::string > {

size_t operator()( const std::string& x ) const {

return hash< const char* >()( x.c_str() );

}

};

}

#else

#ifndef _MSC_VER

#include <hash_map>

#elif (_MSC_VER < 1300)

#include <map>

#define IHAVE_NOT_HASH_MAP

#else

#include <hash_map>

#endif

#endif

#ifdef __GNUC__

using namespace __gnu_cxx;

typedef hash_map<uint32_t, XXXX*> HashXXXX;

#else

using namespace stdext;

typedef hash_map<uint32_t, XXXX*> HashXXXX;

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-60655-5.html