CG@CPPBLOG

 
昨晚在家看了一集《武林外傳》，說的是白展堂給捕快小六教武功，就教了扎馬步，郭芙蓉給莫小貝教武功，就教了個轉圈圈（什么什么八卦掌）。結果莫小貝和小六比武，小六始終扎著馬步，莫小貝就在他旁邊轉圈圈，硬是把兩個人累趴下了。
 
雖然挺可笑，但也反映了一個問題。行為應該取決于目的，雖然那些招式號稱武功，但不能制敵，不如上去捶他一頓。而我們做技術設計的，最容易犯這個毛病了，剛剛學了個新方法，新技巧，新模式，就急不可耐的用了。就像上學時剛學了個公式，做作業時就拼命用，也不管是不是應該用。
 
我以為，其實面向對象設計的威力之所在，是設計的原語更接近現實世界，有些書中提到“隱喻”，其實就是讓我們把設計放到生活中來，找到類似的例子，再反饋到設計中去，如此反復，以完善我們的設計。而這其中，恐怕最重要的要素就是對象的職責和彼此協作機制。
 
                                 崔剛 2007-11-23

 
在我的舊文中，曾經提到在 C++ 中實現 Java 的 final 功能，但每次都要寫一個基類比較麻煩，今次用模板把它加強。
 

 
這樣以后就可以直接繼承模板類 final<T>，而不用每次都寫一個類。
 
在這里順便說一下，為什么一定要虛繼承，假設我們有
 

 
如果上面不是虛繼承，那么 final 類的構造函數由 MyTest 的構造函數負責調用，因為是友元類，則調用成功，無法阻止 test 實例化。而一旦聲明為虛繼承，MyTest 不再負責調用 final 的構造函數，而由 test 來調用，那么因為不是友元類，實例化將失敗，編譯出錯，提示不能訪問私有的構造函數。
 

 
這里給出一個方法，實現對某個方法調用者的限制。

這里將寫方法聲明為保護的，對外界不可訪問。派生類Test的作用僅僅是將友元類進行聲明。
 
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
妙妙妙！
使用這個方法，就可以對類的私有函數進行單元測試了！！！！
                         JeansBer
 
 
 
 

 
倒霉起來，什么都擋不住，現在只能用左手打字了。自從鼠標和筷子換到了左手，突然有重獲新生的感覺，我真切地感到自己還有很多的事情都不會，當米飯被左手的勺子弄得滿桌子都是的時候，我仿佛回到和女兒一樣的年紀。
 
不知道大家有沒有在前進的路上躊躇，你還有至少一半的潛力沒有開發，當你習慣了右手，不要忘記你還有左手。
 
                      崔剛    2007-11-19  左手草就
===========================
支持！今天起用左手鼠標－－陶華
 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
 
難得崔兄如此豁達！真應該向你學習！人生已經如此明鏡，還有什么困難挫折，能擋在我們面前呢？                                         －－ 張進
=======================
呵呵，以前也是手傷了，用左手吃了一個月飯，之后也經常有意使用左手，再后來聽說這樣對神經不好，會引起混亂，覺的有一定道理，也漸少用了。
－－bingo
 
==========================
當你是一個另類時，你會覺得似乎和周圍的人有點格格不入，總覺得有人會恥笑你，雖然沒有人笑你；我小時候是用左手的，寫字、吃飯、砍柴，直到初二吧！小時候扳手力，我搞不定其他小朋友，因為大家都是用右手；打乒乓球我用左手，時不時可以來個出人意料的扣殺，用右手的人是很難接招的。打籃球我也是用左手，很多很多，但在我的成長過程中，我都在強迫自己用右手，導致左右手都發育不良，還好女朋友（現在是老婆了）一直稱贊我腦袋瓜特好使，讓我多少有一點欣慰。若我的后代也遺傳了我的左撇子，我會告訴他自然發展吧！
——鐘遙
 
**********************************
呵呵，我上高中的時候，由于一次右手腕受傷，被迫改用左手運球，投籃；隨后也就養成了左右手平衡發展的習慣。雖然我左手投籃的命中率總是超不過右手，但是平衡發展可以讓自己的缺點不是那么明顯和致命，有時甚至可以轉化成優點。
－－楊曉濤
 
