jsoncpp 使用详解

jsoncpp 主要包含三种类型的 class：Value、Reader、Writer。jsoncpp 中所有对象、类名都在 namespace Json 中，包含 json.h 即可。

Json::Value 只能处理 ANSI 类型的字符串，如果 C++ 程序是用 Unicode 编码的，最好加一个 Adapt 类来适配。

int ReadJsonFromFile(const char* filename)  
{  
    Json::Reader reader;// 解析json用Json::Reader   
    Json::Value root; // Json::Value是一种很重要的类型，可以代表任意类型。如int, string, object, array         

    std::ifstream is;  
    is.open (filename, std::ios::binary );    
    if (reader.parse(is, root, FALSE))  
    {  
        std::string code;  
        if (!root["files"].isNull())  // 访问节点，Access an object value by name, create a null member if it does not exist.  
            code = root["uploadid"].asString();  
        
        code = root.get("uploadid", "null").asString();// 访问节点，Return the member named key if it exist, defaultValue otherwise.    

        int file_size = root["files"].size();  // 得到"files"的数组个数  
        for(int i = 0; i < file_size; ++i)  // 遍历数组  
        {  
            Json::Value val_image = root["files"][i]["images"];  
            int image_size = val_image.size();  
            for(int j = 0; j < image_size; ++j)  
            {  
                std::string type = val_image[j]["type"].asString();  
                std::string url  = val_image[j]["url"].asString(); 
                printf("type : %s, url : %s \n", type.c_str(), url.c_str());
            }  
        }  
    }  
    is.close();  

    return 0;  
} 

void WriteJsonData(const char* filename)
{
    Json::Reader reader;  
    Json::Value root; // Json::Value是一种很重要的类型，可以代表任意类型。如int, string, object, array        

    std::ifstream is;  
    is.open (filename, std::ios::binary );    
    if (reader.parse(is, root))  
    {  
        Json::Value arrayObj;   // 构建对象  
        Json::Value new_item, new_item1;  
        new_item["date"] = "2011-11-11";  
        new_item1["time"] = "11:11:11";  
        arrayObj.append(new_item);  // 插入数组成员  
        arrayObj.append(new_item1); // 插入数组成员  
        int file_size = root["files"].size();  
        for(int i = 0; i < file_size; ++i)  
            root["files"][i]["exifs"] = arrayObj;   // 插入原json中 
        std::string out = root.toStyledString();  
        // 输出无格式json字符串  
        Json::FastWriter writer;  
        std::string strWrite = writer.write(root);
        std::ofstream ofs;
        ofs.open("test_write.json");
        ofs << strWrite;
        ofs.close();
    }  

    is.close();  
}

       当客户端为 C++ ，WebService服务端使用Java、domino，传递中文则会有乱码问题。

产生原因：

       宽字符的原因

       采用TCP连接的C/S模式软件，连接的双方在连接空闲状态时，如果任意一方意外崩溃、当机、网线断开或路由器故障，另一方无法得知TCP连接已经失效，除非继续在此连接上发送数据导致错误返回。很多时候，这不是我们需要的。我们希望服务器端和客户端都能及时有效地检测到连接失效，然后优雅地完成一些清理工作并把错误报告给用户。
      如何及时有效地检测到一方的非正常断开，一直有两种技术可以运用。一种是由TCP协议层实现的Keepalive，另一种是由应用层自己实现的心跳包。
      TCP默认并不开启Keepalive功能，因为开启Keepalive功能需要消耗额外的宽带和流量，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，Keepalive设置不合理时可能会因为短暂的网络波动而断开健康的TCP连接。并且，默认的Keepalive超时需要7,200,000 milliseconds，即2小时，探测次数为5次。
      对于Win2K/XP/2003，可以从下面的注册表项找到影响整个系统所有连接的keepalive参数：
       [HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters]
        "KeepAliveTime”=dword:006ddd00
        "KeepAliveInterval"=dword:000003e8 
        "MaxDataRetries"="5"

      对于实用的程序来说，2小时的空闲时间太长。因此，我们需要手工开启Keepalive功能并设置合理的Keepalive参数。

// 开启KeepAlive
BOOL bKeepAlive = TRUE;
int nRet = ::setsockopt(socket_handle, SOL_SOCKET, SO_KEEPALIVE, (char*)&bKeepAlive, sizeof(bKeepAlive));

if (nRet == SOCKET_ERROR)
{
return FALSE;
}

// 设置KeepAlive参数
tcp_keepalive alive_in = {0};
tcp_keepalive alive_out = {0};
alive_in.keepalivetime = 5000; // 开始首次KeepAlive探测前的TCP空闭时间

alive_in.keepaliveinterval = 1000; // 两次KeepAlive探测间的时间间隔

alive_in.onoff = TRUE;
unsigned long ulBytesReturn = 0;

nRet = WSAIoctl(socket_handle, SIO_KEEPALIVE_VALS, &alive_in, sizeof(alive_in),
&alive_out, sizeof(alive_out), &ulBytesReturn, NULL, NULL);
if (nRet == SOCKET_ERROR)
{
return FALSE;


}

开启Keepalive选项之后，对于使用IOCP模型的服务器端程序来说，一旦检测到连接断开，GetQueuedCompletionStatus函数将立即返回FALSE，使得服务器端能及时清除该连接、释放该连接相关的资源。对于使用select模型的客户端来说，连接断开被探测到时，以recv目的阻塞在socket上的select方法将立即返回SOCKET_ERROR，从而得知连接已失效，客户端程序便有机会及时执行清除工作、提醒用户或重新连接。

另一种技术，由应用程序自己发送心跳包来检测连接的健康性。客户端可以在一个Timer中或低级别的线程中定时向发服务器发送一个短小精悍的包，并等待服务器的回应。客户端程序在一定时间内没有收到服务器回应即认为连接不可用，同样，服务器在一定时间内没有收到客户端的心跳包则认为客户端已经掉线。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

　windows下此处的”非正常断开”指TCP连接不是以优雅的方式断开,如网线故障等物理链路的原因,还有突然主机断电等原因.

有两种方法可以检测:

1.TCP连接双方定时发握手消息

2.利用TCP协议栈中的KeepAlive探测
第二种方法简单可靠,只需对TCP连接两个Socket设定KeepAlive探测,
所以本文只讲第二种方法在Linux,Window2000下的实现(在其它的平台上没有作进一步的测试)

Windows 2000平台下 头文件
#include <mstcpip.h>
//定义结构及宏
/*
struct TCP_KEEPALIVE {
u_longonoff;
u_longkeepalivetime;
u_longkeepaliveinterval;
} ;
*/

    tcp_keepalive live,liveout;  
    live.keepaliveinterval=5000; //每5秒发一次探测报文,发5次没有回应，就断开
    live.keepalivetime=30000;//超过30s没有数据，就发送控测包
    
    live.onoff=TRUE;  
    int Opt = 1;
    int iRet = setsockopt(Accept,SOL_SOCKET,SO_KEEPALIVE,(char *)&Opt,sizeof(int));  
    if(iRet == 0)
    {
         DWORD dw;
         if(::WSAIoctl(Accept,SIO_KEEPALIVE_VALS,
          &live,sizeof(live),&liveout,sizeof(liveout),
          &dw,NULL,NULL)== SOCKET_ERROR){
     }  
}

