|
2017/12/26 下午 03:48:05
相對於靜態多型就是一般較多使用的的動態多型,如:
class Base { public: virtual void f() = 0; };
class Derived :public Base { virtual void f() override { } public: };
若改為靜態多型可能會像以下這樣:
template<typename DERIVED> class Base { public: void f() { static_cast<DERIVED*>(this)->f_Imp(); } };
class Derived :public Base<Derived> { void f_Imp() { } public:
friend class Base<Derived>; };
將原本呼叫虛擬成員函數,變成呼叫一般成員函數,這樣子速度上會快上許多,這才叫 殺 很 大(借用郭書瑤的成名廣告詞)
但...且慢,若你想以後用靜態多型來代替動態多型,或想把以前寫的動態多型改為靜態多型,那你一定會碰一鼻子灰,因兩者是無法互相取代不相干的兩件事。
主要的差異是動態多型是用於 Base 這個使用角度,而靜態多型則用於 Derived 的使用角度,你無法用靜態多型的 Base 去宣告一個變數,一定要加上 Derived 類別,像這樣 Base<Derived>。
所以使用靜態多型就得先了解使用情境:
1. 使用的角度須是 Derived 2. 有兩個以上的 Derived 有共同功能,可以提出來做成 Base 3. 若 Base 須要呼叫 Derived 的功能時就可以做成 靜態多型 了
|
|
|
2017/12/26 下午 04:59:00
關於OOP呢, 適可而止好了. 基本的OOP句法, 尚且已是要極克制地使用. 這前題之下, 竟然對著OOP句法耍小聰明把戲啊.
這豈不是在介紹 "倒立過馬路的好處和注意事項" 嗎 ?
|
|
|
2017/12/26 下午 06:34:26
>關於OOP呢, 適可而止好了. 基本的OOP句法, 尚且已是要極克制地使用. >這前題之下, 竟然對著OOP句法耍小聰明把戲啊. > >這豈不是在介紹 '倒立過馬路的好處和注意事項' 嗎 ?
這種東西在大一點的專案中還是常會看到的,最好還是了解一下
|
|
|
2017/12/27 上午 12:09:15
> >>關於OOP呢, 適可而止好了. 基本的OOP句法, 尚且已是要極克制地使用. >>這前題之下, 竟然對著OOP句法耍小聰明把戲啊. >> >>這豈不是在介紹 '倒立過馬路的好處和注意事項' 嗎 ? > >這種東西在大一點的專案中還是常會看到的,最好還是了解一下
-_-'' , 如果你想拼工作履歷的話, 你私下寄一個電郵給我, 我把履歷寄你吧. (真是的...)
編程式, 熟輕熟重, 我細數一下. 要易讀易懂, 方便除錯, 方便重組, 高階管理友善...
OOP, 需要用, 合適用, 就用吧. 不過, 用OOP, 一般也不是好主意. *o*y--~cC ... 就拿婚姻作個比喻吧.
OOP 就似結婚, 結婚好不好? 這... 它本意是好, 不過, 少男少女 熱戀一下 就說要結婚, 一般也不是好主意. 就算是成年人, 打著人有我有的心態結婚, 也不是好主意.
為啥不是好主意? 結婚了, 就會以它為基礎 函生各式關係, 然後 千絲百結 糾纒不清. 如果, 這段結婚關係挺得過挑戰 又跟其他關係 磨合得好, 好 好 好, 最好不過了. 可是... 反過來的話... (說得太白就囉嗦了, 自得啄磨一下吧)
|
|
|
2017/12/27 上午 09:41:56
> >-_-'' , 如果你想拼工作履歷的話, 你私下寄一個電郵給我, 我把履歷寄你吧. (真是的...) > >編程式, 熟輕熟重, 我細數一下. 要易讀易懂, 方便除錯, 方便重組, 高階管理友善... > >OOP, 需要用, 合適用, 就用吧. 不過, 用OOP, 一般也不是好主意. >*o*y--~cC ... 就拿婚姻作個比喻吧. >
這並不是什麼新東西,上網也能查得到,只是大多著重在技術解說,我只是在使用精神上補充說明而已
|
|
|
2017/12/27 上午 11:39:38
>這並不是什麼新東西,上網也能查得到,只是大多著重在技術解說,我只是在使用精神上補充說明而已 >
@@? 我上面說的,是在說 OOP,並不是好東西,要適可而止。不應用嗎?非也,只是每一步OOP都是影響深遠的決定,不宜倉猝行事。另外,像你這樣,輕率而求句法複雜,是錯。
|
|
|
2017/12/27 下午 02:38:05
「簡單即是美;簡單即是好!」
我想這大概就是 Kenneth Thompson 和 Dennis Ritchie 在結束 Multics 專案後的最重要感想吧!
你看像 Java,它在誕生之初就拋棄了許多在原來 C++ 上強大高效的特性,全部使用虛函式、全部物件都在 heap 上、沒有多重繼承、沒有全域變數……等等。
|
|
|
2017/12/27 下午 02:38:19
>>這並不是什麼新東西,上網也能查得到,只是大多著重在技術解說,我只是在使用精神上補充說明而已 >> > >@@? 我上面說的,是在說 OOP,並不是好東西,要適可而止。不應用嗎?非也,只是每一步OOP都是影響深遠的決定,不宜倉猝行事。另外,像你這樣,輕率而求句法複雜,是錯。
這已經是古老的技術了,我第一次看到這種做法應有二十年以上了, 這還稱不上什麼 "影響深遠的決定,不宜倉猝行事", 就單單只是一種技術而已
|
|
|
2017/12/27 下午 03:19:15
>這已經是古老的技術了,我第一次看到這種做法應有二十年以上了, >這還稱不上什麼 '影響深遠的決定,不宜倉猝行事', >就單單只是一種技術而已
你說的沒錯技術就是技術,常無所謂對錯。 尤其許多老技術歷久彌新! 程式人就是要多交流多分享,激盪出不一樣的火花!
看在你喜歡老技術的份上,這裡給你分享一些經典的老技術,你應該會有興趣!
1. 儘量不要寫函式,程式碼儘量合併寫在一個函式裡,這樣省去函式呼叫的時間開銷; 以及更重要的,避免在堆疊有限的應用環境上因函式呼叫層數過多而發生 stack overflow 的問題!
2. 儘量不要使用區域變數,請改用全域變數儲存、和傳遞資料, 這樣可以避免多餘的資料拷貝動作,以及避免 stack 塞爆的問題!
3. 所有變數請使用匈牙利命名法命名,在變數開頭加上變數型態縮寫, 好讓閱讀者讀到變數名稱就能知道這是什麼型態的東西,進一步更了解它的意義!
4. 程式碼請寫上大量的註解,解釋程式的來龍去脈與流程, 好讓初入門者也能透過人性化的註解了解這些晦澀不明的程式碼! 理想上註解的份量應該佔到程式碼的一半以上篇幅,請先寫註解、在填上程式碼!
5. 每當修改程式碼的時候,請在修改處寫上註解,說明修改原因、修改時間,並寫上你的大名以示負責! 喔對了!你修改前的原始程式碼請不要刪掉,把它們用註解標註起來就好了, 這樣閱讀者才能知道程式被你改以前是長成什麼樣子,以防萬一他想要參可原來的程式碼時可用! 什麼資料庫什麼的我們才不需要,我們只要一份程式碼就什麼都有了!
|
|
|
2017/12/27 下午 04:09:02
>>這已經是古老的技術了,我第一次看到這種做法應有二十年以上了, >>這還稱不上什麼 '影響深遠的決定,不宜倉猝行事', >>就單單只是一種技術而已 > >你說的沒錯技術就是技術,常無所謂對錯。 >尤其許多老技術歷久彌新! >程式人就是要多交流多分享,激盪出不一樣的火花! > >看在你喜歡老技術的份上,這裡給你分享一些經典的老技術,你應該會有興趣! > >1. 儘量不要寫函式,程式碼儘量合併寫在一個函式裡,這樣省去函式呼叫的時間開銷; >以及更重要的,避免在堆疊有限的應用環境上因函式呼叫層數過多而發生 stack overflow 的問題! > >2. 儘量不要使用區域變數,請改用全域變數儲存、和傳遞資料, >這樣可以避免多餘的資料拷貝動作,以及避免 stack 塞爆的問題! > >3. 所有變數請使用匈牙利命名法命名,在變數開頭加上變數型態縮寫, >好讓閱讀者讀到變數名稱就能知道這是什麼型態的東西,進一步更了解它的意義! > >4. 程式碼請寫上大量的註解,解釋程式的來龍去脈與流程, >好讓初入門者也能透過人性化的註解了解這些晦澀不明的程式碼! >理想上註解的份量應該佔到程式碼的一半以上篇幅,請先寫註解、在填上程式碼! > >5. 每當修改程式碼的時候,請在修改處寫上註解,說明修改原因、修改時間,並寫上你的大名以示負責! >喔對了!你修改前的原始程式碼請不要刪掉,把它們用註解標註起來就好了, >這樣閱讀者才能知道程式被你改以前是長成什麼樣子,以防萬一他想要參可原來的程式碼時可用! >什麼資料庫什麼的我們才不需要,我們只要一份程式碼就什麼都有了!
看來我還不夠老,這 5 點我常沒做到,真不知是不是該給你按個讚
|
|
|
2017/12/27 下午 05:24:21
>>這已經是古老的技術了,我第一次看到這種做法應有二十年以上了, >>這還稱不上什麼 '影響深遠的決定,不宜倉猝行事', >>就單單只是一種技術而已 > >你說的沒錯技術就是技術,常無所謂對錯。 >尤其許多老技術歷久彌新! >程式人就是要多交流多分享,激盪出不一樣的火花! > >看在你喜歡老技術的份上,這裡給你分享一些經典的老技術,你應該會有興趣! > >1. 儘量不要寫函式,程式碼儘量合併寫在一個函式裡,...
懶洋洋地瀏覽討論區, 看到這裡, 看傻眼了, 以為自己眼睛出事, 還刷了刷眼鏡. 噢噢噢, 原來都是在說反話. 用這麼長的篇幅+語氣半真地 去說反話啊, ><" ... , 燃燒的大地 真壞心眼呢.
話說回來, 註解佔程式碼的一半以上(4), 這個算是個好建議. 這一點, 不似反話啊.
|
|
|
2017/12/27 下午 05:40:17
>話說回來, 註解佔程式碼的一半以上(4), 這個算是個好建議. 這一點, 不似反話啊.
這點透露你的年齡了喔! 你應該有45以上了吧?
|
|
|
2017/12/27 下午 05:49:14
>>話說回來, 註解佔程式碼的一半以上(4), 這個算是個好建議. 這一點, 不似反話啊. > >這點透露你的年齡了喔! >你應該有45以上了吧? >
#include <math.h> 燃燒的大地 = pow(壞心眼, 2); // ><" ...
|
|
|
2017/12/28 下午 11:27:59
>關於OOP呢, 適可而止好了. 基本的OOP句法, 尚且已是要極克制地使用. >這前題之下, 竟然對著OOP句法耍小聰明把戲啊. s
|
|
|
2017/12/28 下午 11:38:58
不佑按了什麼鍵,貼文還沒打就送出去了 :( >關於OOP呢, 適可而止好了. 基本的OOP句法, 尚且已是要極克制地使用. >這前題之下, 竟然對著OOP句法耍小聰明把戲啊. 那個靜態多型設計,應該只是泛型設計吧。 泛型程式設計,是使用模版快速產生同模異型的程式。泛型程式設計,算不算是OOP? 狹義來說,不是,但廣義來看模板也是一個呈現概念的個體,也是物件沒錯。 但在以物件是言之有物的OOP裡,應該不算是物件,以免跟言之有物的物件混淆。
|
|
|
2017/12/29 上午 12:57:39
嗯嗯,是的,的確,說模板物件,比非模板物件的影響 更深,而且更難除錯。
我用詞還得再小心點。( ><" 我本來已經小心到令人討厭,再加小心,只怕要離開人道了 )
|
|
|
|
|
|
C++ |
 |
|
|
專家等級 |
評價 |
|
|
一代宗師 |
10000 |
|
|
曠世奇才 |
5000 |
|
|
頂尖高手 |
3000 |
|
|
卓越專家 |
1500 |
|
|
優秀好手 |
750 |
|
|
|
|
|
|
|
|
|
Microsoft Internet Explorer
6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2019 程式設計俱樂部 http://www.programmer-club.com.tw/ |
|
|