• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 76,  comments - 621,  trackbacks - 0
            共6頁: 1 2 3 4 5 6 
            這是你自己的做著玩的文檔嗎?如果是公司的文檔,那么這份文檔問題可就多了。看樣子像是一份后期BugList和對應的文檔,我覺得還是用表格的形式,比如Excel或者其它的來做比較好,問題癥狀,Capture, 發(fā)生時間,發(fā)現(xiàn)者,所處大模塊,對應者,對應策略,對應時間,防止在發(fā)生策略等等,個人意見,僅供參考。
            為什么會閃爍,因為你一次畫的東西太多了,要么你就用個MemDC,要么就獲取到ClipBox,專業(yè)點叫臟矩形,在里面做判斷應該繪制哪些東西,這樣繪制東西幾乎不好暫用任何CPU,不要用DrawIcon,每個棋子都是一個Object,都可以把自己以透明的方式畫到畫布上,棋子也是圖片,過濾到某個顏色就是透明的了,在消除消除鋸齒就差不多了,你這4大目標里,最難的是第三個,你能高效的做出來,就可以進中科院混混了~~~
            小伙子,做一個圖片,記好坐標,多方便,何必自己畫啊,象棋程序關鍵在算法不在畫圖~~~
            發(fā)表文章,要嚴格注意錯別字!!!!要不,就不要發(fā)在精華欄。
            自己用用還行,不適合項目使用。
            我對正則略有研究,我對正則的效率非常在意。不過說實話.net里面的正則是我用過的所有正則當中效率最高的,我懷疑里面有池化之類的東西。一直沒有求證。作者有時間不妨好好研究。
            assert是確保不應該發(fā)生的事情不要發(fā)生,而if則是可能發(fā)生。在大多數(shù)的情況下assert后面其實并不需要if,不知道我說的你有沒有理解。在release模式下如果執(zhí)行If,那么后面的代碼就不會執(zhí)行,這個時候錯誤處理就不好弄了。所以建議還是分開,不要這么寫。個人經(jīng)驗,僅供參考。
            re: 08年10月25日[未登錄] megax 2008-10-31 13:12
            使用多態(tài)性來代替程序中的if else,從而提高程序運行效率==這句話不對,多態(tài)只是讓你更好的管理代碼,一個手段而已,和效率沒啥關系
            不是,我說的是從一個字符串后面開始查找想要查找的內(nèi)容。不是說具體的算法
            做一個從后面開始查找的試試?
            系統(tǒng)剪貼板是不可能存儲內(nèi)存區(qū)域指針的。這塊地址的東西有可能被改編,就像記事本。所以存儲的是內(nèi)容和內(nèi)容的類型。你說的局部的不太明白,如果app只是自己管理自己的剪貼拷貝的,不和其它的app共享,那么用啥數(shù)據(jù)結構都無所謂了。
            這個控件恐怕會難賣,除非用于特定于某個行業(yè)或者某個方面的專門的軟件。而在這種情況下,大多數(shù)企業(yè)會選擇針對這個東西專門開發(fā)。【適合于項目管理、生產(chǎn)管理、大修項目。】大多數(shù)的項目管理更傾向于excel。個人軟件的出路應該是選好出發(fā)點,結合自己的興趣,呵呵,個人的一點拙見。。。。
            頭文件類里面的函數(shù)必須寫成inline或者static
            void BuildXMLFile(TiXmlDocument& doc)
            {
            TiXmlPrinter printer;
            printer.SetIndent( "" );
            doc.Accept( &printer );
            }
            其中printer是臨時對象,Accept接受的是指針,BuildXMLFile運行完之后printer就被銷毀了。所以當然會出錯?你以前是不是c#或者java程序寫多了...呵呵
            這么做的意義是什么呢?這么做肯定是非法操作啊,沒看懂。。。
            目前工作比較忙,第一個版本,我打算今年年底發(fā)布。我現(xiàn)在在做自動代碼折疊和一些外圍的工作,主要是功能集成等。16進制編輯器打算在第二個版本之后發(fā)布。
            @GEEKER
            把你覺得悲哀的地方寫出來。另外,罵能解決問題嗎?你經(jīng)常罵人嗎?
            @沈臻豪(foxtail)
            是啊,是不簡單。反正都堅持這么久了,在堅持堅持。我最近在代碼自動折疊上停滯了。始終沒有好的思路
            @無田耕夫
            呵呵,怎么突然問起這個?可否給點提示?

            @jxfwinter
            其實在基于消息的平臺上做gui開發(fā)都差不多的,包括mac, win和linux上那眾多的桌面。
            @NEO
            說實話,mac不是我想的那么好用。mac下的工作效率也并不比win高。Web:Ruby on Rails,Ruby等,這些也完全可以在win上完成,甚至更快的完成。關于linux能提供更好的性能,我還真沒做過測試。不過更豐富的編程資源,似乎言過其實。win和linux都是平臺而已,本身并無好壞之風,我也無意區(qū)分這種好壞。另外【通過中文資料來獲得知識,那早已落后世界至少1年】了,我也不敢茍同。一些基礎,還是可以用的嘛

            @HH
            我只是覺得相較而言windows比linux更偉大而已<-----我覺得這不是偏向性,這是事實。你說呢
            我哪句話說的不對,哪句話帶有偏向性,可以說出來一塊討論討論。其實我本身不贊成討論這樣的話題,我只是覺得相較而言windows比linux更偉大而已。一個優(yōu)秀的員工應該是學習力強餓,我始終這么認為。如果帶有偏向行,那也可能被csdn給氣的吧
            嗯,我試用了,做的還不錯。scintilla可以直接定義document的encoding,這樣就解決了unicode的問題,嗯,不錯,scintilla很強大。壓力很大,我得加快進度了,在基礎控件上得加把勁。用戶使用感覺上也得加油。flexedit似乎是個中國人寫的,里面的command實現(xiàn)的挺有意思,我是費了勁使用管道輸入輸出重定向來實現(xiàn)的,它倒好,直接嵌入了ConsoleWindow。另外它似乎沒有實現(xiàn)打印,呵呵。目前在國內(nèi)真正讓我佩服的中國人做的編輯器是LiteEdit,它已經(jīng)很長時間沒更新了,作者功力不錯,網(wǎng)上可以找到源代碼。其它的編輯器,還沒發(fā)現(xiàn)中國人做的太好的。歡迎繼續(xù)討論,有任何問題,都可以討論,呵呵。
            其實制作編輯器不難,難的是制作一個平均性能很高的編輯器。Scintilla的代碼不錯,幾本思路幾乎和我的一樣。當然,我可沒有抄它的。Scintilla在win上不支持native unicode,我以前想修改來著,后來還是沒做,我?guī)啄昵熬妥鰉egax了,那時候Scintilla還不像現(xiàn)在這么出名。Scintilla最大的缺點是它是用lexx來做的此法分析,這么做會帶來很高的正確性,擴展性卻很低。如果你想做的你可以讀讀這篇文章http://www.catch22.net/tuts/,介紹了一個基礎編輯器的實現(xiàn),一些更高級的功能像高速自動換行等,就得好好琢磨琢磨了
            @沈臻豪(foxtail)
            悠久的是UE,不過UE的內(nèi)核不是Unicode,這點很讓人失望。我經(jīng)常需要在中日英之間切換,Unicode是必須的。而且UE的版本更新太快,啟動內(nèi)存20M,不小啊。EM的最新版本比較強大,對于超大文件有著非常好的支持。基礎架構也比較好,語法擴展也很方便,內(nèi)核支持Unicode,插件架構比較好。如果非要選一個比較好的,我認為是最新版本EM。我以前一直用Editplus,不過它更新的很慢,有些功能做的也不盡如人意。我想做的就是集這幾家所長,最主要的是我想提供一個命令工具,像vi那樣,這個非常有用,我認為。
            re: 推薦一個文本編輯器 megax 2008-08-09 19:55
            這個編輯器簡介嗎?我以前就試過了,沒什么特色,內(nèi)存管理也很一般,它的目的是想模仿mac上的textmate,可惜不怎么成功,很吃內(nèi)存。
            參考資料不好說,我前前后后做了一段時間,閱讀了一些文獻。說實話系統(tǒng)的介紹這個東西制作的書籍或者論文還沒有。我以后會陸續(xù)整理一下,把它寫成一本書,不知道有沒有人買。
            LPCTSTR, LRESULT這些都是可以定義的,一個文件就搞定了。問題是你做出來的東西的入門容易度,我以前也寫過一些封裝,在消息操作系統(tǒng)中,其實就是消息的封裝。封裝消息還是有很高的技巧性的。MFC單純用代碼和宏來做,覺得也挺經(jīng)典的
            MFC的設計是很經(jīng)典的,占用內(nèi)存相對來說也不大。因為沒有使用虛函數(shù),省下了一大筆虛表的開支。UI類庫,我認為最棒的仍然是VCL。不過我仍然會用MFC,經(jīng)典,方便,性能高,文檔齊全。對于我這種關注功能實現(xiàn)的人來說是最好的選擇
            @foxtail
            對啊,內(nèi)核是自己寫的
            re: MegaxEditor megax 2008-06-26 17:14
            @foxtail
            就是一個toolbar上面放一個tab,在這個帖子里面tab的樣式是設置成按鈕的,是codeproject的代碼。我最新版本重寫了一個tabctrl,支持鼠標拖曳,tooltip等,關于mdi你可以在codeproject上找找看
            嗯,對,我想達到的就是source insight的效果,其實source insight并不是用的正則,我覺得它的思路和我差不多,在分完塊之后,可以做一些自定義的regex匹配。你可以打開選項,關鍵字,自定義匹配之后,會發(fā)現(xiàn),并須指定type,才可以指定自定義正則匹配,也就是說一個塊只能匹配一個正則。呵呵....多了,速度就上不來嘍。
            re: 我好想發(fā)財啊。 megax 2008-03-25 17:58
            誰能借我個妞啊,摸完了就還給你
            re: 開始向linux過渡了 megax 2008-03-25 16:38
            請問在windows下會失去什么呢?
            re: 不怕無知,但怕無畏 megax 2008-03-25 15:57
            一個優(yōu)秀的程序員不應該只去關注one byte one byte之類的,這些東西你去面試別人,別人可能暫時不會,但是其實是只要看了,馬上就會的那種,所以這些東西并沒有太大的說服力。你應該找的人是這樣的,要有較強的學習能力和溝通能力,以及受過良好的教育。不要只去扣著那幾個算法,沒意思。。。
            re: 無意義的牢騷 megax 2008-03-13 09:57
            VS 2005很人性化的,各個設置都非常的方便,鍵盤也加入了類似emacs的控制。在IDE這方面,ms還是無人可以匹敵的.
            共6頁: 1 2 3 4 5 6 
            avtt天堂网久久精品| 亚洲国产精品久久久久| 一本久道久久综合狠狠躁AV| 国产三级精品久久| 久久亚洲sm情趣捆绑调教| 波多野结衣久久| 久久亚洲国产精品一区二区| 日日狠狠久久偷偷色综合96蜜桃| 国产亚洲精品久久久久秋霞| 观看 国产综合久久久久鬼色 欧美 亚洲 一区二区| 久久99久久成人免费播放| 热re99久久精品国99热| 久久久久女教师免费一区| 久久久久久国产精品免费无码| 国产呻吟久久久久久久92| 久久99国内精品自在现线| 国产精品久久久久a影院| 麻豆精品久久精品色综合| 久久人做人爽一区二区三区| 久久国产精品一区| 国产精品久久波多野结衣| 亚洲狠狠婷婷综合久久蜜芽| 亚洲精品国产自在久久| 国产精品九九久久免费视频 | 久久久久亚洲av毛片大| 久久精品国产亚洲精品| 久久青草国产手机看片福利盒子| 久久久久久A亚洲欧洲AV冫| 国产精品久久久亚洲| 色狠狠久久AV五月综合| 99精品国产99久久久久久97| 伊人热热久久原色播放www| 天天综合久久一二三区| 久久久久亚洲爆乳少妇无| 久久国产福利免费| 久久久精品人妻无码专区不卡| 草草久久久无码国产专区| 国产精品热久久无码av| 国内精品久久久久久久久| 久久久久99精品成人片| 久久亚洲中文字幕精品一区|