ACE下代码 //by rainfish blog.csdn.net/bat603

Linux平台下

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

临界区（Critical Section）

　　保证在某一时刻只有一个线程能访问数据的简便办法。在任意时刻只允许一个线程对共享资源进行访问。如果有多个线程试图同时访问临界区，那么在有一个线程进入后其他所有试图访问此临界区的线程将被挂起，并一直持续到进入临界区的线程离开。临界区在被释放后，其他线程可以继续抢占，并以此达到用原子方式操作共享资源的目的。 
　　临界区包含两个操作原语： 
　　EnterCriticalSection（） 进入临界区 
　　LeaveCriticalSection（） 离开临界区 
　　EnterCriticalSection（）语句执行后代码将进入临界区以后无论发生什么，必须确保与之匹配的LeaveCriticalSection（）都能够被执行到。否则临界区保护的共享资源将永远不会被释放。虽然临界区同步速度很快，但却只能用来同步本进程内的线程，而不可用来同步多个进程中的线程。 
　　MFC提供了很多功能完备的类，我用MFC实现了临界区。MFC为临界区提供有一个CCriticalSection类，使用该类进行线程同步处理是非常简单的。只需在线程函数中用CCriticalSection类成员函数Lock（）和UnLock（）标定出被保护代码片段即可。Lock（）后代码用到的资源自动被视为临界区内的资源被保护。UnLock后别的线程才能访问这些资源。 
   

互斥量（Mutex） 
   
　　互斥量跟临界区很相似，只有拥有互斥对象的线程才具有访问资源的权限，由于互斥对象只有一个，因此就决定了任何情况下此共享资源都不会同时被多个线程所访问。当前占据资源的线程在任务处理完后应将拥有的互斥对象交出，以便其他线程在获得后得以访问资源。互斥量比临界区复杂。因为使用互斥不仅仅能够在同一应用程序不同线程中实现资源的安全共享，而且可以在不同应用程序的线程之间实现对资源的安全共享。 
   
　　互斥量包含的几个操作原语： 
　　CreateMutex（） 创建一个互斥量 
　　OpenMutex（） 打开一个互斥量 
　　ReleaseMutex（） 释放互斥量 
　　WaitForMultipleObjects（） 等待互斥量对象 
   
　　同样MFC为互斥量提供有一个CMutex类。使用CMutex类实现互斥量操作非常简单，但是要特别注意对CMutex的构造函数的调用 
　　CMutex( BOOL bInitiallyOwn = FALSE, LPCTSTR lpszName = NULL, LPSECURITY_ATTRIBUTES lpsaAttribute = NULL) 
　　不用的参数不能乱填，乱填会出现一些意想不到的运行结果。 
   
  //创建互斥量 

信号量（Semaphores）

　　信号量对象对线程的同步方式与前面几种方法不同，信号允许多个线程同时使用共享资源，这与操作系统中的PV操作相同。它指出了同时访问共享资源的线程最大数目。它允许多个线程在同一时刻访问同一资源，但是需要限制在同一时刻访问此资源的最大线程数目。在用CreateSemaphore（）创建信号量时即要同时指出允许的最大资源计数和当前可用资源计数。一般是将当前可用资源计数设置为最大资源计数，每增加一个线程对共享资源的访问，当前可用资源计数就会减1，只要当前可用资源计数是大于0的，就可以发出信号量信号。但是当前可用计数减小到0时则说明当前占用资源的线程数已经达到了所允许的最大数目，不能在允许其他线程的进入，此时的信号量信号将无法发出。线程在处理完共享资源后，应在离开的同时通过ReleaseSemaphore（）函数将当前可用资源计数加1。在任何时候当前可用资源计数决不可能大于最大资源计数。 
　　PV操作及信号量的概念都是由荷兰科学家E.W.Dijkstra提出的。信号量S是一个整数，S大于等于零时代表可供并发进程使用的资源实体数，但S小于零时则表示正在等待使用共享资源的进程数。 
　　P操作 申请资源： 
  　　（1）S减1； 
  　　（2）若S减1后仍大于等于零，则进程继续执行； 
  　　（3）若S减1后小于零，则该进程被阻塞后进入与该信号相对应的队列中，然后转入进程调度。 
  V操作 释放资源： 
  　　（1）S加1； 
  　　（2）若相加结果大于零，则进程继续执行； 
  　　（3）若相加结果小于等于零，则从该信号的等待队列中唤醒一个等待进程，然后再返回原进程继续执行或转入进程调度。 
   
  　　信号量包含的几个操作原语： 
  　　CreateSemaphore（） 创建一个信号量 
  　　OpenSemaphore（） 打开一个信号量 
  　　ReleaseSemaphore（） 释放信号量 
  　　WaitForSingleObject（） 等待信号量 
   
  //信号量句柄 

事件（Event） 
   
　　事件对象也可以通过通知操作的方式来保持线程的同步。并且可以实现不同进程中的线程同步操作。 
　　信号量包含的几个操作原语： 
  　　CreateEvent（） 创建一个信号量 
  　　OpenEvent（） 打开一个事件 
  　　SetEvent（） 回置事件 
  　　WaitForSingleObject（） 等待一个事件 
  　　WaitForMultipleObjects（）　　　　　　　　 等待多个事件 
  　　　　WaitForMultipleObjects 函数原型： 
  　　　　　WaitForMultipleObjects（ 
  　　　　　IN DWORD nCount, // 等待句柄数 
  　　　　　IN CONST HANDLE *lpHandles, //指向句柄数组 
  　　　　　IN BOOL bWaitAll, //是否完全等待标志 
  　　　　　IN DWORD dwMilliseconds //等待时间 
  　　　　　） 
　　参数nCount指定了要等待的内核对象的数目，存放这些内核对象的数组由lpHandles来指向。fWaitAll对指定的这nCount个内核对象的两种等待方式进行了指定，为TRUE时当所有对象都被通知时函数才会返回，为FALSE则只要其中任何一个得到通知就可以返回。dwMilliseconds在这里的作用与在WaitForSingleObject（）中的作用是完全一致的。如果等待超时，函数将返回WAIT_TIMEOUT。 
   
  //事件数组 

总结： 
　　1． 互斥量与临界区的作用非常相似，但互斥量是可以命名的，也就是说它可以跨越进程使用。所以创建互斥量需要的资源更多，所以如果只为了在进程内部是用的话使用临界区会带来速度上的优势并能够减少资源占用量。因为互斥量是跨进程的互斥量一旦被创建，就可以通过名字打开它。 
　　2． 互斥量（Mutex），信号灯（Semaphore），事件（Event）都可以被跨越进程使用来进行同步数据操作，而其他的对象与数据同步操作无关，但对于进程和线程来讲，如果进程和线程在运行状态则为无信号状态，在退出后为有信号状态。所以可以使用WaitForSingleObject来等待进程和线程退出。 
　　3． 通过互斥量可以指定资源被独占的方式使用，但如果有下面一种情况通过互斥量就无法处理，比如现在一位用户购买了一份三个并发访问许可的数据库系统，可以根据用户购买的访问许可数量来决定有多少个线程/进程能同时进行数据库操作，这时候如果利用互斥量就没有办法完成这个要求，信号灯对象可以说是一种资源计数器。 

