a woman from inside out

Drum Machine

An amazing game,u can roll the ball to destination,but it's difficult. Just try it.
ps.I never imagine shockwave can make such 3D effects.Go figure!

They say we all lose 21 grams at the exact moment of our death.

Life has to go on with or without god.

       找工作就跟找女人一样，前面那个女人要求高，我某方面达不到要求，就被抛弃了。所以，我还得再找工作。

       前面那个女人能给我我想要的那么多，是否还能找到出的起同样价钱的呢，我不知道，说真的，没信心。

 

 

 

高 德 納 的 二 十 年 計 畫     
                                                            8123033 穆信成
高德納已經五十八歲了。  他打算再花二十年的時間繼續他的著作，
The Art of Computer Programming.   大家知道  Donald E. Knuth
是資訊科學界公認的大宗師，  知道他以他的重量級著作   The Art
of Computer Programming(以下簡稱TAOCP)[2,3,4] 聞名於世，原計
畫要出七冊，但目前只完成了三冊。但也許並沒有很多人知道他還有
個中文名字：「高德納」。
  * * *
TAOCP 這套書的名氣這麼大，敢去碰它的人反倒不多。寒假我因為一
些原因，讀了高德納的另一本書 "The Stanford GraphBase"[1]。大
師的書到底是什麼樣子呢？ 
高德納在序言裡說了寫這本書的原因：在寫 TAOCP 的第四冊前， 他
想要用一個叫做 ladders 的遊戲當作貫穿全書的例子。 於是寫了不
少相關的程式和龐大的測試資料，最後集結成了一個程式／資料庫。
他想這套 GraphBase 可以作為大家測試 graph 演算法的基礎，讓那
些 「街上混的程式員們 (programmers-on-the-street)」 知道電腦
科學家們也會做實際的事。另外，這套程式庫全部用他鼓吹的 liter-
ate programming 方式寫成，也可以當成一個活生生的例子。
最後一個，但卻是最重要的原因是，"to have fun".「的確，快樂是
這一路上最主要的原因，但我不敢承認。電腦科學家們總是得裝出一
副咬牙工作的樣子，讓別人心甘情願付給他們高薪水。但遲早這個社
會得承認， 有些工作仍然值得尊敬 --- 即使它們比任何事情都要來
得有趣。」
我不禁笑了。高德納在辦正事的途中岔出去做別的事情，一做就是好
幾年已經不是第一次。TeX 這個現在大家都在用的排版系統不就是他
嫌 TAOCP 被排得不好看， 因此自己捲起袖子研究電腦排版的產物嗎？
Tex 耗去了他十年的光陰，而這本 Stanford GraphBase 則可以追溯
到二十年前。高德納好像永遠不怕老？
Ladders 這個遊戲是這樣的：挑兩個五個字母的英文單字，試試看一
次一個字母，把一個字變成另外一個。但是在過程中它必須仍然是一
個英文單字。比如說把 black 變成 white 的方法是這樣的：
    black -> brack -> brace -> trace -> trice -> trite
    -> write -> white
