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:鼠標控制的問題