问题p军_Q哈哈！
QQError C1189 Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
A:Go to the project properties (Project menu, Properties). Set 'Use of MFC' to "Use MFC in a Shared DLL". You have to make this change for both the debug and release configurations
]]>
TinyXML是一个开源的解析XML的解析库Q能够用?/span>C++Q能够在Windows?/span>Linux中编译。这个解析库的模型通过解析XML文gQ然后在内存中生?/span>DOM模型Q从而让我们很方便的遍历q棵XML树?/span>
DOM模型x对象模型，是将整个文档分成多个元素Q如书、章、节、段{）Qƈ利用树型l构表示q些元素之间的顺序关pM及嵌套包含关pR?br /> 不过TinyXml需要用者手动释放new出的内存。初学C++者往往Ҏ造成内存泄露?/span>
]]>
Pen pen(Color::Black);
int width = abs(m_vecPoint[1].X - m_vecPoint[0].X);
int height = abs(m_vecPoint[1].Y - m_vecPoint[0].Y);
if (width<0||height<0)
{
graphic.DrawRectangle(&pen,m_vecPoint[1].X,m_vecPoint[1].Y,width,height);
}
else{
graphic.DrawRectangle(&pen,m_vecPoint[0].X,m_vecPoint[0].Y,width,height);
}
]]>
//调用位图,执行E序时打开囄2
CDC memdc;3
CBitmap *olddc;4
CBitmap bitmap;5
bitmap.LoadBitmap(IDB_BITMAP1);6
pDC=this->GetDC();7
memdc.CreateCompatibleDC(pDC);8
olddc=memdc.SelectObject(&bitmap);9
pDC->BitBlt(0,0,rect.Width(),rect.Height(),&memdc,0,0,SRCCOPY);当然Q先免不了设|坐标系?img src ="http://m.shnenglu.com/polly-yang/aggbug/147629.html" width = "1" height = "1" />]]>
核心代码如下
1// TODO: 在此处ؓ本机数据dl制代码
2 CRect rect;
3 GetClientRect(&rect);
4
5 pDC->SetMapMode(MM_ANISOTROPIC);
6 pDC->SetWindowExt(100, 100);//H口逻辑大小Q?000*1000,
7 pDC->SetViewportExt(100, -100);//改变Y坐标方向--viewport使用物理大小
8 pDC->SetViewportOrg(rect.left, rect.bottom);//讄H口中心点ؓ坐标pd?-Viewport使用物理大小
9 CPen PenNew(PS_GEOMETRIC,10,RGB(255,0,0));
10 CPen* pPenOld;
11 pPenOld=pDC->SelectObject(&PenNew);
12
srand((unsigned) time(NULL)); /*播种?/span>*/
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();
// TODO: 在此处ؓ本机数据dl制代码2
CRect rect;3
GetClientRect(&rect);4
5
pDC->SetMapMode(MM_ANISOTROPIC);6
pDC->SetWindowExt(100, 100);//H口逻辑大小Q?000*1000,7
pDC->SetViewportExt(100, -100);//改变Y坐标方向--viewport使用物理大小8
pDC->SetViewportOrg(rect.left, rect.bottom);//讄H口中心点ؓ坐标pd?-Viewport使用物理大小 9
CPen PenNew(PS_GEOMETRIC,10,RGB(255,0,0));10
CPen* pPenOld;11
pPenOld=pDC->SelectObject(&PenNew);12
srand((unsigned) time(NULL)); /*播种?/span>*/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();Q?/p>
1) NOOP
NOOP法的全写ؓNo Operation。该法实现了最最单的FIFO队列Q所有IOh大致按照先来后到的顺序进行操作。之所以说“大致”Q?/p>
原因是NOOP在FIFO的基上还做了盔RIOh的合qӞq不是完完全全按照先q先出的规则满IOh。NOOP假定I/Oh由驱动程序或者设
备做了优化或者重排了序(像一个智能控制器完成的工作那?。在有些SAN环境下，q个选择可能是最好选择。Noop 对于 IO 不那么操
心，Ҏ有的 IOh都用 FIFO 队列形式处理Q默认认?IO 不会存在性能问题。这也?CPU 也不用那么操心?a >www.linuxidc.com当然
Q对于复杂一点的应用cdQ用这个调度器Q用戯己就会非常操心?
2) Deadline scheduler
DEADLINE在CFQ的基上，解决了IOh饿死的极端情c除了CFQ本nh的IO排序队列之外QDEADLINE额外分别IO和写IO提供了FIFO
队列。读FIFO队列的最大等待时间ؓ500msQ写FIFO队列的最大等待时间ؓ5s。FIFO队列内的IOh优先U要比CFQ队列中的高，Q而读FIFO
队列的优先又比写FIFO队列的优先高。优先可以表示如下Q?
FIFO(Read) > FIFO(Write) > CFQ
deadline 法保证对于既定?IO h以最的延迟旉Q从q一点理解，对于 DSS 应用应该会是很适合的?/p>
3) Anticipatory scheduler
CFQ和DEADLINE考虑的焦点在于满零散IOh上。对于连l的IOhQ比如顺序读Qƈ没有做优化。ؓ了满随机IO和顺序IO混合的场景，
Linuxq支持ANTICIPATORY调度法。ANTICIPATORY的在DEADLINE的基上，为每个读IO都设|了6ms 的等待时间窗口。如果在q?ms内OS?/p>
C盔R位置的读IOhQ就可以立即满
Anticipatory schedulerQas) 曄一度是 Linux 2.6 Kernel ?IO scheduler 。Anticipatory 的中文含义是”预料? 预想?#8221;, q个
词的揭CZq个法的特点，单的_有个 IO 发生的时候，如果又有q程h IO 操作Q则生一个默认的 6 毫秒猜测旉Q猜?/p>
下一?q程h IO 是要q什么的。这对于随即d会造成比较大的延时Q对数据库应用很p糕Q而对?Web Server {则会表现的不错?/p>
q个法也可以简单理解ؓ面向低速磁盘的Q因为那?#8221;猜测”实际上的目的是ؓ了减磁头移动时间?/p>
4QCFQ
CFQ法的全写ؓCompletely Fair Queuing。该法的特Ҏ按照IOh的地址q行排序Q而不是按照先来后到的序来进行响应?
在传l的SAS盘上Q磁盘寻道花Ml大多数的IO响应旉。CFQ的出发点是对IO地址q行排序Q以量的盘旋{ơ数来满_可能多的
IOh。在CFQ法下，SAS盘的吞吐量大大提高了。但是相比于NOOP的缺ҎQ先来的IOhq不一定能被满I可能会出现饿ȝ情况?
Completely Fair Queuing Qcfq, 完全公^队列) ?2.6.18 取代?Anticipatory scheduler 成ؓ Linux Kernel 默认?IO scheduler
。cfq Ҏ个进E维护一?IO 队列Q各个进E发来的 IO h会被 cfq 以轮循方式处理。也是Ҏ一?IO h都是公^的。这使得
cfq 很适合Lȝ应用(eg: OLTP DB)。我所知道的企业 Linux 发行版中QSUSE Linux 好像是最先默认用 cfq ?
查看和修改IO调度器的法非常单。假设我们要对sdaq行操作Q如下所C：
cat /sys/block/sda/queue/scheduler
echo “cfq” > /sys/block/sda/queue/scheduler
ȝ:
1 CFQ和DEADLINE考虑的焦点在于满零散IOh上。对于连l的IOhQ比如顺序读Qƈ没有做优化。ؓ了满随机IO和顺序IO混合的场?/p>
QLinuxq支持ANTICIPATORY调度法。ANTICIPATORY的在DEADLINE的基上，为每个读IO都设|了6ms的等待时间窗口。如果在q?ms内OS?/p>
C盔R位置的读IOhQ就可以立即满?/p>
IO调度器算法的选择Q既取决于硬件特征，也取决于应用场景?
在传l的SAS盘上QCFQ、DEADLINE、ANTICIPATORY都是不错的选择Q对于专属的数据库服务器QDEADLINE的吞吐量和响应时间都表现良好?/p>
然而在新兴的固态硬盘比如SSD、Fusion IO上，最单的NOOP反而可能是最好的法Q因为其他三个算法的优化是基于羃短寻道时间的Q?/p>
固态硬盘没有所谓的寻道旉且IO响应旉非常短?/p>
2 对于数据库应? Anticipatory Scheduler 的表现是最差的。Deadline ?DSS 环境表现?cfq 更好一点，?cfq l合来看表现更好一
些。这也难?RHEL 4 默认?IO 调度器设|ؓ cfq. ?RHEL 4 ?RHEL 3Q整?IO 改进q是不小的?
]]>
教材上的法Ҏ没讲明白，琢磨了好久。其实分cL果很不好。数据分析sample如下Q?br /> 3.20 2.00----0
4.60 5.70----0
1.50 5.00----0
1.80 6.90----3
6.10 5.50----0
7.40 4.90----5
7.20 9.30----6
8.40 0.40----7
9.00 2.70----8
4.30 1.20----0
]]>