大家看得出來，如果把每個單字當作一個 node,  兩個單字如果只差
一個字母，就連一條 edge,  那麼這個遊戲可以想成在兩個 node 中
找一條 path .
但 GraphBase 有趣的地方卻是資料。 高德納收集了一個含 5757 個
單字的資料庫。他參考了 1971 年以前 Beeler 為了這個遊戲專門編
的一部字典，刪去老的字，加入新的單字。高德納花了很大篇幅解說
他選字的標準：姓名不選，所以 Knuth 就沒有了；但是 gauss 已經
是一個電磁學單位，所以受錄了進去。他很耐心的等到 e-mail 終於
被大家寫成 email, 以便把他收集到資料庫中。
接下來就開始玩這個資料庫囉。高德納發現 5757 個單字中，有 774
個 degree 是 1 的（只有一根接出去的 edge），位居第一。Degree
= 2 的也有 727 個。株連最廣的單字是 "bares" 和 "cores" ， de-
gree = 25，而 "cores" 的 25 個鄰居都是 degree 大於 9 的。 De-
gree = 1 的單字中有 103 組根本就是孤零零的兩兩成對，如 alpha-
aloha, gonad-monad.  跑一個找 connected component 的演算法，
發現大部分的單字都在同一個有 4493 個單字的大 component 裡面。
高德納自己定了一個方法橫量單字在文章中的出現頻率。 在這 5757
個單字中， "which" 是最常出現的， 其次是 "there" 和 "their"。
"often" 果然常出現，比出現("occur") 還要常出現。
看來高德納真的是玩得不亦樂乎呢。"to have fun",  於是我們可以
想像高德納出這本書的真正原因，是他自己建了這些資料後，發現越
玩越有趣，終於忍不住想出書了。
玩過了單字，想知道美國大學足球隊誰比較強嗎？高德納已經把 120
支隊伍的 638 場比賽建成 graph 了。 他又參考資料， 找出美國的
128 個城市之間的最短距離，並且在發現前人的資料明顯錯誤後自己
寫程式來修正。把蒙娜麗莎的微笑掃描起來後，高德納示範了如何運
用 bipartite graph matching 的技巧，用骨牌重新拼出這幅名畫。
高德納的文筆親切而幽默。CWeb 是他大力推廣的 literate program-
ming 系統，他認為每個人都應該有一套。 「但是今天已經沒什麼人
能永遠跟上新軟體的發行，所以如果你沒有 CWeb,也不用覺得太有罪
惡感。」 接下來他解釋如何安裝  Stanford GraphBase,  這一段的
makefile 可以給想學 make 的同學們做很好的參考。 如果裝不起來
呢？高德納問，你有沒有好好祈禱呀？最後，他希望大家能像他一樣，
多用這些程式庫和資料檔做些實驗，「也許有天你也會迫不及待地想
出本這樣的書呢！」
瀏覽了全書，我想：高德納到底是太閒，還是有用不完的精力？將近
六十歲的他，仍舊充滿著旺盛的活力和赤子般的好奇心，而這一切又
以他深厚的功力做為基礎。
* * *
四月號的 Dr. Dobb's Journal 做了一篇高德納的專訪[5]。 為什麼
寫書寫到一半， 卻花了十年的時間在 Tex 上？   他說，  Niklaus
Wirth （Pascal, Modular-2 和 Oberon 的設計者）一直想設計飛機，
但他發現他需要夠好的工具，於是他設計了一個個的電腦語言，造了
自己的電腦。高德納也希望他的書能夠不因科技的進步而被淘汰，希
望即使製書的科技進步，他的書仍舊是用領先的方式製作的。
談到另一位大師 Edsgar Dijkstra, 他說 Dijkstra 的力量來自於他
不妥協的拗脾氣。「光是想像用 C++ 寫程式就會讓他病倒！」Dijk-
stra 的拿手技巧是鉅細靡遺地用 formal 方法推導、檢驗程式， 這
和工業界不斷產生數以 mega 計的軟體，  但使用者卻無時不負擔著
bug 的風險的實際情況顯然有段差距。高德納則認為自己位於兩種極
端的中間。一方面他贊同 formal 方法提供的可靠性，但他也知道在
大系統中這種方式的極限。他盡力維持他的軟體的品質，因此他願意
提供賞金給在 TeX 中找到新 bug 的人。
* * *
由於高德納已經不用 email 了，他有一個 Web page[6]，
    http://www-cs-faculty.Stanford.EDU/~knuth/
