討論區快速選單
知識庫快速選單
傑米的攝影旅遊筆記 Top1安全軟體開發知識-CSSLP 政府補助!資策會APP就業班
[ 回上頁 ] [ 討論區發言規則 ]
C和C++所寫出來的程式,哪一個效率比較好
更改我的閱讀文章字型大小
作者 : loveorc2003(BK.) Visual Basic優秀好手新手入門優秀好手一般優秀好手貼文超過1000則人氣指數超過200000點
[ 貼文 1381 | 人氣 206151 | 評價 2670 | 評價/貼文 1.93 | 送出評價 712 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/8/19 下午 09:00:26
請問一下C和C++所寫出來的程式,哪一個效率比較好
作者 : ma_hty(白老鼠(Gary))討論區板主 OpenGL卓越專家DirectX優秀好手C++頂尖高手貼文超過2000則人氣指數超過70000點
[ 貼文 2079 | 人氣 89850 | 評價 9950 | 評價/貼文 4.79 | 送出評價 78 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/19 下午 10:57:56
C 也好, C++ 也好, 那個寫得好, 效率就較好... :P
(設計回應 : @@?? 誰人不知呢??? )
作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/20 下午 07:12:41
說的真好!

>C 也好, C++ 也好, 那個寫得好, 效率就較好... :P
>(設計回應 : @@?? 誰人不知呢??? )
作者 : cog(Cog) VC++卓越專家C++優秀好手貼文超過200則
[ 貼文 458 | 人氣 12 | 評價 3390 | 評價/貼文 7.4 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/20 下午 07:22:49
是的,甚至是寫得好的Basic程式,都可以比寫得不好的C程式跑得快,
不過我想問題的原意應該是,如果是一樣的程式,在C和C++下那一個比較快吧,這個沒研究過,不確定。
作者 : chengcti(chengcti)
[ 貼文 31 | 人氣 460 | 評價 310 | 評價/貼文 10 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/20 下午 07:48:50
C
C++ 在 OO 的因素, 所以程式會變大. 速度會變慢

作者 : ma_hty(白老鼠(Gary))討論區板主 OpenGL卓越專家DirectX優秀好手C++頂尖高手貼文超過2000則人氣指數超過70000點
[ 貼文 2079 | 人氣 89850 | 評價 9950 | 評價/貼文 4.79 | 送出評價 78 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/20 下午 08:28:42
^^", 原意我也是明白的, 就好像我初學 C++ 時, 也會有同一樣的疑惑.
但是... 寫程式久了, 慢慢明白到, 什麼語言也好, 程式要寫得好, 最重要
的是要配合程式語言本身的架構.

純粹說一行兩行程式碼, C 是會比 C++ 略快一點點的.

可是, 只一行兩行沒意思呢, 寫程式, 除了算速度之外, 還有 維護, 開發,
原碼共享性 等等... 一堆因數雖要考慮在內的. 如果要用 C 去模擬一部
份 C++ 的配套, 不僅費力氣, 而且不太可能寫得比原來的 C++ 好.

C 寫得不好, 可以難維護之餘又跑得慢.
C++ 寫得不好, 也可以難維護之餘又跑得慢呀.

如果寫得好嘛... 假設得這個, 還有什麼不可以假設呢?! ^^"

思前想後... 關鍵始終是 編碼人員 的功力.
作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/23 上午 08:53:54
可見對C++還不夠深入。
由於語言要支援OO的特性,compiler必須在某些地方額外加入一些程式碼來達成OO的效果。但是藉由瞭解OO底層的運作機制,不管是從理論面或自己去trace compile出來的codes,都可以瞭解怎樣的語法會產生怎樣的程式碼,由此,就可以在OO特性與效率上獲得一個平衡,最壞,不過就退化到跟C一樣,不是嗎?

>C
>C++ 在 OO 的因素, 所以程式會變大. 速度會變慢
>
>
作者 : nietzsche(尼采) VC++優秀好手C++優秀好手貼文超過200則
[ 貼文 498 | 人氣 3089 | 評價 2890 | 評價/貼文 5.8 | 送出評價 4 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/23 下午 12:51:51
效率嗎?
我覺得...不要去討論比較好...@@"
真的要比較,C當然會比較快....一點點..
C++要去存取物件內的 member function,
定址之間,時間上就比C差了一點點...
以相同的小程式來說,或許2者之間的差異不到 1/1000 ms,
所以不用去在乎那些微的差異...

重點是你要走的領域是哪方面的...
以我現在來說,主力是C,因為要誇平台(手機平台,有些 compiler 不支援 c++ ),
所以大部份都以 C 來完成,
而現在也才發覺...要寫出一個好的 C 程式,並不是那麼容易,
也許因為中了C++的毒太深了...@@"
作者 : cplusplus(Cpp) C++優秀好手貼文超過500則人氣指數超過10000點
[ 貼文 846 | 人氣 16660 | 評價 1120 | 評價/貼文 1.32 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/24 上午 12:01:22
virtual的member function用起來跟一般的function本質上一樣
經過編譯器幫你最佳化後 效能會是一樣的 :)
會損耗c++效能的大部分是動態性的部分跟繼承體系造成的OVERHEAD
還有一些應該可以避免的呼叫 像是沒做事的constructor跟destructor呼叫等~
不過這可以利用一些meta-programming來解決 但是現在還不是百分之百完善就是了...
另外還有像是非oo的特性,如exception,也要付出一些代價...用 throw()限制EXCEPTION丟出 或是用一些像是new(nothrow)的話 可以增加效能還有最佳化的可能性

所以說 如果排除掉不去用這些c++的特性的話 加上程式最佳化 寫出來的程式是差不多的
正如上面各位前輩所說的 效率不是全部 也要看領域來決定 :)

以上拙見
作者 : x33333(阿新)
[ 貼文 163 | 人氣 7000 | 評價 400 | 評價/貼文 2.45 | 送出評價 14 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/24 上午 02:07:27
在這邊看到了一些電玩設計的同好
C和C++所寫出來的程式,哪一個效率比較好?
那去看看為什麼電玩大廠任天堂的GBA&Game Cube的SDK
要用純C 而捨棄C++了...
作者 : ma_hty(白老鼠(Gary))討論區板主 OpenGL卓越專家DirectX優秀好手C++頂尖高手貼文超過2000則人氣指數超過70000點
[ 貼文 2079 | 人氣 89850 | 評價 9950 | 評價/貼文 4.79 | 送出評價 78 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/24 上午 09:22:06
電玩大廠 用 純C, 考慮的不是效能的問題. 而是 platform 的問題.
因為把 純C 的程式轉到電腦之外的機器上 較 C++程式 的容易很多.
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 上午 01:14:17
>由於語言要支援OO的特性,compiler必須在某些地方額外
>加入一些程式碼來達成OO的效果。但是藉由瞭解OO底層
>的運作機制,不管是從理論面或自己去trace compile出來的
>codes,都可以瞭解怎樣的語法會產生怎樣的程式碼,由此,
>就可以在OO特性與效率上獲得一個平衡,最壞,不過就
>退化到跟C一樣,不是嗎?
很有見地!!

>真的要比較,C當然會比較快....一點點..
>C++要去存取物件內的 member function,
>定址之間,時間上就比C差了一點點...
只差pass一個this指標而已。
但要因此判定”C比較快”好像不對!
從台北到高雄,塔火車和飛機,那個比較快?
因為塔飛機check in,過關檢查等手續會多耗半小時
所以當然是坐火車較快。
這樣的說法你同意嗎?
當然不對,評斷的錯誤在於忽略了其它的快慢要素,如
飛機和火車的時速,台北到高雄的距離...
既然在你的C++程式中定義了物件,當然要有”利益”目的
(花了錢買東西,不會只為了花錢而已吧)
如果用了物件,沒有任何的利益,反而只是多花了一點時間在
pass this指標而已。那麼你儘可以使用 static 成員函式或global函式
。不要忘了,C++提供飛機,但還是有火車可以塔乘啊!!
了一個this多花了一點點時間而已
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 上午 01:26:45
>電玩大廠 用 純C, 考慮的不是效能的問題. 而是 platform 的問題.
>因為把 純C 的程式轉到電腦之外的機器上 較 C++程式 的容易很多.
一針見血!!
想想有那些 CPU有C++編譯器?
我想對大部份人來說,除了舉出 X86 和 68K 外,就要抓頭了...
除了C++編譯器的問題外,工程師的慣性也是因素。
如果你是位寫8051程式的工程師,你可能不知道,8051也有C++
編譯器喔!!
但即使你現在知道了,會不會去使用它(或何時才會去用),會是一個
好問題。只是8051的C++編譯器已經面世了好多年了,至今仍乏人問津!
 
 
 
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 上午 01:45:13
>非virtual的member function用起來跟一般的function本質上一樣
如前所言,是差了一個this指標參數^^

>會損耗c++效能的大部分是動態性的部分跟繼承體系造成的OVERHEAD
繼承體系造成的OVERHEAD在編譯階段,不是在執行期;
至於所謂的"動態性",不知是何所指?

>還有一些應該可以避免的呼叫 像是沒做事的constructor跟destructor呼叫等~
如果constructor跟destructor沒有好處,就不要寫它就成了!
如之前說的,沒用的東西就不要買!

>另外還有像是非oo的特性,如exception,也要付出一些代價...用 throw()
>限制EXCEPTION丟出 或是用一些像是new(nothrow)的話 可以增加效能
>還有最佳化的可能性
還是那一句話,如果你覺得exception沒用就不要買單!
exception 是個好東西,要用好東西當然要付代價,但效能要看跟誰比囉。
C 又沒有 exception 怎麼比....


作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 上午 01:50:51
颱風天,白天覺睡多了,睌上抓狂胡亂發言。
若有失言,尚請看在coco年紀的份上,
不尊賢也敬老,不要罵偶囉....

作者 : cplusplus(Cpp) C++優秀好手貼文超過500則人氣指數超過10000點
[ 貼文 846 | 人氣 16660 | 評價 1120 | 評價/貼文 1.32 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 上午 07:35:13

>>非virtual的member function用起來跟一般的function本質上一樣
>如前所言,是差了一個this指標參數^^
是的 如過同樣功能以C時做 要把C的struct集合體傳進去 也是要一個指標的 :)
>
>>會損耗c++效能的大部分是動態性的部分跟繼承體系造成的OVERHEAD
>繼承體系造成的OVERHEAD在編譯階段,不是在執行期;
>至於所謂的'動態性',不知是何所指?
啊 動態性就是那些virtual call跟些RTTI的東西罷了 表達不清 請見諒
像是有些指標間的計算跟轉換 必須再執行時期才可計算....:) 而這跟繼承體系有很大的關係
CLASS的指標轉換 member function的指標計算 還有一些指標的檢查
尤其到了 多重繼承與虛擬繼承 那可蠻麻煩... 另外繼承體系的OVERHEAD也包括了
大小空間上的 像是個額外的VPTR...
另外有些新功能像是繼承來的virtual function可以傳回跟原宣告不同的形別
比如說

class A{virtual A* f();};
class B:public A{B* f();};
.......
A *a;
....
A *aa=a->f(); //may be B::f(); need test
 這也必須再執行時做計算
有很多類似小細節 都是為了支援oo 所以也不可以拿這些跟c比
>
>>還有一些應該可以避免的呼叫 像是沒做事的constructor跟destructor呼叫等~
>如果constructor跟destructor沒有好處,就不要寫它就成了!
>如之前說的,沒用的東西就不要買!
:)
for example
class A{A(){};
     A(int)....};
class B:public A{};
class C{A a;};
B的話 編譯器會合成一個constructor 然後呼叫 因為B實際上是繼承A而來
但是編譯器不知A的constructor實際上是不是trivial的 所以會造成呼叫沒用的constructor
C的話則是必須呼叫B的constructor 所以也產生了一個其實不做事的constructor但有3次
fucntion call...
>
>>另外還有像是非oo的特性,如exception,也要付出一些代價...用 throw()
>>限制EXCEPTION丟出 或是用一些像是new(nothrow)的話 可以增加效能
>>還有最佳化的可能性
>還是那一句話,如果你覺得exception沒用就不要買單!
>exception 是個好東西,要用好東西當然要付代價,但效能要看跟誰比囉。
>C 又沒有 exception 怎麼比....

是的 我最後正是這個意思 ^^...
要用好東西當然要付出一點代價

c++有自己附上的東西 c沒有 所以不能是這樣單純的說誰效率好 :p
自己用c實做c++的功能的話 效率應該會比c++差很多吧 :p

以上一些c++的底層細節在C++ Object Model有詳細說明

以上拙見...
>
作者 : cplusplus(Cpp) C++優秀好手貼文超過500則人氣指數超過10000點
[ 貼文 846 | 人氣 16660 | 評價 1120 | 評價/貼文 1.32 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 下午 12:34:18
訂正
C的話則是必須呼叫"A的constructor " //不是B 打錯~~
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 下午 02:31:33
>啊 動態性就是那些virtual call跟些RTTI的東西罷了 表達不清 請見諒
>像是有些指標間的計算跟轉換 必須再執行時期才可計算....:) 而這跟
>繼承體系有很大的關係
virtual function 是在物件中加入了一個資料成員 : virtual function 的指標
呼叫 virtual function 時只要"間接"呼叫 virtual function 的指標就可實現了.
不論多少層的virtual function,其呼叫都只有一次的"間接"呼叫而已。
這個一次的"間接"呼叫有沒有overhead?有啊!就多一個load 指標的
動作吧。但virtual function又是C++新增的功能,C若要模擬virtual function
還是免不了"間接"呼叫啊! ^^

>CLASS的指標轉換 member function的指標計算 還有一些指標的檢查
計算?load 一個指標而已,”計算”是太嚴重了吧^^

>尤其到了 多重繼承與虛擬繼承 那可蠻麻煩... 另外繼承體系的OVERHEAD
>也包括了大小空間上的 像是個額外的VPTR...
我怎麼還是覺得這些overhead還是在執行時期(我誤解你的意思了嗎?...)

>另外有些新功能像是繼承來的virtual function可以傳回跟原宣告不同的形別
>比如說
這個...我還不知道耶....是不是落伍了 :(

>class A{virtual A* f();};
>class B:public A{B* f();};
>.......
>A *a;
>....
>>A *aa=a->f(); //may be B::f(); need test
> 這也必須再執行時做計算
就是一個間接呼叫而已唄...

>class A{A(){};
> A(int)....};
>class B:public A{};
>class C{A a;};
>B的話 編譯器會合成一個constructor 然後呼叫 因為B實際上
>是繼承A而來但是編譯器不知A的constructor實際上是不是
>trivial的 所以會造成呼叫沒用的constructor
>C的話則是必須呼叫A的constructor 所以也產生了一個其實
>不做事的constructor但有3次
>fucntion call...
喔,我的意思是,A B 都不要寫沒有做事的contructor就不會造成
呼叫沒用的constructor了。
既然A建立了default contructor,邏輯上就是程式員要求建立A或B時
要呼叫A(){} (即使它什麼事都沒做)。但這是指沒有最佳化說的,
在最佳化的編譯時,沒做事的contruct仍是”可能”被聰明的編譯器
忽略的。

>c++有自己附上的東西 c沒有 所以不能是這樣單純的說誰效率好 :p
Yep!! 沒有C++或C誰的效率好的問題;只有張三或李四誰的程式
效率好。^^


>自己用c實做c++的功能的話 效率應該會比c++差很多吧 :p
>以上一些c++的底層細節在C++ Object Model有詳細說明
C++本身還一直在演化,編譯器的技術也在精進。書上寫的是一個
可以實現的標準規格,但編譯器並不一定照單全收。
例如C++規格上說靜態的local物件在程式進入主程式之前就會建立。
程式員撰寫靜態的local物件,可以按這規格寫程式,但編譯器卻不
一定會這麼乖。至少我在VC 6上看到的就不是這樣。
VC 6的靜態local物件,只有在第一次執行到該物件的宣告處才會建立。
會不會重複建立static 物件?不會!VC6使用flag來確立static物件只會被
建立一次(若沒被使用,則連一次都不會建立,這意思是沒有用到的
local static 物件根不會存在)。

作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 下午 02:32:52
訂正
>尤其到了 多重繼承與虛擬繼承 那可蠻麻煩... 另外繼承體系的OVERHEAD
>也包括了大小空間上的 像是個額外的VPTR...
我怎麼還是覺得這些overhead還是在編譯時期(我誤解你的意思了嗎?...)
作者 : ma_hty(白老鼠(Gary))討論區板主 OpenGL卓越專家DirectX優秀好手C++頂尖高手貼文超過2000則人氣指數超過70000點
[ 貼文 2079 | 人氣 89850 | 評價 9950 | 評價/貼文 4.79 | 送出評價 78 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 下午 03:15:53
>我怎麼還是覺得這些overhead還是在編譯時期(我誤解你的意思了嗎?...)  //(全沒 virtual function 的話, 就正確... )


polymorphism...
作者 : cplusplus(Cpp) C++優秀好手貼文超過500則人氣指數超過10000點
[ 貼文 846 | 人氣 16660 | 評價 1120 | 評價/貼文 1.32 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 下午 08:43:10
我覺得一層間接性也算是一種OVERHEAD 雖然影響不大 但積少成多囉

>計算?load 一個指標而已,”計算”是太嚴重了吧^^
是的 :) 說計算好像太過了 但是也不只是一個 LOAD而已
單一繼承
A *pa=pb;
> A *pa=pb;
多重繼承的可能情形 一個加法 還算CONSTANT
A *pa=pb;
> A *pa=pb?(A*)(((char*)pb)-sizeof(A)):0; // + or - depends on OO model
虛擬繼承 overhead更大一點 必須RUNTIME做
A *pa=pb;
> A *pa=pb?(A*)(((char*)pb)+pb->vptr[-1]):0; // as well

以上混用就不敢想了 更多層的話...暈了
這跟一般指標指派相比 算是overhead了吧(依該啦)
成員函式指標跟成員資料指標的話也有一點點要轉換的
想像用一個指向virtual function的成員函式指標 透過一個pointer呼叫
哇 這是可行的~ 好棒! 但轉換真是麻煩呢....
另外還有CALL一個virtual functionthis也要做相對應的轉換...
以上 雖然 好像很小的細節 但是這些就是為了達成OO的overhead 無可避免
c++的這種OO Model是很優秀的 是目前領先的OO Model

>我怎麼還是覺得這些overhead還是在執行時期(我誤解你的意思了嗎?...)
抱歉 是我混在一起說了 SORRY
空間的overhead 不算是執行時期需要計算的overhead
但是空間的確是種overhead 不管什麼時候...比如
class A:public B,public C; 如果BC各有個vptr A裡就會多個8BYTE 如果加上自己的
就是12BYTE當然這說的只是為了vptr...
在來 還有所謂的padding問題 B:5byte,C:5byte A:5byte 各自有自己的5BYTE
最後一個A可能是24BYTE 是為了padding(所謂memory alignment)
為了時間效率 鎖犧牲的空間效率 不過蠻驚人的 如果各是1,1,1 出來的卻是12
這空間上可多了300%....當然可以取消alignment 但是這又犧牲了存取時間 :)
這種小地方積少成多 是很可怕的 那個300% 呼~!
>
>就是一個間接呼叫而已唄...
如上所述 這邊檢查要更麻煩的樣子 書上說太過麻煩沒有列出 另外又很多更複雜的情形書中也不提 只是說明代過 這讓compiler實作者去頭痛吧 :p

>既然A建立了default contructor,邏輯上就是程式員要求建立A或B時
>要呼叫A(){} (即使它什麼事都沒做)。但這是指沒有最佳化說的,
>在最佳化的編譯時,沒做事的contruct仍是”可能”被聰明的編譯器
>忽略的。
恩 可惜的是大部分編譯器真的不是那麼聰明(該說笨了:( ) 所以通常必須由我們幫忙
加入一些"TRAITS"來做最相關的佳化 期待有天編譯器可以做完全 :) 不過我覺得遙遙無期哪...實做不易 正確性也是一個考量 :p 我想在這之前還是要辛苦程式員一下了
另外A因為有其他的constructor 所以在必要時也必須提供一個不做事的default constructor for what 有什麼必要? 陣列~ STL容器~ 許多程式庫~ 都會要求物件必有個default constructor!
因此可惜常常無法避免的...要不就不寫任何constructor,在需要default constructor的地方也可以通過編譯, 但實際上不會任何constructor被呼叫 但是這麼做也就不能寫其他有參數的 constructor了 顧此失彼~
所以有時是逼不得已 但是又得犧牲效率 不然放著某些函式庫不用 太殘忍了 :P
SGI的STL就有提供TRAITS設定 可以讓使用者決定要不要呼叫那些無用的constructor
效率優異 :)

>例如C++規格上說靜態的local物件在程式進入主程式之前就會建立。
>程式員撰寫靜態的local物件,可以按這規格寫程式,但編譯器卻不
COCO大 我記得只有全域的static會在一開始被建立
LOCAL 的確是第一次用到才會變建構 這我記得蠻清楚的 不知道您是在哪看到?

最後 我不是說 c++效率低於c
以上的東西 c一根毛都沒有 :p(開開玩笑 不是貶低c)
因為這根本是不能比的 :)
以上只是說明 打字不快 好累 >"<
作者 : cplusplus(Cpp) C++優秀好手貼文超過500則人氣指數超過10000點
[ 貼文 846 | 人氣 16660 | 評價 1120 | 評價/貼文 1.32 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/25 下午 08:48:24
>>另外有些新功能像是繼承來的virtual function可以傳回跟原宣告不同的形別
>>比如說
>這個...我還不知道耶....是不是落伍了 :(
另外~! 有一點很重要~! 就是coco 大一點也不落伍 :P
作者 : kennytsai(Kenny) C++卓越專家貼文超過500則
[ 貼文 714 | 人氣 2903 | 評價 2820 | 評價/貼文 3.95 | 送出評價 139 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 上午 05:22:00
一個C的程式,可以讓C或C++的編譯器來處理,個人'覺得'兩邊的結果會一樣,因為同一家公司的產品,應該會以同樣的方式來處理。
一個C++的程式,只能在C++的編譯器上處理,無法比較。
一個與OO有關的議題,高手A用C++撰寫,高手B用C來撰寫,如果雙方都達成指定的功能時,請問哪一個比較有效率呢?你是想問這個嗎?這個情況會不會有點兒難以評量呢?
C的編譯器比C++的編譯器簡單,應該在最佳化方面佔有優勢,但就如coco兄所說的,火車跟飛機粉難比阿,火車有普通或對號快,飛機有可能會誤點,那高鐵呢?我.....扯到哪裡去了。

作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 上午 11:06:29
這點我也不知道耶!我也是極端落伍了。:(((((

>>>另外有些新功能像是繼承來的virtual function可以傳回跟原宣告不同的形別
>>>比如說
>>這個...我還不知道耶....是不是落伍了 :(
>另外~! 有一點很重要~! 就是coco 大一點也不落伍 :P
作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 上午 11:22:49
是,非virtual的member function本質跟一般的function一樣。

至於提到this指標的overhead,這不是overhead,是比較底下兩段code:

用C++
class CCC
{
    int a;
    int b;
    void func();
};

用C
struct SSS
{
   int a;
   int b;
};
void func(struct SSS* s);


在必要的情況下,哪個overhead大?
如果說傳該struct不是必須的,那class裡面的那個可以設定為static



>>非virtual的member function用起來跟一般的function本質上一樣
>如前所言,是差了一個this指標參數^^
>
>>會損耗c++效能的大部分是動態性的部分跟繼承體系造成的OVERHEAD
>繼承體系造成的OVERHEAD在編譯階段,不是在執行期;
>至於所謂的'動態性',不知是何所指?
>
>>還有一些應該可以避免的呼叫 像是沒做事的constructor跟destructor呼叫等~
>如果constructor跟destructor沒有好處,就不要寫它就成了!
>如之前說的,沒用的東西就不要買!
>
>>另外還有像是非oo的特性,如exception,也要付出一些代價...用 throw()
>>限制EXCEPTION丟出 或是用一些像是new(nothrow)的話 可以增加效能
>>還有最佳化的可能性
>還是那一句話,如果你覺得exception沒用就不要買單!
>exception 是個好東西,要用好東西當然要付代價,但效能要看跟誰比囉。
>C 又沒有 exception 怎麼比....
>
>
>
作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 上午 11:26:21
我猜,動態性只的就是含有virtual的繼承體系的運作狀況。(喔喔喔喔喔,我也寫得出這種模擬兩可,超級有學問的話 ~.-)

由於指標或reference參數可在執行時期決定何者所真正只的物件是哪種class的,所以稱「dynamic binding」,不知道對不對。

>至於所謂的'動態性',不知是何所指?
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 01:58:30
re:長長
>至於提到this指標的overhead,這不是overhead
這麼說沒錯!
C 想要實作相同的功能,就必須pass代表的物件指標給處理函式,
這就是 this ^^

作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 03:02:13
>COCO大 我記得只有全域的static會在一開始被建立
>LOCAL 的確是第一次用到才會變建構 這我記得蠻清楚的 不知道您是在哪看到?
這真得考倒偶了....
應該是在C的書上看到的吧,所以我那句話更正為:C規格上說的....
C++ 只是想當然的推論罷!
至於那一本書,記憶有沒有錯...不要再問了,自己查吧!
老人家的記憶總是可以被原諒的,嘻嘻...

我整理一下我記得的(不保證對),有興趣的人可以翻書並在使用的C++測試對照。
(當然要把結果分享,別藏私喔)

先把幾個名詞澄清一下:
物件:除了類別型態外,基礎型態的變數也是物件
當用宣告一個物件如下:
A aObj= bObj;//A 是一個類別或型態

那麼過程為:
1.配置空間(aObj的記憶體)
2.建構(呼叫 A 的建構子)
3.初始化(指派bObj給A)

我前面說的:靜態的local物件在程式進入主程式之前就會建立
指的是完成第2個過程(建構)。由於 C 沒有建構這回事,所以"建立"就相當於建構完成。
至於 C++,老實說我書讀的不多,怎麼規定的不知道,但編譯器多在進入主程式之前
完成靜態local物件的空間配置。建構則不一定。
那麼靜態local物件何時初始化?這倒是有看過C++書的說明:
在第一次執行到宣告處時才完成初始化(不知Cpp的建立的意思是不是指初始化?)
但 C 則是在進入主程式之前就完成初始化的工作。
(因為 C並沒有建構子的制約,在宣告靜態local物件的函式中初始化有點 stupid)

類別中若有建構子,初始化在函式中為之或有不得不的苦衷,但連基礎型態也在函式
中初始化,真的是笨死了(效率真的輸給C了),所以C++的編譯器,"可能"維持和C
一樣在進入主程式之前就初始化完成。
像MSDN雖是這麼說的:
A local static object or variable is initialized the first time the flow of control
reaches its definition.
但我測試結果VC6還是在進入主程式之前就已完成static local variable(基礎型態物件)
如:
void fun()
{
static staticLocal=1;//這一行並不會有真實的程式碼產生(不能設break point)
//          因為staticLocal的初始化動作已在進入主程式之前完成
:::::::::::::::::::::::
}

終歸一句,C/C++的標準歸標準,編譯器不一定會照單全收,甚至連自己的menu都不
遵循。
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 03:05:19
更正:

void fun()
{
static int staticLocal=1;//這一行並不會有真實的程式碼產生(不能設break point)
//          因為staticLocal的初始化動作已在進入主程式之前完成
:::::::::::::::::::::::
}
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 03:15:46
剛剛好奇的測試自訂沒有建構子的類別物件情況,發現VC6還是在
進入主程式之前就完成static local 物件的初始化工作了:
struct A{
int m_i;
int m_j;
};

void fun(){
static A aa={1,2};//這行初始化在進入main之前就完成了
cout<<aa.m_i<<endl;
}

void main(void){
fun();
}
作者 : tkd(TKD) 人氣指數超過10000點
[ 貼文 144 | 人氣 10153 | 評價 460 | 評價/貼文 3.19 | 送出評價 4 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 03:28:59
coco兄的整理真精彩ㄟ!
我也贊同coco兄的說法。
文獻或書籍上描述的語法的特性及生成
在不同廠牌的Compiler下,不一定會依此實作
是Depend-On Compiler。
^.^
作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 09:28:26
是啊!staic local objects的extent等同於global objects,但scope則同於local objects.

至於初始化,我想不同compiler可以決定要在第一次reference時候才初始化(lazy initialization),還是在一開始就初始化,但是覺得static local objects的初始化在一開始比較就完成比較直覺吧。不曉得用lazy initialization有什麼好處,有人知道的話,請不吝指教,謝謝。


>void fun()
>{
>static int staticLocal=1;//這一行並不會有真實的程式碼產生(不能設break point)
>//          因為staticLocal的初始化動作已在進入主程式之前完成
>:::::::::::::::::::::::
>}
作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 09:30:20
沒有定義constructor的class,compiler會為其定做一個,copy constructor也是如此,但是有時候行為就比較不能預期。這是與static local的兩回事的結論,可以不混為一談。

>剛剛好奇的測試自訂沒有建構子的類別物件情況,發現VC6還是在
>進入主程式之前就完成static local 物件的初始化工作了:
>struct A{
> int m_i;
> int m_j;
>};
>
>void fun(){
> static A aa={1,2};//這行初始化在進入main之前就完成了
> cout<<aa.m_i<<endl;
>}
>
>void main(void){
> fun();
>}
>
作者 : cplusplus(Cpp) C++優秀好手貼文超過500則人氣指數超過10000點
[ 貼文 846 | 人氣 16660 | 評價 1120 | 評價/貼文 1.32 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 11:19:35
>剛剛好奇的測試自訂沒有建構子的類別物件情況,發現VC6還是在
>進入主程式之前就完成static local 物件的初始化工作了:
那就是vc6沒遵守ANSI規範囉~
我剛剛試了vc7是不會有這情形
恩~~ 現在大部分還是要depend on compiler囉~ 規範遵不遵守看個家囉 :)
對了 我想的應該是呼叫CONSTRUCTOR這部分....:) 遇到才呼叫並初始化

另外 TO 長長
不一定沒有constructor 編譯器就會幫你生一個
它認為有需要才生...像COCO大大最後的例子 是不會產生出來的 :)
c++ 的 STANDARD 有說明
為什麼要lazy initialization
簡單說是"避免配置或是花費用不到的資源" 用不到的東西 就先別去花時間用了
這也算是一種執行時期的效率分散分擔吧 :) 不會讓程式一開始的負擔那麼重
作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 11:28:37
對!謝謝你!我懂了。這部分我沒有仔細看ANSI的SPEC,所以。。。

太謝謝了

>另外 TO 長長
>不一定沒有constructor 編譯器就會幫你生一個
>它認為有需要才生...像COCO大大最後的例子 是不會產生出來的 :)
>c++ 的 STANDARD 有說明
>為什麼要lazy initialization
>簡單說是'避免配置或是花費用不到的資源' 用不到的東西 就先別去花時間用了
>這也算是一種執行時期的效率分散分擔吧 :) 不會讓程式一開始的負擔那麼重
>
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 11:30:38
>沒有定義constructor的class,compiler會為其定做一個,
這是C++規格上如此說吧,但編譯器不一定會做什麼。
這麼說也許比較貼於際:
沒有定義constructor的class,compiler”可能”(或需要時)會為其
定做一個。

>copy constructor也是如此,但是有時候行為就比較不能預期。
就看你要預期什麼?default的copy contructor 是memberwise copy 應是
可預期的。
作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/26 下午 11:33:06
答對了!
不愧是coco大大!我看來還要加把勁才行。太多細節沒有真的弄得很清楚。

>>沒有定義constructor的class,compiler會為其定做一個,
>這是C++規格上如此說吧,但編譯器不一定會做什麼。
>這麼說也許比較貼於際:
>沒有定義constructor的class,compiler”可能”(或需要時)會為其
>定做一個。
>
>>copy constructor也是如此,但是有時候行為就比較不能預期。
>就看你要預期什麼?default的copy contructor 是memberwise copy 應是
>可預期的。
作者 : passerx(passer)
[ 貼文 129 | 人氣 2029 | 評價 400 | 評價/貼文 3.1 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 上午 04:25:49
"struct" 有建構子嗎???
如果你改成"class"應該就是第一次reference的時後才會init吧!

>剛剛好奇的測試自訂沒有建構子的類別物件情況,發現VC6還是在
>進入主程式之前就完成static local 物件的初始化工作了:
>struct A{
> int m_i;
> int m_j;
>};
>
>void fun(){
> static A aa={1,2};//這行初始化在進入main之前就完成了
> cout<<aa.m_i<<endl;
>}
>
>void main(void){
> fun();
>}
>
作者 : cplusplus(Cpp) C++優秀好手貼文超過500則人氣指數超過10000點
[ 貼文 846 | 人氣 16660 | 評價 1120 | 評價/貼文 1.32 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 上午 08:15:23
structs in C++ do have constructors...
作者 : tkd(TKD) 人氣指數超過10000點
[ 貼文 144 | 人氣 10153 | 評價 460 | 評價/貼文 3.19 | 送出評價 4 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 上午 09:21:18
VC6.0至VC.NET在特性上已有一定幅度的改變
可以參考以上的網址:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vcrefWhatsNewForVisualCVersion70.asp
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 下午 01:45:40
>"struct" 有建構子嗎???
>如果你改成"class"應該就是第一次reference的時後才會init吧!
在C++中struct和class只有預設Member Access Privileges不同而已。
我的例子使用 struct純為省打 "public:" 而已 ^^

struct A{
:::::::::
};
就等於
class A{
public:
:::::::::
};

class A{
:::::::::
};
就等於
struct A{
private:
:::::::::
};
作者 : daniel(冷眼)討論區板主 VC++優秀好手遊戲程式設計優秀好手DirectX優秀好手C++優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1564 | 人氣 84169 | 評價 6990 | 評價/貼文 4.47 | 送出評價 15 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 下午 02:39:38
其實 這讓我想起 幾年前
2個朋友在吵 誰寫的程式快
一個用組合語言 一個用c++

大家都會認為組合語言一定比較快

其實在簡單的程式 確實如此...
但重點在於..我們那年代的人..(=__= 我65的..只學16bit語法)
沒學mmx 指令集

而c++ 確可以用到64bit 組譯

因為這樣的原因..在大型程式組合語言的 效能(從寫作,執行,除錯..可能不及c++)

以上是個人感覺
作者 : passerx(passer)
[ 貼文 129 | 人氣 2029 | 評價 400 | 評價/貼文 3.1 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 下午 05:31:04

這是在ANSI C++ standard上的嗎?
抱歉我學C++的時候是在7-8年前,那時候還沒release.

BTW. 一般會在C++內用struct都不是拿來當object用的吧!
就我看過的上百個open source projects還沒看過有人在struct內寫建構子或解構子的.
更不用說是virtual之類C++的特性了.(可以在struct內用virtual嗎?)

PS.我只用gcc/g++其他的不太了.


>structs in C++ do have constructors...
作者 : passerx(passer)
[ 貼文 129 | 人氣 2029 | 評價 400 | 評價/貼文 3.1 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 下午 06:01:22
前面離題了.
我想如果你能預測經過compiler之後會變成什麼樣子,那這個問題你應該心裡有數了,
如果不能預測,那去探討programming technology會比較有意義.
作者 : daniel(冷眼)討論區板主 VC++優秀好手遊戲程式設計優秀好手DirectX優秀好手C++優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1564 | 人氣 84169 | 評價 6990 | 評價/貼文 4.47 | 送出評價 15 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 下午 08:24:03
一般會在C++內用struct都不是拿來當object用的吧!
>就我看過的上百個open source projects還沒看過有人在struct內寫建構子或解構子的.
>PS.我只用gcc/g++其他的不太了.

linux 的core 也有類似的東西.....
struct 定義資料型態,為什麼不能有 建構元呢
也可以operator

當然你想加fun也可,不過那就不單純了
建議寫個class 來使用 這struct

單純的接口,我想這是oop的目的之一吧
//!----------------------------------------------------------------------------
/**
 * @brief message struct
 */
typedef struct tagDiMSG
{
    Uint uMsg; // 窗口消息
    WPARAM wParam;
    LPARAM lParam;
    PSTR pStr;
    POint pt;
    void *pPtr;
    //!--------------------------------------------------
    //!
    //!--------------------------------------------------
   tagDiMSG(void): uMsg(MSG_NULL),wParam(0),lParam(0) {};
   tagDiMSG(Uint msg,WPARAM wParam,LPARAM lParam) : uMsg(msg),wParam(wParam),lParam(lParam) {};
   tagDiMSG &operator = (tagDiMSG* pMessage)
   {
  uMsg = pMessage->uMsg;
wParam = pMessage->wParam;
lParam = pMessage->lParam;
pStr = pMessage->pStr;
pt = pMessage->pt;
return *this;
  };
}DiMSG, * LPDMSG;
作者 : archimage(archimage)
[ 貼文 85 | 人氣 5 | 評價 1280 | 評價/貼文 15.06 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 下午 08:35:40

>
>這是在ANSI C++ standard上的嗎?
>抱歉我學C++的時候是在7-8年前,那時候還沒release.
>
>BTW. 一般會在C++內用struct都不是拿來當object用的吧!
>就我看過的上百個open source projects還沒看過有人在struct內寫建構子或解構子的.
>更不用說是virtual之類C++的特性了.(可以在struct內用virtual嗎?)
>
>PS.我只用gcc/g++其他的不太了.

struct是可以有建構式的。(當然也有解構式囉,這應該是ANSI C++的標準)。如coco所說的",在C++中struct和class只有預設Member Access Privileges不同而已"。所以也可以有virtual function(以DirectX來說,如果不是使用C++的話,它是使用struct來描述interface)。像我就常常自己override operator的運算式來做struct的copy,還蠻方便的^^。(gcc/g++也可以使用,我之前開發的軟體就是在windows及linux都可以使用)
其中在討論C or C++那一個效率較好的問題是很複雜的問題。假設你不考慮程式人員的程式設計能力。相同的處理函式,一個在C++(member function),另一個在C語言時,C++由於會需要使用到this pointer來存取相關變數(或是呼叫),所以C++會慢幾個clock...但是在程式架構及軟體重用性來說,C++的OO觀念可以讓開發人員比較簡單且清楚地開發出軟體;若是又加上不同的程式人員的經驗及技巧,就算是相同的演算法,也會因為不同的presentation的方式也會有不同的結果(像是標準c程式碼與MMX/SSE等最佳化的比較,相同的演算法,但是後者在特定機器就是比較快)。
我撰寫程式的時間不太長。但是我的認知裡面,如何寫出一個好的程式是屬於“技術“(skill)(像是套用一些MMX/SSE/SSE2等SIMD instruction)。而往往在軟體開發的過程中,所使用的演算法(或是數學運算式)是影響軟體效能(或是結果)的主要關鍵(image processing或是3d engine algorithm),我會說這算是“知識“(knowledge)。“技術“及“知識“我認為都同等重要,只是我一直自認自己的knowledge不足,所以有些問題一直沒有辦法處理得很好(像是車牌定位/辨識、物件追蹤、super resolution等東西)( 離題了..sorry>.< ),有好的演算法再配上好的程式撰寫技巧才是一個軟體的效率保証。(當然撰寫開發的工具也是同等重要)
作者 : x33333(阿新)
[ 貼文 163 | 人氣 7000 | 評價 400 | 評價/貼文 2.45 | 送出評價 14 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 下午 09:09:47
那以這篇文章來看又要如何是好?
http://www.thepure.org/viewtechdoc.php?WRITERID=gdsoft&DOCID=1
在Framework的架構上 是不是混合語言都能跟編譯語言一樣好
如果一切的平台到時候都如此的話 是不是就沒有效率的問題了?
只有什麼語言適合寫什麼做什麼事了
組合語言寫的執行檔比較小或小很多 那應該效率會更好
請大大發表看法吧!
作者 : archimage(archimage)
[ 貼文 85 | 人氣 5 | 評價 1280 | 評價/貼文 15.06 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 下午 09:34:45

>那以這篇文章來看又要如何是好?
>http://www.thepure.org/viewtechdoc.php?WRITERID=gdsoft&DOCID=1
>在Framework的架構上 是不是混合語言都能跟編譯語言一樣好
>如果一切的平台到時候都如此的話 是不是就沒有效率的問題了?
>只有什麼語言適合寫什麼做什麼事了
>組合語言寫的執行檔比較小或小很多 那應該效率會更好
>請大大發表看法吧!
.net framework真的如他所說那麼神...那麼一堆人就準備要失業囉~~
同樣的方式,你認為java的vm在不同的平台執行時的速度都一樣嗎?我認
為該篇文章所說的只是M$所要達到的目標,但是事實上呢?M$的立意是好
的,不過將基礎打好,等到時機成熟再轉換平台應該不會遇到什麼問題才對。
基礎功要打好才是王道啊!(不論是技術面都是知識都屬基礎功)。否則永遠
只會將軟體開發當作是組裝業(ODM or OEM),而不是真正毛利較高的基礎
元件研發(像是聯發科的光碟驅動元件)。當然這是我個人的看法啦~~
作者 : archimage(archimage)
[ 貼文 85 | 人氣 5 | 評價 1280 | 評價/貼文 15.06 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 下午 10:06:20
補充一下,我印象中當初M$會出.NET Framework不就是要達到跨平台的目的嗎?
頂多只是程式在不同的平台可以執行外(雖然.NET也是會因為不同平台產生所屬的
native code來增加執行效能),你的軟體最終的執行效率也一樣是需要好的程式
架構、所使用的演算法(或稱解決方式)以及程式的撰寫技巧這些因素吧?
作者 : ma_hty(白老鼠(Gary))討論區板主 OpenGL卓越專家DirectX優秀好手C++頂尖高手貼文超過2000則人氣指數超過70000點
[ 貼文 2079 | 人氣 89850 | 評價 9950 | 評價/貼文 4.79 | 送出評價 78 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/27 下午 10:25:22
前一陣子, 因為 .Net Framework 整合了 DirectX 9, 所以就去學
 .Net Framework, 學會了之後, 才發現它實在跑得太慢, 跟本不可
以接受, 最後放棄了.

.Net Framework 的所謂 跨平台, 本來就不是什麼新的東西, 是 JAVA 好幾
年以前就高舉著的旗幟. 而且... 跨的都是 Mic記產品 的平台, 跨?! 還有,
自家產品的平台也弄得不好, 一切的平台實在是太遙遠的事. JAVA 混了這
些年了, 又有多少軟體一舉轉到 JAVA 去呢? 請不要誤會, 不是說 JAVA 的
不是, 只是, 軟體開發, 要考慮的因素實在太多, 跨平台 只是其中之一而已.

記得還在大學的時候, C++的老師常常說的一句話 : 小 不一定 好. 好像是
Bubble Sort 編簡單 理解容易 又小, 難道就會比 Quick Sort 好嗎?!

世事如棋 局局新, 又豈是一兩個技術可以完全的包羅呢? 由初學電腦時, Ram
只有 16 Mega, 到現在動輒也有幾百 Mega; 由 CPU 100 MHz 到 現在 3 GHz;
由最初的 2D Graphic, 到後來 Voodoo 出現, 以至現在可以跑得比 CPU 快好
幾倍的 顯示卡... ... 每一個突破, 都帶來新的機遇, 改變著編程的理念, 會得
應變的, 可以乘流而上呀, 因循而默守成規的, 只好安份守已了. 始終, 編程都
是人的事, 還是別寄望 傳說中魔法一般的技術 好了.
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/28 上午 12:38:35
>前一陣子, 因為 .Net Framework 整合了 DirectX 9, 所以就去學
 >.Net Framework, 學會了之後, 才發現它實在跑得太慢, 跟本不可
>以接受, 最後放棄了.
要跨平台,就要所謂的虛擬機器來達成,java 如此,.Net frame work
還是逃不出如來佛掌心。
所謂虛擬機器戳破了,就是跨平台語言的直譯器(interpreter)。
直譯器程式在先天上就比編譯成機器碼的程式(compiler vs interpreter)
慢(很多)。
跨平台和執行效率本就是魚與熊掌!


作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/28 上午 12:54:01
>為什麼要lazy initialization
>簡單說是"避免配置或是花費用不到的資源" 用不到的東西
>就先別去花時間用了這也算是一種執行時期的效率分散分擔吧 :)
>不會讓程式一開始的負擔那麼重
嗯...但不僅是"不會讓程式一開始的負擔那麼重"
想像一下,程式有好多的含有static物件的函式來處理各種case,而
程式在執行時,並不是所有的case均會碰到(但無法預測誰用不到),
那些用不到的local static 物件,是不是最好到程式結束都不要初始化?
甚至連空間都是最好用到時才動態配置更佳?
 
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/28 上午 02:05:58
>這是在ANSI C++ standard上的嗎?
是!

>抱歉我學C++的時候是在7-8年前,那時候還沒release.
不會吧...只是C++的spec確實改了又改。

>BTW. 一般會在C++內用struct都不是拿來當object用的吧!
在 OO 的觀念,含有資料和函式成員型態的實體固然是物件(object),
只有資料成員的型態的實體還是物件,就算是一個簡單到像:
int a;//<-- a還是物件(即使它只是基礎型態)
那麼一個只有函式成員(沒有資料)型態(類別)的實體(嘿嘿嘿...它有實體嗎?)
算不算是物件?嚴格來說...不算,但廣義來看,還是物件;
就如空字串("")算不算字串?算...是吧,...有點免強啦,反正”沒有東西”也
算是東西吧! ^^
談這些的目的,是要澄清,物件的特癥在資料(成員),不是在函式(方法)。
物件”導向”(oriented)才會觸到操作物件的方法(成員函式)。
所以呢...回到原問題:”般會在C++內用struct都不是拿來當object用的吧”
就算是 C 的struct實體,本來就是物件!只是 C只有”物件”沒有”導向”
所以 C 的struct沒有成員函式。這樣說已夠清礎了吧!^^
所以呢,在C++中既然要把物件”導向”化,把原C的struct擴充成含
有繼承,建構,操作函式...等等的巨獸就是再自然不過的事了!
只是struct因要和C相容,所以成員存取預設需為public,這和OO封裝原則
格格不入,所以才需另加上 class 這個新的關鍵字。

文中的"嘿嘿嘿"注意到了嗎?其實一個沒有資料成員的物件有一些有趣的
課題:它既然沒有實體,呼叫其員函式時需要this嗎?這個留給有興趣的
人去研究。

**延伸題:一個沒有任何資料和函式成員(完全空的)的類別:
class CEmpty{};
CEmpty WhatIam;
//WhatIam算不算是物件?


>就我看過的上百個open source projects還沒看過有人在struct內
>寫建構子或解構子的.
我並沒有鼓勵大家使用struct來代替class的意思。
有沒有人在struct內寫建構子是一件事,但C++能不能在struct內寫建構子
是另一件事,不是嗎?

>更不用說是virtual之類C++的特性了.(可以在struct內用virtual嗎?)
當然可以!
事實上,在C++裡面, class, struct, union 都是類別的關鍵字,程式師都可
以用這三個關鍵字來定義類別!只是union比較特別,它所有的資料成員共用
同一個記憶體,而virtual function會產生資料成員的不速之客:virtual pointer
,這個資料成員不能和其它的資料成員共用記憶體(會天下大亂),所以union
不能有virtual成員。(但我認為這不是絶對的,virtual成員對程式師來說是隱
蔽的,所以union可以有virtual是可能的)。

>PS.我只用gcc/g++其他的不太了
以上所言和gcc/g++相容 ^^
作者 : cplusplus(Cpp) C++優秀好手貼文超過500則人氣指數超過10000點
[ 貼文 846 | 人氣 16660 | 評價 1120 | 評價/貼文 1.32 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/28 上午 03:02:07
local static
這好像不是lazy initialization所指的意思吧 ^^?
作者 : ma_hty(白老鼠(Gary))討論區板主 OpenGL卓越專家DirectX優秀好手C++頂尖高手貼文超過2000則人氣指數超過70000點
[ 貼文 2079 | 人氣 89850 | 評價 9950 | 評價/貼文 4.79 | 送出評價 78 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/28 上午 03:14:14
coco 大大 真的把 C++ 玩得出神入化啊, 好可怕呢...

從沒這麼的深究過這樣的東西, struct 對我來說只是用來簡化 memory
access 的工具, 因為總是下意識的覺得 struct 比較簡單, 變化少會較
容易處理, 但是, 經 coco 大大這麼一說, struct 較簡單的想法原來都是
我一廂情願的想法. 看來, 我真的要把 C 和 C++ 認真的再學一次了.
作者 : kestrel(Kestrel)
[ 貼文 103 | 人氣 198 | 評價 850 | 評價/貼文 8.25 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/28 上午 03:23:56
> 所謂虛擬機器戳破了,就是跨平台語言的直譯器(interpreter)。
> 直譯器程式在先天上就比編譯成機器碼的程式
> (compiler vs interpreter) 慢 (很多)。
> 跨平台和執行效率, 本就是魚與熊掌!

垮平台若要提高速度上的效率, 可以用 IL Code 層級的垮平台, 只要執行它的平台有 IL Code 的編譯執行環境, 就可以跑它了.

因為編譯 IL Code 檔, 要比編譯人寫的 Source 檔要快的多. 故 User 方, 可以忍耐等待 "先編譯、再執行" 的延遲. 這裡說的, 並不是直譯式的一邊譯、一邊執行哦! 而是指全部編譯完成, 再跳去進去執行的方式.

故要跑 IL Code 檔時, 都會先自動編譯成該平台的 Native Code (可以當成機器碼) , 然後再執行.

按書上寫, 其實 .Net 的目標就是如此. 不過為何還是慢像是直譯器的執行現象呢? 其實我也不曉得.

不過現在的 .net 系統, 不知有沒有像如下這樣做:

第一次 run 該 IL Code 檔, 因為就會編譯成該平台的 Native Code 檔了, 那就把產出的檔存起來, 以後再次它執行, 那就不用再編譯了, 直接就跑那個 Native Code 檔, 就可以了.

很有趣的是, 在世上的硬體分佈有一個現象, 就是 x86 相容機為最多, 只有軟體層的系統不同, 故 CPU 看的懂的機械碼, 基本上都是一樣的 (每次想到這一點, 就很爽! 因為早年學過的 x86 組語, 居然還可以繼續用在大多數的機器上.).

所以不管是 Linux, Windows, 或其它 x86 用的系統, 其實硬體都是相容的. 那在世界上, .net 環境至少也要讓 2/3 以上的平台, 先要跑的很順暢吧!

若在光是 x86 的機子上各種軟體系統中, 就已經跑的東倒西歪了, 那就甭談還要去跨非 x86 相容硬體的系統了...
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/29 上午 01:48:17
>local static
>這好像不是lazy initialization所指的意思吧 ^^?
local static 物件在第一次執行到宣告處時執行初始化
不覺得和 lazy initialization 精神是相通的嗎?
其實由程式師來決定static 物件初始化的時機是不錯的想法。
說不定那將來C++會在class和local的static宣告可以加
上 lazy或early的關鍵字呢 !
以上就當笑話吧 ^^
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/29 上午 01:59:16
>垮平台若要提高速度上的效率, 可以用 IL Code 層級的垮平台,
>只要執行它的平台有 IL Code 的編譯執行環境, 就可以跑它了.
只要統一所有平台的API library,寫好的程序要在那個平台跑,就在
那個平台提供的編譯器重新編譯就成了(本來C的可攜性構想不就是如此嗎?)。
只是,這世界這麼好統一,就不會有那麼多的紛爭了^^
有將 Java的byte-code翻成機器碼的,也有人預期會有可直接執行
byte-code 的CPU,但統一之路尚遙遠的很....
作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/29 下午 12:04:52
已經有了可直接執行byte-code的CPU,但是沒有很流行而已。

>有將 Java的byte-code翻成機器碼的,也有人預期會有可直接執行
>byte-code 的CPU,但統一之路尚遙遠的很....
作者 : frankfkc(長長) 程式設計甘苦談卓越專家C++優秀好手貼文超過1000則人氣指數超過50000點
[ 貼文 1148 | 人氣 62194 | 評價 4640 | 評價/貼文 4.04 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/29 下午 12:06:29
在實作compiler為何不可以替local static實作lazy initialization?
^^"

>local static
>這好像不是lazy initialization所指的意思吧 ^^?
作者 : victorlin(VICTOR) 貼文超過200則人氣指數超過10000點
[ 貼文 205 | 人氣 16178 | 評價 340 | 評價/貼文 1.66 | 送出評價 27 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/29 下午 02:16:52
只是路過...一點看法
我是覺得 要比起語言先天上的差異誰比較快
我倒是比較覺來來比演算法和寫法上哪個比較快
前者只差幾個0.00...X
後者差的就比較多了 雖然說演算法有些用起來要用空間換時間
不過也有空間時間都省的

不過現在的硬體進步如此快之下 可能那種差異變得有跟沒有差不多
作者 : rdtsai(rdtsai)
[ 貼文 6 | 人氣 166 | 評價 60 | 評價/貼文 10 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/8/29 下午 04:23:38
C 吧...
快狠準的Language....
作者 : yiha(yiha)
[ 貼文 28 | 人氣 669 | 評價 320 | 評價/貼文 11.43 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/2 上午 11:34:08
一個有點無聊的問題,竟引起這麼多的迴響,這裡還真是熱鬧。雖然對問這個問題的人來說,這些討論可能困難了點,不過能得到這麼多深入的討論也算值回票價了。
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/2 下午 03:13:21
>在實作compiler為何不可以替local static實作lazy initialization?
已經做了(事實上C++已有符合lazy initialization規範),只是
本來的lazy initialization是為了效率考量的技術,但全部照本宣科
的結果有時會適得其反。例如:
void func(...){
static int Localstatic=1;
}

當func若被呼叫很頻繁時,邏輯上Localstatic只被初始化一次,不會影響執行效率的。
但實作上,在func內需有一段程式碼去check Localstatic 是否初始化過。
這時個func被呼叫了一百萬次就會有九十九萬次做了無意義的check。
若Localstatic在進入主程式之前就被初始化,func內就不會有這些無意義的check。
也因如此,所以很多編譯器是case by case 來決定如何初始化 local static variables.
但編譯器再聰明,還是無法很正確的判斷那些 local static variables 應該在進入主程式
之前初始化。所以最好的方式就是程式員可以指定 lazy 或 early,說不定那個制定C++
的官方成員看了coco的建議,下一個版本的C++會加上lazy和early這兩個關鍵字呢^^
作者 : passerx(passer)
[ 貼文 129 | 人氣 2029 | 評價 400 | 評價/貼文 3.1 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/2 下午 06:59:03
現在所有的compiler對於所有基本型態的static變數在compil之後就都已經把那個東西的初始值
放在data segment內了,也就是在run time的時候根本就沒有init這檔事.
只有有建構子的東西才會有lazy init這個事情.

你的程式跟你說的是完全不相干的兩個事情,你真的知道自己在說什麼嗎?


>>在實作compiler為何不可以替local static實作lazy initialization?
>已經做了(事實上C++已有符合lazy initialization規範),只是
>本來的lazy initialization是為了效率考量的技術,但全部照本宣科
>的結果有時會適得其反。例如:
>void func(...){
>static int Localstatic=1;
>}
>
>當func若被呼叫很頻繁時,邏輯上Localstatic只被初始化一次,不會影響執行效率的。
>但實作上,在func內需有一段程式碼去check Localstatic 是否初始化過。
>這時個func被呼叫了一百萬次就會有九十九萬次做了無意義的check。
>若Localstatic在進入主程式之前就被初始化,func內就不會有這些無意義的check。
>也因如此,所以很多編譯器是case by case 來決定如何初始化 local static variables.
>但編譯器再聰明,還是無法很正確的判斷那些 local static variables 應該在進入主程式
>之前初始化。所以最好的方式就是程式員可以指定 lazy 或 early,說不定那個制定C++
>的官方成員看了coco的建議,下一個版本的C++會加上lazy和early這兩個關鍵字呢^^
>
作者 : sunny_gong(simula)討論區板主 C++頂尖高手貼文超過500則人氣指數超過30000點
[ 貼文 892 | 人氣 45047 | 評價 7220 | 評價/貼文 8.09 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/2 下午 08:41:26
>
>你的程式跟你說的是完全不相干的兩個事情,你真的知道自己在說什麼嗎?
>
我是認為,討論程式語言觀念與編譯器技術,是很自由的事情,大家都會有靈光一現、天馬行空的想法,言語之間偶爾會脫逸既有的認知,是難免的事情,但是這並不能抹殺其創意。旁人的一些糾正與提醒,會很有幫助,然而基本上還是以維持個人論點的自由發揮為主。畢竟很難找到哪個中文討論區有在討論程式語言觀念與編譯器做法的,如果大家知道哪裡有這樣的討論區,請不吝提供 ^_^
作者 : epilots(無)
[ 貼文 11 | 人氣 391 | 評價 120 | 評價/貼文 10.91 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/2 下午 08:44:05
加入 lazy和early 關鍵字點子是不錯但沒有必要
假設在 function 內初始,初始後它會在初始起始位址上加上 JMP 指令
這樣就可以確實做到在 function 內初始
經過最佳化發現初始值是常數運算式
function 內的初始無關,就沒必要去做設定
因為它的位址已對應到初始值,也省下 JMP 指令

若是加上 early keyword, 若初值要等到 function 執行才會有初值,那就會產生編譯錯誤
若是加上 lazy keyword, 只是告訴編譯器不要優化去掉初次設定

由於 function 內的 static 變數只在該 function 內使用,並不會造成其他影響
因此,不加 lazy 和 early 比加上更好

>>在實作compiler為何不可以替local static實作lazy initialization?
>已經做了(事實上C++已有符合lazy initialization規範),只是
>本來的lazy initialization是為了效率考量的技術,但全部照本宣科
>的結果有時會適得其反。例如:
>void func(...){
>static int Localstatic=1;
>}
>
>當func若被呼叫很頻繁時,邏輯上Localstatic只被初始化一次,不會影響執行效率的。
>但實作上,在func內需有一段程式碼去check Localstatic 是否初始化過。
>這時個func被呼叫了一百萬次就會有九十九萬次做了無意義的check。
>若Localstatic在進入主程式之前就被初始化,func內就不會有這些無意義的check。
>也因如此,所以很多編譯器是case by case 來決定如何初始化 local static variables.
>但編譯器再聰明,還是無法很正確的判斷那些 local static variables 應該在進入主程式
>之前初始化。所以最好的方式就是程式員可以指定 lazy 或 early,說不定那個制定C++
>的官方成員看了coco的建議,下一個版本的C++會加上lazy和early這兩個關鍵字呢^^
>
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/2 下午 10:42:50
>加入 lazy和early 關鍵字點子是不錯但沒有必要
>假設在 function 內初始,初始後它會在初始起始位址上加上 JMP 指令
>這樣就可以確實做到在 function 內初始
加上JMP指令?程式修改程式?這主意不太好...何況JMP也要執行時間呢。
就PC的程式來說,程式load進來後應是在寫入保護的(這表示程式不應在執行
期變動);
如果程式是燒在ROM上,想在執行期更動,那就得要有特異功能了^^

>經過最佳化發現初始值是常數運算式
>跟 function 內的初始無關,就沒必要去做設定
>因為它的位址已對應到初始值,也省下 JMP 指令
???不懂耶???

>若是加上 early keyword, 若初值要等到 function 執行
>才會有初值,那就會產生編譯錯誤
你是說:等到 function 執行才”能”有初值嗎?競速的問題嗎?
一般來說 local static 物件的競速現象,只有在該物件有自定義的建構子
才會發生。
例如 local static 物件在建構時使用了某個傳輸裝置,而傳輸裝置是在進入
主程式後才備妥和開啟。這時若在進入主程式前建構該local static 物件就會
發生錯誤。
但這種lstatic物件,加了early是程式師的錯誤,不是"early"關鍵字的錯。
編譯器可以預設一些一般初始化的條件,例如有建建構子的local static物件,
在第一次使用時建構和初始化,若是沒有自訂義建構子的物件則預設在主程
式之前建構和初始化。
程式師則根據物件的特性,決定是否使用lazy/early來變更這個預設
(設錯了不能怪編譯器喔)。

作者 : passerx(passer)
[ 貼文 129 | 人氣 2029 | 評價 400 | 評價/貼文 3.1 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 上午 01:49:59

>>
>>你的程式跟你說的是完全不相干的兩個事情,你真的知道自己在說什麼嗎?
>>
>我是認為,討論程式語言觀念與編譯器技術,是很自由的事情,大家都會有靈光一現、天馬行空的想法,言語之間偶爾會脫逸既有的認知,是難免的事情,但是這並不能抹殺其創意。旁人的一些糾正與提醒,會很有幫助,然而基本上還是以維持個人論點的自由發揮為主。畢竟很難找到哪個中文討論區有在討論程式語言觀念與編譯器做法的,如果大家知道哪裡有這樣的討論區,請不吝提供 ^_^

抱歉我無意攻擊任何人,
我只是覺得說得跟寫出來的程式不一樣,
討論不但會變成沒有意義,而且會變成誤導.
我提供一個經驗好了,
不久前跟同事在討論事情,聊到一個程式有一段如下:

const char *str = "abcde";

其中一個同事說在run-time的時候str會"自動"alloc一塊memory然後把"abcde" copy
進去,不用的時候就"自動"free掉,我當場心中os,並反駁他,但是另外一個同事
居然說在書上(忘了問是哪一本)是前一位同事說得那樣.最後當然是寫個程式証明書上是錯
的.
作者 : sunny_gong(simula)討論區板主 C++頂尖高手貼文超過500則人氣指數超過30000點
[ 貼文 892 | 人氣 45047 | 評價 7220 | 評價/貼文 8.09 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 上午 03:01:32
瞭解,passer兄。因為很難得有這樣的討論串,所以希望大家不要太拘束於技術細節與既有觀念,自由的討論下去,讓腦袋奔馳一下...Free Your Mind...一些小小的錯誤,譬如舉例不當,是無傷大雅的,這只需要加以指明即可。希望大家以後都不用躲子彈...因為...You Don't Need To...看到 Agent Smith 就跟他拼下去...
作者 : seanchang(H) Assembly卓越專家貼文超過1000則
[ 貼文 1200 | 人氣 773 | 評價 3240 | 評價/貼文 2.7 | 送出評價 43 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 上午 09:52:08
>其實 這讓我想起 幾年前
>2個朋友在吵 誰寫的程式快
>一個用組合語言 一個用c++
>大家都會認為組合語言一定比較快
>其實在簡單的程式 確實如此...
>但重點在於..我們那年代的人..(=__= 我65的..只學16bit語法)
>沒學mmx 指令集
>而c++ 確可以用到64bit 組譯
>因為這樣的原因..在大型程式組合語言的 效能(從寫作,執行,除錯..可能不及c++)
>以上是個人感覺
演算法的效能一樣的時候,是不會有任何語言的效能超過組合語言的,而其關鍵是在於程式師對CPU指令的熟悉度,用高階語言是compiler幫你熟悉CPU指令而已,這是事實.組合語言不太合適寫複雜的程式,這也是事實.組語除錯的複雜度取決於程式師對'資料'結構的設計複雜與否.
至於64 bits編譯,對 32/16/8 bits CPU來說寫組語一樣可以達成.只是compiler會幫忙做的事情,組語必須自己寫好,或有人提供.請不要忘了最重要的一件事,程式語言的對象是'人',不是機器,對CPU而言,它只處理那些二進位編碼而已.



作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 上午 11:42:16
>現在所有的compiler對於所有基本型態的static變數在compil之後
>就都已經把那個東西的初始值
>放在data segment內了,也就是在run time的時候根本就沒有init這檔事.
>只有有建構子的東西才會有lazy init這個事情.
"所有基本型態的static變數在compil之後就都已經把那個東西的初始值
放在data segment內"
那還是叫”進入主程之前初始化”!^^
所以,我應該知道我在說什麼吧@^(沒有口水戰之意,玩笑話別介意)

或許在你試的compiler是這樣,
但是不是”現在所有的compiler”都這樣做,是有很大疑問的。
例如說一個 embeded system 用途的compile,最後的程式碼是燒在ROM裡。
程式中寫了
static int i=1;//不論是local或global
int j=2;//global 變數的初始化
i,j當然是在RAM區(可讀寫),編譯器如何”在compil之後就都已經把那個東西的
初始值放在data segmen”?當然是不可能的任務!
編譯器唯一可以做的是把初始化的工作寫成程式和user的程式放在一起燒成ROM。
在進入主程式之前要先執行初始化(把1寫入i,2寫入j),這段程式通常叫 startup。
無論是把初始化data直接放在資料區或在statup時用程式寫入,通用的定義都是
在進入主程式之前初始化,只有討論到某個編譯器時才會討論到該編譯器是否直接
把初始化data直接放在資料區(在embeded system不可能)。

 


作者 : epilots(無)
[ 貼文 11 | 人氣 391 | 評價 120 | 評價/貼文 10.91 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 上午 11:56:16

>>加入 lazy和early 關鍵字點子是不錯但沒有必要
>>假設在 function 內初始,初始後它會在初始起始位址上加上 JMP 指令
>>這樣就可以確實做到在 function 內初始
>加上JMP指令?程式修改程式?這主意不太好...何況JMP也要執行時間呢。
>就PC的程式來說,程式load進來後應是在寫入保護的(這表示程式不應在執行
>期變動);
>如果程式是燒在ROM上,想在執行期更動,那就得要有特異功能了^^
>
>>經過最佳化發現初始值是常數運算式
>>跟 function 內的初始無關,就沒必要去做設定
>>因為它的位址已對應到初始值,也省下 JMP 指令
>???不懂耶???
>
>>若是加上 early keyword, 若初值要等到 function 執行
>>才會有初值,那就會產生編譯錯誤
>你是說:等到 function 執行才”能”有初值嗎?競速的問題嗎?
>一般來說 local static 物件的競速現象,只有在該物件有自定義的建構子
>才會發生。
function 引述,提出早期初始是優化,晚期初始是預設
可以早到當然隨意,不可早到偏偏早到是自找
寧願顯示警告提示或錯誤產生是一種鹽井的態度,我可沒否定
競速是因為物件與非物件同時使用才會產生的問題

>例如 local static 物件在建構時使用了某個傳輸裝置,而傳輸裝置是在進入
>主程式後才備妥和開啟。這時若在進入主程式前建構該local static 物件就會
>發生錯誤。
>但這種lstatic物件,加了early是程式師的錯誤,不是'early'關鍵字的錯。
>編譯器可以預設一些一般初始化的條件,例如有建建構子的local static物件,
>在第一次使用時建構和初始化,若是沒有自訂義建構子的物件則預設在主程
>式之前建構和初始化。
>程式師則根據物件的特性,決定是否使用lazy/early來變更這個預設
>(設錯了不能怪編譯器喔)。
>
不管是否在進入主程式後才備妥和開啟不打緊
主程式 Main 並不是影響物件初始的因素
主要是物件初始的順序無法決定造成的

要解決非常簡單
只要在物件的建構子裡做 Check and Load
將需要的物件一併載入初始即可
要不然建構子是用假的嗎???

>
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 下午 02:49:45
>不管是否在進入主程式後才備妥和開啟不打緊
>主程式 Main 並不是影響物件初始的因素
>要解決非常簡單
>只要在物件的建構子裡做 Check and Load
>將需要的物件一併載入初始即可
>要不然建構子是用假的嗎???
不是能不能解決的問題,而是規格問題。
C++規定static物件的初始化在進入主程式之前,目的就是要
程式師知道static物件的初始化是在那一個階段。也是因為有了規定
才有你所謂的解決和規定不合問題。
編譯器不管是為了什麼原因,改變了C++的規格(例如沒有建構子的local static物件,
初始化在主程式之前),但都要保證,程式師依標準規格去思考程式的邏輯不會有問題
才可。

>主要是物件初始的順序無法決定造成的
這是另外的一個議題?

很抱歉原議題似乎由於我的隨興多寫幾個字,討論似乎有點漫天亂流。
本來只是很”順便”的舉了一個static的例子,結果引發了static何時初始化
的議論紛紛,為了省打”public”而用struct代替了class,結果又引發了
class和struct的爭論。
多次有人在文中論及 lazy initialization,本來我也覺得”lazy initialization”冒得
有點突兀,但後來想,咦!local static 的議題和”lazy initialization”的精神不無相
合之處,就用它舉例來回應lazy initialization,怎知又是一場混亂。
為了不想定義一個類別,所以用了 static int i; 在程式
中,結果又引發了基礎型態的static 物件的初始化資料編譯完成後就含在資料區中
(不經程式初始化)算不算”進入主程式之前”初始化之爭....真是一敗塗地。

我想....這個討論議題是不是就打住了?
”物件初始的順序”若有人覺得這議題有興趣,就另開一個議題吧
,再此我就不談了,免得一個議題搞得像是一個討論區^^
作者 : epilots(無)
[ 貼文 11 | 人氣 391 | 評價 120 | 評價/貼文 10.91 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 下午 04:17:59

>>不管是否在進入主程式後才備妥和開啟不打緊
>>主程式 Main 並不是影響物件初始的因素
>>要解決非常簡單
>>只要在物件的建構子裡做 Check and Load
>>將需要的物件一併載入初始即可
>>要不然建構子是用假的嗎???
>不是能不能解決的問題,而是規格問題。
>C++規定static物件的初始化在進入主程式之前,目的就是要
>程式師知道static物件的初始化是在那一個階段。也是因為有了規定
>才有你所謂的解決和規定不合問題。
>編譯器不管是為了什麼原因,改變了C++的規格(例如沒有建構子的local static物件,
>初始化在主程式之前),但都要保證,程式師依標準規格去思考程式的邏輯不會有問題
>才可。

第一次見到有人不承認建構子是 C++ 語言規格,用繼承可以吧!
GCC編譯器對 UNICODE 字元的轉換竟然是將 ASCII 碼擴展成兩碼
不是直接轉成 UNICODE 字元碼,這樣才有解決的考量
直接從規格著手算不上解決,只是沒想到可以這樣用而已!
事實上繼承就是替你解決這樣的問題
繼承和建構子可不是我自創的,在制定規格時就已經思考過了
你不用是自己的事卻妄想加入關鍵字早已違背規格
在說別人之前,先看看自己回應的文章吧!
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 下午 06:10:21
re:無
先喝杯冰水,降降火氣^^

>第一次見到有人不承認建構子是 C++ 語言規格,用繼承可以吧!
我沒有這樣說,如果有那一句話讓你這樣的大誤解,請指明,我改進我
的國文。

>GCC編譯器對 UNICODE 字元的轉換竟然是將 ASCII 碼擴展成兩碼
>不是直接轉成 UNICODE 字元碼,這樣才有解決的考量
>直接從規格著手算不上解決,只是沒想到可以這樣用而已!
>事實上繼承就是替你解決這樣的問題
恕老人家愚昧,不知你在討論什麼...唔..我也好像沒有問題要解決^^

>繼承和建構子可不是我自創的,在制定規格時就已經思考過了
這個嘛...我雖然所學不多,但我也知道^^

>你不用是自己的事卻妄想加入關鍵字早已違背規格
唉...我沒忘想症啦,說到加入lazy/early那篇文章不是聲明”以上就當笑話”嗎?
也不知為什麼大家就死抓著它討論了。很抱歉讓你看得不爽,請自行把它丟到垃圾
桶吧。

>在說別人之前,先看看自己回應的文章吧!
我看了...但我好像除了就事論事之外,沒說別人怎樣啊!!
有的話,請指明,我陪不是。但若是討論議題火氣太大,偶就不回應了...


作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 下午 06:15:04
>唉...我沒忘想症啦,說到加入lazy/early那篇文章不是聲明”以上就當笑話”嗎?
自己回應自己^^
發瘋的人總覺自己沒有發瘋。
說不定我真的得了”忘想症”而不自知,晚卜找一下心理醫生聊聊,呵呵呵...
作者 : archimage(archimage)
[ 貼文 85 | 人氣 5 | 評價 1280 | 評價/貼文 15.06 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 下午 06:37:44

>>唉...我沒忘想症啦,說到加入lazy/early那篇文章不是聲明”以上就當笑話”嗎?
>自己回應自己^^
>發瘋的人總覺自己沒有發瘋。
>說不定我真的得了”忘想症”而不自知,晚卜找一下心理醫生聊聊,呵呵呵...
>
為什麼這一個討論到最後會變成這樣....我認為這有需要搞到火氣這麼大嗎?每個人有每
個人的立場,大家討論與此主題相關的問題即可,不同主題或許可以開另一個主題讓大
家一起討論。當然我程度比較低..lazy/early的問題我並沒有深入地研究過(我甚至沒有
去思考是何時被init.,我還一直以為它一開始就跟global variable..),我遇到比較細節
的問題時,都是去翻所編譯出來的asm來看的,因為我一直以為規格是規格,實作是實
作...
看到各位大師的討論,才知道自己的渺小..受教了.
作者 : ma_hty(白老鼠(Gary))討論區板主 OpenGL卓越專家DirectX優秀好手C++頂尖高手貼文超過2000則人氣指數超過70000點
[ 貼文 2079 | 人氣 89850 | 評價 9950 | 評價/貼文 4.79 | 送出評價 78 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/3 下午 08:02:48
>第一次見到有人不承認建構子是 C++ 語言規格,用繼承可以吧!
>GCC編譯器對 UNICODE 字元的轉換竟然是將 ASCII 碼擴展成兩碼
>不是直接轉成 UNICODE 字元碼,這樣才有解決的考量
>直接從規格著手算不上解決,只是沒想到可以這樣用而已!
>事實上繼承就是替你解決這樣的問題
>繼承和建構子可不是我自創的,在制定規格時就已經思考過了
>你不用是自己的事卻妄想加入關鍵字早已違背規格
>在說別人之前,先看看自己回應的文章吧!
>

re: 無
coco 大大 的 C 和 C++ 強得很呢... 要找碴的話, 你... 找錯人了...
作者 : epilots(無)
[ 貼文 11 | 人氣 391 | 評價 120 | 評價/貼文 10.91 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/4 上午 08:00:44

>>第一次見到有人不承認建構子是 C++ 語言規格,用繼承可以吧!
>>GCC編譯器對 UNICODE 字元的轉換竟然是將 ASCII 碼擴展成兩碼
>>不是直接轉成 UNICODE 字元碼,這樣才有解決的考量
>>直接從規格著手算不上解決,只是沒想到可以這樣用而已!
>>事實上繼承就是替你解決這樣的問題
>>繼承和建構子可不是我自創的,在制定規格時就已經思考過了
>>你不用是自己的事卻妄想加入關鍵字早已違背規格
>>在說別人之前,先看看自己回應的文章吧!
>>
>
>re: 無
>coco 大大 的 C 和 C++ 強得很呢... 要找碴的話, 你... 找錯人了...
>
這算找碴未免不分是非了
我建議 coco 大大用建構子, 他說那不是規格
我說是規格, 並另外建議用繼承
作者 : sunny_gong(simula)討論區板主 C++頂尖高手貼文超過500則人氣指數超過30000點
[ 貼文 892 | 人氣 45047 | 評價 7220 | 評價/貼文 8.09 | 送出評價 108 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/4 上午 08:29:59
已經變成羅生門了,這篇討論就此打住吧。
作者 : sunyear(coco) VC++卓越專家C++頂尖高手貼文超過2000則
[ 貼文 2294 | 人氣 1485 | 評價 5850 | 評價/貼文 2.55 | 送出評價 5 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人loveorc2003註記此篇回應為最佳解答 2004/9/4 上午 09:58:18

>我建議 coco 大大用建構子, 他說那不是規格
>我說是規格, 並另外建議用繼承
這裡的貼文又不能更改,證據都在
我說了:
*請把我那裡說過這樣的話”原文照貼”出來,我賠不是!
*請把我那裡說過這樣的話”原文照貼”出來,我賠不是!
*請把我那裡說過這樣的話”原文照貼”出來,我賠不是!
(學陳X豪的^^)
我沒說過話,請勿重覆放送,否則連老人家也要按奈不住的.

re:板大
>已經變成羅生門了,這篇討論就此打住吧。
贊成!
作者 : loveorc2003(BK.) Visual Basic優秀好手新手入門優秀好手一般優秀好手貼文超過1000則人氣指數超過200000點
[ 貼文 1381 | 人氣 206151 | 評價 2670 | 評價/貼文 1.93 | 送出評價 712 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/8 上午 12:08:27
我是這篇文章的發文者,看到這大家這熱烈的討論,還蠻開心的,即使已偏離主題討論,但是我可以從大家討論的過程中,獲取更多的技術概念,雖然在討論的過程中,難免會跟其他人的意見看法不一樣,可能事實只有一個,也有可能是一體兩面,不管怎樣,藉由討論,都會提升技術上的概念,即使討論到最後發現是自己的看法想法是錯了,我想收穫也一定比別人還多,另外在討論的時候,講到激動處難免會有一些情緒上發洩的字眼,雖然是人之常情,但是也要盡量多多的避免,不然大家可能會誤會你^^,最後我還蠻希望這篇討論有一個完美的句點,不然感覺好像有使無終的感覺,此外我總覺得台灣的論壇總比不過國外,或者是大陸的論壇,但是我發現在討論的人都是有一定程度的程式高手,希望這些程式高手能再互先切磋,讓這裡成為技術的天堂
作者 : loveorc2003(BK.) Visual Basic優秀好手新手入門優秀好手一般優秀好手貼文超過1000則人氣指數超過200000點
[ 貼文 1381 | 人氣 206151 | 評價 2670 | 評價/貼文 1.93 | 送出評價 712 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/15 下午 09:48:12
最近看到一些防火牆的原始碼是用C寫的,可能C比較快一點..........
作者 : jbinchiu(bin)
[ 貼文 5 | 人氣 153 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/8/18 上午 09:40:10
對阿 就此打住吧
作者 : hingdani(錢大娘)
[ 貼文 12 | 人氣 328 | 評價 20 | 評價/貼文 1.67 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/8/26 下午 03:13:45
引自Thinking in C++
Chapter1

Performance issues
A common question is, “Doesn’t OOP automatically make my programs a lot bigger and slower?” The answer is, “It depends.” Most traditional OOP languages were designed with experimentation and rapid prototyping in mind rather than lean-and-mean operation. Thus, they virtually guaranteed a significant increase in size and decrease in speed. C++, however, is designed with production programming in mind. When your focus is on rapid prototyping, you can throw together components as fast as possible while ignoring efficiency issues. if you’re using any third party libraries, these are usually already optimized by their vendors; in any case it’s not an issue while you’re in rapid-development mode. When you have a system that you like, if it’s small and fast enough, then you’re done. if not, you begin tuning with a profiling tool, looking first for speedups that can be done with simple applications of built-in C++ features. if that doesn’t help, you look for modifications that can be made in the underlying implementation so no code that uses a particular class needs to be changed. Only if nothing else solves the problem do you need to change the design. The fact that performance is so critical in that portion of the design is an indicator that it must be part of the primary design criteria. You have the benefit of finding this out early using rapid development.


As mentioned earlier, the number that is most often given for the difference in size and speed between C and C++ is ±10%, and often much closer to par. You might even get a significant improvement in size and speed when using C++ rather than C because the design you make for C++ could be quite different from the one you’d make for C.


作者 : hingdani(錢大娘)
[ 貼文 12 | 人氣 328 | 評價 20 | 評價/貼文 1.67 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/8/26 下午 03:15:41

詳細內容請參考http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html#HTMLFormat

The evidence for size and speed comparisons between C and C++ tends to be anecdotal and is likely to remain so. Regardless of the number of people who suggest that a company try the same project using C and C++, no company is likely to waste money that way unless it’s very big and interested in such research projects. Even then, it seems like the money could be better spent. Almost universally, programmers who have moved from C (or some other procedural language) to C++ (or some other OOP language) have had the personal experience of a great acceleration in their programming productivity, and that’s the most compelling argument you can find.

作者 : goldenhydra(vindy)
[ 貼文 115 | 人氣 1386 | 評價 460 | 評價/貼文 4 | 送出評價 8 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/9/13 上午 12:46:23
哪個跑得快,有那麼難嗎?以下面的這一段為例.

for(int i = 0; i < n ; i++) {
   doSomething() ;
}

假設 - 在 c 下 doSomething() 是一般的函式, 在 c++ 下是虛擬函式.
單純就效率而言, 請問是 c 跑得快, 還是 c++ 跑得快啊 ? 答案應該是很清楚的.儘管如此...也不能全盤否定 c++ 的好處啊.
作者 : avhacker(av) C++優秀好手貼文超過200則
[ 貼文 217 | 人氣 100 | 評價 1090 | 評價/貼文 5.02 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/9/13 上午 02:13:33
就算是 virtual function, 若不透過 reference 或 pointer 來呼叫,那效率與 non virtual function 是完全一樣的。
何況如果一個 function 要設計程 virtual, 就是為了在執行期決定行為,而同樣的需求用 C 來做,整體的效率與維護成本很可能更高。

>哪個跑得快,有那麼難嗎?以下面的這一段為例.
>
>for(int i = 0; i < n ; i++) {
> doSomething() ;
>}
>
>假設 - 在 c 下 doSomething() 是一般的函式, 在 c++ 下是虛擬函式.
>單純就效率而言, 請問是 c 跑得快, 還是 c++ 跑得快啊 ? 答案應該是很清楚的.儘管如此...也不能全盤否定 c++ 的好處啊.
作者 : goldenhydra(vindy)
[ 貼文 115 | 人氣 1386 | 評價 460 | 評價/貼文 4 | 送出評價 8 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/9/15 上午 02:01:24
我個人的觀點是 C++ 是 C 的延伸,不管如何的好用終究是 C 的延伸.終究受制於 C 的極限.所謂的物件導向也不過是把原本是人做的事,由編譯程式代為完成而己.可以去享受它的美好,但不用太去推崇.
作者 : andytgc(Andy)
[ 貼文 1 | 人氣 1 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/10/7 下午 05:15:26
C 吧.....
因为simple to process so faster.....
但是如没C++,program can be hard to write and big by only using C.....
作者 : kiko4522(MilkPig)
[ 貼文 1 | 人氣 1 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/12/19 下午 05:03:01
都蠻好的阿~只要你會寫的話....
作者 : frank007love(滴可明)
[ 貼文 65 | 人氣 9082 | 評價 20 | 評價/貼文 0.31 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/12/19 下午 09:09:08
C吧
作者 : taiwanhau(努力學習中的皓皓)
[ 貼文 1 | 人氣 7 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2006/1/20 上午 09:49:55
I think is C .. but it is really meaningless!
作者 : carlfeynman(CarlFeynman)
[ 貼文 17 | 人氣 616 | 評價 0 | 評價/貼文 0 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2006/1/23 下午 08:58:44
基本上這個主題沒有意義吧,除了程式設計師本身的功力,還要看你是使用什麼編譯器,還有怎樣針對程式碼作最佳化。
作者 : skyzone(skyZone)
[ 貼文 7 | 人氣 230 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2006/4/3 下午 04:11:37
看你用在那個平台,和資源吧
作者 : jopher(jopher)
[ 貼文 8 | 人氣 977 | 評價 10 | 評價/貼文 1.25 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2006/9/27 下午 02:13:35
當兩者執行最後總計速度差別在 0.01秒 時, 您認為效率比較有意義嗎?
但就開發應用程式的效率來考慮(同一人), 尤其是越大型程式時, 則 C++的效率倍於C .
知道了嗎 !
真正能帶給人方便的程式, 絕大部份都是中大程式.
作者 : openmind(openmind)
[ 貼文 164 | 人氣 645 | 評價 230 | 評價/貼文 1.4 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2006/9/29 下午 04:37:05
如果是比執行效率,毫無疑問 C 勝過 C++,即使是相同的演算法
( The Practice of Programming, Programming Pearls 等大師
寫的書早做出證明)

但是若以開發效率來比,C++勝過C,其中的關鍵因素就是STL,
其中的關鍵就是解決了C記憶體管理問題,C++ TR1加入了更強更豐富的
library,相反的C語言幾十年來 RTL 幾乎沒有變化。任何一個現代
程式語言沒有豐富的standard lib可以說不用混了。

但是C在firmware上還會有一席之地就是了
作者 : ma_hty(白老鼠(Gary))討論區板主 OpenGL卓越專家DirectX優秀好手C++頂尖高手貼文超過2000則人氣指數超過70000點
[ 貼文 2079 | 人氣 89850 | 評價 9950 | 評價/貼文 4.79 | 送出評價 78 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2006/9/29 下午 11:57:51
>如果是比執行效率,毫無疑問 C 勝過 C++,即使是相同的演算法
>( The Practice of Programming, Programming Pearls 等大師
>寫的書早做出證明)
>

這個論題很久以前已經有了明確的答案, 已經再沒什麼可以討論的空間. 結論就是, 只要使用正確, 用 C 也好 或是 用 C++ 也好, 編譯出的程式執行效率是並沒分別的. 細心的爬爬文吧.

讓人們產生 "C++執行效率較差" 這個錯覺的原因, 是沿自那些 大量流傳著 設計不良 的 C++ 範例. 而設計不良的範例較多, 是因為正確使用 C++ 的學識需求 遠遠較 C 為高, 就只是這樣而已.

再強調一次 "只要正確的使用, 兩者是並無差別".

提提你, 有些參與這個討論的人, 會只為保護自己的意見而作沒理據的反駁, 使討論彌漫著一種漫談的氣氛, 學術只有是非, 並沒情感的, 討論時, 最好不要投人過多的個人情感.
作者 : yinglung(CoolLong)
[ 貼文 107 | 人氣 2565 | 評價 150 | 評價/貼文 1.4 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2007/12/22 下午 12:30:45
兩者無法拿來比較

純粹是看你整個程式的架構是走那一方面的

用OO 那就拿C++

沒用OO 那就拿C
(如 os kernel )

作者 : bensontan(Benson) 貼文超過1000則人氣指數超過30000點
[ 貼文 1054 | 人氣 40462 | 評價 3290 | 評價/貼文 3.12 | 送出評價 80 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2007/12/22 下午 08:42:31
偶其實不贊同兩者並無分別~ 因為大家沒有討論到 "非正常使用" 的部份~

char MyProgram[1000];

void (*funptr)();

void dynamicLoader()
{
    memcpy(MyProgram, mycode, 1000);
    funptr = (void (*)())MyProgram;
}

在 Turbo C之類的舊式 C語言裡可以用強制型別轉換把A轉成B, 甚至可以
把一些函式 dynamic replace, 這在之後的C++的 compiler 都會成為bug,
而無法支援~

因此, 如果你能dynamic load你的程式 (再加上自動常駐), 你的效率自
然會比C++好~
作者 : franklin(doggie) C++優秀好手
[ 貼文 156 | 人氣 11 | 評價 750 | 評價/貼文 4.81 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2007/12/22 下午 09:00:05
> 在 Turbo C之類的舊式 C語言裡可以用強制型別轉換把A轉成B
c++也可以喔

funptr = reinterpret_cast< (void (*)())>MyProgram;

c++的效能會比較差的原因是它偷偷多做了很多事
而不是什麼事它不能做
作者 : franklin(doggie) C++優秀好手
[ 貼文 156 | 人氣 11 | 評價 750 | 評價/貼文 4.81 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2007/12/22 下午 10:24:50
寫的不太對
正確寫法應該是

typedef void (*FuncPtr)();

funptr = reinterpret_cast< FuncPtr>( MyProgram);

作者 : little23(little23)
[ 貼文 27 | 人氣 3168 | 評價 0 | 評價/貼文 0 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2008/1/4 下午 07:43:33
可以解釋一下嗎?
作者 : pluto0327(請多指教)
[ 貼文 58 | 人氣 7697 | 評價 10 | 評價/貼文 0.17 | 送出評價 14 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2008/1/8 下午 02:10:41
印象中~學校老師說~ 看程式設計師的功力!@@
 板主 : simula
 > C++ - 討論區
 - 最近熱門問答精華集
 - 全部歷史問答精華集
 - C++ - 知識庫
  ■ 全站最新Post列表
  ■ 我的文章收藏
  ■ 我最愛的作者
  ■ 全站文章收藏排行榜
  ■ 全站最愛作者排行榜
  ■  月熱門主題
  ■  季熱門主題
  ■  熱門主題Top 20
  ■  本區Post排行榜
  ■  本區評價排行榜
  ■  全站專家名人榜
  ■  全站Post排行榜
  ■  全站評價排行榜
  ■  全站人氣排行榜
 請輸入關鍵字 
  開始搜尋
 
Top 10
評價排行
C++
1 Raymond 12600 
2 simula 4690 
3 青衫 4670 
4 coco 3900 
5 白老鼠(Gary) 3610 
6 Ben 2250 
7 ozzy 2010 
8 Anderson 1960 
9 windblown 1650 
10 Kenny 1540 
C++
  專家等級 評價  
  一代宗師 10000  
  曠世奇才 5000  
  頂尖高手 3000  
  卓越專家 1500  
  優秀好手 750  
Microsoft Internet Explorer 6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2014 程式設計俱樂部 http://www.programmer-club.com.tw/
0.609375