/////////////////////////////////////////////////////
 
感謝大家跟帖，其實用左手挺好的，鍛煉一下，看看什么時候可以左右互搏。 ：）  崔剛 2007-11-19
 
================
忘了對崔剛的傷勢表示慰問，腫了呢！
傷成這樣都如此樂觀，稱贊稱贊！就當是因禍得福吧！借此機會開拓自己的另一半！
——鐘遙

 
Martin Flower在《重構》里提到空對象模式，對于從容器中查找失敗需要返回引用時，可以使用，同時我覺的對于空指針調用也有一定作用，試舉一例：
 

 1 #include <iostream>
 2  
 3 class Mail{
 4 public:
 5         virtual void print()
 6                   {std::cout<<"Hello!"<<std::endl;};
 7         void* operator new(size_t);
 8 };
 9  
10 class NullMail{
11         NullMail(){};
12         static NullMail inst;
13 public:
14         virtual void print(){
15                 using namespace std;
16                 cout<<"error! You can't access a NULL object!"<<endl;
17         }
18         static NullMail&  GetInst(){return inst;};
19 };
20 
21 NullMail NullMail::inst;
22  
23 void* Mail::operator new(size_t){
24         return &NullMail::GetInst();
25 }
26  
27 Mail*   GetMailPtr(){
28         return NULL;
29 }
30  
31 Mail&   GetMailRef(){
32         return (Mail&)NullMail::GetInst();
33 }
34  
35 //
36  
37         Mail*   ptr_Mail = GetMailPtr();
38         Mail&   ref_Mail = GetMailRef();
39         //ptr_Mail->print();
40         ref_Mail.print();

 
當我們返回一個空指針給調用者，如果他沒有判斷，那就會發生系統崩潰，而我們返回一個空對象的引用就可以避免這一點。
 
另外一個附加的有趣現象，你認為下面的調用會輸出什么信息？
 

1 
2         ptr_Mail = new Mail;
3         ptr_Mail ->print();
4         ref_Mail.print();   

 
正確的答案是：

1         Hello!
2         Hello!

 
因為Mail的缺省構造函數將自己的vptr填給了NullMail單例。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
一個問題，是不是Mail的每個公共接口，NullMail都要去實現一下？           －－th
 
//除非實在沒有必要，的確應當實現一下所有的公有虛方法。cuigang，2007-11-08
 
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
“對于從容器中查找失敗需要返回引用時”，下午剛剛碰到一個這樣的問題。     jb
 

 
昨天看了一下除顫的代碼，發現里面類的框架里有一個NoCopy（類似名字）的類，將拷貝構造函數和賦值運算符聲明為私有的，那么繼承于這個類的派生類也不能被克隆，注釋中強調要私有繼承，其實如何繼承都可以，只要派生類不在public部分重新定義拷貝構造函數和賦值運算符就可以，另外也不必單獨寫一個類，這個聲明寫到基類就可以了。
 
看到這個我又想到一些類似的小技巧，比如單件模式，其實就是將缺省構造函數聲明為私有，以限制實例化。例如還有：
 
1、強制必須動態分配，可以將析構函數聲明為私有，同時提供free方法（因為不能delete）。
 
2、禁止動態分配，將new方法聲明為私有。
 
3、禁止繼承，繼承一個類（最好虛繼承），這個類的構造函數是私有的，并且它的友元類是派生類。這個比較復雜，代碼示例如下
 
class final{
        friend class MyTest;
private:
        final(){};
};
class MyTest : public virtual final{
public:
        MyTest(){};
};
 
這樣就實現了Java的Final功能。
 

以氣為宗還是以劍為宗？
 
話說華山派因氣劍之爭分為二宗，一者以修習內功心法見長，是為氣宗，一者以鉆研劍法招式為本，是為劍宗。二宗意識形態不同，哪能共存，某年某月某日兩派華山一役，劍宗盡滅。但老金似乎并不認為氣宗就一定高過劍宗，又讓令狐沖學了劍宗本事后突飛猛進。到底哪個才是末學，老金并沒有給出答案。
 
程序員往往也面臨這個抉擇。
 
 
 