裡頭還有個 FAQ, 可以看到他中文名字的圖章。大家劈頭要問的當然
是：第四冊什麼時候出來呀？
他說，TAOCP的第四冊將會分成三部份，4A : Enumeration and Back-
tracking, 4B : Graph and Network Algorithms 和 4C : Optimiza-
tion and Recursion.  從 1997 年開始，他會以大約每 128 頁為一
個單位（ 高德納好像很喜歡用 2 的乘冪做單位，他付給找出 TAOCP
中錯誤的賞金也是 $65536 分）把第四冊的部份散發給大家，聽取各
方的意見。如果一切順利，第四冊將在 2003 年正式完成。第五冊的
完成時間則定在 2009 年。第五冊告一段落後，他會重新整理 TAOCP
的一到三冊，更新內容。再下一步，他將把一到五冊的重要內容全部
濃縮在一本書裡。之後才著手進行六和七冊。
所以，高德納至少得活到 2020 年囉....
為了完成 TAOCP, 高德納已經退休，過著半隱士的生活。 他不用 e-
mail, 不怎麼會見訪客， 取消大部分的演講和旅行。 他說，他得用
batch 方式工作，而不能把事情 swap 來 swap 去的。他託人在家裡
造了一座管風琴，空閒的時間裡，他就會彈彈琴自娛。如果你會彈琴，
他很願意和你見個面，來個四手聯彈。
為什麼那麼賣力呢？ 在DDJ的專訪裡， 當被問到他是否能從 Tex 和
Metafont 圖利時， 他說，一旦一個人能夠餵飽自己，能夠有個安身
之所，剩下的就是他能為別人做些什麼，如何能為群體做出一些貢獻
了。
因此他很希望程式創作者們不要把演算法當作自己的私產。程式應該
容易閱讀和了解，因為越多人能夠了解它，它才能夠發揮越大的影響
力。
也許他也是基於這個想法繼續 TAOCP 的寫作吧？  在他的 web page
中，對於他的這件「此生的大事」，他下了這樣的註腳：「我嘗試著
盡我所能的去學習電腦科學裡的一些領域，然後把這些知識摘要成大
家比較容易了解的方式，讓沒有那麼多時間做這種學習的人也能夠吸
收他們」。
為了這個目的，他必須閱讀超過二十萬頁的文件，然後把它們濃縮到
兩千頁裡頭。他寫的東西並不是最流行的，但他希望他能從日新月異
的新技術中，萃取出值得存活到下個世紀的東西。
不禁想起前陣子同學討論到的話題：專家是訓練有素的狗嗎？我們該
不該成為專家？高德納毫無疑問地是個專家，但他的大師學養和風範
也許能給我們不少啟發。
Reference
[1] Donald E. Knuth, The Stanford GraphBase : A Platform for Combinatorial 
     Computing, Addison-Wesley, 1993
[2] Donald E. Knuth, The Art of Computer Programming, Vol 1 : Fundamental
     Algorithms, Addison-Wesley, 1973
[3] Donald E. Knuth, The Art of Computer Programming, Vol 2 : Seminumerical
     Algorithms, Addison-Wesley, 1973
[4] Donald E. Knuth, The Art of Computer Programming, Vol 3 : Sorting and
     searching, Addison-Wesley, 1973
       The Art of Computer Programming 有日文，俄文，西班牙文等許多國的版本。
       其中，中文版資料如下
       Chinese translation by Guan JiWen and Su YunLin, Pei Xue He Cha Zhao,
       Beijing: Defense Industry Publishing Co., 1985
[5] Jack Woehr, An interview with Donald Knuth, Dr. Dobb's Journal, April
     1996, p16-p22
[6] Donald E Knuth's WWW Page : http://www-cs-faculty.Stanford.EDU/~knuth/
     http://www.geekchic.com/repliq6.htm 也有一篇小小的訪問。高德納最喜歡的
     語言是 CWeb, 最喜歡的運動是棒球，認為有許多人是他值得崇敬的。
    高德納將在最近將他的論文以更淺顯的方式整理過後，重新集結出版。
    這套書的預定讀者並不是電腦科學的專家，似乎很值得一讀。這套書
    將有八本，前兩冊已經出版：
[7]  Literate Programming, Stanford, California: Center for the Study of
      Language and Information, 1992
[8]  Selected Papers on Computer Science, Stanford's Center for the Study
      of Linguistics and Information and Cambridge University Press, spring,
      1996
