在WinMain()函数中，E序所q行的最重要工作是注册窗口类Q从而把自定义的H口q程提供lWindows。然后程序调用Windows创徏和显C窗口，由此启动同用L交互q程。在消息循环中，E序不断取得消息Q但q不q行处理Q而是其发回WindowsQ由Windows消息发l相应的H口q程。消息@环的作用在于控制生命期，如果没有消息循环Q进E将立即l束?
在较高层ơ上来看Q一个可扩展的系l会l模块提供资源和自由Q而模块应当配合系l的整体l构。程序执行时QWindows会ؓ其创E，分配资源Qƈ调用WinMain()。WinMain()是进E入口，也是q程出口Q在此期间进E可以做M事情Q但是ؓ了用Windows提供的各U便利，它必ȝ合WindowsE序模型Q将自己的运行结合到Windows环境中。作E出口，WinMain()军_着E序生命期。一个提供窗口过E而等待Windows调用的程序如何维持和l束自己的生命期呢，应该由消息来军_。当q程没有要处理的消息Ӟ它应该等待，所以WinMain()必须知道有没有消息，Windows发给H口q程的消息不能绕qWinMain()Q当q程收到特定的消息时Q它l束生命期，所以WinMain()q应该了解消息的内容。这正是GetMessage()所做的Q如果取不到消息阻塞，如果取到WM_QUIT消息p?Q结束消息@环。那么如果取到普通的消息呢，由WinMain()直接调用H口q程不可以吗Q这U做法有悖于E序由Windows调用的基本思想Q而实际上也会出现问题。一个窗口程序可能有很多H口c，一些窗口类及其H口q程是程序自定义的，另一些则是在Windows内部定义的，E序看不到其H口q程Q比如各U控件窗口。窗口程序运行v来以后，q些H口cM盔R合，它们通信的方式就是消息。由于消息指向的H口q程可能是自定义的，也可能是Windows内部的，只有Windows才能把它们都送到目的圎ͼq保持发送方式的一致性。所以WinMain()取到消息后，通过DispatchMessage()其发回WindowsQ由Windows为其调用适当的窗口过E，直到H口q程调用后返回WindowsQDispatchMessage()才返回?Windows调用H口q程之后控制首先q回WindowsQ由WinMain()调用H口q程之后控制保持在程序中Q这U区别是否也有作用？不过l我试验Q在一个Win32 SDK的HelloE序中改由WinMain()调用H口q程Q没有发C么问?
参考资料：
1.《WindowsE序设计?Charles Petzold ?北京博RU技发展有限公司 ?北大出版C?
]]>
产生q个问题的原因是QEXE和DLL中分别静态链接了Cq行时库Q从而new和deleteq算W来自Cq行时库的不同版本。Cq行时库在管理堆内存Ӟ会用一些全局变量来跟t内存分配情况，因此E序中链接的Cq行时库必须唯一Q否则就会引起不一致?br />
解决的办法很单：在EXE和DLL中都动态链接Cq行时库Q也是在工E设|的Link面板选择"忽略所有默认的?Q再加入msvcrt.lib?br />
对这个问题有两种错误的观炚w要澄清：一U以为EXE和DLL有不同的堆，实际上DLLL被映到加蝲它的q程的地址I间Q它没有自己的堆Q一U以为DLL和EXE相对于不同的起始地址Q动态链接的地址映射机制引v了前面的问题Q实际上DLL是和OBJ一L目标模块Q每个目标模块都有自q起始地址Q但是链接成加蝲模块以后׃l一C个v始地址Q一个目标模块对其它模块的引用在链接前是以符h式表C的Q链接后会被修改成地址方式。静态链接和动态链接都会保证：加蝲模块是统一~址的?br />
参考资料：
1. http://topic.csdn.net/t/20020714/19/873683.html
2. MSDN July 2000/Knowledge Base/Windows Development/Win32 Software Development Kit/HOWTO: Use the C Run-Time
3. 《操作系l－内核与设计原?W四??William Stallings 著，迎梅等?电子工业出版C?br />
]]>
1. Z么要用异总曉K误码?
错误码的~点Q?span lang="EN-US">
1) 默认是可以忽略的Q因用函数时可以不处理其q回|从而错误处理要依赖于程序员的主动性，而不是程序机制的要求Q?/span>
2) 不能跨作用域传送，必须逐层向上转发Q即使中间没有对错误码进行重新定义；
使用异常可以解决解决q两个问题：
1) 异常默认是不可忽略的Q抛出的异常必须捕获Q否则就会报错；
2) 异常可以跨作用域传送，从而错误的发现和处理被很好地分d来；
2. 异常和断a的区别：
异常被捕获后可以不作处理Q程序从捕获位置l箋执行。而断a是完全无法忽略的Q程序在断言p|处立即终止。因此断a通常用于调试版本Q用来发现程序中的逻辑错误。虽然异怹能v到这L作用Q但是不应该用异总替断aQ?br />1) 如果发现了逻辑错误Q必M改程序，而不可能在程序中q行处理和恢复，所以不需要向外传送，没有必要使用异常?br />2) 使用断言的开销比异常小得多Q而且断言可以从发布版中完全去除?br />
异常用于处理正确E序中的q行期问?span lang="EN-US">(比如内存分配p|Q窗口创建失败，U程创徏p|Q打开文gp|)Q以可能恢复，而不是终止程序。对于运行异常，使用断言是非怸合适的Q理由很昄Q?br />1) 断言在发布版不v作用Q?br />2) 断言的处理方式不够友好；
3) q行异常不是E序错误Q没有必要报告源代码出错位置Q?br />
参考资料：
1.《C++~程规范-101条规则、准则与最佛_c?Herb SutterQAndrei Alexandrescu ?刘基??人民邮电出版C?br />2.《C++E序设计语言?Bjarne Stroustrup 著 裘宗燕 ?机械工业出版C?br />3.《C与C++中的异常处理?Robert Schmidt ?无情 ?http://download.pchome.net/development/reference/11135.html
]]>
从MVC的Ş成过E来看，最初只有模型和视图两个元素。模型封装了数据q提供操作接口，视图用来表现数据和接收用戯求。模型是独立的，而视图依赖于模型Q从模型获取数据q行昄Q向模型发送用戯求，q根据返回结果刷新自己?br>
需要用多个视图表现同一模型Ӟ情况发生了变化：一个视图修Ҏ据以后，不但本n要刷斎ͼ其他所有视图也要刷新。如果由该视N知其他视图Q它需要知道其他所有视图，׃每个视图都可能发Z改，每个视图都要知道其他所有视图，q种兌q于复杂Q不但难以维护，而且不便于增加新的视图。如果让模型通知所有视图更斎ͼ可能会媄响模型的独立性。用观察?Observer)模式可以解决上述矛盾Q从而实玎ͼ由模型通知视图Q而模型不依赖于具体的视图Q具体视图之间相互独立?br>
视图是用戯求的接收者，但不宜作求的处理者。因为界面是易变的，如果业务代码和界面代码放在一P频繁的界面修改可能会破坏比较E_的业务代码。将业务逻辑分离出来Q由一个控制器负责Q就是ؓ了避免这U干扰?br>
模型Q视囑֒控制器的基本协作关系如下?br>
模型在状态变化的时候，直接通知所有视图，视图向模型查询状态数据，然后h自n。当用户发出操作Ӟ视图把消息发l控制器Q控制器按照业务逻辑q行处理Q需要查询或更新数据Ӟ控制器会调用模型。下面是一个更详细的示意图
同样的数据，可以有不同的昄和进行各U处理。显CZ仅是表现数据Q而处理是Ҏ用户h改变数据的过E，不但包含业务逻辑Q也要提供响应策略。响应策略由控制器负责，视图可以使用不同的控制器提供不同的响应方式，q是{略(Strategy)模式的应用?br>
此外QMVCq允许视囑ֵ套，通过使用l合(Composite)模式Q一致地处理l合视图和普通视图?br>
用多个视图表C个模型，在视图不变的情况下改变响应策略，允许视图嵌套Q这是MVC的三个主要特性。在内部l构上，MVC的主要关pLp察者模式，{略模式和组合模式给出的。由观察者模式确定的模型视图关系是其中最为重要的?br>
MVC模式有许多变体。前q结构中Q由模型通知视图hQ称Z动MVCQ如果由控制器更新模型以后通知视图Q称动MVCl构。在许多应用中，没有明显的控制器角色Q也没有视图嵌套。可见根据实际需要，构成MVC的三个模式上都可能出现变化。Web览器就是被动MVCl构的一个实例?img height=437 alt="" src="http://www.shnenglu.com/images/cppblog_com/zliner/Browser.gif" width=652 border=0>
“览器是一个交互程序，从概念上Ԍ它是׃l客戗一l解释器与一个管理它们的控制器所l成。控制器形成了浏览器的中心部Ӟ它解释鼠标点M键盘输入Qƈ且调用其他组件来执行用户指定的操作。例如，当用户键入一个URL或者点M个超文本引用Ӟ控制器调用一个客户从所需文档所在的q程服务器上取回该文档，q且调用解释器向用户昄该文档?font face="Times New Roman">每个览器必d含一个HTML解释器来昄文档Q其他解释器是可选的。HTML解释器的输入q合HTML语法的文档所l成Q输出由位于用户昄器上的格式版本文档所l成。解释器通过HTML规则转换成适合用户昄g的命令来处理版面l节。HTML解释器一个最重要的功能是包含可选项。解释器必须存储关于昄器上位置之间关系的信息和HTML文档中被瞄定的项。当用户用鼠标选定了一个项Q浏览器通过当前的光标位|和存储的位|信息来军_哪个被用户选定?/font>”(参考资?)
MFC的文?视图l构(Document/View architecture)是MVC模式的一U变体，下面讨论它是怎样实现的?br>
文档/视图l构没有体现业务逻辑和视囄分离Q但是将响应{略和视囑分开来。它主要包含四种对象Q?/p>
- 文档
- 视图
- 视图框架H口
- 文档模板
q里的视图框架窗口定义了视图对用戯入的响应方式Q而文档模板用来管理前三种对象的组合。文档，视图Q视图框架窗口三者是对应的，从而构成一个三元组。一个应用程序可能需要多个这L三元l，以实现文档的多视图，所以引入文档模板来表示该三元组。因为程序中可能使用多个文档模板QMFC用一个文档管理者对象来理它们?br>
在MFC中，应用E序和主框架H口是用来封装底层机制的对象Q文档，视图Q视图框架窗口和文档模板是用来构架文?视图l构的对象。应用程序通过文档理者来使用文档/视图l构?br>
如果要给文档增加一U视图，只需要增加一个文档模板；如果要改变一U视囄响应{略Q只要改变对应文档模板中的视图框架窗口?br>
<未完待箋>
参考资料：
1.《设计模?可复用面向对象Y件的基础?Erich Gamma{著Q李英军{译 机械工业出版C?br>2.《Java与模式?阎宏 电子工业出版C?br>3. 模型-视图-控制?/a> ( MSDN > 技术资源库 > 体系l构 > 使用 Microsoft .NET 的企业解x案模?nbsp;>
4. 《Java设计Q对象，UML和过E?Kirk Knoernschild 著，|英伟等?人民邮电出版C?br>5. 《计机|络与因特网?D.E.Comer ?徐良贤等?机械工业出版C?br>6.《深入解析MFC?中国电力出版C?br>7.《VC技术内q》第5?/ 希望电子出版C?/nobr>
]]>
2. 用例之间的基本关pLQ泛化，包含和扩展?br />用例A到B的泛化关p表CA和B是具体与抽象的关pR?br />用例A到B的包含关p表CA使用了B提供的功能?br />用例A到B的扩展关p表CA向B提供的可用的功能?br />但从A到B的包含关pd从B到A的扩展关pL不同的：
A包含B说明B是从A中分解出来的公共行ؓQB自n是独立的Q但对于A来说是不可缺的一部分?br />B扩展A说明B是从A中分解出来的变体行ؓQ必L定扩展点Q也是在基本用例中执行变体行ؓ的具体条件。B仅仅是A的补充，而不是不可缺的部分QB自n也不是独立的。A可以单独执行Q表C通常的情况，在特定的情况下，用B来补充它?br />抽象用例不能被实例化Q不能被实际执行Q它的作用在于更好地l织用例关系?br />
参考书Q?br />《UML用户指南?Grady BoochQJames RumbaughQIvar Jacobson?늻忠等?机械工业出版C?br />《统一软g开发过E?Ivar JacobsonQGrady BoochQJames Rumbaugh?周伯生等?机械工业出版C?br />
]]>
单个操作pȝ的引DE是q样的：首先Q主引导记录(MBR)被加载到内存q行Q它d盘分区?DPT)Q查扄一个活动分?可引导分?Q该分区的引导扇区存攄操作pȝ的引D录。然后，pȝ引导记录被加载到内存q行Q它从系l安装目录读取系l的启动文gQ将其加载执行，控制随后的启动过E?/span>
q里面涉及到一些程序和数据Q它们存攑֜不同的地方，在不同阶D运行。第一D늨序MBRQ它的数据是DPTQ它们存攑֜盘的主引导扇区。第二段E序是系l引D录，存放在系l所在分区的引导扇区。第三段E序是系l启动文Ӟ存放在系l所在分区系l安装目录中。这三段E序像接力跑一P前一D늨序的工作是加蝲后一D늨序，q把控制交给它?/span>
引导记录和启动文仉操作pȝ而不同，
是在安装时Ş成的Q每个系l的安装E序都把其引D录写入安装分区的引导扇区Q而启动文件是pȝ的一部分?/span>
上面的引DE有一个基本缺P是只能引导一个系l，q且只能引导装在W一zd分区的系l?br />
如果一个操作系l不在活动分区，那么该系l要被引导有三种办法Q改写MBRQ改写第一zd分区引导记录Q或把所在分为第一zd分区。最后一U做法是不方便的Q系l通常会改写前两段引导E序Q那么它在解册w引导问题的同时Q也不能破坏其他pȝ的引|q就引出了多pȝ地引导问题。常见的做法?/span>pȝ提供一个启动管理器接管引导q程。启动管理器能够获得机器上多个系l的引导记录Q从而可以根据用户选择启动不同的系l。系l在安装时改写磁盘第一zd分区的引D录，使启动管理器被作为第三段E序加蝲?/span>
如果启动理器能够知道机器上每个pȝ所在的分区Q就能获得该pȝ的引D录，从而可以引Dpȝ。但实际上，启动理器所属系l的引导记录是不能再ơ被加蝲的，必须Ҏ对待。同一pd的系l，也可能有cM的问题。所以启动管理器可能要了解机器上每个pȝ具体如何启动Q相应进行引对{这样只有让高版本的pȝ提供启动理器，因ؓ低版本的启动理器无法启动高版本pȝ?/span>2000/XP的启动管理器是OS Loader。它?8?000/XP的引导就是不同的Q对98是加?8引导记录的镜像文Ӟ?000/XP是加载HAL.DLL{文件。OS Loader在引导多pȝӞ对于windowspd的引导有Ҏ性，必须向下兼容?/span>
OS Loader的蝲体是ntldr文gQ它q行时还会读取一个配|文件boot.iniQ两个文仉存放在磁盘第一zd分区根目录。boot.ini记录了每个系l所在的分区Q每个版本的windows在安装时都会在boot.ini中填写有兌w的一V?000/XP在安装时都会更新OS Loader和重写第一zd分区的引D录，后安装者的两个E序才会被保留。如果后?000Q由于前q的OS Loader版本问题Q就可能无法引导XP?/span>
]]>
1. 问题Q对32位的二进制整敎ͼ不用循环Q求出其?的个数?br />
#define POW(c) (1<<(c))#define MASK(c) (((unsigned long)-1) / (POW(POW(c)) + 1))#define ROUND(n, c) (((n) & MASK(c)) + ((n) >> POW(c) & MASK(c)))int bit_count(unsigned int n)
{
n = ROUND(n, 0); n = ROUND(n, 1); n = ROUND(n, 2); n = ROUND(n, 3); n = ROUND(n, 4); return n;
}基本的想法是把所有的1加v来，得到的就?的个数。我们需要把q些1分离出来Q每?都是q等的，与其位置无关。难题在于不能一个一个去取，那就用到了@环，当然递归也是不允许的。需要有一U统一的办法，可是很难惌具体该怎样。我们逐步地做qg事，假设?6位和?6位分别求得了1的个敎ͼ那么加v来就行了?6位二q制中的1仍然是未知的Q随机出现的Q问题的性质没有变，但我们可以l分解，q种逐步的做法不一定就意味着递归。每?6位分解ؓ两个8位，...,每个2位分解ؓ两个1位，把两?位上的数相加是q两位上1的个数。现在需要取出每一位上的数吗？如果惛_了这个问题，q最l的思\不远了。现?2位已l分成了16个两位，很容易将其看作两?6位，一个是所有奇CQ一个是所有偶C。我们不难把q两?6位分开Q然后移位相加，求Z每两位中1的个数。到了这一步，以后的思\很自然了?br />
参考：
《计二q制?1'的个数》来自?a >http://kaikai.cnblogs.com
]]>