1，const char*（C风格字符串）与string之间转换：

             （1） const char*可以直接对string类型赋值，例如：

                       const char* pchar = "qwerasdf";

                       stringstr = pchar;

             （2） string通过c_str()函数转换为C风格字符串，例如：

                       string str = "qwerasdf";

                       const char* pchar = str.c_str();

2，const char*类型可以直接给CString类型赋值，例如：

               const char* pchar = "qwerasdf";

               CString str = pchar;

3，string类型变量转为为Cstring类型变量

             CString类型变量可以直接给string类型变量赋值，但是string类型不能对CString类型直接赋值。通过前两类

      转换我们可以得到，string类型变量转换为const char*类型，然后再直接赋值就可以了。例如：

       CString cstr；

       sring str = “asdasd”；

       cstr = str.c_str();

      同理，CStrng类型变量先转换为string类型在调用c_str()函数就可以完成向const char*类型的转换。例如：

      CString cStr = "adsad";   

      string str = cStr;  

      const char* pchar = str.c_str();
4，double，int转string

      double temp;
   stringstream strStream;
   strStream<<temp;
   string ss = strStream.str() 

   string 转double，int 
   string.atoi   ,   string.atof

     从上面我们可以上面看出，通过类型之间的相互转化，会使本来要通过复杂的函数来完成的类型转换变得简单易懂。

TinyXML是一个开源的解析XML的解析库，能够用于C++，能够在Windows或Linux中编译。这个解析库的模型通过解析XML文件，然后在内存中生成DOM模型，从而让我们很方便的遍历这棵XML树。

DOM模型即文档对象模型，是将整个文档分成多个元素（如书、章、节、段等），并利用树型结构表示这些元素之间的顺序关系以及嵌套包含关系。
    不过TinyXml需要使用者手动释放new出的内存。初学C++者往往容易造成内存泄露。

CWnd::GetClientRect  
    void GetClientRect( LPRECT lpRect ) const;
Parameters:
lpRect
    Points to a RECT structure or a CRect object to receive the client coordinates. The left and top members will be 0. The right and bottom members will contain the width and height of the window.
Remarks:
    Copies the client coordinates of the CWnd client area into the structure pointed to by lpRect. The client coordinates specify the upper-left and lower-right corners of the client area. Since client coordinates are relative to the upper-left corners of the CWnd client area, the coordinates of the upper-left corner are (0,0).

CWnd::GetWindowRect
void GetWindowRect( LPRECT lpRect ) const;
Parameters:
lpRect
Points to a CRect object or a RECT structure that will receive the screen coordinates of the upper-left and lower-right corners.
Remarks:
Copies the dimensions of the bounding rectangle of the CWnd object to the structure pointed to by lpRect. The dimensions are given in screen coordinates relative to the upper-left corner of the display screen. The dimensions of the caption, border, and scroll bars, if present, are included.

GetWindowRect() 得到的是在屏幕坐标系下的RECT；（即以屏幕左上角为原点）
GetClientRect() 得到的是在客户区坐标系下的RECT； （即以所在窗口左上角为原点）

GetWindowRect()取的是整个窗口的矩形；
GetClientRect()取的仅是客户区的矩形，也就是说不包括标题栏，外框等；

第一个函数获得的是窗口在屏幕上的位置，得到的结果可能是这样CRect(10,10,240,240);
第二个函数和它不同，它只获得了客户区的大小，因此得到的结果总是这样CRect(0,0,width,height);

ScreenToClient() 就是把屏幕坐标系下的RECT坐标转换为客户区坐标系下的RECT坐标。

The GetClientRect function retrieves the coordinates of a window's client area. The client coordinates specify the upper-left and lower-right corners of the client area. Because client coordinates are relative to the upper-left corner of a window's client area, the coordinates of the upper-left corner are (0,0).

GetClientRect得到的是客户区的大小，也就是说这样得到的左上角永远是（0，0）

The GetWindowRect function retrieves the dimensions of the bounding rectangle of the specified window. The dimensions are given in screen coordinates that are relative to the upper-left corner of the screen.

GetWindowRect 是窗口相对于整个屏幕的坐标，屏幕左上点为0，0

相互转化用ScreenToClient 或者 ClientToScreen

ClientToScreen
The ClientToScreen function converts the client coordinates of a specified point to screen coordinates.
BOOL ClientToScreen(
   HWND hWnd,        // window handle for source coordinates
   LPPOINT lpPoint   // pointer to structure containing screen coordinates
);
Parameters
hWnd
Handle to the window whose client area is used for the conversion.
lpPoint
Pointer to a POINT structure that contains the client coordinates to be converted. The new screen coordinates are copied into this structure if the function succeeds.
Return Values
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero.
虽然存在调用GetWindowRect后再调用ScreenToClient==GetClientRect，但ScreenToClient（）和ClientToScreen()两者都是属于WINDOWS API函数，可能是存在一定的冗余设计，但意义不同。
不过在.Net Framework下对WINDOWS API函数进行了重新整理和优化，在获取控件或窗口的屏幕坐标和客户区坐标时更方便的多，只需要得到与控件或窗口相对应屏幕坐标和客户区坐标属性值就可以了。

 1// TODO: 在此处为本机数据添加绘制代码
 2    CRect rect;
 3    GetClientRect(&rect);
 4
 5    pDC->SetMapMode(MM_ANISOTROPIC);
 6    pDC->SetWindowExt(100, 100);//窗口逻辑大小：1000*1000,
 7    pDC->SetViewportExt(100, -100);//改变Y坐标方向--viewport使用物理大小
 8    pDC->SetViewportOrg(rect.left, rect.bottom);//设置窗口中心点为坐标系原点--Viewport使用物理大小 
 9    CPen PenNew(PS_GEOMETRIC,10,RGB(255,0,0));
