|
|
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-2018 程式設計俱樂部 http://www.programmer-club.com.tw/ |
|
|