[9]  Selected Papers on Analysis of Algorithms, to be published
[10] Selected Papers on Computer Languages, to be published
[11] Selected Papers on Design of Algorithms, to be published
[12] Selected Papers on Digital Typography, to be published
[13] Selected Papers on Discrete Mathematics, to be published
[14] Selected Papers on Fun and Games, to be published

下面的是学C++时要注意的。绝对经典。！！

　　1.把C++当成一门新的语言学习（和C没啥关系！真的。）；

　　2.看《Thinking In C++》，不要看《C++变成死相》；

　　3.看《The C++ Programming Language》和《Inside The C++ Object Model》,不要因为他们很难而我们自己是初学者所以就不看；

　　4.不要被VC、BCB、BC、MC、TC等词汇所迷惑——他们都是集成开发环境，而我们要学的是一门语言；

　　5.不要放过任何一个看上去很简单的小编程问题——他们往往并不那么简单，或者可以引伸出很多知识点；

　　6.会用Visual C++，并不说明你会C++；

　　7.学class并不难，template、STL、generic programming也不过如此——难的是长期坚持实践和不遗余力的博览群书；

　　8.如果不是天才的话，想学编程就不要想玩游戏——你以为你做到了，其实你的C++水平并没有和你通关的能力一起变高——其实可以时刻记住：学C++是为了编游戏的；

　　9.看Visual C++的书，是学不了C++语言的；

　　10.浮躁的人容易说：XX语言不行了，应该学YY；——是你自己不行了吧！？

　　11.浮躁的人容易问：我到底该学什么；——别问，学就对了；

　　12.浮躁的人容易问：XX有钱途吗；——建议你去抢银行；

　　13.浮躁的人容易说：我要中文版！我英文不行！——不行？学呀！

　　14.浮躁的人容易问：XX和YY哪个好；——告诉你吧，都好——只要你学就行；

　　15.浮躁的人分两种：a)只观望而不学的人；b)只学而不坚持的人；

　　16.把时髦的技术挂在嘴边，还不如把过时的技术记在心里；

　　17.C++不仅仅是支持面向对象的程序设计语言；

　　18.学习编程最好的方法之一就是阅读源代码；

　　19.在任何时刻都不要认为自己手中的书已经足够了；

　　20.请阅读《The Standard C++ Bible》(中文版：标准C++宝典)，掌握C++标准；

　　21.看得懂的书，请仔细看；看不懂的书，请硬着头皮看；

　　22.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍；

　　23.请看《Effective C++》和《More Effective C++》以及《Exceptional C++》；

　　24.不要停留在集成开发环境的摇篮上，要学会控制集成开发环境，还要学会用命令行方式处理程序；

　　25.和别人一起讨论有意义的C++知识点，而不是争吵XX行不行或者YY与ZZ哪个好；

　　26.请看《程序设计实践》，并严格的按照其要求去做；

　　27.不要因为C和C++中有一些语法和关键字看上去相同，就认为它们的意义和作用完全一样；

　　28.C++绝不是所谓的C的“扩充”——如果C++一开始就起名叫Z语言，你一定不会把C和Z语言联系得那么紧密；

　　29.请不要认为学过XX语言再改学C++会有什么问题——你只不过又在学一门全新的语言而已；

　　30.读完了《Inside The C++ Object Model》以后再来认定自己是不是已经学会了C++；

　　31.学习编程的秘诀是：编程，编程，再编程；

　　32.请留意下列书籍：《C++面向对象高效编程（C++ Effective Object-Oriented Software

Construction）》《面向对象软件构造(Object-Oriented Software

Construction)》《设计模式（Design Patterns）》《The Art of Computer

Programming》；

　　33.记住：面向对象技术不只是C++专有的；

　　34.请把书上的程序例子亲手输入到电脑上实践，即使配套光盘中有源代码；

　　35.把在书中看到的有意义的例子扩充；

　　36.请重视C++中的异常处理技术，并将其切实的运用到自己的程序中；

　　37.经常回顾自己以前写过的程序，并尝试重写，把自己学到的新知识运用进去；

