最近嘗試用Cocoa做一個四則運算計算器來練手，類似于Windows cmd: calc的那種。

畢竟這個東西算是我們項目組的入門練習，當年很多新人剛進來，老組長都會教他們用MFC/QT做個計算器來看看水平。由于各種原因，我當年倒是沒有受到這種“禮遇”，等我真正開始做軟件的時候，還是服務器端這樣的純C++代碼做得比較多。但是不做不知道，一做才發現UI的邏輯還是挺復雜的，比如說，按“1”是追加到當前顯示還是覆蓋現有的顯示呢，最后把邏輯弄清楚倒不是很麻煩，但要寫出好看的代碼還是有比較大的差距的。

以上都是前言，好像比較長……

要說的是，在這個過程中發現的問題，計算結果是浮點數，要怎么判斷其是否能無損地轉換成整數，從而消除小數點后的一段無用的“0”，以更好地顯示。直接上代碼：

我的方法是通過浮點型的結構來進行判斷。

浮點類型一般結構如下：
|+/-|      exponent       |             tail                 |
對于float，指數部分為8字節，尾數部分為23字節。

判斷方法是，計算指數的值，根據偏移判斷小數點后的尾數，想得比較簡單，汗！
引入參數精度是為了判斷值小于1時達到某個閾值的時候可以將后面的小數略去。

Honestly，其實這個應該可以用sprintf，然后判斷小數點后的“0”來實現的，似乎更加簡單方便。
但是我覺得，作為一個“碼農”，重造輪子也是一種趣味嘛！

身處一個學生團隊中，雖說會像公司一樣從事項目研發、承包一些外包項目，學生就如公司的員工一樣，老師有點像公司Boss又不完全是，但感覺最大的分別是人與人、人與集體之間關系維系的紐帶不一樣。

好比說在公司里，拋開興趣愛好、對公司情感等的上層因素，人與集體之間最基本的關系是合同制、契約關系。這意味著，我完成我的工作，你就要相應地支付勞動報酬，雖然有些赤裸裸的資本主義金錢利益交易的色彩，但確是最實在、最有保證的關系。如果我完成不了我的工作，你可以少付、乃至不付勞動報酬；超額完成任務，可以有相應的獎金（理想狀態下）；哪天我請假了，我沒有工作，那天的工資可以扣除。好比鋼煉里面的“等價交換”原則，雖則不時有些殘酷，卻又是最自然、最透明、最公正的。這學期由于項目原因，在外面公司待了好一段時間，看到了不少外面的人對于工作的態度也是相當的坦蕩蕩，該請假時就請假，遲到了就扣錢。當然，這最好還是以不影響集體利益為前提。

反觀我所處環境的情況，師生之間顯然不可能是雇傭關系，那是什么來維系一個團隊的運作，完成一個個的項目呢？我認為是“責任”。培養成有責任感的人，也是我們所提倡的。但，我曾經聽過一個過來人說的故事，某人某次小假期回家，最后幾天突然生病了還比較嚴重，父母都勸他在家把病養好再回去做項目，他還是執意要回來，畢竟大家都在工作，他也不好意思就這樣多休息幾天。又如，大三那年的暑假，正值新項目開始，項目周期短、工作量大，大家都在奮戰著，突然我家里發生變故，當時我想還是不要回去了，回去也沒用，而且我一走，我這塊的進度誰來保障，就還是留在學校趕項目，后來回想起來還是有些遺憾。我們這些人總在莫名其妙中對集體擔負著這樣那樣的“責任”，雖然這樣的責任意識長期保持著會讓我們成為很不一樣的人，但是與此同時我們也是活得很累的人。