======================
我不喜歡依靠外物，我選氣宗。
                         --彭建軍
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
個人學氣功，集體練劍陣－－陶華
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
考慮這個問題很久了，想到兩句話：一個是《老子》里的“以正治國，以奇用兵”，一個是《三國》里的“用兵之道，一正一奇，正者持之，奇者勝之”。引申到軟件里，我認為能固化能傳授的經驗和工具（如正向設計，規范流程，代碼熟悉）就是正，反之非常依靠經驗（如查死機問題，打補丁）就是奇。正是奇的根本，沒有正的奇就是旁門左道。bingo
 
============================
孤孤單單一個人,走在麗影雙雙的街頭,
忘了我在找什么,等待明天還是往回走?
總是在失去以后才想再擁有
......
這個問題我都想的很累了,很想看到大家的想法,
頂起來!希望看到更精彩的高論!
                                        JIn CHuang(張進)
/**************************************/
氣劍之爭，實是尋求武學的終極之道，究竟是個人修為重要，還是研習招式重要。武學自古有內外之分，少林武當皆以內家氣功見長，但也有鐵砂掌之類的外家招式，令狐沖的獨孤九劍可能就是劍法巔峰之學了，從也不見小李探花用什么內力。可見內外家都有絕頂高手，但深入看，其實這些名家無不內外兼修，難以想象僅有內力卻無招數，那如何制敵？或徒有高招但綿而無力，敵何懼之？   其實便如玩暗黑系游戲，給人物加屬性一樣，每次只有5個點，你說加什么屬性？
            崔剛 2007-10-31
*/
 
===================================
頂!
順便問問,“葵花寶典”很是厲害,是內功還招式,或是兼而有之?mosj
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
”葵花寶典“是內功吧，“辟邪劍法”是招式！令狐沖最后能敵得過岳不群還不是靠收了桃谷六仙的內力，最后又習了少林易筋經的結果。所以麻，還是得靠內外兼修！這才是武學大家！
Ftz
 
////////////////////////////////////////////////////////////////
問各位玩過星際類似游戲的，你們認為造更多的兵重要還是升科技重要？ 崔剛，2007-11-1
 
 
#########################
不要執著于答案，跟郭富城一起動起來吧！要兵不要科技，就是無源之水；要科技不要兵，就是竹籃打水。              靳波
 
============================
狂占礦，狂造兵，狂升級，狂騷擾，狂操作，最后搞死他。  --彭建軍
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
把所有能用的都用上，不留任何閑置資源－－陶華
 
============================
升科技或者造兵都可能贏，唯一必輸的就是什么都不做。
--王祁
 
===================================
 
要隱喻練武，拿樸素的話來講，我認為，一個程序員的成長可分為如下六個階段：

第一階段
    熟練地使用某種語言。這就相當于練武中的套路和架式這些表面的東西。

第二階段
    精通基于某種平臺的接口（例如我們現在常用的Win 32的API函數）以及所對應語言的自身的庫函數。到達這個階段后，也就相當于可以進行真實散打對練了，可以真正地在實踐中做些應用。

第三階段
    能深入地了解某個平臺系統的底層，已經具有了初級的內功的能力，也就是“手中有劍，心中無劍”。

第四階級
    能直接在平臺上進行比較深層次的開發。基本上，能達到這個層次就可以說是進入了高層次。這時進入了高級內功的修煉。這時已經不再有語言的束縛，語言只是一種工具，即使要用自己不會的語言進行開發，也只是簡單地熟悉一下，就手到擒來。

第五階級
    已經不再局限于簡單的技術上的問題了，而是能從全局上把握和設計一個比較大的系統體系結構，從內核到外層界面。可以說是“手中無劍，心中有劍”。到了這個階段以后，能對市面上的任何軟件進行剖析，并能按自己的要求進行設計，不論多復雜的軟件，只要有充足的時間，也一定能設計出來。

第六階級
    是最高的境界，達到“無招勝有招”。這時候，任何問題就純粹變成了一個思路的問題，不是用什么代碼就能表示的。也就是“手中無劍，心中也無劍”。此時，對于練功的人來說，他已不用再去學什么少林拳，只是在旁看一下少林拳的對戰，就能把此拳拿來就用。這就是真正的大師級的人物。
 