疑问： 
　　在 Linux 上，有两类信号量。第一类是由 semget/semop/semctl API 定义的信号量的 SVR4（System V Release 4）版本。第二类是由 sem_init/sem_wait/sem_post/interfaces 定义的 POSIX 接口。 它们具有相同的功能，但接口不同。 在2.4.x内核中，信号量数据结构定义为(include/asm/semaphore.h)。 
　　但是在Linux中没有对互斥量的具体提法，只是看到说互斥量是信号量的一种特殊情况，当信号量的最大资源数=1同时可以访问共享资源的线程数=1 就是互斥量了。临界区的定义也比较模糊。没有找到用事件处理线程/进程同步互斥的操作的相关资料。在Linux下用GCC/G++编译标准C++代码，信号量的操作几乎和Windows下VC7的编程一样，不用改多少就顺利移植了，可是互斥量，事件，临界区的Linux移植没有成功。 
   
　　本文所有事例程序在WindowsXp Sp2 + VC7 下编译通过。

本文转自：http://www.bccn.net/Article/kfyy/vc/jszl/200709/6380_2.html

用途一：

定义一种类型的别名，而不只是简单的宏替换。可以用作同时声明指针型的多个对象。比如：

char* pa, pb; // 这多数不符合我们的意图，它只声明了一个指向字符变量的指针，

// 和一个字符变量；

以下则可行：

typedef char* PCHAR;

PCHAR pa, pb;  

这种用法很有用，特别是char* pa, pb的定义，初学者往往认为是定义了两个字符型指针，其实不是，而用typedef char* PCHAR就不会出现这样的问题，减少了错误的发生。

用途二:
用在旧的C代码中，帮助struct。以前的代码中，声明struct新对象时，必须要带上struct，即形式为： struct 结构名对象名，如：

struct tagPOINT1

 {
    int x;

    int y; 
};

struct tagPOINT1 p1;

而在C++中，则可以直接写：结构名对象名，即：tagPOINT1 p1;

typedef struct tagPOINT
{
    int x;

    int y;
}POINT;

POINT p1; // 这样就比原来的方式少写了一个struct，比较省事，尤其在大量使用的时

候,或许，在C++中，typedef的这种用途二不是很大，但是理解了它，对掌握以前的旧代

码还是有帮助的，毕竟我们在项目中有可能会遇到较早些年代遗留下来的代码。

用途三：

用typedef来定义与平台无关的类型。

比如定义一个叫 REAL 的浮点类型，在目标平台一上，让它表示最高精度的类型为：

typedef long double REAL;

在不支持 long double 的平台二上，改为：

typedef double REAL;

在连 double 都不支持的平台三上，改为：

typedef float REAL;

也就是说，当跨平台时，只要改下 typedef 本身就行，不用对其他源码做任何修改。

标准库就广泛使用了这个技巧，比如size_t。另外，因为typedef是定义了一种类型的新别名，不是简单的字符串替换，所以它比宏来得稳健。
     这个优点在我们写代码的过程中可以减少不少代码量哦！

用途四：

为复杂的声明定义一个新的简单的别名。方法是：在原来的声明里逐步用别名替换一部

分复杂声明，如此循环，把带变量名的部分留到最后替换，得到的就是原声明的最简化

版。举例： 

 原声明：void (*b[10]) (void (*)());

变量名为b，先替换右边部分括号里的，pFunParam为别名一：

typedef void (*pFunParam)();

再替换左边的变量b，pFunx为别名二：

typedef void (*pFunx)(pFunParam);

原声明的最简化版：

pFunx b[10];
 
原声明：doube(*)() (*e)[9];

变量名为e，先替换左边部分，pFuny为别名一：

typedef double(*pFuny)();

再替换右边的变量e，pFunParamy为别名二

typedef pFuny (*pFunParamy)[9];

原声明的最简化版：

pFunParamy e;

理解复杂声明可用的“右左法则”：从变量名看起，先往右，再往左，碰到一个圆括号

就调转阅读的方向；括号内分析完就跳出括号，还是按先右后左的顺序，如此循环，直

到整个声明分析完。举例：

int (*func)(int *p);

首先找到变量名func，外面有一对圆括号，而且左边是一个*号，这说明func是一个指针

；然后跳出这个圆括号，先看右边，又遇到圆括号，这说明(*func)是一个函数，所以

func是一个指向这类函数的指针，即函数指针，这类函数具有int*类型的形参，返回值

类型是int。

int (*func[5])(int *);

func右边是一个[]运算符，说明func是具有5个元素的数组；func的左边有一个*，说明

func的元素是指针（注意这里的*不是修饰func，而是修饰func[5]的，原因是[]运算符

优先级比*高，func先跟[]结合）。跳出这个括号，看右边，又遇到圆括号，说明func数

组的元素是函数类型的指针，它指向的函数具有int*类型的形参，返回值类型为int。

这种用法是比较复杂的，出现的频率也不少，往往在看到这样的用法却不能理解，相信以上的解释能有所帮助。

*****以上为参考部分，以下为本人领悟部分*****

使用示例：

1.比较一：

#include <iostream>

using namespace std;

typedef int (*A) (char, char);

int ss(char a, char b)
{
    cout<<"功能1"<<endl;

    cout<<a<<endl;

    cout<<b<<endl;

    return 0;
}
 
int bb(char a, char b)
{

    cout<<"功能2"<<endl;

    cout<<b<<endl;

    cout<<a<<endl;

    return 0;

}

void main()
{

    A a;

    a = ss;

    a('a','b');

    a = bb;

    a('a', 'b');
}

2.比较二：

typedef int (A) (char, char);

void main()
{

    A *a;

    a = ss;

    a('a','b');

    a = bb;

    a('a','b');
}
 

两个程序的结果都一样：

功能1

a

b

功能2

b

a

*****以下是参考部分*****

参考自：http://blog.hc360.com/portal/personShowArticle.do?articleId=57527

typedef 与 #define的区别：

案例一：

通常讲，typedef要比#define要好，特别是在有指针的场合。请看例子：

typedef char *pStr1;

#define pStr2 char *;

pStr1 s1, s2;

pStr2 s3, s4;
在上述的变量定义中，s1、s2、s3都被定义为char *，而s4则定义成了char，不是我们

所预期的指针变量，根本原因就在于#define只是简单的字符串替换而typedef则是为一

个类型起新名字。

案例二：

下面的代码中编译器会报一个错误，你知道是哪个语句错了吗？

typedef char * pStr;

char string[4] = "abc";

const char *p1 = string;

const pStr p2 = string;

p1++;

p2++;

　　是p2++出错了。这个问题再一次提醒我们：typedef和#define不同，它不是简单的

文本替换。上述代码中const pStr p2并不等于const char * p2。const pStr p2和

const long x本质上没有区别，都是对变量进行只读限制，只不过此处变量p2的数据类

型是我们自己定义的而不是系统固有类型而已。因此，const pStr p2的含义是：限定数