10    CPen* pPenOld;
11    pPenOld=pDC->SelectObject(&PenNew);
12    srand((unsigned) time(NULL)); /**//*播种子*/
13    pDC->MoveTo(50,50);
14    //pDC->LineTo(100,100);
15    for (int i=0;i<5;i++){
16        int x=rand()%500;
17        int y=rand()%500;
18        pDC->LineTo(x,y);
19        pDC->BitBlt(x,y,25,25,NULL,0,0,BLACKNESS);
20
21    }
22    pDC->SelectObject(pPenOld);
23    PenNew.DeleteObject();

：

1) NOOP

NOOP算法的全写为No Operation。该算法实现了最最简单的FIFO队列，所有IO请求大致按照先来后到的顺序进行操作。之所以说“大致”，

原因是NOOP在FIFO的基础上还做了相邻IO请求的合并，并不是完完全全按照先进先出的规则满足IO请求。NOOP假定I/O请求由驱动程序或者设

备做了优化或者重排了顺序(就像一个智能控制器完成的工作那样)。在有些SAN环境下，这个选择可能是最好选择。Noop 对于 IO 不那么操

心，对所有的 IO请求都用 FIFO 队列形式处理，默认认为 IO 不会存在性能问题。这也使得 CPU 也不用那么操心。www.linuxidc.com当然

，对于复杂一点的应用类型，使用这个调度器，用户自己就会非常操心。

2) Deadline scheduler

DEADLINE在CFQ的基础上，解决了IO请求饿死的极端情况。除了CFQ本身具有的IO排序队列之外，DEADLINE额外分别为读IO和写IO提供了FIFO

队列。读FIFO队列的最大等待时间为500ms，写FIFO队列的最大等待时间为5s。FIFO队列内的IO请求优先级要比CFQ队列中的高，，而读FIFO

队列的优先级又比写FIFO队列的优先级高。优先级可以表示如下：

FIFO(Read) > FIFO(Write) > CFQ

deadline 算法保证对于既定的 IO 请求以最小的延迟时间，从这一点理解，对于 DSS 应用应该会是很适合的。

3) Anticipatory scheduler

CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求，比如顺序读，并没有做优化。为了满足随机IO和顺序IO混合的场景，

Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上，为每个读IO都设置了6ms 的等待时间窗口。如果在这6ms内OS收

到了相邻位置的读IO请求，就可以立即满足

Anticipatory scheduler（as) 曾经一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含义是”预料的, 预想的”, 这个

词的确揭示了这个算法的特点，简单的说，有个 IO 发生的时候，如果又有进程请求 IO 操作，则将产生一个默认的 6 毫秒猜测时间，猜测

下一个 进程请求 IO 是要干什么的。这对于随即读取会造成比较大的延时，对数据库应用很糟糕，而对于 Web Server 等则会表现的不错。

这个算法也可以简单理解为面向低速磁盘的，因为那个”猜测”实际上的目的是为了减少磁头移动时间。

4）CFQ

CFQ算法的全写为Completely Fair Queuing。该算法的特点是按照IO请求的地址进行排序，而不是按照先来后到的顺序来进行响应。

在传统的SAS盘上，磁盘寻道花去了绝大多数的IO响应时间。CFQ的出发点是对IO地址进行排序，以尽量少的磁盘旋转次数来满足尽可能多的

IO请求。在CFQ算法下，SAS盘的吞吐量大大提高了。但是相比于NOOP的缺点是，先来的IO请求并不一定能被满足，可能会出现饿死的情况。

Completely Fair Queuing （cfq, 完全公平队列) 在 2.6.18 取代了 Anticipatory scheduler 成为 Linux Kernel 默认的 IO scheduler

。cfq 对每个进程维护一个 IO 队列，各个进程发来的 IO 请求会被 cfq 以轮循方式处理。也就是对每一个 IO 请求都是公平的。这使得

cfq 很适合离散读的应用(eg: OLTP DB)。我所知道的企业级 Linux 发行版中，SUSE Linux 好像是最先默认用 cfq 的.

查看和修改IO调度器的算法非常简单。假设我们要对sda进行操作，如下所示：

cat /sys/block/sda/queue/scheduler

echo “cfq” > /sys/block/sda/queue/scheduler

总结:

1 CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求，比如顺序读，并没有做优化。为了满足随机IO和顺序IO混合的场景

，Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上，为每个读IO都设置了6ms的等待时间窗口。如果在这6ms内OS收

到了相邻位置的读IO请求，就可以立即满足。

IO调度器算法的选择，既取决于硬件特征，也取决于应用场景。

在传统的SAS盘上，CFQ、DEADLINE、ANTICIPATORY都是不错的选择；对于专属的数据库服务器，DEADLINE的吞吐量和响应时间都表现良好。

然而在新兴的固态硬盘比如SSD、Fusion IO上，最简单的NOOP反而可能是最好的算法，因为其他三个算法的优化是基于缩短寻道时间的，而

固态硬盘没有所谓的寻道时间且IO响应时间非常短。

2 对于数据库应用, Anticipatory Scheduler 的表现是最差的。Deadline 在 DSS 环境表现比 cfq 更好一点，而 cfq 综合来看表现更好一

些。这也难怪 RHEL 4 默认的 IO 调度器设置为 cfq. 而 RHEL 4 比 RHEL 3，整体 IO 改进还是不小的。