我覺得，一切以集體為重的責任意識很容易淹沒了個性的存在，很多個人化的事情也因次而難以開展。由于我們的關系是抽象化的“責任”而不是更為具體的“合同”，很多事情還真是到了說不清的地步。考試、學生自然或不自然地便圍繞著集體的項目來安排，有些很私人化的事情不好去做。最疲累的是不自覺無時無刻關注著這樣的“責任”關系、并以一種較為“癲狂”的方式來履行。作為一個“全職”人員，朝九晚十是平常事，但有時候我覺得待不住了、坐得快要吐了，我覺得我還是不能離開，因為集體還要運作，或者說個人的不合作很容易弱化集體的凝聚力（不否認這是我寫這篇文章的原因）。

另一方面，以“責任”為紐帶來帶領集體，總有些異樣的感覺。曾經也做到了類似項目組長之類的工作，需要管理一部分人，但總感覺在這個過程中沒有什么有說服力的關系來調度手下的人。如果是合同關系下的工作，你不情我不愿，可以走可以換人，大家都樂得輕松。金錢利益是必須的，但總可以換種方式來獲取它。但是換著以“責任”意識作基礎，手下的人沒有這個意識似乎工作都不用做了，又或者所做的不是個人所希望得到的，作為管理者我也不能給你什么、保證些什么。

好吧，寫到這里，我覺得我想描述的是一個很濃厚的“膠合層”，但以“責任”來概括似乎已經不夠全面了。但依據《Unix編程藝術》，太厚的膠著層不是一種好的設計方式。簡潔、透明、直接的會是更好的方式，工作也能夠更好地開展。

幸好還是有終極的個人保障機制——you can quit！離開集體，便徹底脫離這種千絲萬縷的關系。

不說太多，僅此吐槽！

官方有個比較精簡的編譯安裝指南，見這里。但是對于我所碰到的問題沒有說明

提示鏈接時SSL的符號沒有找到，但我是裝好了openssl的，也特意找了一下，都安裝在/usr/下

然后翻看了一下build/examples/IPC_SAP/SSL_SAP/下的Makefile，找到“LIBS = -lrt -ldl”，沒有指明openssl庫的鏈接

遂加上！～

LIBS = -lrt -ldl -lssl

編譯之！～

build/test/SSL的問題同解。

不知道其他Linux發行版有沒有這樣的問題，還是我的配置有問題，但總算最終編譯完了。

     摘要:   閱讀全文

1.new操作符可以帶多參數
2.沒有對應的operator delete會出現warning（vs2008）
3.operator new/delete是類成員的情況下，用自定義的operator new創建、調用構造函數，會自動調對應的operator delete來析構
4.delete操作符可以帶多參數，要使用自定義的operator new只能顯式調用
5.自定義的operator delete不會自動析構對象

話說昨天解決了MFC跨線程操作控件的問題，我滿以為今天可以free一回，玩玩Linux、學學Vim、再準備一下畢業論文的事情，但還是有事情要做，然后又是“被”MFC郁悶了一天。

先介紹一下總體的情況。我們項目客戶端的開發環境是VS2008+SP1，用的是MFC類庫，里面居然用到了CMFCToolBar、CMFCMenuBar以及Appearance變化等的SPI新特性。說“居然”是因為這些東西不是項目必要的，當時可能也以為只是名字變了用法沒變，估計在工程創建的時候根本就沒有考慮這些，直接按著單文檔工程默認配置，next、next直接創建完的，囧！當時做的時候也只是當作測試Demo來用，也沒太在意，畢竟我們項目的重點在服務器而非這個MFC客戶端。