据类型为char *的变量p2为只读，因此p2++错误。虽然作者在这里已经解释得很清楚了，可我在这个地方仍然还是糊涂的，真的希望哪位高手能帮忙指点一下，特别是这一句“只不过此处变量p2的数据类型是我们自己定义的而不是系统固有类型而已”，难道自己定义的类型前面用const修饰后，就不能执行更改运算，而系统定义的类型却可以？

本文转自：http://www.cnblogs.com/csyisong/archive/2009/01/09/1372363.html

说说异或运算^和他的一个常用作用。
异或的运算方法是一个二进制运算：
1^1=0
0^0=0
1^0=1
0^1=1

两者相等为0,不等为1.

这样我们发现交换两个整数的值时可以不用第三个参数。
如a=11,b=9.以下是二进制
a=a^b=1011^1001=0010;
b=b^a=1001^0010=1011;
a=a^b=0010^1011=1001;
这样一来a=9,b=13了。


举一个运用， 按一个按钮交换两个mc的位置可以这样。

mybt.onPress=function()
{
mc1._x=mc1._x^mc2._x;
mc2._x=mc2._x^mc1._x;
mc1._x=mc1._x^mc2._x;
//
mc1._y=mc1._y^mc2._y;
mc2._y=mc2._y^mc1._y;
mc1._y=mc1._y^mc2._y;
}

这样就可以不通过监时变量来传递了。

最后要声明：只能用于整数。

1. 位运算 请点评

整数在计算机中用二进制的位来表示，C语言提供一些运算符可以直接操作整数中的位，称为位运算，这些运算符的操作数都必须是整型的。在以后的学习中你会发现，有些信息利用整数中的某几个位来存储，要访问这些位，仅仅有对整数的操作是不够的，必须借助位运算，例如第 2 节 “Unicode和UTF-8” 介绍的UTF-8编码就是如此，学完本节之后你应该能自己写出UTF-8的编码和解码程序。本节首先介绍各种位运算符，然后介绍与位运算有关的编程技巧。

1.1. 按位与、或、异或、取反运算 请点评

在第 3 节 “布尔代数” 讲过逻辑与、或、非运算，并列出了真值表，对于整数中的位也可以做与、或、非运算，C语言提供了按位与（Bitwise AND）运算符&、按位或（Bitwise OR）运算符|和按位取反（Bitwise NOT）运算符~，此外还有按位异或（Bitwise XOR）运算符^，我们在第 1 节 “为什么计算机用二进制计数” 讲过异或运算。下面用二进制的形式举几个例子。

图 16.1. 位运算

注 意，&、|、^运算符都是要做Usual Arithmetic Conversion的（其中有一步是Integer Promotion），~运算符也要做Integer Promotion，所以在C语言中其实并不存在8位整数的位运算，操作数在做位运算之前都至少被提升为int 型了，上面用8位整数举例只是为了书写方便。比如：

unsigned char c = 0xfc;
 unsigned int i = ~c;

计算过程是这样的：常量0xfc是int 型的，赋给c 要转成unsigned char ，值不变；c 的十六进制表示是fc，计算~c 时先提升为整型（000000fc）然后取反，最后结果是ffffff03。注意，如果把~c 看成是8位整数的取反，最后结果就得3了，这就错了。为了避免出错，一是尽量避免不同类型之间的赋值，二是每一步计算都要按上一章讲的类型转换规则仔细检查。

1.2. 移位运算 请点评

移位运算符（Bitwise Shift）包括左移<<和右移>>。左移将一个整数的各二进制位全部左移若干位，例如0xcfffffff3<<2得到0x3fffffcc：

图 16.2. 左移运算

最高两位的11被移出去了，最低两位又补了两个0，其它位依次左移两位。但要注意，移动的位数必须小于左操作数的总位数，比如上面的例子，左边是unsigned int 型，如果左移的位数大于等于32位，则结果是Undefined。移位运算符不同于+ - * / ==等运算符，两边操作数的类型不要求一致，但两边操作数都要做Integer Promotion，整个表达式的类型和左操作数提升后的类型相同。

复习一下第 2 节 “不同进制之间的换算” 讲过的知识可以得出结论，在一定的取值范围内，将一个整数左移1位相当于乘以2 。比如二进制11（十进制3）左移一位变成110，就是6，再左移一位变成1100，就是12。读者可以自己验证这条规律对有符号数和无符号数都成立，对负数也成立。当然，如果左移改变了最高位（符号位），那么结果肯定不是乘以2了，所以我加了个前提“在一定的取值范围内 ”。由于计算机做移位比做乘法快得多，编译器可以利用这一点做优化，比如看到源代码中有i * 8 ，可以编译成移位指令而不是乘法指令。

当操作数是无符号数时，右移运算的规则和左移类似，例如0xcfffffff3>>2得到0x33fffffc：

图 16.3. 右移运算

最低两位的11被移出去了，最高两位又补了两个0，其它位依次右移两位。和左移类似，移动的位数也必须小于左操作数的总位数，否则结果是Undefined。在一定的取值范围内，将一个整数右移1位相当于除以2，小数部分截掉。

当操作数是有符号数时，右移运算的规则比较复杂：

• 如果是正数，那么高位移入0

• 如果是负数，那么高位移入1还是0不一定，这是Implementation-defined的。对于x86平台的gcc 编译器，最高位移入1，也就是仍保持负数的符号位，这种处理方式对负数仍然保持了“右移1位相当于除以2 ”的性质。

综上所述，由于类型转换和移位等问题，用有符号数做位运算是很不方便的，所以，建议只对无符号数做位运算，以减少出错的可能 。

习题 请点评

1、下面两行printf 打印的结果有何不同？请读者比较分析一下。%x 转换说明的含义详见第 2.9 节 “格式化I/O函数” 。

int i = 0xcffffff3;
 printf("%x/n", 0xcffffff3>>2);
 printf("%x/n", i>>2);

unsigned int a, b, mask = 0x0000ff00;
 a = 0x12345678;
 b = (a & mask) >> 8; /* 0x00000056 */

b = (a >> 8) & ~(~0U << 8);

unsigned int a, b, mask = 0x0000ff00;
 a = 0x12345678;
 b = a & ~mask; /* 0x12340078 */

unsigned int a, b, mask = 0x0000ff00;
 a = 0x12345678;
 b = a | mask; /* 0x1234ff78 */

unsigned int a, b, mask = 1U << 6;
 a = 0x12345678;
 b = a ^ mask; /* flip the 6th bit */

a = a ^ b;
 b = b ^ a;
 a = a ^ b;

1、《高性能 Windows Socket 服务端与客户端组件（源代码及测试用例下载）》

    《基于 IOCP 的通用异步 Windows Socket TCP 高性能服务端组件的设计与实现》

    《通用异步 Windows Socket TCP 客户端组件的设计与实现》

　　摘要：编写 Windows Socket TCP 客户端其实并不困难，Windows 提供了6种 I/O 通信模型供大家选择。但本座看过很多客户端程序都把 Socket 通信和业务逻辑混在一起，剪不断理还乱。每个程序都 Copy / Parse 类似的代码再进行修改，实在有点情何以堪。因此本座利用一些闲暇时光写了一个基于 IOCP 的通用异步 Windows Socket TCP 高性能服务端组件和一个通用异步 Windows Socket TCP 客户端组件供各位看官参详参详，希望能激发下大家的灵感。

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip

2、《Windows C++ 应用程序通用日志组件（组件及测试程序下载）》

　　摘要：编写一个通用的日志组件应该着重考虑三个方面：功能、可用性和性能。下面，本座详细说明在设计日志组件时对这些方面问题的考虑：

• • 功能：本日志组件的目的是满足大多数应用程序记录日志的需求 —— 把日志输出到文件或发送到应用程序中，并不提供一些复杂但不常用的功能
  • 可用性：本日志组件着重考虑了可用性，尽量让使用者用起来觉得简便、舒心
  • 性能：性能是组件是否值得使用的硬指标，本组件从设计到编码的过程都尽量考虑到性能优化

　　资源下载地址：http://ldcsaa.googlecode.com/files/VC_Logger.zip

3、《如何养成良好的 C++ 编程习惯（一）—— 内存管理》

　　摘要：说起 C/C++ 的内存管理似乎令人望而生畏，满屏的 new / delete / malloc / free，OutPut 窗口无尽的 Memory Leak 警告，程序诡异的 0X00000004 指针异常，仿佛回到那一年我们一起哭过的日子，你 Hold 得住吗？其实，现实并没有你想的那么糟糕。只要你付出一点点，花一点点心思，没错！就一点点而已 —— 用 C++ 类封装内存访问，就会解决你大部分的烦恼，让你受益终身。以 Windows 程序为例，主要有以下几种内存管理方式：

• • 虚拟内存（Virtual Memory）
  • 默认堆和私有堆（Process Heap & Private Heap）
  • 内存映射文件（File Mapping）
  • 进程堆栈（Heap，其实就是用 malloc() 或 默认的 new 操作符在 Process Heap 里一小块一小块地割肉 ^_^）
  • 栈（Stack，内存由调用者或被调用者自动管理）

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip （源代码在 Common/Src 目录中）

4、《实现 Win32 程序的消息映射宏（类似 MFC ）》

　　摘要：对于消息映射宏，不用多说了，用过 MFC 的人都很清楚。但目前有不少程序由于各种原因并没有使用 MFC，所以本帖讨论一下如何在 Win32 程序中实现类似MFC的消息映射宏。其实 Windows 的头文件 “WindowsX.h”（注意：不是“Windows.h”） 中提供了一些有用的宏来帮助我们实现消息映射。本座是也基于这个头文件实现消息映射。

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip （源代码在 Common/Src/Win32Helper.h 文件中）

5、《用宏实现 C++ Singleton 模式》

　　摘要：Singleton 设计模式应用非常广泛，实现起来也很简单，无非是私有化若干个构造函数，“operator =” 操作符，以及提供一个静态的创建和销毁方法。但是对每个类都写这些雷同的代码是本座不能容忍的，因此，本座使用宏把整个 Singleton 模式封装起来，无论是类的定义还是类的使用的极其简单。

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip （源代码在 Common/Src/Singleton.h 文件中）

6、《C++ 封装私有堆（Private Heap）》

　　摘要：Private Heap 是 Windows 提供的一种内存内存机制，对于那些需要频繁分配和释放动态内存的应用程序来说，Private Heap 是提高应用程序性能的一大法宝，使用它能降低 new / malloc 的调用排队竞争以及内存空洞。

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip （源代码在 Common/Src/PrivateHeap.h 文件中）

7、《基于 crt debug 实现的 Windows 程序内存泄漏检测工具》

　　摘要：Windows 程序内存泄漏检测是一项十分重要的工作，基于 GUI 的应用程序通常在调试结束时也有内存泄漏报告，但这个报告的信息不全面，不能定位到产生泄漏的具体行号。其实自己实现一个内存泄漏检测工具是一件非常简单的事情，但看过网上写的很多例子，普遍存在两种问题：

• • 要么考虑不周全，一种环境下能用，而在另外一种环境下却不能很好工作，或者漏洞报告的输出方式不合理。
  • 要么过于保守，例如：完全没有必要在 _malloc_dbg() 和 _free_dbg() 的调用前后用 CriticalSection 进行保护（跟踪一下多线程环境下 new 和 malloc 的代码就会明白）。

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip （源代码在 Common/Src/debug/win32_crtdbg.h 文件中）

Java

1、《Portal-Basic Java Web 应用开发框架 v3.0.1 正式发布（源码、示例及文档）》

　　摘要：Portal-Basic Java Web应用开发框架（简称 Portal-Basic）是一套功能完备的高性能Full-Stack Web应用开发框架，内置稳定高效的MVC基础架构和DAO框架（已内置Hibernate、MyBatis和JDBC支持），集成 Action拦截、Form Bean / Dao Bean / Spring Bean装配、国际化、文件上传下载和缓存等基础Web应用组件，提供高度灵活的纯 Jsp/Servlet API 编程模型，完美整合 Spring，支持Action Convention“零配置”，能快速开发传统风格和RESTful风格的Web应用程序，文档和代码清晰完善，非常容易学习。

　　资源下载地址：http://code.google.com/p/portal-basic/downloads/list

2、《用 Java 实现的日志切割清理工具（源代码下载）》

　　摘要：对于服务器的日常维护来说，日志清理是非常重要的事情，如果残留日志过多则严重浪费磁盘空间同时影响服务的性能。如果用手工方式进行清理，会花费太多时间，并且很多时候难以满足实际要求。例如：如何在每个星期六凌晨3点把超过2G大的日志文件进行切割，保留最新的100M日志记录？网上没有发现能满足本座要求的日志切割工具，因此花了一些闲暇时间自己写了一个。由于要在多个平台上使用，为了方便采用 Java 实现。本工具命名为 LogCutter，主要有以下特点：

• • 支持 Linux、Mac 和 Windows 等所有常见操作系统平台
  • 支持命令行交互式运行
  • 支持后台非交互式运行（Linux/MAC 下使用 daemon 进程实现，Windows 用系统 Service 实现）
  • 支持两种日志清理方式（删除日志文件或切割日志文件）
  • 支持对 GB18030、UTF-8、UTF-16LE、UTF-16BE 等常用日志文件类型进行切割（不会发生切掉半个字符的情况）
  • 高度可配置（程序执行周期、要删除的日志文件过期时间、要切割的日志文件阀值和保留大小等均可配置

　　资源下载地址：http://ldcsaa.googlecode.com/files/LogCutter.zip

3、《通用 Java 文件上传和下载组件的设计与实现》

　　摘要：文件上传和下载是 Web 应用中的一个常见功能，相信各位或多或少都曾写过这方面相关的代码。但本座看过不少人在实现上传或下载功能时总是不知不觉间与程序的业务逻辑纠缠在一起，因此，当其他地方要用到这些功能时则无可避免地 Copy / Pase，然后再进行修改。这样丑陋不堪的做法导致非常容易出错不说，更大的问题是严重浪费时间不断做重复类似的工作，这是本座绝不能容忍的。哎，人生苦短啊，浪费时间在这些重复工作身上实在是不值得，何不把这些时间省出来打几盘罗马或者踢一场球？为此，本座利用一些闲暇之时光编写了一个通用的文件上传和文件下载组件，实现方法纯粹是基于 JSP，没有太高的技术难度，总之老少咸宜 ^_^。现把设计的思路和实现的方法向各位娓娓道来，希望能起到抛砖引玉的效果，激发大家的创造性思维。