——鐘遙，2007.11.1
++++++++++++++++++++++++++++++
有人在乎外表風度,有人在意內心溫度,我選擇內外兼修--立朗商務男裝(楊曉濤 引)
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
不管是內家功夫,還是外加功夫,高手們無不兼容并包,但最終所有高手倚重的往往只有一個.
鳩摩智算是人中龍鳳,見什么學什么?強煉少林寺72項絕技,結果還是比不過喬峰的降龍十八掌.喬峰
自幼得到少林真傳,也就是基本功很好,所以就算是只用太祖長拳,就在聚賢莊做到無人能敵.
段譽屬于另外一種煉劍宗的極端,本來不會武功,,偏偏造化讓他懂了六脈神劍,就這一個練到運用自如,就能打敗很多高手.
所以,內外兼容并包,沒有錯,但是最終的方向只能有一個,否則他就是神了.
                                                      zhangjin
 
/**************************************/
/*
感謝各位捧場，看了各位的跟帖，特別是鐘遙竟然寫的比主貼還長，真是敬佩敬佩。看來各位均覺得內外兼修，兼容并包是正途，之后鐘遙就覺得招式已為末學，而張進就說只要選一個就好。但我以為無論是御氣，還是劍法，終有盡頭。就好像星際，當你人口達到上限，科技全部升滿，操作已登峰造極，你練什么？到最后高手對決，恐怕拼的還是智慧、勇氣和自信。
                             崔剛  2007-11-02
*/
 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
 
我最認同鐘遙兄的觀點,我好像記得梁肇新也有此觀點吧!
其次,才是我的大繆!
哈哈,哈哈!看來我們部門真是臥虎藏龍,大家已經登封造極,開始討論學什么了!
不過這是一個監護軟件的鎮山之貼,此貼留名,幸甚!

                                             jin chuang
 

一個問題的討論
 
今天在QQ里跟大家討論了一個問題，雖然沒有結論，但是還是貼出來留個記號。
 