后來由于項目原因，甲方要求我們把這個客戶端盡快修改成一個可以發布版本。不改不知道，一改嚇一跳，當準備動手修改工具欄時才發現與以前慣的CToolBar真實差距甚大。CToolBar可以用CImageList把自定義的BMP圖片放到工具欄的按鈕，詳細可看這里，CMFCToolBar根本就不是這樣的一個玩法。直接放一個CToolBar上來，在DockControlBar()的時候會出現斷言錯誤（缺少DockBar，貌似是這個名字，汗！）。定位代碼到MainFrm的EnableDocking()，現在的MainFrm的繼承關系是CMainFrm->CFrameWndEx->CFrameWnd，而以前是CMainFrm->CFrameWnd，CFrameWndEx::EnableDocking()是為DockPane()服務的，而DockControlBar()需要的DockBar并不會被初始化。調用基類的CFrameWnd::EnableDocking()后再DockControlBar()不會出現斷言，但是那個工具欄沒有顯示。而且現在新特性下在工具欄位置能夠按出右鍵菜單，但右鍵菜單中根本不可能有關于該CToolBar的信息，乍看起來很不和諧~

最后，求助本地MSDN無果，貌似SP1沒有包含對MSDN文檔的更新；求助MSDN官網，那個真是“言簡意賅”。只能說，MS你這次真的“亮”了！

以下為google + vs2008 sp1 sample + 看代碼的成果：

• 創建默認ToolBar外的第二個ToolBar

注意，Wizard生成的工具欄Create時沒有帶ID，但第二個工具欄Create時最好要帶ID。加了ID之后，在工具欄右鍵菜單才會出現第二個工具欄的CheckBox。否則，不良后果有：1、右鍵菜單沒有該工具欄Checkbox；2、把默認工具欄和該工具欄拖出來（浮動），可以看到名字都是一樣的（英文版為Standard）；3、后面要提到的UserImage不能作為按鈕圖標顯示。

• 加載工具欄資源

我們先來看看CMFCToolBar加載工具欄的函數原型：
可以看出，uiResID代表要加載的工具欄資源，理論上只需要這一個參數就能完成工具欄的加載。但是VS的Toolbar Editor只能編輯4bit的工具欄圖標，以前CToolBar是用CImagList來加載更多bits的圖標的，現在應該怎么做呢？多虧了Explore sample的例子，我發現后面的幾個UINT參數就是BMP的資源，最主要的是最后一個uiHotResID，即便其他用默認值，這項賦BMP ID就能按預期的圖標顯示。Cold、Disable表示的是不同狀態下的圖標樣式，帶Menu的是Menu有關的圖標，具體可看SP1 Feature的sample。
我的Demo里自定義工具欄的總創建過程：
最后的SetWindowText()設置工具欄的名稱。
CMFCToolBar有LoadBitmap的方法，但是測試發現，用LoadToolBar只加載工具欄資源，再用LoadBitmap加載BMP資源，雖然返回值是TRUE，但顯示圖標為空白，沒有實際效果。

• 工具欄停靠

與默認工具欄無異。

• 用戶自定義圖標

CMFCToolBar可以讓用戶自定義工具欄圖標，使用靜態成員函數SetUserImages()將一個CMFCToolBarImages對象設置進去，由所有CMFCToolBar對象共享。Wizard自動生成代碼中有這樣的例子：
這個例子加載了工程路徑下的一個BMP，其他方法可以查看MSDN，與CImageList有點點類似。
使用CMFCToolBar::ReplaceButton()可以替換已有的工具欄按鈕，以下是我的Demo中的代碼：
第一個參數ID_QTLOGO為自定義工具欄上的一個按鈕，后面是一個CMFCToolBarButton的臨時對象。CMFCToolBarButton構造函數第一個參數為替換后的ID，第三個參數為名稱，第二個參數為圖標的索引(zero-based)，第四個參數為m_bUserButton，指明第二個參數是索引工具欄已加載圖標(LoadToolBar或LoadBitmap)還是用戶自定義圖標（SetuserImages），TRUE指用戶自定義圖標。這里的結果是將ID_QTLOGO上的圖標替換為UserImages.bmp上的第一個圖標。

GetCmdMgr()->GetCmdImage()可以根據工具欄上圖標的ID獲取出已加載圖標的索引值：
這里將工具欄上ID_QTLOGO的圖標替換為ID_PLUS按鈕對應的圖標。