　　资源下载地址：http://code.google.com/p/portal-basic/downloads/list （作为 Portal-Basic 第一部分，代码在 com.bruce.util.http 包中）

4、《深度剖析：Java POJO Bean 对象与 Web Form 表单的自动装配》

　　摘要：时下很多 Web 框架 都实现了 Form 表单域与 Java 对象属性的自动装配功能，该功能确实非常有用，试想如果没这功能则势必到处冲积着 request.getParameter() 系列方法与类型转换方法的调用。重复代码量大，容易出错，同时又不美观，影响市容。现在的问题是，这些框架通过什么方法实现自动装配的？如果不用这些框架我们自己如何去实现呢？尤其对于那些纯 JSP/Servlet 应用，要是拥有自动装配功能该多好啊！本座深知各位之期盼，决定把自动装配的原理和实现方法娓娓道来。

　　资源下载地址：http://code.google.com/p/portal-basic/downloads/list （作为 Portal-Basic 第一部分，代码在 com.bruce.util 包中）

5、《Linux 安装 MySQL / MySQL 主从备份》

　　资源下载地址：http://ldcsaa.googlecode.com/files/services.zip

本文转自：http://www.cppblog.com/ldcsaa/archive/2013/01/07/197048.html

来源:Intetnet

1 进程与进程通信

　　进程是装入内存并准备执行的程序，每个进程都有私有的虚拟地址空间，由代码、数据以及它可利用的系统资源(如文件、管道等)组成。多进程/多线程是Windows操作系统的一个基本特征。Microsoft Win32应用编程接口(Application Programming Interface, API)提供了大量支持应用程序间数据共享和交换的机制，这些机制行使的活动称为进程间通信(InterProcess Communication, IPC)，进程通信就是指不同进程间进行数据共享和数据交换。
　　正因为使用Win32 API进行进程通信方式有多种，如何选择恰当的通信方式就成为应用开发中的一个重要问题，下面本文将对Win32中进程通信的几种方法加以分析和比较。

2 进程通信方法

2.1 文件映射
　　文件映射(Memory-Mapped Files)能使进程把文件内容当作进程地址区间一块内存那样来对待。因此，进程不必使用文件I/O操作，只需简单的指针操作就可读取和修改文件的内容。
　　Win32 API允许多个进程访问同一文件映射对象，各个进程在它自己的地址空间里接收内存的指针。通过使用这些指针，不同进程就可以读或修改文件的内容，实现了对文件中数据的共享。
　　应用程序有三种方法来使多个进程共享一个文件映射对象。
　　(1)继承：第一个进程建立文件映射对象，它的子进程继承该对象的句柄。
　　(2)命名文件映射：第一个进程在建立文件映射对象时可以给该对象指定一个名字(可与文件名不同)。第二个进程可通过这个名字打开此文件映射对象。另外，第一个进程也可以通过一些其它IPC机制(有名管道、邮件槽等)把名字传给第二个进程。
　　(3)句柄复制：第一个进程建立文件映射对象，然后通过其它IPC机制(有名管道、邮件槽等)把对象句柄传递给第二个进程。第二个进程复制该句柄就取得对该文件映射对象的访问权限。
　　文件映射是在多个进程间共享数据的非常有效方法，有较好的安全性。但文件映射只能用于本地机器的进程之间，不能用于网络中，而开发者还必须控制进程间的同步。
2.2 共享内存
　　Win32 API中共享内存(Shared Memory)实际就是文件映射的一种特殊情况。进程在创建文件映射对象时用0xFFFFFFFF来代替文件句柄(HANDLE)，就表示了对应的文件映射对象是从操作系统页面文件访问内存，其它进程打开该文件映射对象就可以访问该内存块。由于共享内存是用文件映射实现的，所以它也有较好的安全性，也只能运行于同一计算机上的进程之间。
2.3 匿名管道
　　管道(Pipe)是一种具有两个端点的通信通道：有一端句柄的进程可以和有另一端句柄的进程通信。管道可以是单向－一端是只读的，另一端点是只写的；也可以是双向的一管道的两端点既可读也可写。
　　匿名管道(Anonymous Pipe)是在父进程和子进程之间，或同一父进程的两个子进程之间传输数据的无名字的单向管道。通常由父进程创建管道，然后由要通信的子进程继承通道的读端点句柄或写端点句柄，然后实现通信。父进程还可以建立两个或更多个继承匿名管道读和写句柄的子进程。这些子进程可以使用管道直接通信，不需要通过父进程。
　　匿名管道是单机上实现子进程标准I/O重定向的有效方法，它不能在网上使用，也不能用于两个不相关的进程之间。
2.4 命名管道
　　命名管道(Named Pipe)是服务器进程和一个或多个客户进程之间通信的单向或双向管道。不同于匿名管道的是命名管道可以在不相关的进程之间和不同计算机之间使用，服务器建立命名管道时给它指定一个名字，任何进程都可以通过该名字打开管道的另一端，根据给定的权限和服务器进程通信。
　　命名管道提供了相对简单的编程接口，使通过网络传输数据并不比同一计算机上两进程之间通信更困难，不过如果要同时和多个进程通信它就力不从心了。
2.5 邮件槽
　　邮件槽(Mailslots)提供进程间单向通信能力，任何进程都能建立邮件槽成为邮件槽服务器。其它进程，称为邮件槽客户，可以通过邮件槽的名字给邮件槽服务器进程发送消息。进来的消息一直放在邮件槽中，直到服务器进程读取它为止。一个进程既可以是邮件槽服务器也可以是邮件槽客户，因此可建立多个邮件槽实现进程间的双向通信。
　　通过邮件槽可以给本地计算机上的邮件槽、其它计算机上的邮件槽或指定网络区域中所有计算机上有同样名字的邮件槽发送消息。广播通信的消息长度不能超过400字节，非广播消息的长度则受邮件槽服务器指定的最大消息长度的限制。
　　邮件槽与命名管道相似，不过它传输数据是通过不可靠的数据报(如TCP/IP协议中的UDP包)完成的，一旦网络发生错误则无法保证消息正确地接收，而命名管道传输数据则是建立在可靠连接基础上的。不过邮件槽有简化的编程接口和给指定网络区域内的所有计算机广播消息的能力，所以邮件槽不失为应用程序发送和接收消息的另一种选择。
2.6 剪贴板
　　剪贴板(Clipped Board)实质是Win32 API中一组用来传输数据的函数和消息，为Windows应用程序之间进行数据共享提供了一个中介，Windows已建立的剪切(复制)－粘贴的机制为不同应用程序之间共享不同格式数据提供了一条捷径。当用户在应用程序中执行剪切或复制操作时，应用程序把选取的数据用一种或多种格式放在剪贴板上。然后任何其它应用程序都可以从剪贴板上拾取数据，从给定格式中选择适合自己的格式。
　　剪贴板是一个非常松散的交换媒介，可以支持任何数据格式，每一格式由一无符号整数标识，对标准(预定义)剪贴板格式，该值是Win32 API定义的常量；对非标准格式可以使用Register Clipboard Format函数注册为新的剪贴板格式。利用剪贴板进行交换的数据只需在数据格式上一致或都可以转化为某种格式就行。但剪贴板只能在基于Windows的程序中使用，不能在网络上使用。
2.7 动态数据交换
　　动态数据交换(DDE)是使用共享内存在应用程序之间进行数据交换的一种进程间通信形式。应用程序可以使用DDE进行一次性数据传输，也可以当出现新数据时，通过发送更新值在应用程序间动态交换数据。
　　DDE和剪贴板一样既支持标准数据格式(如文本、位图等)，又可以支持自己定义的数据格式。但它们的数据传输机制却不同，一个明显区别是剪贴板操作几乎总是用作对用户指定操作的一次性应答－如从菜单中选择Paste命令。尽管DDE也可以由用户启动，但它继续发挥作用一般不必用户进一步干预。DDE有三种数据交换方式：
　　(1) 冷链：数据交换是一次性数据传输，与剪贴板相同。
　　(2) 温链：当数据交换时服务器通知客户，然后客户必须请求新的数据。
　　(3) 热链：当数据交换时服务器自动给客户发送数据。
　　DDE交换可以发生在单机或网络中不同计算机的应用程序之间。开发者还可以定义定制的DDE数据格式进行应用程序之间特别目的IPC，它们有更紧密耦合的通信要求。大多数基于Windows的应用程序都支持DDE。
2.8 对象连接与嵌入
　　应用程序利用对象连接与嵌入(OLE)技术管理复合文档(由多种数据格式组成的文档)，OLE提供使某应用程序更容易调用其它应用程序进行数据编辑的服务。例如，OLE支持的字处理器可以嵌套电子表格，当用户要编辑电子表格时OLE库可自动启动电子表格编辑器。当用户退出电子表格编辑器时，该表格已在原始字处理器文档中得到更新。在这里电子表格编辑器变成了字处理器的扩展，而如果使用DDE，用户要显式地启动电子表格编辑器。
　　同DDE技术相同，大多数基于Windows的应用程序都支持OLE技术。
2.9 动态连接库
　　Win32动态连接库(DLL)中的全局数据可以被调用DLL的所有进程共享，这就又给进程间通信开辟了一条新的途径，当然访问时要注意同步问题。
　　虽然可以通过DLL进行进程间数据共享，但从数据安全的角度考虑，我们并不提倡这种方法，使用带有访问权限控制的共享内存的方法更好一些。
2.10 远程过程调用
　　Win32 API提供的远程过程调用(RPC)使应用程序可以使用远程调用函数，这使在网络上用RPC进行进程通信就像函数调用那样简单。RPC既可以在单机不同进程间使用也可以在网络中使用。
　　由于Win32 API提供的RPC服从OSF-DCE(Open Software Foundation Distributed Computing Environment)标准。所以通过Win32 API编写的RPC应用程序能与其它操作系统上支持DEC的RPC应用程序通信。使用RPC开发者可以建立高性能、紧密耦合的分布式应用程序。
2.11 NetBios函数
　　Win32 API提供NetBios函数用于处理低级网络控制，这主要是为IBM NetBios系统编写与Windows的接口。除非那些有特殊低级网络功能要求的应用程序，其它应用程序最好不要使用NetBios函数来进行进程间通信。
2.12 Sockets
　　Windows Sockets规范是以U.C.Berkeley大学BSD UNIX中流行的Socket接口为范例定义的一套Windows下的网络编程接口。除了Berkeley Socket原有的库函数以外，还扩展了一组针对Windows的函数，使程序员可以充分利用Windows的消息机制进行编程。
　　现在通过Sockets实现进程通信的网络应用越来越多，这主要的原因是Sockets的跨平台性要比其它IPC机制好得多，另外WinSock 2.0不仅支持TCP/IP协议，而且还支持其它协议(如IPX)。Sockets的唯一缺点是它支持的是底层通信操作，这使得在单机的进程间进行简单数据传递不太方便，这时使用下面将介绍的WM_COPYDATA消息将更合适些。
2.13 WM_COPYDATA消息
　　WM_COPYDATA是一种非常强大却鲜为人知的消息。当一个应用向另一个应用传送数据时，发送方只需使用调用SendMessage函数，参数是目的窗口的句柄、传递数据的起始地址、WM_COPYDATA消息。接收方只需像处理其它消息那样处理WM_COPY DATA消息，这样收发双方就实现了数据共享。
　　WM_COPYDATA是一种非常简单的方法，它在底层实际上是通过文件映射来实现的。它的缺点是灵活性不高，并且它只能用于Windows平台的单机环境下。