崔剛(崔剛) 2007-10-25 16:18:55
如何通過基類指針調用派生類特有方法，前提是不允許強制轉換指針類型？
例如有基類 class base{};
派生類
class derive:public base{
public:
        int A();
}
我得到了一個base* 類型的指針 derive_ptr，但它指向derive類型對象，我如何調用方法 derive::A(), 不可以
((derive*)derive_ptr)->A();
李奇兵(李奇兵) 2007-10-25 16:20:17
把方法A（）申明為虛的
陶華(陶華) 2007-10-25 16:20:52
除非基類有這個虛接口
李奇兵(李奇兵) 2007-10-25 16:20:55
把方法A（）申明為虛的，在Base定義一個。
向官文(向官文) 2007-10-25 16:21:16
用函數指針應該可以實現吧
陳道生(陳道生) 2007-10-25 16:22:46
沒方法
崔剛(崔剛) 2007-10-25 16:22:27
呵呵，如果base類有幾十個派生類，每個派生類都有不同的特有方法，那么在基類中就會存在幾十個虛方法，而每個派生類只實現一個，其它全部不實現，
這樣是不是不太好？？
李偉(監護）(李偉(監護）) 2007-10-25 16:23:25
如果是public的，基類應該聲明吧
張建生(張建生) 2007-10-25 16:23:57
這樣的話該函術確實不應該在基類里面定義
基類里面只定義共有的
靳波(靳波) 2007-10-25 16:23:47
這個問題的答案肯定很有技巧，但我認為這種技巧太花哨，不知道也沒關系
陶華(陶華) 2007-10-25 16:24:49
崔剛，你那樣定義是違反替換原則的
向官文(向官文) 2007-10-25 16:25:02
咱們的消息映射機制就是用基類的函數指針調派生類的成員函數
李偉(監護）(李偉(監護）) 2007-10-25 16:25:02
還是想知道。。
莫書健(莫書健) 2007-10-25 16:25:22
上面那段代碼會不會運行是對的？
只是這樣強制轉換不是很符合編碼規范
崔剛(崔剛) 2007-10-25 16:25:28
呵呵，不要懷疑我的問題的實用性
彭建軍(彭建軍) 2007-10-25 16:26:34
對于這個問題，C++的標準解決方法應該是dynamic_cast
靳波(靳波) 2007-10-25 16:26:15
cast也是類型轉換
莫書健(莫書健) 2007-10-25 16:27:41
加不加dynamic_cast之類的，運行效果應該一樣
彭建軍(彭建軍) 2007-10-25 16:29:18
是類型轉換，但那是C++標準的轉換方式。
向官文(向官文) 2007-10-25 16:30:45
dynamic_cast 據說會損失執行期效率
靳波(靳波) 2007-10-25 16:31:33
dynamic是在運行時進行轉換，所以不是據說，是肯定會損失執行期效率。
靳波(靳波) 2007-10-25 16:36:22
#include "stdafx.h"
#include <iostream>
using namespace std;
class Base
{
};
class Derive : public Base
{
public:
 int A(){cout<< "Derive::A()\n"; return 0;}
};
union Amazing
{
 Base* pBase;
 Derive* pDerive;
};

int _tmain(int argc, _TCHAR* argv[])
{
 Base* derive_prt = new Derive;
 Amazing trick;
 trick.pBase = derive_prt;
 trick.pDerive->A();
 delete derive_prt;
 return 0;
}
向官文(向官文) 2007-10-25 16:37:45
typedef void (base:: *BasefnPtr) ();
BasefnPtr fn_ptr = &derive::A;
然后用基類的指針去調
(pBase->*fn_ptr)();
我看高端里消息響應函數就這樣調
沒理解錯吧 ;)
崔剛(崔剛) 2007-10-25 16:39:09
同志們，跑題了
1、不能強制轉換，標準的強制轉換也不行。
2、不是把派生類指針轉成基類指針，那樣是沒問題的。我說的是把基類指針轉成派生類指針。
楊曉濤(楊曉濤) 2007-10-25 16:40:14
靳波的方法挺有創意的，呵呵
靳波(靳波) 2007-10-25 16:40:45
：）
莫書健(莫書健) 2007-10-25 16:41:37
jinbo的方法有什么優點？
崔剛(崔剛) 2007-10-25 16:41:46
靳波太搞笑了，這樣寫不可維護
靳波(靳波) 2007-10-25 16:41:41
這個方法太危險
崔剛(崔剛) 2007-10-25 16:42:13
變相的強制轉換，不合格，0分
莫書健(莫書健) 2007-10-25 16:43:34
cuigang的需求估計沒有解決方法
陶華(陶華) 2007-10-25 16:44:57
需求評審不通過
崔剛(崔剛) 2007-10-25 16:44:40
問題本身是沒有解的，但是迂回的方法有，比如IoControl或者高端中ControlModule的方法就是一種，但是不是有其它更好的辦法呢？
崔剛(崔剛) 2007-10-25 16:45:34
visitor 模式也提供了一種方法，但是太麻煩，本質上和 IoControl 沒什么區別。
張進(張進) 2007-10-25 16:48:45
還有一種方法,把編譯器作者拉出來打,狂打,直到他搞定為止!
陳道生(陳道生) 2007-10-25 16:48:57
有點像已經知道方法名和參數,如何調用實例對應的方法,在c++中無解,在其他語言大放異彩(java,c#),都是要具有元編程能力的語言才行.
崔剛(崔剛) 2007-10-25 16:48:26
我需要一種安全方便又易于維護的辦法，不要急著回答
崔剛(崔剛) 2007-10-25 16:49:23
難道我們真的離不開強制轉換？？
莫書健(莫書健) 2007-10-25 16:52:18
如果想調用派生類的方法，就要使用虛函數，
設計基類是要充分抽象，盡量想到種種情況
向官文(向官文) 2007-10-25 16:53:01
崔剛好像對強制轉換深惡痛絕啊～
崔剛(崔剛) 2007-10-25 16:52:46
我認為依靠繼承的方法不可取
莫書健(莫書健) 2007-10-25 16:53:19
實在不行，就將就強制一把，我想也可以容忍的
楊曉濤(楊曉濤) 2007-10-25 16:54:05
類本身也需要細化，寄希望一個類包含所有的接口是不現實的；
粗暴的將所有功能放在一個類中，也是不美觀的，不招人喜歡的
崔剛(崔剛) 2007-10-25 16:53:45
不是我厭惡強制而是強制不安全，維護代碼時可能發生不可意料的問題。
靳波(靳波) 2007-10-25 16:53:57
既然你已經有答案，不如公布出來讓大家參詳參詳。
崔剛(崔剛) 2007-10-25 16:54:54
我沒有答案，有的話就給你們上課了
莫書健(莫書健) 2007-10-25 16:56:11
這個課題就叫“崔剛猜想”吧
陶華(陶華) 2007-10-25 16:58:27
給C＋＋標準委員會提個需求
崔剛(崔剛) 2007-10-25 16:59:27
另，dynamic_case<> 需要編譯器支持 RTTI
向官文(向官文) 2007-10-25 17:04:51
C++這門靜態語言解決這個執行期的動態問題恐怕無解
也許出路在第三方的接口上吧
崔剛(崔剛) 2007-10-25 17:05:55
換句話說，大家是不是認為，在目前階段，象ControlModule和IoControl這樣的接口是相對合適的嘍。
崔剛(崔剛) 2007-10-25 17:13:41
2007年10月8日，汪勝平在他的工作日志里寫道：
關于ControlModule型接口
這種類型的接口有以下好處：
1、降低編譯依賴性。
2、如果模塊A通過接口ControlModule依賴模塊B，當模塊B不存在時，理論上模塊A仍然可以正常工作。
當然它也有一個不好的地方，那就是本來簡單的調用關系，因為這個接口的引入變得復雜一些了。
但是，這兩個好處需要小心使用才能保證。
1、沒有函數名的依賴，但是并不代表就沒有編譯依賴了。比較典型的是ID的依賴。ID在模塊B中被定義。在A中直接包含
B的頭文件。不過這種編譯依賴可以由第三方定義ID來解決。
2、如果需要傳遞的信息比較多，我們最容易想到的方法是定義一個結構體來傳遞相關信息。這個結構體如果由B來定義，
那么A又落入了在編譯上依賴B的陷阱。
3、如果A在調用時沒有考慮好B不存在怎樣處理，那么ControlModule的第二個好處就體現不出來。
對于ControlModule型接口。我覺得要慎用，它不是萬能的。某些時候，虛函數也許更方便。
=================================
這是一個典型的C方式函數。我覺得如果是通用的接口，可以用多態，如果是特殊函數，這樣寫純屬找茬。//崔剛 2007-10-12
=================================
ControlModule這類的接口，簡單問題復雜化，難道只是為了
“降低編譯依賴性”？這會不會是我們軟件部附加上去的想法,
這類接口經常用于驅動接口(請參看linux\windows,
還有我們的mmos驅動模型),
我想最初這樣做的理由會不會是這樣：
1）為了減少接口個數。
2）統一屬性設置/獲取接口。
至少在驅動是這樣的。
比如：
set_property1();
set_property2();
:
:
set_propertyN();
減少為一個
#define ID_PROPERTY_1  0
#define ID_PROPERTY_2  1
:
:
#define ID_PROPERTY_N  n
Control( property_id, ...);
mosj

夏恒星(夏恒星) 2007-10-25 17:37:29
呵呵，原來這樣的問題并不只有我遇到，俺在代碼中加了注釋：
    //注意: 將基類指針強制轉換為派生類指針并不可取
    //但是此處要使用協議各層提供的非基類提供的接口
    //能不能從設計上避免?
    mTopProtocol = (CUartCommProtocol* )(m_pProtocolStack->GetSpecifiedLayer(UART_COMM_PROTOCOL));
崔剛(崔剛) 2007-10-25 17:44:02
這種應用更常見的地方是，把不同的派生類放到共同基類類型的指針容器里，然后把這個基類指針取出來，再干一些派生類的事情。
崔剛(崔剛) 2007-10-25 17:46:11
隨便在高端里copy一段代碼給大家看：
 MSpinBox* pSB;
 pSB = (MSpinBox*)GetWindowItem(IDC_CO_SPIN_TB_HI);
 INT32 value = pSB->GetIntCur();
汪勝平(汪勝平) 2007-10-25 17:53:20
我覺得這種類型的接口比ControlModule強，
雖然這些接口會增加編譯期依賴。
崔剛(崔剛) 2007-10-25 17:53:40
這就見仁見智了。
崔剛(崔剛) 2007-10-25 17:58:59
下班前，抄一段《JAVA編程思想》的話給各位共勉，包括發炎的沒發炎但吃了藥的。
http://vss2/sites/jhsoftware/Lists/List13/Attachments/768/ThinkJava.bmp
 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
太“行而上”了！不過監護軟件部真是不可小覷啊！                       張進
 
/*******************************************/
/*
我不認為這是一個“形而上”的問題，或者一個智力游戲，它有著廣泛的用途，否則不會有這么多的討論和解決方案。昨天晚上回家查了一下，“向下轉型”的確是我們要在設計中避免的，但在實際設計卻經常面臨，目前所有語言基本都支持到dymanicv_case<>的地步，而這卻需要RTTI的支持，雖然其他高級語言比如C#，Java，Python都在語言級別提供象“反射”等方式來解決這個問題的超集，但是此種“元類”的語言特性違背了C++的精神，想必無論如何也不會出現在C++里，因為效率的犧牲和運行時存儲的需求應該也不適用于目前的嵌入式設備。
反過來再想想，我們何必要求非常安全的途徑解決這樣的問題。C++/C本來就是一種弱類型語言，不安全的特性比比皆是，所以動態強制轉換未必不是一個正途。
另外，對于汪勝平最后說出的問題，我覺得ControlModule之類的寫法可以用這種強制轉換的方式解決，當然孰優孰劣就留給各位去判別了。
           崔剛 2007-10-26
*/

 
昨天是教師節，自離開講臺以來，再也未因此發過錢財，不覺有些懷念，所以今天就說說老師這個職業。師者，所以傳道授業解惑也。我以為，昌黎先生的三種，傳道為先，授業為本，解惑為末。
 
有些事情說著容易做著難，道是什么，如何傳，可以大膽的說，沒人知道。所以傳道變成了悟道，同學們，你們要悟。老師們是不知道什么是道，即便知道，也說不出來，即便能說出來，你也聽不明白，沒辦法傳給你。正所謂，師傅引進門，修行在個人。
 
反過頭來看企業的員工培養，面臨同樣的問題。通常的企業都是師徒制，師傅帶徒弟。遇到一個好師傅尤為重要，當年郭靖跟著江南七怪的時候，乏見成效，而全真派的牛鼻子馬鈺一來，郭靖就突飛猛進，害得柯鎮惡還以為我們的靖哥哥跟了梅超風走歪門邪道呢。那么，原因何在呢？教不得法也。大凡武林正派甚至泰山北斗猶如少林武當，均以內功心法見長，內力修為方為習武之根本，而招式均乃奇技淫巧，這也就是妖怪寶貝多的緣故了。馬鈺畢竟是聰慧之人，撿了個便宜。
 
修習內功豈是速成之徑，所以我們急功近利的想法就是告訴他怎么做，而不是為什么，豈知欲速則不達。所以企業培養人才，應該著重培養他的內力，不要只顧眼前。師傅們不管得道與否，均需謹記，傳道為先，雖然你可能說不出，講不明。
 
 

 
因為師范生緣故，學過一陣心理學，知道馬斯洛的層次需要，其大致是是說，人的需要分作5層，自高至低依次是自我實現尊重愛與歸屬安全生存
而人的需要往往是逐漸升高的，只有下一層需要得到滿足，然后才會產生上一層需要。這里談它，不是想在這里丟書包，只是想說，馬斯洛說的并不全對，因為在我們生活中，不乏有越層的需要，比如饑餓貧困但是深深愛著公主的流浪漢，四處奔波隱姓埋名的共產黨地下工作者，貧民窟里志存高遠的年輕人，當然也有一些患者也不滿足。
 
不過有越層需要的人往往都是偏執狂，他的這種追求（我覺得已經不能稱為需要了）對他而言大多成本很高。如果他努力且幸運，可能會成為一個了不起的人，否則會表現出嚴重的抑郁癥甚至精神分裂。
 
其實，追求軟件的質量也是類似的，這些就是CMM要分級的原因，而且不允許越級評審，因為他們認為越級是危險的。大躍進式的發展是代價高昂而且危險的（以下均指一般情況，不包括特例），如果你本次項目的千行故障率是12，你想把它在下次項目降到8甚至6，基本上是屬于幻想，那需要付出血的代價。
 
趕英超美是沒問題的，要用三個五年計劃甚至一個五年計劃來實現，這種事情只有太祖和瘋子敢做。