特別地，如果在你將這些工具欄改來改去但顯示結果卻沒有改變的時候，你可以嘗試刪除 HKEY_CURRENT_USER\Software\Local AppWizard-Generated Applications\$(你的程序名) 這個鍵值，當你重啟程序后工具欄應該會按你的預想變化的。這是我在查資料時看到的，當時沒注意但后來發現挺有用的，出處沒有記錄下來。

最后，ReplaceButton還可以將按鈕替換為其他控件。

• 其他...

我在自定義工具欄上做了一個有效響應，里面使用靜態成員函數CMFCToolBar::ResetAllImages()將所有圖標都清空了，此時會發現默認工具欄、自定義工具欄的圖標都為空。
更奇妙的是，后面我對兩個工具欄重新加載了BMP，而且加載的BMP資源是反了的，此時默認工具欄上出現了原來自定義工具欄的4個圖標，余下部分及自定義工具欄則為原來默認工具欄圖標。可以想象，RestAllImages只是將圖標資源都釋放了，工具欄資源依然健在，重新加載BMP的時候，工具欄圖標就像一個個順序排好的空間，加載進來的BMP圖標會出現從前往后補位的現象。
注意代碼中，默認工具欄圖標重新加載時使用的資源是IDR_MAINFRAME_256，是默認的工具欄資源。也就是說，這里用LoadBitmap加載工具欄資源也是有效果的。這樣應該可以說明工具欄在創建時LoadToolBar、LoadBitmap分別成功地加載了工具欄、BMP資源，實際上是加載了兩套圖標資源，這兩者是順序而非重合的，所以只顯示原來的工具欄資源。要想指定兩者的重合關系，只有在LoadToolBar的時候同時傳入工具欄資源及BMP資源的ID。

Demo下載

————————————————————————————————————————————————————————————————
好吧，終于寫完了！寫得很倉促，不足的地方也很多，歡迎指教！

備注：Rimi是我們用的一個分布式機制。

在進行設備樹（也就是一個CTreeCtrl控件）更新修改的時候，遇到了一個比較bug的問題。

為了提供更好的用戶體驗，甲方希望設備樹更新之后滾動條位置能夠保持與更新前一致。設備樹的更新過程是這樣的：更新消息來自Rimi的通知機制，類似于函數回調，客戶端在收到消息之后調用Rimi的對象方法來獲取新的設備樹信息，然后更新樹。乍看之下，要完成這個修改好像很簡單，只要更新前先記錄滾動條的滾動位置，更新后還原位置，如果更新后滾動條滾動范圍變化了還要微調一下位置，邏輯上來講就這么幾個步驟。

我一開始也是按照這樣的思路，GetScrollPos()獲取當前滾動條的滾動位置，然后更新樹（先刪除所有節點再逐個添加，其他省略...），GetScrollRange()獲得新的滾動范圍，最后SetScrollPos()將舊的位置與滾動范圍最大值中最小的一個設回去（這里用到的ScrollBar是CTreeCtrl自動產生的，注意不是兩個控件，這里調用的函數都是CTreeCtrl的方法）。但實際效果是，樹更新后滾動條滾到準確的位置，但樹的視圖到了最頂，點擊一下滾動條的那個方塊才能回到之前的位置。也就是說，滾動位置的更新與樹的視圖分離了。

之后，我一直以為是我控件的方法用錯了，對著MSDN和CSDN糾結了很久。最后忍無可忍，自己寫了個測試Demo，里面就一Dialog，一CTreeCTrl，樹上隨便加了些東西，然后又一按鍵，按鍵后會重新刷新樹，再滾動到原來的位置，結果居然是對的，視圖跟著滾動條的位置變化了。為了更好的模擬設備樹節點增刪的效果，我在按鍵響應上又作了處理，按一下重刷樹的時候會隱藏幾個節點，再按一下這些節點顯示出來，滾動位置按照客戶端里面的一個處理方法，結果居然也是正確的。問題變得玄乎了！