　　38.不要漏掉书中任何一个练习题——请全部做完并记录下解题思路；

　　39.C++语言和C++的集成开发环境要同时学习和掌握；

　　40.既然决定了学C++,就请坚持学下去，因为学习程序设计语言的目的是掌握程序设计技术，而程序设计技术是跨语言的；

　　41.就让C++语言的各种平台和开发环境去激烈的竞争吧，我们要以学习C++语言本身为主；

　　42.当你写C++程序写到一半却发现自己用的方法很拙劣时，请不要马上停手；请尽快将余下的部分粗略的完成以保证这个设计的完整性，然后分析自己的错误并重新设计和编写（参见43）；

　　43.别心急，设计C++的class确实不容易；自己程序中的class和自己的class设计水平是在不断的编程实践中完善和发展的；

　　44.决不要因为程序“很小”就不遵循某些你不熟练的规则——好习惯是培养出来的，而不是一次记住的；

　　45.每学到一个C++难点的时候，尝试着对别人讲解这个知识点并让他理解——你能讲清楚才说明你真的理解了；

　　46.记录下在和别人交流时发现的自己忽视或不理解的知识点；

　　47.请不断的对自己写的程序提出更高的要求,哪怕你的程序版本号会变成Version 100.XX；

　　48.保存好你写过的所有的程序——那是你最好的积累之一；

　　49.请不要做浮躁的人；

　　50.请热爱C++!

这篇文章帮了我大忙，不过现在还是不知道消除MFC预设的背景色，前两种方法如何实现？我对MFC的框架还不是很了解

 