3 结束语

　　Win32 API为应用程序实现进程间通信提供了如此多种选择方案，那么开发者如何进行选择呢？通常在决定使用哪种IPC方法之前应考虑下一些问题，如应用程序是在网络环境下还是在单机环境下工作等。

本文转自：http://www.cnblogs.com/erwin/archive/2007/04/16/715084.html

评论

# re: C++高效编程忠告 2007-07-19 19:21 沐枫

闲来无聊，无聊一下：

2 头文件的作用
这是由于历史原因造成的。
头文件主要用于存放接口声明，以便不同的c文件共享函数声明。
到了c++中，已经造成一种妨碍了。

3 * & 的位置
这个位置放哪，虽然要紧，但更要紧的是，遵守一个变量一行定义。这样就不会出现错误，也很好读。如：
int * i;
int j;

4 if
仍然是历史原因造成的。c标准中没有真正的bool类型(c++98和c99加了)，而是用int来代替，这就造成了麻烦。所以新写的程序要避免使用BOOL，而用bool来替代。
如果是旧标准的编译器，仍然要注意BOOL其实是int这个要点。

5 const #define enum
这几个各有用途，有时候也不能互代。使用时，优先顺序 enum const #define。看具体要求，不一定非要怎么怎么样。

6 参数传递
用指针或用引用，倒不定要要争个谁好谁坏。
实际上，用指针还更容易让人明白传进去的是指针。而引用则不然。引用的引入，在c++中是为了解决运算符重载的问题。
不过，不管用哪个，倒是建议优先采用 const T* 或const T&，这种常量指针或常亘引用。这不仅关系程序优化，也关系到代码的质量。

8 memcpy
除非没有类似的库函数，否则不要重新写一个。要知道，绝大多数编译器会对这些库函数作特殊优化。这是手工编码无法做到的。

11 字串
建议不要使用strcpy,strcmp类似的函数，应该改为strncpy, strncmp等函数。目前新型的编译器会认为strxxx函数是非法的（被淘汰的），建议用strnxxx，或者编译器提供的更安全的版本。

13 指针的大小
与编译器及系统平台有关。大小从2/4/8/16各种可能性都有.不要认死了。

14 关于new/delete 与malloc/free
你用了类似class的关键字后，就注定不兼容于c了。因此，用了c++的东西，就不要去用mallco/free，除非特殊情况。
同理，不使用c++的东西，也决不要去用new /delete.
否则，你的跨语言或跨平台的想法就打水漂了。还容易出错。