無意間發現客戶端里面有個手動刷新設備樹的快捷鍵，估計是當年pb做調試的時候留下來的。快捷鍵的響應直接調用更新樹的函數，重刷后的顯示出人意料地是對的。比較一下兩種更新方式的過程：

Rimi：   通知到來—>更新樹（Rimi回調函數，Rimi自己維護了一個線程池，遠程調用在被調用端的發起者都是Rimi自己的線程）
快捷鍵： 按鍵響應—>更新樹（MFC消息處理函數）

更新樹所用到的是同一個函數，但調用者卻是不同的。因為Rimi用了boost::function，那我也在按鍵響應的時候對要調的函數用function來包裝一下，造成兩者在調用棧上調用的函數、順序大部分是一致的，只有最底層不同，一邊是Rimi，一邊是MFC消息傳遞。

后來jianhao說，以前在Rimi的回調函數里面調Rimi對象的方法出過問題，然后我又順道回憶起之前zxb在Rimi函數（還是對象方法）里面調system()也有問題。

難道說Rimi線程就是“萬惡之源”？好吧，我把更新代碼移到另外一個線程里面，Rimi回調的時候喚醒更新線程，更新后視圖還是不能跟著滾動位置變；將快捷鍵的響應也修改一下，自己不作更新，也是喚醒更新線程，這個方法也變得不靈了，囧！這可以說明問題跟Rimi線程無關。

難道說線程調用才是“萬惡之源”？把之前做的那個Demo小改了一把，線程做刷新，按鍵響應只喚醒更新線程，果然不靈了！上網google了一把，關鍵字“mfc 線程 操作控件”，首先映入眼簾的是《MFC中跨線程操作控件會不會出現像C#中的異常問題?》。這時候我也不關心這個帖子的內容了，線程操作控件有異常是吧，那就不用線程做咯！這時候我才回想起WIN32里面有自定義消息這玩意，MFC里面給定一個消息ID，ON_MESSAGE綁定一個處理函數，PostMessage或SendMessage來發消息，然后由WIN32自己的消息循環來調用處理函數，這樣應該是可以保證用非Rimi線程來更新設備樹的。再一次把Demo小改了一把，按鍵響應Post一個自定義消息，消息處理函數做刷新，結果是對的；再改，按鍵響應喚醒線程，線程里面Post自定義消息，結果也是對的。

原以為是控件使用問題，又以為是Rimi不兼容問題，最后實質為MFC跨線程使用控件的問題。其實我也不清楚這是不是真正的問題，畢竟我MFC既不懂又用得少。That's all!

最后附上我的測試代碼
http://m.shnenglu.com/Files/neverwinter/testtree.rar

最近做項目寫代碼遇到了對象自殺的問題。

第一個是自己設計的，對象持有定時器，自己維護生命周期。

第二個是無意中遇到的，由于采用boost的線程庫，將成員函數變為線程用，最后在一堆調用之后居然把自己殺掉了。

很不幸的是，在過程中都遇到了相同的問題——堆棧掛掉了。

然后一輪定位，居然都是boost mutex的問題，scoped_lock很容易讓人放松警惕。


作為類成員的mutex沒有被解鎖，然后所在的類就被釋放了，這就造成了堆棧掛掉。

對象自殺顯然不是一種很好的風格，還是盡量避免吧！

 此文章涉嫌各種敏感，已被博主刪除~

項目中有這樣的需求：
1.給一個一定大小的空文件改寫內容；
2.不能改變該空文件的大小。

一開始是用ofstream做的，但是每次一打開文件，原來的空文件的大小就改變了。之后用app方式打開，但是每次的新數據都是追加到文件尾部，seekp無論如何不能到達實際文件的首部，這樣文件大小就變了，不符合需求2。

后來發現用fstream，采用in | out的方式來打開，終于可以安全地改寫文件了。