无闪烁刷屏技术的实现(文章来自:http://www.vchelp.net)

在实现绘图的过程中，显示的图形总是会闪烁，笔者曾经被这个问题折磨了好久，通过向高手请教，搜索资料，问题一基本解决，现将文档整理出来以供大家参考.
1.      显示的图形为什么会闪烁？
我们的绘图过程大多放在OnDraw或者OnPaint函数中，OnDraw在进行屏幕显示时是由OnPaint进行调用的。当窗口由于任何原因需要重绘时，总是先用背景色将显示区清除，然后才调用OnPaint，而背景色往往与绘图内容反差很大，这样在短时间内背景色与显示图形的交替出现，使得显示窗口看起来在闪。如果将背景刷设置成NULL，这样无论怎样重绘图形都不会闪了。当然，这样做会使得窗口的显示乱成一团，因为重绘时没有背景色对原来绘制的图形进行清除，而又叠加上了新的图形。有的人会说，闪烁是因为绘图的速度太慢或者显示的图形太复杂造成的，其实这样说并不对，绘图的显示速度对闪烁的影响不是根本性的。例如在OnDraw(CDC *pDC)中这样写：
pDC->MoveTo(0,0);
pDC->LineTo(100,100);
这个绘图过程应该是非常简单、非常快了吧，但是拉动窗口变化时还是会看见闪烁。其实从道理上讲，画图的过程越复杂越慢闪烁应该越少，因为绘图用的时间与用背景清除屏幕所花的时间的比例越大人对闪烁的感觉会越不明显。比如：清楚屏幕时间为1s绘图时间也是为1s，这样在10s内的连续重画中就要闪烁5次；如果清楚屏幕时间为1s不变，而绘图时间为9s，这样10s内的连续重画只会闪烁一次。这个也可以试验，在OnDraw(CDC *pDC)中这样写：
for(int i=0;i<100000;i++)
{
pDC->MoveTo(0,i);
pDC->LineTo(1000,i);
}
呵呵，程序有点变态，但是能说明问题。
     说到这里可能又有人要说了，为什么一个简单图形看起来没有复杂图形那么闪呢？这是因为复杂图形占的面积大，重画时造成的反差比较大，所以感觉上要闪得厉害一些，但是闪烁频率要低。那为什么动画的重画频率高，而看起来却不闪？这里，我就要再次强调了，闪烁是什么？闪烁就是反差，反差越大，闪烁越厉害。因为动画的连续两个帧之间的差异很小所以看起来不闪。如果不信，可以在动画的每一帧中间加一张纯白的帧，不闪才怪呢。
2、如何避免闪烁
     在知道图形显示闪烁的原因之后，对症下药就好办了。首先当然是去掉MFC提供的背景绘制过程了。实现的方法很多，
* 可以在窗口形成时给窗口的注册类的背景刷付NULL
* 也可以在形成以后修改背景
     static CBrush brush(RGB(255,0,0));
     SetClassLong(this->m_hWnd,GCL_HBRBACKGROUND,(LONG)(HBRUSH)brush);
* 要简单也可以重载OnEraseBkgnd(CDC* pDC)直接返回TRUE
     这样背景没有了，结果图形显示的确不闪了，但是显示也象前面所说的一样，变得一团乱。怎么办？这就要用到双缓存的方法了。双缓冲就是除了在屏幕上有图形进行显示以外，在内存中也有图形在绘制。我们可以把要显示的图形先在内存中绘制好，然后再一次性的将内存中的图形按照一个点一个点地覆盖到屏幕上去（这个过程非常快，因为是非常规整的内存拷贝）。这样在内存中绘图时，随便用什么反差大的背景色进行清除都不会闪，因为看不见。当贴到屏幕上时，因为内存中最终的图形与屏幕显示图形差别很小（如果没有运动，当然就没有差别），这样看起来就不会闪。
3、如何实现双缓冲
     首先给出实现的程序，然后再解释，同样是在OnDraw(CDC *pDC)中：
CDC MemDC; //首先定义一个显示设备对象
CBitmap MemBitmap;//定义一个位图对象
//随后建立与屏幕显示兼容的内存显示设备
MemDC.CreateCompatibleDC(NULL);
//这时还不能绘图，因为没有地方画 ^_^
//下面建立一个与屏幕显示兼容的位图，至于位图的大小嘛，可以用窗口的大小
MemBitmap.CreateCompatibleBitmap(pDC,nWidth,nHeight);
//将位图选入到内存显示设备中
//只有选入了位图的内存显示设备才有地方绘图，画到指定的位图上
CBitmap *pOldBit=MemDC.SelectObject(&MemBitmap);
//先用背景色将位图清除干净，这里我用的是白色作为背景
//你也可以用自己应该用的颜色
MemDC.FillSolidRect(0,0,nWidth,nHeight,RGB(255,255,255));
//绘图
MemDC.MoveTo(……);
MemDC.LineTo(……);
//将内存中的图拷贝到屏幕上进行显示
pDC->BitBlt(0,0,nWidth,nHeight,&MemDC,0,0,SRCCOPY);
//绘图完成后的清理
MemBitmap.DeleteObject();
MemDC.DeleteDC();
上面的注释应该很详尽了，废话就不多说了。
4、如何提高绘图的效率
      实际上，在OnDraw(CDC *pDC)中绘制的图并不是所有都显示了的，例如：你在OnDraw中画了两个矩形，在一次重绘中虽然两个矩形的绘制函数都有执行，但是很有可能只有一个显示了，这是因为MFC本身为了提高重绘的效率设置了裁剪区。裁剪区的作用就是：只有在这个区内的绘图过程才会真正有效，在区外的是无效的，即使在区外执行了绘图函数也是不会显示的。因为多数情况下窗口重绘的产生大多是因为窗口部分被遮挡或者窗口有滚动发生，改变的区域并不是整个图形而只有一小部分，这一部分需要改变的就是pDC中的裁剪区了。因为显示（往内存或者显存都叫显示）比绘图过程的计算要费时得多，有了裁剪区后显示的就只是应该显示的部分，大大提高了显示效率。但是这个裁剪区是MFC设置的，它已经为我们提高了显示效率，在进行复杂图形的绘制时如何进一步提高效率呢？那就只有去掉在裁剪区外的绘图过程了。可以先用pDC->GetClipBox()得到裁剪区，然后在绘图时判断你的图形是否在这个区内，如果在就画，不在就不画。
如果你的绘图过程不复杂，这样做可能对你的绘图效率不会有提高。

终于完成了A阶段，下面可以进入B阶段了，主要集中在程序的UI上，另外考虑如何提升速度。

我的临时文档，看起来好乱，程序里的标识符也没完全按文档里的来，真是乱套了，明天好好修改修改。

 

 

放入MyDefine.h,MyDefine.cpp文件

1． 河的边线

Doc里放入：

//num of ctrl pnt,nodal pnt,display style,

//wave speed wave distance and wave num

int ctrlNum,ndlNum,style,wSpeed,wDistance,wNum;

//the pnt array represent ctrl pnts and nodal pnts.

CArray <CPoint,CPoint&> c_PntsL,c_PntR,n_PntsL,n_PntsR;

视图类和文档类都要引用MyDefine.h，用＃ifndef吧

以下内容放在视图类里的OnCreate函数中，先为CView的派生类声明一个图元文件的数据成员HMETAFILE m_hMetaFile;

CArray <CPoint,CPoint&> initL,initR;

//预先输入的控制点，自定义

Int const Max=60;

//CArray <CPointPartner,CPointPartner&> init_CPntPtr,final_CPntPtr;

//CPointPartner作为TYPE有问题，还是用数组

//改为:

CPointPartner init_CPntPtr[Max],final_CPntPtr[Max];

//最后的点对数组final_CPntPtr给CCurve类用

While(i<Num)

{

CPointPartner temp_CPntPtr (initL[i],initR[i]);

init_CPntPtr.Add(temp_CPntPtr);

i++;

}

//鼠标点击或预先指定控制点，即一些点对

//以及处理后得到的点对

CSpline spL (initL);

CSpline spR (initR);

//两边的样条曲线

CArray<CPoint,CPoint&> finalL,finalR;

//处理后得到的样条曲线上的点

spL.GetPoints(finalL);

spR.GetPoints(finalR);

Count=finalL.GetSize();

For(int i=0;i<count;i++)

{

CPointPartner Temp_finalP (finalL[i],finalR[i])

Final_CPntPtr[i]=temp_finalP;//重载＝运算符

}

//将样条对象spL，spR里的点放入finalL和finalR,之后又放入点对数组final_CPntPtr;

//共count个点对

CMetaFileDC metaFileDC;

metaFileDC.Create();

这里画出边线（通过finalL和finalR）

m_hMetaFile=metaFileDC.Close();

5．23晚19：30以上程序的调试已完成（未加鼠标控制）

2． 一道道波纹（CCurve类）

在视图类中声明数据：CArray<Points,Points&> mPntsCurve;

在OnDraw里

先确定水波位置：

WavePL[i]和WavePR[i]

For（int i=0,i<WaveN;i++）

{

CCurve tempCurve (final_CPntPtr[i]);

tempCurve.ComputePnts(mPntsCurve);

连这些点成线

}

详细设计：

Doc里定义两个点，

View里定义一个函数BOOL ComputePnts(CArray<CPoint,CPoint&>& m_Pnts,CPoint m_LPnt,CPoint m_RPnt)

OnDraw里给两个点赋值，调用ComputePnts，再绘图

与MFC的联系

//用图元文件保存边线，中间的curve即时画出来

//要描绘的点，每两点画条线连接LineTO

或者将点集的计算都放在文档类中，给文档类新建两个函数

数据的放置位置还得琢磨琢磨

5．21 晚12：00此文档完成

Spline的计算在CDoc里，Curve的计算在CView里

5. 29 晚1：47 添加（明天再修改）

 

5.30

Q: Spline里的temp值使得数组越界问题

A: 精度造成的，两个float型变量t和T1[j1+1]都为0.90000,但t>T1[j1+1]为true,

Tips：

1． 查找类型强制转换以及精度丢失的知识

2． 看林锐的《高质量C++编程》，注意这些细节。

5.31

已完成：位图作为背景。

 

Q:鼠标控制的问题