15 const 函数
const不一定只能引用const成员。它可以使用任何成员，只是默认情况不能改变成员的值而已。如果成员被定义为mutable（c++98)，则不限制。

18 #ifdef
说的太绝对了。而且没有任何说明如何做。
事实上#ifdef能做的事还是挺多的。  回复  更多评论   

# re: C++高效编程忠告 2007-07-19 21:44 梦在天涯

恩，楼上说的很好，可见C++的功底之强，学习中。。。  回复  更多评论   

# re: C++高效编程忠告 2007-07-20 09:33 金庆

三、* , &修饰符的位置
int* & rY = pI; // ptr's ref
用int*表示指针更清楚。

int *i,j;
我更倾向于这样分开写:
int * pI;
int j;

六、C++函数中值的传递方式
“如果输入参数是以值传递的话，最好使用引用传递代替”
应该是“如果输入参数是常量值的话，最好使用常量引用传递代替”。
但是简单常量就不需要引用传递。

十二、sizeof的问题
一般没有这样定义函数的:
void fun(char a[1000])
而是void fun(char * p, int len)  回复  更多评论   

# re: C++高效编程忠告 2007-07-20 09:47 金庆

“头文件到了c++中，已经造成一种妨碍了”？
能说明一下吗？

头文件在C++中还是必须的吧？

  回复  更多评论   

# re: C++高效编程忠告 2007-07-20 12:00 沐枫

@金庆
就是必须的，所以才是一种妨碍。

目前C++有3种编程：c, 类, 模板。
其中，头文件对于c来说，并不成问题，甚至还带来许多便利。
但是对于类，和模板，特别是模板来说，麻烦就大了。

对于类来说，封装性和实现隐藏是一个很重要的概念，但大多数情况下，许多人都不容易做到这一点。.h文件中会有许多私有的数据成员，甚至还有不少的函数实现（如inline函数），从而对封装性和实现隐藏造成破坏，造成编译依赖，进一步造成编译器的复杂度提高。最终为了避开这些问题，将会造成库设计要求的提高。

至于模板风格的编程就更不得了，目前几乎没有支持分离模板的编译器。况且即便分离了，又能怎么样？最终的结果是，大多的模板风格的程序，所有的代码都在.h文件中，.cpp反而只剩了一句话：#include "xxx.h"，没了。

  回复  更多评论   

# re: C++高效编程忠告[未登录] 2007-07-22 21:18 梦在天涯

对目前的编译器都不支持模板的分离，都必须在。h中实现。  回复  更多评论

本文转自：http://www.cppblog.com/mzty/archive/2007/07/19/28359.html

什么是完成包？

完成包，即IO Completion Packet，是指异步IO操作完毕后OS提交给应用层的通知包。IOCP维护了一个IO操作结果队列，里面
保存着各种完成包。应用层调用GQCS(也就是GetQueueCompletionStatus)函数获取这些完成包。

最大并发线程数

在一个典型的IOCP程序里，会有一些线程调用GQCS去获取IO操作结果。最大并发线程数指定在同一时刻处理完成包的线程数目。
该参数在调用CreateIoCompletionPort时由NumberOfConcurrentThreads指定。

工作者线程

工作者线程一般指的就是调用GQCS函数的线程。要注意的是，工作者线程数和最大并发线程数并不是同一回事(见下文)。工作者
线程由应用层显示创建(_beginthreadex 之类)。工作者线程通常是一个循环，会不断地GQCS到完成包，然后处理完成包。

调度过程

工作者线程以是否阻塞分为两种状态：运行状态和等待状态。当线程做一些阻塞操作时(线程同步，甚至GQCS空的完成队列)，线程
处于等待状态；否则，线程处于运行状态。

另一方面，OS会始终保持某一时刻处于运行状态的线程数小于最大并发线程数。每一个调用GQCS函数的线程OS实际上都会进行记录，
当完成队列里有完成包时，OS会首先检查当前处于运行状态的工作线程数是否小于最大并发线程数，如果小于，OS会按照LIFO的顺
序让某个工作者线程从GQCS返回(此工作者线程转换为运行状态)。如何决定这个LIFO？这是简单地通过调用GQCS函数的顺序决定的。

从这里可以看出，这里涉及到线程唤醒和睡眠的操作。如果两个线程被放置于同一个CPU上，就会有线程切换的开销。因此，为了消
除这个开销，最大并发线程数被建议为设置成CPU数量。

从以上调度过程还可以看出，如果某个处于运行状态的工作者线程在处理完成包时阻塞了(例如线程同步、其他IO操作)，那么就有
CPU资源处于空闲状态。因此，我们也看到很多文档里建议，工作者线程数为(CPU数*2+2)。

在一个等待线程转换到运行状态时，有可能会出现短暂的时间运行线程数超过最大并发线程数，这个时候OS会迅速地让这个新转换
的线程阻塞，从而减少这个数量。(关于这个观点，MSDN上只说：by not allowing any new active threads，却没说明not allowing
what)

调度原理

这个知道了其实没什么意义，都是内核做的事，大致上都是操作线程control block，直接摘录<Inside IO Completion Ports>:

The list of threads hangs off the queue object. A thread's control block data structure has a pointer in it that
references the queue object of a queue that it is associated with; if the pointer is NULL then the thread is not
associated with a queue.

So how does NT keep track of threads that become inactive because they block on something other than the completion
port" The answer lies in the queue pointer in a thread's control block. The scheduler routines that are executed
in response to a thread blocking (KeWaitForSingleObject, KeDelayExecutionThread, etc.) check the thread's queue
pointer and if its not NULL they will call KiActivateWaiterQueue, a queue-related function. KiActivateWaiterQueue
decrements the count of active threads associated with the queue, and if the result is less than the maximum and
there is at least one completion packet in the queue then the thread at the front of the queue's thread list is
woken and given the oldest packet. Conversely, whenever a thread that is associated with a queue wakes up after
blocking the scheduler executes the function KiUnwaitThread, which increments the queue's active count.

参考资料

<Inside I/O Completion Ports>:
http://technet.microsoft.com/en-us/sysinternals/bb963891.aspx
<I/O Completion Ports>:
http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx
<INFO: Design Issues When Using IOCP in a Winsock Server>:
http://support.microsoft.com/kb/192800/en-us/

本文转自：http://www.cppblog.com/kevinlynx/archive/2008/06/23/54390.html

问题的关键就在于：Base类的析构函数不是virtual的。因为不是virtual，所以在对一个Base类型的指针进行delete时，就不会调用到派生类Derived的析构函数。而派生类里的析构函数会用于析构其内部的子对象，也就是这里的m_data。这样，就造成了内存泄漏。

这其实是一个很低级的失误。但毫不客气地说C++中有很多这种少个关键字或者代码位置不对就会造成另一个结果的例子。事实上，针对这些悲剧也有很多书提出一些准则来让大家去无脑遵守。例如针对这个例子，我就记得曾有书说，只要你觉得你的类会被继承，那么最好给析构函数加上virtual。

原文地址： http://codemacro.com/2012/09/13/c-plus-plus-virtual-destructor/
written by Kevin Lynx  posted at http://codemacro.com

本文转自：http://www.cppblog.com/kevinlynx/archive/2012/09/13/190541.html