[請益] 一個非專業初學者請益如何學習C++

[c***@ptt.cc]

各位前輩好
我本身唸的是物理，雖是基礎學科
但在我們的專業當中，也有大量使用電腦的領域
因為在學校內的課程中，並未開設電腦課程
所以我自己是希望可以以自修的方式加強程式設計的技能

我現在的背景是：
並未接受或自修資訊科系的正規訓練
也就是 計算機概論 資料結構 資料處理 資料庫等都未學過
基本上是空白的，只能算是一個進階的電腦使用者

但因為就我本身的物理專業而言，電腦算是一個工具
並不能算是我本身正在鑽研的領域
所以比較抱著可以正確有效率的使用即可，並不是像電腦專業領域的研究者細細鑽研了

所以目前是打算直接先進入C++的學習，等對程式設計有了基本的掌握
有初步的程式設計能力後，再根據我所需要的能力
再去切入資料庫、資料結構、資料處理、演算法、網路...等
而我目前的計劃是以自修的方式
閱讀Essential C++ -> C++ Primer 3/e 這兩本由侯捷所出的中譯本

不知道各位資訊領域的前輩，對於我這樣個情況與計劃
有什麼看法與建議？
誠心歡迎各位前輩的指導，謝謝

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.122.244.162

[汀]

Post by c***@ptt.cc
閱讀Essential C++ -> C++ Primer 3/e 這兩本由侯捷所出的中譯本
不知道各位資訊領域的前輩，對於我這樣個情況與計劃
有什麼看法與建議？
誠心歡迎各位前輩的指導，謝謝

如果你學 C++ 的目的，不是要幹掉寫 C 的人...
不是為了節省開發程式時間、精鍊程式碼提高易維護性、增進程式效率等等，
那麼，不管你是不是資訊領域的人，
你看完 C++ Primer 之後只要學習如何應用就好。

可以先買一本 The C++ Standard Library（也是侯捷翻的）來讀，
讀完以後擺在旁邊當工具書用，
之後把 boost 這個 library 和 ACE 這個 framework 學起來，
你應該就能撰寫絕大多數沒有 GUI 的程式。
要 GUI 的話，日後也可以學一套 Qt 或 wxwindows 等等的東西，
如果你一天能花得起 8 小時在學這些東西上，
大概一兩年就能有不小的成就...
花不起的話，可能會比較晚一點，要有耐性就是了。

比較進階但是只跟 C++ 本身有關的書籍，
就比較不建議你去讀，
像是 Effective C++、More Effective C++、Exceptional C++，
或是 Modern C++ Design 和 C++ Template 全覽這類的...
並不是說這些書不重要，
而是對你目前的需求來說可能一輩子用不到。

--
Name: Tseng, Ling-hua E-mail Address: ***@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
╔═══╗ ┼────────────────────────╮
║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮
║ 年少║ ┼╮ < IP：140.119.164.16 > ╰─╮
╚╦═╦╝  ╰  ＊ From：218-171-138-13.dynamic.hinet.net 
 ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎ 

[d***@ptt.cc]

我覺得你如果是學物理的的話 程式學熟了可以去研究一些資料壓縮的東西 因為那些跟
物理還蠻有關的 像熵值跟熱力學有關吧 我物理也不太行 有錯的話指教一下吧






※ 引述《***@whshs.cs.nccu.edu.tw (汀)》之銘言：
: ※ 引述《***@ptt.cc》之銘言：
: > 閱讀Essential C++ -> C++ Primer 3/e 這兩本由侯捷所出的中譯本
: > 不知道各位資訊領域的前輩，對於我這樣個情況與計劃
: > 有什麼看法與建議？
: > 誠心歡迎各位前輩的指導，謝謝
: 如果你學 C++ 的目的，不是要幹掉寫 C 的人...
: 不是為了節省開發程式時間、精鍊程式碼提高易維護性、增進程式效率等等，
: 那麼，不管你是不是資訊領域的人，
: 你看完 C++ Primer 之後只要學習如何應用就好。
: 可以先買一本 The C++ Standard Library（也是侯捷翻的）來讀，
: 讀完以後擺在旁邊當工具書用，
: 之後把 boost 這個 library 和 ACE 這個 framework 學起來，
: 你應該就能撰寫絕大多數沒有 GUI 的程式。
: 要 GUI 的話，日後也可以學一套 Qt 或 wxwindows 等等的東西，
: 如果你一天能花得起 8 小時在學這些東西上，
: 大概一兩年就能有不小的成就...
: 花不起的話，可能會比較晚一點，要有耐性就是了。
: 比較進階但是只跟 C++ 本身有關的書籍，
: 就比較不建議你去讀，
: 像是 Effective C++、More Effective C++、Exceptional C++，
: 或是 Modern C++ Design 和 C++ Template 全覽這類的...
: 並不是說這些書不重要，
: 而是對你目前的需求來說可能一輩子用不到。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.164.28.205

[Victor]

※ 引述《***@bbs.nchu.edu.tw (國王的新衣)》之銘言：
: ※ 引述《***@ptt.cc》之銘言：
: 計算機概論念不念無所謂
: 談了很多表象的東西，但基本的觀念不是沒有就是錯誤的
: 程式語言只要學好C就夠用了
: 如果你還想深究，
: 向下我會建議你學Assembly與單晶片實作
: 向上我會建議你學軟體工程
: 就像是物理學，基礎學科很重要，雖然它不是直接的應用
: 卻是工程的思維基礎
: 計算機科學也有基礎科學，只是目前的發展與教學體系都不完善
: 充滿了皮毛與過渡性的東西，學這些東西都是浪費時間
: MS的東西充滿了商業目的的資訊抹黑，學了不容易有長進
: 可謂事半功倍
: C++的物件導向語法就不用學了，根本就是浪費時間的東西
C++物件導向語法不用學= =?浪費時間?
我可不這麼認為 ...至少我認為還蠻有用的
用起來還蠻順手的...

: 至於軟體工程，可能要花很多時間來說明，如果有興趣的話再慢慢談吧！

--
VICTOR工作室

URL : http://www.kinmen.info/vic/

C/C++
Visual Basic 6.0

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.116.65.245

[㊣塞破超人００９]

Post by Victor
計算機概論念不念無所謂
談了很多表象的東西，但基本的觀念不是沒有就是錯誤的
C++的物件導向語法就不用學了，根本就是浪費時間的東西

火星人火星人火星人火星人火星人火星人火星人火星人火星人火星人火星人

火星人重現江湖

Post by Victor
至於軟體工程，可能要花很多時間來說明，如果有興趣的話再慢慢談吧！

火星的軟體工程？不要啦。
　
--
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
 我們要保證一切的利益都歸於國家與黨。 
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Mk.3(N)  journeyman  - Moderator, Military Board
2-16-2K orig., 9-26-01 dropback 中央大學松濤風情資訊站

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 218-162-233-162.dynamic.hinet

[爆米香]

: > 各位前輩好
: > 我本身唸的是物理，雖是基礎學科
: > 並未接受或自修資訊科系的正規訓練
: > 也就是 計算機概論 資料結構 資料處理 資料庫等都未學過
: MS的東西充滿了商業目的的資訊抹黑，學了不容易有長進
: 可謂事半功倍
^^^^^^^^

用反了

: C++的物件導向語法就不用學了，根本就是浪費時間的東西
: 至於軟體工程，可能要花很多時間來說明，如果有興趣的話再慢慢談吧！

建議:直接用Matlab,解工程的東西都很好用

學C++的話,要畫圖實在是很麻煩,也是要學一段時間才會基礎的使用

--
◎龍貓資訊天地(bbs.mgt.ncu.edu.tw)
◎[bonmeepon]From: 220-142-5-96.dynamic.hinet.net

[rendering]

※ 引述《***@bbs.nchu.edu.tw (國王的新衣)》之銘言：
: ※ 引述《***@ptt.cc》之銘言：
: > 各位前輩好
: > 我本身唸的是物理，雖是基礎學科
: > 並未接受或自修資訊科系的正規訓練
: > 也就是 計算機概論 資料結構 資料處理 資料庫等都未學過
: 計算機概論念不念無所謂
: 談了很多表象的東西，但基本的觀念不是沒有就是錯誤的
: 程式語言只要學好C就夠用了
: 如果你還想深究，
: 向下我會建議你學Assembly與單晶片實作
: 向上我會建議你學軟體工程
: 就像是物理學，基礎學科很重要，雖然它不是直接的應用
: 卻是工程的思維基礎
: 計算機科學也有基礎科學，只是目前的發展與教學體系都不完善
: 充滿了皮毛與過渡性的東西，學這些東西都是浪費時間
: MS的東西充滿了商業目的的資訊抹黑，學了不容易有長進
: 可謂事半功倍
: C++的物件導向語法就不用學了，根本就是浪費時間的東西
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

啊 此話怎說


: 至於軟體工程，可能要花很多時間來說明，如果有興趣的話再慢慢談吧！



--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.228.216.204

[c***@ptt.cc]

※ [本文轉錄自 C_and_CPP 看板]

作者: canlin () 看板: C_and_CPP
標題: Re: [請益] 一個非專業初學者請益如何學習C++
時間: Sat Aug 6 22:28:17 2005

首先先感謝各位前輩的熱心幫助
原本以為會沒人理我，但沒想到得到了大家這麼多的回應
再次謝謝大家

對於各位前輩的指導，我在此感謝並一一回應
對於我們唸物理的來說，matlab, mathematica......等眾多的 科學性應用套裝軟體
我們是一定會用到的，但我之所以還要學程式設計的原因就是因為這些都是
已經設計好的套裝軟體，對於某些常用的或是制式化的應用與處理當然我們會選擇
先使用這些軟體去做，方便又省時
但很多時候我們有我們自己想做的idea 或是要求、或是更複雜的計算，物理模擬
物理理論模擬等，這些常常就是這些套裝軟體不適合或是不好做，或是做起來
根本跟自己寫沒兩樣的東西了，所以擁有自行撰寫程式的能力絕對是必須的
或是另一個角度看，我們系上老師作跟電腦有關領域的大師，沒一個不會
程式設計的，不敢說他們是專業的程設大師，但絕對這能力是需要的

再來
我說明一下我現在的能力好了，之前沒有說明是因為原本希望可以再
從頭好好打底子，但是看各前輩的回應，好像這是很重要的因素
我從小學就有接觸過qb，只有粗淺概念
高中學習過vb, asp，已經學到可以撰寫小程式
大學接觸過html, javascript, java
以java為尺標的話，我是看java2 入門與實務應用 碁峰出版
我已學過(以書中章節為尺標的話)：
資料型態與運算子、字串與陣列，流程控制，物件導向與封裝概念
繼承與多形、類別的延伸使用、例外處理、基本i/o控制、常用類別
AWT and Swing基本使用
之前不說是因為這本書很爛，我自己都知道我學的不是很好，雖然唸過這幾個
大項目，但我相信我的觀念一定不好，加上我自己並不喜歡java
所以才會希望可以是當作空白的初學者重新洗禮
這樣子的說明不知道對於各位前輩在提供建議上 會不會有所助益

那為何我要選擇C++？
我想我之所以會選擇c++而不是選擇其他也許跟數學或是物理更有淵源的程式語言
ex: pascal fortran, perl等
是因為就我所知，物件導向是一個程式設計上的個重要的里程碑
這個觀念帶來的影響是相當重要的
就我而言，程式是一個工具，我本身也非鑽研電腦的專業人士
所以一定是先從高階語言下手。
而物件導向這種樂高積木式的概念(不知道我這樣說對不對......)
可以方便我進行teamwork，以後程式寫多了，也可以重複使用節省時間
當然，有物件導向的概念縱使不是以物件導向為理念的程式語言也可以寫成
物件導向，但就我而言我會就直接選擇C++了
(其實我們系上的老師有很多都還是forfran...等的愛用者)
而且因為我所寫的東西可以的話是希望可以在unix and windows, even apple上
執行，所以C++好像又更適當了些
以上是我目前為何會打算選擇C++作為專精的langurage的原因
不知前輩們有何想法？

對於有前輩建議我還是要先唸或是同時唸資料結構與演算法
因為我不是唸這科系的，所以我也不能說非常清楚沒有這些先備知識
所會造成的影響，但既然有前輩這樣說了，那可否請前輩們推薦
資料結構與演算法好的或是經典的中文書，翻譯或是臺灣自己寫的都可
我想我會努力多多學習的，至少也會先去翻翻瀏覽一下

感謝！

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.122.244.162

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.122.244.162

[㊣塞破超人００９]

Post by c***@ptt.cc
但很多時候我們有我們自己想做的idea 或是要求、或是更複雜的計算，物理模擬

哪一些時候？
靈活使用Mathematica, Matlab, 一樣可以寫界面，做大型計算
能力和imperative languages 沒有兩樣
只有對rough performance要求非常高的場合才有顯著差距
而現在硬體的能力強得亂七八糟，這種壓榨硬體到極限的事情還不太容易做
你到底要做什麼？你在學校裡接觸過那樣的例子嗎？

Post by c***@ptt.cc
就我而言，程式是一個工具，我本身也非鑽研電腦的專業人士
所以一定是先從高階語言下手。
而物件導向這種樂高積木式的概念(不知道我這樣說對不對......)
可以方便我進行teamwork

跟誰teamwork?

某鯛魚非常勤學，跑去跟客座的鱷魚學了肺呼吸方法，學成回來以後對其他鯛
魚說：鰓呼吸是演化中原始的階段，進步的物種都採用肺呼吸，你我也要學肺
呼吸。然後他就開始教所有的鯛魚肺呼吸，可是他忘了鯛魚是沒有肺的。

物理界就是鰓呼吸的環境，這裡所有人都用鰓呼吸，而且呼吸得很好。除非你
找到用肺呼吸的物理研究者，否則你自己跑去學肺呼吸，回來物理界，往往會
嗆死。

反過來講，如果你將來要棄物理了，那麼你或許有望進入肺呼吸的世界。但是
我並沒有看到你有這樣的規劃。

如果你只是覺得C++ 很好，想要把一個好的語言學好，那麼你儘管學，但是不
要幻想這跟你本行可以有什麼加成的效果。這中間要搭上關係，往往離得很遠，
不經濟也不實用。我知道有那種物理研究者，已經拿到博士，不喜歡Fortran,
C++ 用得很好，連PERL都很厲害，但是他從來不把這些事情掛嘴上。

找出重點。It's physics that counts.
　
--
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
 我們要保證一切的利益都歸於國家與黨。 
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Mk.3(N)  journeyman  - Moderator, Military Board
2-16-2K orig., 9-26-01 dropback 中央大學松濤風情資訊站

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 218-162-233-162.dynamic.hinet

[汀]

Post by c***@ptt.cc
我想我之所以會選擇c++而不是選擇其他也許跟數學或是物理更有淵源的程式語言
ex: pascal fortran, perl等
是因為就我所知，物件導向是一個程式設計上的個重要的里程碑
這個觀念帶來的影響是相當重要的
就我而言，程式是一個工具，我本身也非鑽研電腦的專業人士
所以一定是先從高階語言下手。

以不偏袒任何語言的客觀角度來說，
如果您是為了物件導向的種種好處，
而且主要是為了做實驗等等的目的，
我建議你去學 Java 比較好，
試著不要去討厭 Java 吧...

Post by c***@ptt.cc
而物件導向這種樂高積木式的概念(不知道我這樣說對不對......)

這只是物件導向的某一個好處 - 程式碼可再利用性。

Post by c***@ptt.cc
可以方便我進行teamwork，以後程式寫多了，也可以重複使用節省時間
當然，有物件導向的概念縱使不是以物件導向為理念的程式語言也可以寫成
物件導向，但就我而言我會就直接選擇C++了
(其實我們系上的老師有很多都還是forfran...等的愛用者)

一般而言棄 Java 選 C++ 的人，
比較偏向自由性和執行效率，
不過也因為 C++ 太自由了，
造成要完全駕馭它反而要花上好幾年的時間，
為了這種自由性賠上好幾年的歲月，
憑良心講這對物理系的人來說不划算。

Post by c***@ptt.cc
而且因為我所寫的東西可以的話是希望可以在unix and windows, even apple上
執行，所以C++好像又更適當了些

這點 Java 其實也是可以。

Post by c***@ptt.cc
以上是我目前為何會打算選擇C++作為專精的langurage的原因
不知前輩們有何想法？

嗯，就上面那些。

Post by c***@ptt.cc
對於有前輩建議我還是要先唸或是同時唸資料結構與演算法
因為我不是唸這科系的，所以我也不能說非常清楚沒有這些先備知識
所會造成的影響，但既然有前輩這樣說了，那可否請前輩們推薦
資料結構與演算法好的或是經典的中文書，翻譯或是臺灣自己寫的都可
我想我會努力多多學習的，至少也會先去翻翻瀏覽一下
感謝！

這個不急，
學 Java 或 C++ 的路上你自然能學會怎樣用，
基本上你需要會的也只是使用而已，
並不需要瞭解細部的數學計算和證明，
除非你是要投演算法方面的論文。

如果你還是堅持要學 C++，
之前開給你的 The C++ Standard Library 這本書，
會描述到 STL 裡的一些 data structues 和 algorithms 使用方法，
至於比較進階的東西你也能透過使用 boost 這套 library 學到，
依經驗來說，就算不去接觸正式的教科書，
也能從實作中領悟到正式教科書所能帶給你的基礎知識。

當然不去讀教科書對一般純實作的人而言的確有一個缺點，
就是缺乏制式化的標準名詞來和別人進行心得交流或討論，
不過並不代表你永遠不會知道那些專有名詞，
只是會延後到比較晚的時間點才會得知罷了。

--
Name: Tseng, Ling-hua E-mail Address: ***@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
╔═══╗ ┼────────────────────────╮
║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮
║ 年少║ ┼╮ < IP：140.119.164.16 > ╰─╮
╚╦═╦╝  ╰  ＊ From：218-171-138-13.dynamic.hinet.net 
 ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎ 

[汀]

Post by Victor
C++物件導向語法不用學= =?浪費時間?
我可不這麼認為 ...至少我認為還蠻有用的
用起來還蠻順手的...

你第一次看他文章啊??
其實我覺得會出現物件導向無用那句.....實在非常正常XD

我也看得蠻久了，不過我還是覺得這種東西是看人看團隊看公司。
以常見的繪圖範例：Shape、Line、Circle、... 來說，
用非物件導向來寫會這樣用：
struct Shape {
enum ShapeType type;
union {
...
} u;
};
由 type 欄位來決定取用 u 的哪個欄位，
一般判斷它的時候會輔以 switch case 敘述。

用基礎的物件導向技術，
上述的 type 欄位會消失，
然後會多出了好幾個 struct/class 繼承 base class Shape，
而 base class Shape 可能提供一些 virtual function 像是 Draw()，
讓這系列 classes 的「使用端」免除用 switch case 或 if else 判斷型別的麻煩，
但是在某些時候還是難以免除 switch case 或 if else 的使用，
這和物件導向當初的精神相違，算是個跛腳的物件導向設計方法。

用上 design pattern 的高級物件導向技術，
會利用 factory + singleton 的 patterns 解決這個問題，
增加了 class 登記機制，把登記責任歸在設計 class 的人身上，
使用端再也不需要去寫那些難以維護的 switch case 或 if else 敘述，
在繼承樹上加入新 class 的人再也不需要看遍所有程式碼中的 switch case，
然後花時間在那邊一個一個修改。

三種方法中，依據現實環境的不同，
可能會被強迫性的選擇某種方式，
雖然知道這三種方法的人都知道第三種方法比較好，
但是有時候你是在修改別人寫好的程式，
有時候上頭交代你修改的軟體根本就是用 C 寫的，
有時候你待的團隊懂得 design pattern 的人就是很少...
有時候你的專案很小規格很固定，軟體的生命很短，也能選第一種。

堅持哪種最好並沒有意義，
而是要能正確選擇應付目前要解決的問題最適當的方法。

--
Name: Tseng, Ling-hua E-mail Address: ***@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
╔═══╗ ┼────────────────────────╮
║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮
║ 年少║ ┼╮ < IP：140.119.164.16 > ╰─╮
╚╦═╦╝  ╰  ＊ From：218-171-138-13.dynamic.hinet.net 
 ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎ 
--
 * Modify: tinlans 05/08/07 0:46:11 <218-171-138-13.dynamic.hinet.net> 

[╮(╯_╰)╭]

Post by ㊣塞破超人００９

Post by c***@ptt.cc
但很多時候我們有我們自己想做的idea 或是要求、或是更複雜的計算，物理模擬

哪一些時候？
靈活使用Mathematica, Matlab, 一樣可以寫界面，做大型計算
能力和imperative languages 沒有兩樣
只有對rough performance要求非常高的場合才有顯著差距
而現在硬體的能力強得亂七八糟，這種壓榨硬體到極限的事情還不太容易做
你到底要做什麼？你在學校裡接觸過那樣的例子嗎？

Post by c***@ptt.cc
就我而言，程式是一個工具，我本身也非鑽研電腦的專業人士
所以一定是先從高階語言下手。
而物件導向這種樂高積木式的概念(不知道我這樣說對不對......)
可以方便我進行teamwork

跟誰teamwork?
某鯛魚非常勤學，跑去跟客座的鱷魚學了肺呼吸方法，學成回來以後對其他鯛
魚說：鰓呼吸是演化中原始的階段，進步的物種都採用肺呼吸，你我也要學肺
呼吸。然後他就開始教所有的鯛魚肺呼吸，可是他忘了鯛魚是沒有肺的。
物理界就是鰓呼吸的環境，這裡所有人都用鰓呼吸，而且呼吸得很好。除非你
找到用肺呼吸的物理研究者，否則你自己跑去學肺呼吸，回來物理界，往往會
嗆死。
反過來講，如果你將來要棄物理了，那麼你或許有望進入肺呼吸的世界。但是
我並沒有看到你有這樣的規劃。
如果你只是覺得C++ 很好，想要把一個好的語言學好，那麼你儘管學，但是不
要幻想這跟你本行可以有什麼加成的效果。這中間要搭上關係，往往離得很遠，
不經濟也不實用。我知道有那種物理研究者，已經拿到博士，不喜歡Fortran,
C++ 用得很好，連PERL都很厲害，但是他從來不把這些事情掛嘴上。
找出重點。It's physics that counts.
　

我也同意這位先生的說法
別太在意 C++ 在做什麼
也別太在意 OO 是什麼
更別太在意一些有的沒的電腦名詞
不要迎合這個版的討論
那些東西現在與你無關

寫爛 code 不要緊, 能解決問題的就好
不會 OO 無所謂, 寫久就知道怎麼改



--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 61-229-131-84.dynamic.hinet.n

[s***@kkcity.com.tw]

以物理系來說, 學 c++ 真的不划算
物理寫程式有兩種主要用途
1 是寫儀器設備的控制, 多半是 DSP or 8051 只能用 C
2 是大量計算, 用啥都沒差, 但是 C 的最佳化較好學
程式架構比語言更重要, 能不能重復使用是靠架構
C++ 並不好學, 更是有一堆難懂的語法,
一般是寫商用程式, 沒有複雜運算但是東西又多又雜時用
C 可以當是 C++ 的一部份, 其它部份有用到再學吧

Post by 汀

Post by c***@ptt.cc
而物件導向這種樂高積木式的概念(不知道我這樣說對不對......)

這只是物件導向的某一個好處 - 程式碼可再利用性。

Post by c***@ptt.cc
可以方便我進行teamwork，以後程式寫多了，也可以重複使用節省時間
當然，有物件導向的概念縱使不是以物件導向為理念的程式語言也可以寫成
物件導向，但就我而言我會就直接選擇C++了
(其實我們系上的老師有很多都還是forfran...等的愛用者)

一般而言棄 Java 選 C++ 的人，
比較偏向自由性和執行效率，
不過也因為 C++ 太自由了，
造成要完全駕馭它反而要花上好幾年的時間，
為了這種自由性賠上好幾年的歲月，
憑良心講這對物理系的人來說不划算。

Post by c***@ptt.cc
而且因為我所寫的東西可以的話是希望可以在unix and windows, even apple上
執行，所以C++好像又更適當了些

這點 Java 其實也是可以。

Post by c***@ptt.cc
以上是我目前為何會打算選擇C++作為專精的langurage的原因
不知前輩們有何想法？

嗯，就上面那些。

Post by c***@ptt.cc
對於有前輩建議我還是要先唸或是同時唸資料結構與演算法
因為我不是唸這科系的，所以我也不能說非常清楚沒有這些先備知識
所會造成的影響，但既然有前輩這樣說了，那可否請前輩們推薦
資料結構與演算法好的或是經典的中文書，翻譯或是臺灣自己寫的都可
我想我會努力多多學習的，至少也會先去翻翻瀏覽一下
感謝！

這個不急，
學 Java 或 C++ 的路上你自然能學會怎樣用，
基本上你需要會的也只是使用而已，
並不需要瞭解細部的數學計算和證明，
除非你是要投演算法方面的論文。
如果你還是堅持要學 C++，
之前開給你的 The C++ Standard Library 這本書，
會描述到 STL 裡的一些 data structues 和 algorithms 使用方法，
至於比較進階的東西你也能透過使用 boost 這套 library 學到，
依經驗來說，就算不去接觸正式的教科書，
也能從實作中領悟到正式教科書所能帶給你的基礎知識。
當然不去讀教科書對一般純實作的人而言的確有一個缺點，
就是缺乏制式化的標準名詞來和別人進行心得交流或討論，
不過並不代表你永遠不會知道那些專有名詞，
只是會延後到比較晚的時間點才會得知罷了。

--
┌─────◆ＫＫＣＩＴＹ◆─────┐ ◢ ╱  想要成立班系社團站台嗎? 
│ bbs.kkcity.com.tw │ █▉ ─ KKcity即日起開放BBS站申請囉!
└──《From:203.67.162.156 》──┘ ◥ ╲ 免程式技術、硬體成本的選擇!!

[月季]

※ 引述《***@bbs.sayya.org (墳墓)》之銘言：
: 另外，分享一下 Pike[1] 這個語言，雖然好像目前在
: 用的人不多（大家都在玩3P……是因為比較刺激嗎？XD）。
: [1] http://pike.ida.liu.se/
: Pike 的話，也是 Script 語言，語法接近 C/C++ ，支
: 援 GC ，另外 modules 也夠多（雖然比不上 Python
: 和 PHP/Perl 這三個），但足夠處理大部份的問題了。
: 而且 Pike 的物件導向也夠完整，不會像 PHP 4.x 一
: 樣像跛腳，GTK 也直接整合進去了。
: 而且真的頗好學，像我之前寫過用 C Call GTK 的程式，
: 給大家參考一下，也許 Pike 會是 3P 之外的另一個可
: 以選擇的 P。;)
不得不推一下pike!
沒想到還有別人在接觸pike!
pike真的很好學 他是從LPC演變過來的
玩過mud的人學一定倍感親切！
pike程式碼簡單易懂
在他的一個範例裡
94行就寫出一個multi-thread的http server!
他的推廣度一直不及python....我覺得很可惜
有興趣可以玩玩看！很好用的

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 219.68.148.187

[汀]

Post by 月季
不得不推一下pike!
沒想到還有別人在接觸pike!
pike真的很好學 他是從LPC演變過來的
玩過mud的人學一定倍感親切！
pike程式碼簡單易懂
在他的一個範例裡
94行就寫出一個multi-thread的http server!
他的推廣度一直不及python....我覺得很可惜
有興趣可以玩玩看！很好用的

聽到它是 LPC 演變過來的讓我很有興趣，
稍微看了一下，mixed 跟 mapping 還是存在，
不過我有幾個比較好奇的地方，
沒辦法馬上從它的 doc 看出來，
想請教一下。

1. Pike 是不是跟 LPC 一樣有一個常駐的 VM，
所有的 objects 會像是 processes 一樣常駐於 VM 內部？
是否每個程式檔被編譯載入後即是一個物件？

2. call_other operator 是否還存在於 Pike 中？
譬如寫 x->foo(a, b, c); 可以呼叫物件 x 中的 foo() 函式，
若 foo() 有三個參數 a、b、c，我寫 x->foo(a, b);，
是不是 c 可以自動被視為 undefined value？

3. 是否還有任意物件之間互相 shadow 的功能？
譬如 a 物件內部定義有 foo() 函式，
現在我臨時造出 b 物件（由跟 a 完全不相干的程式檔產生），
裡面也有一個 foo() 函式，
然後我讓 b 物件 shadow a 物件，
往後任何 a->foo() 這種呼叫均等同於 b->foo()？
（LPC 時代沒有 class 的概念，所以都用物件這個名詞）
另外是不是也有 nomask 這種保留字可以防止 shadow？

4. 是否還有 this_object()、function owner 和 bind 的觀念？
(1) 譬如目前程式是在物件 a 中執行，this_object() 會傳回 a。
(2) 由物件 a 中擷取出來的 function pointer，其 owner 為 a。
(3) 若物件 a 中定義有 foo() 這個函式，以 (: foo :) 獲得其指標，
是否能利用 f = bind((: foo :), b); 使 f 的 owner 被 bind 為 b？
此後執行 (*f)(a, b, c); 形同在 b 中執行 foo() 函式？
（同時 f 指向的 foo() 函式中所有 this_object() 呼叫均傳回 b）

5. 是否還存在 virtual object 的用法？
以往 LPC 必須使用實際存在的程式檔產生物件，
但是 LPC 的 VM 有一個機制能在找不到該檔案時呼叫一個 master applies，
由該 master applies 依據檔名等資訊 clone 出適當的物件傳回，
而該物件會在之後視為由該不存在的程式檔所產生的。

6. 是不是還有 save_object() 這種函式，
可以將所有 nosave/non-static global variable 以 text form 存入檔案，
之後直接用 restore_object() 讀出以恢復物件狀態？

不好意思問這麼多問題，
因為這些都是目前我還會使用 LPC 的理由，
但是他們官方網頁沒有跟 LPC 的比較表。
我問的東西可能跟 LPC4 有差距，
因為我熟悉的是 LPC3 時代 branch 出去的 MudOS LPC。

--
Name: Tseng, Ling-hua E-mail Address: ***@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
╔═══╗ ┼────────────────────────╮
║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮
║ 年少║ ┼╮ < IP：140.119.164.16 > ╰─╮
╚╦═╦╝  ╰  ＊ From：218-171-138-13.dynamic.hinet.net 
 ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎ 
--
--
 * Modify: tinlans 05/08/07 3:58:31 <218-171-138-13.dynamic.hinet.net> 

[p***@kkcity.com.tw]

Post by ㊣塞破超人００９

Post by Victor
計算機概論念不念無所謂
談了很多表象的東西，但基本的觀念不是沒有就是錯誤的
C++的物件導向語法就不用學了，根本就是浪費時間的東西

火星人火星人火星人火星人火星人火星人火星人火星人火星人火星人火星人
火星人重現江湖

Post by Victor
至於軟體工程，可能要花很多時間來說明，如果有興趣的話再慢慢談吧！

火星的軟體工程？不要啦。

只有「很會寫程式」的人，才會說學物件導向是浪費時間的。

確實，如果一看到問題，就能夠直達精確解，那麼物件導向的確沒什麼用。
--
┌─────◆ＫＫＣＩＴＹ◆─────┐ ■ KKBOX 可立刻 聽音樂 ■ 
│ bbs.kkcity.com.tw │  ■■所有想找的歌通通不必等 ■■ 
└──《From:212.66.131.2 》──┘ ■■■http://www.kkbox.com.tw■■■

[s***@kkcity.com.tw]

※ 引述《***@ptt.cc》之銘言：
建議你專心學習自己的科目
搞東搞西最後就是啥都不會
非資工學科 或是不走ap的
你學C++ 我是覺得,可能有其他更好的選擇
要是我是你,我是比較會走python perl等等的工具路線
或是看你們接觸到最多的工具是用啥程式語言開發的
選那個作為學習 或許更好
或是乾脆找工讀生寫你的code(我以前就幫應數系教授寫過程式)
--
┌─────◆ＫＫＣＩＴＹ◆─────┐▇─┐ＫＫＡＤＳＬ→六星級優質連線服務
│ bbs.kkcity.com.tw │┴ └─▇ 馬上申請帶你上網環遊全世界！
└──《From:210.64.184.40 》──┘ KKADSL ┴  http://adsl.kkcity.com.tw 

[www.dev.idv.tw]

Post by s***@kkcity.com.tw
建議你專心學習自己的科目
搞東搞西最後就是啥都不會
非資工學科 或是不走ap的
你學C++ 我是覺得,可能有其他更好的選擇
要是我是你,我是比較會走python perl等等的工具路線
或是看你們接觸到最多的工具是用啥程式語言開發的
選那個作為學習 或許更好
或是乾脆找工讀生寫你的code(我以前就幫應數系教授寫過程式)

嗯...說的好..
的確，我也建議前面發問的網友可以考慮使用Perl
或是Python等Script language。畢竟本科的東西才是最重要的。
工具要以最容易上手以及最容易開發為主要考量。
除非，您要開發的東西有極高的效能考量，果真如此使用C/C++
才會有其效果。

幾年前新聞不是報導過一些DNA計算的程式都是用Perl寫的嗎？
不過，對於初學者我比較推薦Python。

--
Gary W. Lee
URL: http://www.dev.idv.tw/
A web site about C/C++, Tcl, Python, wxWidgets, UNIX/Linux, Windows ..., etc.
--
※ Origin: 元智大學 風之塔 <bbs.yzu.edu.tw> 
※ From : 220-135-180-191.hinet-ip.hinet.net
※ X-Info: Re: [請益] 一個非專業初學者請益如何學習C++
※ X-Sign: 11FBDFSFjJn115.Vt7co (05/08/07 15:19:24 )

[待救的小米]

※ 引述《***@bbs.yzu.edu.tw (www.dev.idv.tw)》之銘言：
: ※ 引述《***@kkcity.com.tw》之銘言：
: > 建議你專心學習自己的科目
: > 搞東搞西最後就是啥都不會
: > 非資工學科 或是不走ap的
: > 你學C++ 我是覺得,可能有其他更好的選擇
: > 要是我是你,我是比較會走python perl等等的工具路線
: > 或是看你們接觸到最多的工具是用啥程式語言開發的
: > 選那個作為學習 或許更好
: > 或是乾脆找工讀生寫你的code(我以前就幫應數系教授寫過程式)
: 嗯...說的好..
: 的確，我也建議前面發問的網友可以考慮使用Perl
: 或是Python等Script language。畢竟本科的東西才是最重要的。
: 工具要以最容易上手以及最容易開發為主要考量。
: 除非，您要開發的東西有極高的效能考量，果真如此使用C/C++
: 才會有其效果。
: 幾年前新聞不是報導過一些DNA計算的程式都是用Perl寫的嗎？
: 不過，對於初學者我比較推薦Python。
DNA的應用程式 很多是用Perl寫的沒錯
但是那是因為生物資訊的領域 必須用到很多處理字串的環境
所以才會大量依賴perl

perl在計算上的速度 很有可能跟C/C++差了一大截 差到一兩百倍都有可能
因為我的碩士論文本來是用Perl做的
後來為了這兩百倍的效率 把kernel換成C++再重作一次
所以我想perl我想可能不適合用在物理界上面

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.109.73.177

[a***@bbs.nsysu.edu.tw]

我的看法是
一個已經有Domain Knowledge的人
Program是有餘力學多少就學多少
把介面隔閡盡量消除,能跟專業人士溝通就好.
但是我不建議都自己來

原因是, 你如何知道你寫的程式有沒有重大Bug,
當你一個模擬程式需要跑一個月,結果因為Memory Leakage
導致第29天時當掉該如何是好?
這還不算嚴重,更甚者你如何知道你的程式跑出的結果正確無誤?
當然,你可以輔以你的專業知識來判斷答案的合理性
不過你會想發表Paper吧!你寫的軟體跑出來的結果,會被審議委員承認嗎?
我想國際上有很多專業的套裝軟體或Library,
那些系上應該會買吧!
你要學的只要會使用和呼叫就好了!
--
* Origin: 中山大學-美麗之島BBS * From: 61.31.87.131

[try or test]

Post by c***@ptt.cc
但很多時候我們有我們自己想做的idea 或是要求、或是更複雜的計算，物理模擬
物理理論模擬等，這些常常就是這些套裝軟體不適合或是不好做，或是做起來
根本跟自己寫沒兩樣的東西了，所以擁有自行撰寫程式的能力絕對是必須的
或是另一個角度看，我們系上老師作跟電腦有關領域的大師，沒一個不會
程式設計的，不敢說他們是專業的程設大師，但絕對這能力是需要的

====
傳統的科學計算就是 FORTRAN 程式語言, 但到了多處理機, 分散式電腦的時代,
單機循序處理程式就發揮不了效果. 對物理言, 越是摸不到看不見的就得靠理論
分析與模擬, 最明顯的就是大氣物理的天氣預報, 計算效率還是很重要的, 尤其
是數字模型的分散式高速計算.
前一陣子學校的理學院想發展前瞻模擬研究, 為了現在的高速電腦都是多處理機
架構, 舊的 FORTRAN 程式無法多機分散處理, 大嘆人才難求, 最後就不了了之.
不曉得這些是否是該納入考慮的項目 ?

Post by c***@ptt.cc
那為何我要選擇C++？
我想我之所以會選擇c++而不是選擇其他也許跟數學或是物理更有淵源的程式語言
ex: pascal fortran, perl等
是因為就我所知，物件導向是一個程式設計上的個重要的里程碑
這個觀念帶來的影響是相當重要的
就我而言，程式是一個工具，我本身也非鑽研電腦的專業人士
所以一定是先從高階語言下手。
而物件導向這種樂高積木式的概念(不知道我這樣說對不對......)
可以方便我進行teamwork，以後程式寫多了，也可以重複使用節省時間
當然，有物件導向的概念縱使不是以物件導向為理念的程式語言也可以寫成
物件導向，但就我而言我會就直接選擇C++了
(其實我們系上的老師有很多都還是forfran...等的愛用者)
而且因為我所寫的東西可以的話是希望可以在unix and windows, even apple上
執行，所以C++好像又更適當了些
以上是我目前為何會打算選擇C++作為專精的langurage的原因

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234

[璉璉]

?
Fortran 不是有向量計算？

最早免費的平行運算函式庫及跨電腦的 PVM (分散式運算)， Fortran 不都可以用？

不過內建語法是沒有啦...

於 news:4JU2lI%24xDJ%40bbs.csie.ncu.edu.tw 發表

Post by c***@ptt.cc
但很多時候我們有我們自己想做的idea 或是要求、或是更複雜的計算，物理模擬
物理理論模擬等，這些常常就是這些套裝軟體不適合或是不好做，或是做起來
根本跟自己寫沒兩樣的東西了，所以擁有自行撰寫程式的能力絕對是必須的
或是另一個角度看，我們系上老師作跟電腦有關領域的大師，沒一個不會
程式設計的，不敢說他們是專業的程設大師，但絕對這能力是需要的

====
傳統的科學計算就是 FORTRAN 程式語言, 但到了多處理機, 分散式電腦的時代,
單機循序處理程式就發揮不了效果. 對物理言, 越是摸不到看不見的就得靠理論
分析與模擬, 最明顯的就是大氣物理的天氣預報, 計算效率還是很重要的, 尤其
是數字模型的分散式高速計算.
前一陣子學校的理學院想發展前瞻模擬研究, 為了現在的高速電腦都是多處理機
架構, 舊的 FORTRAN 程式無法多機分散處理, 大嘆人才難求, 最後就不了了之.
不曉得這些是否是該納入考慮的項目 ?

Post by c***@ptt.cc
那為何我要選擇C++？
我想我之所以會選擇c++而不是選擇其他也許跟數學或是物理更有淵源的程式語言
ex: pascal fortran, perl等
是因為就我所知，物件導向是一個程式設計上的個重要的里程碑
這個觀念帶來的影響是相當重要的
就我而言，程式是一個工具，我本身也非鑽研電腦的專業人士
所以一定是先從高階語言下手。
而物件導向這種樂高積木式的概念(不知道我這樣說對不對......)
可以方便我進行teamwork，以後程式寫多了，也可以重複使用節省時間
當然，有物件導向的概念縱使不是以物件導向為理念的程式語言也可以寫成
物件導向，但就我而言我會就直接選擇C++了
(其實我們系上的老師有很多都還是forfran...等的愛用者)
而且因為我所寫的東西可以的話是希望可以在unix and windows, even apple上
執行，所以C++好像又更適當了些
以上是我目前為何會打算選擇C++作為專精的langurage的原因

--
水海科技系統研發驗證工作室 ASP.NET Web News Reader 0.2.0 UTF-8 Beta
新聞群組 RSS網誌發布測試中 http://tlcheng.no-ip.com/News/rss2.aspx
網站地圖 http://tlcheng.no-ip.com/wwwmap.htm
流域防洪/水資源運用/徐昇網/玫瑰圖/語音通訊 文章與程式
Basic/Fortran/Windows API/.Net/輔助說明檔 原始碼、文章與討論
--
ASPNET News http://tlcheng.no-ip.com/News/ | http://tlcheng.twbbs.org/News/
RSS 2.0 http://tlcheng.no-ip.com/News/rss2.aspx?Action=List&Newsgroup=tw.bbs.comp.language

[s***@kkcity.com.tw]

Post by try or test
傳統的科學計算就是 FORTRAN 程式語言, 但到了多處理機, 分散式電腦的時代,
單機循序處理程式就發揮不了效果. 對物理言, 越是摸不到看不見的就得靠理論
分析與模擬, 最明顯的就是大氣物理的天氣預報, 計算效率還是很重要的, 尤其
是數字模型的分散式高速計算.
前一陣子學校的理學院想發展前瞻模擬研究, 為了現在的高速電腦都是多處理機
架構, 舊的 FORTRAN 程式無法多機分散處理, 大嘆人才難求, 最後就不了了之.
不曉得這些是否是該納入考慮的項目 ?

自己開發一個 distributed programming language 來用呀
以前 fortran 就是為了要用才發明的,
NEC earth simulator 是開 asic 專給模擬用
作研究卻都用現成的工具實在不算前瞻
--
┌─────◆ＫＫＣＩＴＹ◆─────┐▇─┐ 優質連線服務隆/重/豋/場!!
│ bbs.kkcity.com.tw │┴  └─▇  KKADSL 帶你環遊全世界
└──《From:203.67.162.156 》──┘ KKADSL ┴ http://adsl.kkcity.com.tw

[try or test]

Post by 璉璉
?
Fortran 不是有向量計算？
最早免費的平行運算函式庫及跨電腦的 PVM (分散式運算)， Fortran 不都可以用？
不過內建語法是沒有啦...

VECTOR FORTRAN 是用在 Vector Computer 不是 Distributed Processor
System . PVM 還是無法讓傳統寫好的 FORTRAN Program 擺上去就能跑, 對於
不是 Shared Memory 的多處理機還是有困難的.

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234

[國王的新衣]

Post by Victor
: C++的物件導向語法就不用學了，根本就是浪費時間的東西
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
啊 此話怎說

這個問題可從兩個角度來想
其一
學習語言程式純粹以方便作考量，花最小的代價達到目的，
而不管其內部的結構是否合理對稱，思維合不合邏輯

其二
與其一恰恰相反，
適用於喜歡打破砂鍋問到底的人
講究從頭到尾都要能夠合乎邏輯，並可據以舉一反三
這種方式才能讓你有能力去解決更大尺度的問題

在我看來OO只是個糖果，它能在短期內幫你解決簡單的問題
或許你會覺得它很好用

可是當問題的Range越來越放大，其基本結構上的矛盾所造成問題就開始越來越彰顯
便利性越來越少，反而怪異不具對稱性的 ”例外修補語法” 越來越多
(什麼建構子、物件別名等….)
讓語法變得越來越複雜，就像一間漏水的瓦房，永遠有補不完的漏洞
糞土之牆終究是不可圬也

到最後你會發現，它會花去你大部份的時間來解決 ”語法” 上的問題
而不是 ”Domain knowledge”問題，非常不經濟

結構上的矛盾無法讓你很清楚的去思維系統的結構，同時介面也變得混亂不堪

人的光陰有限
程式語言本來就是 ”人為” 的東西
人為的出發點錯誤造成後面的問題重重，捉襟見肘

如果出發點正確，這些問題就不會存在了
花時間去解決這本來就可以不存在的問題，本來就是浪費時間






--
Ξ Origin: 中興大學天樞資訊網 <bbs.nchu.edu.tw>
Ξ From : 61-230-66-119.dynamic.hinet.net

[Yukuan]

我終於見識到外星人了 :)
我的見解是，沒錯，你是可以用 function pointer 來解決 OOP
所要試圖處理的抽象化問題，但那也是自討苦吃。

此外， C++ 的 namespace 等跟 OOP 無關的部分，卻很適合在規模
較大的程式中使用。

※ 引述《***@bbs.nchu.edu.tw (國王的新衣)》之銘言：
: ※ 引述《***@ptt.cc (rendering)》之銘言：
: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: > 啊 此話怎說
: 這個問題可從兩個角度來想
: 其一
: 學習語言程式純粹以方便作考量，花最小的代價達到目的，
: 而不管其內部的結構是否合理對稱，思維合不合邏輯
: 其二
: 與其一恰恰相反，

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 211.20.97.42

[國王的新衣]

Post by Yukuan
我終於見識到外星人了 :)
我的見解是，沒錯，你是可以用 function pointer 來解決 OOP
所要試圖處理的抽象化問題，但那也是自討苦吃。

why ?


非OO的程式語法，也有它的抽象模型
而且跟OO比起來，更貼近於真實系統的類比而簡潔
用起來比OO更方便，適用的範圍更廣(軟硬體到行政組織管理)
只是一般人都不知道罷了，所謂自討苦吃之說法從何而來

我想OO會那麼引人注目，是因為它標榜系統模型觀念吧﹗
我相信有許多快被龐大程式碼淹死的人急需要它
只可惜抓到的還是一根草



--
Ξ Origin: 中興大學天樞資訊網 <bbs.nchu.edu.tw>
Ξ From : 61-230-69-84.dynamic.hinet.net

[rendering]

※ 引述《***@bbs.nchu.edu.tw (國王的新衣)》之銘言：
: ※ 引述《***@ptt.cc (Yukuan)》之銘言：
: > 我終於見識到外星人了 :)
: > 我的見解是，沒錯，你是可以用 function pointer 來解決 OOP
: > 所要試圖處理的抽象化問題，但那也是自討苦吃。
: why ?
: 非OO的程式語法，也有它的抽象模型
: 而且跟OO比起來，更貼近於真實系統的類比而簡潔
: 用起來比OO更方便，適用的範圍更廣(軟硬體到行政組織管理)
: 只是一般人都不知道罷了，所謂自討苦吃之說法從何而來
: 我想OO會那麼引人注目，是因為它標榜系統模型觀念吧﹗
: 我相信有許多快被龐大程式碼淹死的人急需要它
: 只可惜抓到的還是一根草


各位大大 小弟無意在此挑起任何論戰

真不好意思 <(_ _)>


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.222.148.171

[s***@kkcity.com.tw]

Post by Yukuan
我終於見識到外星人了 :)
我的見解是，沒錯，你是可以用 function pointer 來解決 OOP
所要試圖處理的抽象化問題，但那也是自討苦吃。
此外， C++ 的 namespace 等跟 OOP 無關的部分，卻很適合在規模
較大的程式中使用。

我想看point痛苦的原因
只是個人不習慣吧

就像有人覺得用循序程式語言(C,C++,basic等)寫程式很困難
用funcational language寫東西才是王道
但是一般人不一定會有同感

個人喜好罷了
我也覺得用C++寫程式搞OO根本是浪費時間
因為我不習慣

就像你覺得不用OO是自討苦吃ㄧ樣
--
┌─────◆ＫＫＣＩＴＹ◆─────┐ ◢╱ 只要你通過身份認證 ~ ◥█
│ bbs.kkcity.com.tw │ █▉─ 免經驗、五人連署即開班系板 ◥
└──《From:61.224.72.26 》──┘ ◥╲ 趕快為班上設個秘密基地吧! ◢

[try or test]

Post by rendering
: > 我終於見識到外星人了 :)
: > 我的見解是，沒錯，你是可以用 function pointer 來解決 OOP
: > 所要試圖處理的抽象化問題，但那也是自討苦吃。
: why ?
: 非OO的程式語法，也有它的抽象模型
: 而且跟OO比起來，更貼近於真實系統的類比而簡潔
: 用起來比OO更方便，適用的範圍更廣(軟硬體到行政組織管理)
: 只是一般人都不知道罷了，所謂自討苦吃之說法從何而來
: 我想OO會那麼引人注目，是因為它標榜系統模型觀念吧﹗
: 我相信有許多快被龐大程式碼淹死的人急需要它
: 只可惜抓到的還是一根草
各位大大 小弟無意在此挑起任何論戰
真不好意思 <(_ _)>

電腦的高階程式語言, 從結構化程設以來就隱涵有 "去勢" 規範化
的企圖, 照規矩來某些事會很方便少出錯, 但某些事就幹不出來.
像高階語言的 FORTRAN 就很不容易像組語寫出 Dirty Program 覆
蓋掉一段程式碼改變執行後的特性.
Object 與 Event 的概念很早就有 (Simul 67), 普及時是在號稱
Software Crisis 的年代, 所以 re-usability 被強調, 但她在很多語
言(例如: Cocurrent High Level Language, Inference AI Language)
之後再被改頭換面提出, 所以被附以很多的期望, OOD(Design), OOP(
Programming), OODB(Database) 四處流行, 在程式語言中抽象說法最
多, 企圖改變整個軟工的程設與實現具體執行的整套對映關係. 但多年
下來, 遷就效率現實也就漸漸不那麼形而上的不切實際.
這裡, C 與 C++ 的老手很多, 對新進想學的還是不妨提出各自的
經驗見解給學習者一些參考.
工程就是有人定的規矩, 規格或規範, 照著做就是耐命可持久, 各
種高階程式語言多多少少是崁入了那些軟體發展上所要的機制. 不順著
概念做, 就會變成像是虛假拐騙, 這就成了程設的絕招秘方或旁門左道
, 這跟算法的奧妙是另外一種不同類型.
程式語言是有特色特性的, 是會限制使用者的思考模式的.

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234

[國王的新衣]

Post by s***@kkcity.com.tw
我想看point痛苦的原因
只是個人不習慣吧

Pointer這種東西，對於程式語言的初學者來說
的確是一個難以了解又麻煩的東西

它卻是循序化程式抽象模型的基礎
個人曾以 “不動產物件的傳遞模型” 來詮釋它
本文可以讓初學者徹底了指標是什麼, 要如何使用
以及它的來由

指標這種東西的出現，來自於硬體上的架構
只要有電腦，就一定有這種東西

當初用了 ”物件” 這個字眼，被誤會成 ”OO”，其實他們是不太相干的東西

我說所有的指標不管它指向什麼，都是32 bit，也被別人挑了好久的語病
正確的說法應該是：指標的位元數應該等於匯流排上硬體位址線數




--
Ξ Origin: 中興大學天樞資訊網 <bbs.nchu.edu.tw>
Ξ From : 61-230-69-84.dynamic.hinet.net

[s***@kkcity.com.tw]

Post by try or test

Post by 璉璉
?
Fortran 不是有向量計算？
最早免費的平行運算函式庫及跨電腦的 PVM (分散式運算)， Fortran 不都可以用？
不過內建語法是沒有啦...

VECTOR FORTRAN 是用在 Vector Computer 不是 Distributed Processor
System . PVM 還是無法讓傳統寫好的 FORTRAN Program 擺上去就能跑, 對於
不是 Shared Memory 的多處理機還是有困難的.

microtasking
但是最好重寫吧 (fortran-d), 再厲害的 compiler 也不能幫你改演算法
研發新工具也是很重要, 值得花錢花人的
很多圖形處理就是天文學系弄出來的, NMR 也是靠自己發明演算法
--
┌─────◆ＫＫＣＩＴＹ◆─────┐KKMAN團隊  全新力作 ◎◎KKBOX◎◎
│ bbs.kkcity.com.tw │知名歌手通通都有  所有新歌想聽就聽
└──《From:59.120.53.7 》──┘※※ 內容豐富多元的線上音樂台 ※※

[眠月..]

Post by 國王的新衣
Pointer這種東西，對於程式語言的初學者來說
的確是一個難以了解又麻煩的東西
它卻是循序化程式抽象模型的基礎
個人曾以 “不動產物件的傳遞模型” 來詮釋它

你那篇論文什麼時候改名字了？

不是《物件導向的不動產模型》嗎？

--
To iterate is human, to recurse is divine. 
遞迴只應天上有, 凡人該當用迴圈. 　 L. Peter Deutsch
--
夫兵者不祥之器物或惡之故有道者不處君子居則貴左用兵則貴右兵者不祥之器非君子
之器不得已而用之恬淡為上勝而不美而美之者是樂殺人夫樂殺人者則不可得志於天下
矣吉事尚左凶事尚右偏將軍居左上將軍居右言以喪禮處之殺人之眾以哀悲泣之戰勝以
喪禮處之道常無名樸雖小天下莫能臣侯王若能守之萬物將自賓天地相合以降甘露民莫
之令而自均始制有名名亦既有夫亦將知止知止218-168-45-117.dynamic.hinet.net海

[三億兩千萬大散戶]

雖然我也不懂物件
不過我覺得C++的auto_ptr蠻好用的
多多使用應該比較不會有memory leak吧
只是要傳pointer前要多加上 &* 比較麻煩一點
--
夫兵者不祥之器物或惡之故有道者不處君子居則貴左用兵則貴右兵者不祥之器非君子
之器不得已而用之恬淡為上勝而不美而美之者是樂殺人夫樂殺人者則不可得志於天下
矣吉事尚左凶事尚右偏將軍居左上將軍居右言以喪禮處之殺人之眾以哀悲泣之戰勝以
喪禮處之道常無名樸雖小天下莫能臣侯王若能守之萬物將自賓天地相合以降甘露民莫
之令而自均始制有名名亦既有夫亦將 203-204-133-140.adsl.static.giga.net.tw海

[汀]

Post by s***@kkcity.com.tw
我想看point痛苦的原因
只是個人不習慣吧
就像有人覺得用循序程式語言(C,C++,basic等)寫程式很困難
用funcational language寫東西才是王道
但是一般人不一定會有同感
個人喜好罷了
我也覺得用C++寫程式搞OO根本是浪費時間
因為我不習慣
就像你覺得不用OO是自討苦吃ㄧ樣

用 C++ 寫 OO 其實可以節省很多時間，
因為 C++ 還有 template 這種程式產生器，
讓 C++ 的 OO 不管是寫起來或是看起來都很精簡，
但是有個前提就是要花很長的時間 study，
不過這個 study 是苦一次就能受用終身。

使用 OO 有一個很重要的原因就是責任轉嫁，
它可以將原本必須在某處集中處理的寫法變成分散處理
（問題本身還是必須集中處理，但是 OO 機制在背後會幫你做一些事情），
集中處理的最大缺點就是每次增加新東西，
就要跑去找到那個集中處理的點來修改程式碼，
分散處理的好處，是要求增加新東西的人多寫一些程式碼，
而集中處理的部分就交給 compiler 產生，
compiler 不會像人一樣有疏失，所以可以很安心。

當然，如果整個程式是你一人維護的，
這兩種方法的差距可能小到讓你看不見，
但是如果是 teamwork，選用前者會帶給大家很多麻煩，
集中處理的另一個缺點，
就是必有一塊程式碼是人人可改（講難聽一點就叫公車，人人可上），
有時候甚至會發生一個人改到另一個人寫的東西，
結果在做 cvs/svn commit 的時候發生 conflict，
然後導致 team 的成員之間互相強姦對方程式碼的現象發生，
這又是更實際面上會碰到的問題...

雖然 OO 這種東西並非純粹為 teamwork 而生，
但是對我而言它的意義純粹是為了 teamwork，
如果你寫的程式是將來打算 open source 給大家改的，
或是這個 project 本身就是要 teamwork，
那麼我會建議使用 OO 來設計。

--
Name: Tseng, Ling-hua E-mail Address: ***@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
╔═══╗ ┼────────────────────────╮
║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮
║ 年少║ ┼╮ < IP：140.119.164.16 > ╰─╮
╚╦═╦╝  ╰  ＊ From：218-171-138-13.dynamic.hinet.net 
 ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎ 

[布丁珍奶加椰果]

Post by 國王的新衣
Pointer這種東西，對於程式語言的初學者來說
的確是一個難以了解又麻煩的東西
它卻是循序化程式抽象模型的基礎
個人曾以 “不動產物件的傳遞模型” 來詮釋它
本文可以讓初學者徹底了指標是什麼, 要如何使用
以及它的來由
指標這種東西的出現，來自於硬體上的架構
只要有電腦，就一定有這種東西
當初用了 ”物件” 這個字眼，被誤會成 ”OO”，其實他們是不太相干的東西
我說所有的指標不管它指向什麼，都是32 bit，也被別人挑了好久的語病
正確的說法應該是：指標的位元數應該等於匯流排上硬體位址線數

從pentium pro開始
x86的address bus就有36bit了...

x86_64的pointer為64bit
不過K8的address bus是40bit
--
※ Origin: SayYA 資訊站 <bbs.sayya.org> 
◆ From: tsugumi.m3.ntu.edu.tw

[GP02]

Post by 眠月..
你那篇論文什麼時候改名字了？
不是《物件導向的不動產模型》嗎？

因為審不過只好換湯不換藥
繼續嘗試

就跟技院審不過換個名字就想升科大一樣

--
╭┼ Origin:  幽谷˙反地球聯邦組織  aeug.twbbs.org 
┼┘ Author: GP02 從 www.mobilemind.com.tw 發表

[眠月..]

Post by 布丁珍奶加椰果

Post by 國王的新衣
我說所有的指標不管它指向什麼，都是32 bit，也被別人挑了好久的語病
正確的說法應該是：指標的位元數應該等於匯流排上硬體位址線數

從pentium pro開始
x86的address bus就有36bit了...
x86_64的pointer為64bit
不過K8的address bus是40bit

大師他都用 #define 出來的東西當作是語言內建型別

還是信誓旦旦的向我們開示 int32 乃 C 語言之內建型別

這早已超脫凡人狹隘的目光 到達 神的境界

我想硬體上面到底有幾條址線對他來說已經完全不重要了

他 神的世界只有一個數字 那就是 32

--
To iterate is human, to recurse is divine. 
遞迴只應天上有, 凡人該當用迴圈. 　 L. Peter Deutsch
--
夫兵者不祥之器物或惡之故有道者不處君子居則貴左用兵則貴右兵者不祥之器非君子
之器不得已而用之恬淡為上勝而不美而美之者是樂殺人夫樂殺人者則不可得志於天下
矣吉事尚左凶事尚右偏將軍居左上將軍居右言以喪禮處之殺人之眾以哀悲泣之戰勝以
喪禮處之道常無名樸雖小天下莫能臣侯王若能守之萬物將自賓天地相合以降甘露民莫
之令而自均始制有名名亦既有夫亦將知止知止218-168-45-117.dynamic.hinet.net海

[唯DVI是圖￣▽￣]

Post by 布丁珍奶加椰果
從pentium pro開始
x86的address bus就有36bit了...

PAE mode 下指標仍然是 32bit.

Post by 布丁珍奶加椰果
x86_64的pointer為64bit
不過K8的address bus是40bit

long-mode 指標 64bit, TLB 64bit address,
cache 64bit address, 出去才會只有 40bit.
--
沒別的意思, 補充而已.

石室詩士施氏，嗜獅，嗜食十獅。氏時時適市視獅，十時，氏適市，適十獅適市。
是時，氏視是十獅，恃十石矢勢，使是十獅逝世。
氏拾是十獅屍，適石室。石室食時，始識是十獅，實十石獅。試釋是事。
原作: 語文學家趙元任 "石室施氏".

--
╭┼ Origin:  幽谷˙反地球聯邦組織  aeug.twbbs.org 
┼┘ Author: dolphi 從 192.168.2.2 發表

[新的人生]

Post by 眠月..

Post by 布丁珍奶加椰果
從pentium pro開始
x86的address bus就有36bit了...
x86_64的pointer為64bit
不過K8的address bus是40bit

大師他都用 #define 出來的東西當作是語言內建型別
還是信誓旦旦的向我們開示 int32 乃 C 語言之內建型別
這早已超脫凡人狹隘的目光 到達 神的境界
我想硬體上面到底有幾條址線對他來說已經完全不重要了
他 神的世界只有一個數字 那就是 32

真是好慘....

總覺得 gsj 一定有搞笑藝人的體質, 怎麼一出手, 就讓我口中的檸檬冰
沙噴到我的 PDP 上了.....

可是我左看右看, gsj 應該是 YA 教授等級才對...

每個字都是對, 但是加起來.........


--
以上的文字都是誤會
看到的一切都是幻覺
--
※ Origin: 土匪．山寨 <bbs.techarea.org / poorman.twbbs.org> 
◆ From: richliu.techarea.org

[Yukuan]

※ 引述《***@bbs.poorman.org (新的人生)》之銘言：
: 真是好慘....
: 總覺得 gsj 一定有搞笑藝人的體質, 怎麼一出手, 就讓我口中的檸檬冰
: 沙噴到我的 PDP 上了.....
: 可是我左看右看, gsj 應該是 YA 教授等級才對...
: 每個字都是對, 但是加起來.........

不用那麼酸吧，大家純粹討論。
雖然我不認同 gsj 的說法，
但我卻能理解他為什麼這麼說。
也許我們太平凡了吧！

Von Neumann 不是也說過：
不用組合語言 coding 不是好的 programmer 嗎？ :)

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.132.186.233

[rendering]

※ 引述《ykjiang (Yukuan)》之銘言：
: ※ 引述《***@bbs.poorman.org (新的人生)》之銘言：
: : 真是好慘....
: : 總覺得 gsj 一定有搞笑藝人的體質, 怎麼一出手, 就讓我口中的檸檬冰
: : 沙噴到我的 PDP 上了.....
: : 可是我左看右看, gsj 應該是 YA 教授等級才對...
: : 每個字都是對, 但是加起來.........
: 不用那麼酸吧，大家純粹討論。
: 雖然我不認同 gsj 的說法，
: 但我卻能理解他為什麼這麼說。
: 也許我們太平凡了吧！
: Von Neumann 不是也說過：
: 不用組合語言 coding 不是好的 programmer 嗎？ :)


推 不用這麼酸

每個人大腦都不太一樣 思考方式也不同

gsj 應該是老手了 會這麼肯定地否定一些東西 一定有過人之處

不一樣的想法 能帶來思考 這是很好的



--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.228.216.204
※ 編輯: renderer 來自: 61.228.216.204 (08/08 21:29)

[汀]

Post by 國王的新衣

Post by s***@kkcity.com.tw
我想看point痛苦的原因
只是個人不習慣吧

Pointer這種東西，對於程式語言的初學者來說
的確是一個難以了解又麻煩的東西
它卻是循序化程式抽象模型的基礎
個人曾以 “不動產物件的傳遞模型” 來詮釋它
本文可以讓初學者徹底了指標是什麼, 要如何使用
以及它的來由
指標這種東西的出現，來自於硬體上的架構
只要有電腦，就一定有這種東西
當初用了 ”物件” 這個字眼，被誤會成 ”OO”，其實他們是不太相干的東西
我說所有的指標不管它指向什麼，都是32 bit，也被別人挑了好久的語病
正確的說法應該是：指標的位元數應該等於匯流排上硬體位址線數

這個在之前跟其他人的討論裡有提過...
C++ 有所謂的 pointer to non-static class member 這種 pointer，
這種 pointer 在一般 pointer 是 32-bit 的環境下，
也可能因為 compiler 的設計而不只有 32-bit，
在目前標題是 C++ 的前提下，你的那句話就會被這種情形否定。

當然，不管是 C 或 C++，
pointer 的 bit 數跟硬體 address bus 的寬度並沒有絕對的關係，
雖然從計算機概論、計算機組織等基礎學科角度出發來判斷是沒錯，
不過不能太過於武斷，
因為總是會有人想出千奇百怪的變化方式來設計硬體。

--
Name: Tseng, Ling-hua E-mail Address: ***@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
╔═══╗ ┼────────────────────────╮
║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮
║ 年少║ ┼╮ < IP：140.119.164.16 > ╰─╮
╚╦═╦╝  ╰  ＊ From：218-171-138-13.dynamic.hinet.net 
 ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎ 
--
 * Modify: tinlans 05/08/08 21:34:29 <218-171-138-13.dynamic.hinet.net> 

[眠月..]

Post by rendering
推 不用這麼酸
每個人大腦都不太一樣 思考方式也不同
gsj 應該是老手了 會這麼肯定地否定一些東西 一定有過人之處
不一樣的想法 能帶來思考 這是很好的

我從來不知道有哪一個自稱 C 語言老手的

會把 define 出來的 int32 當作是內建型別

而且還信誓旦旦的指正別人............

罵別人 C 語言用這麼久竟然不知道有 int32 真是嫩這樣

他討罵不只是因為他常常講錯 更是因為他講錯以後還態度機巴的說別人錯

今天只是酸他 沒有直接噴三字經已經是很客氣了 (′-`)y~

--
To iterate is human, to recurse is divine. 
遞迴只應天上有, 凡人該當用迴圈. 　 L. Peter Deutsch
--
夫兵者不祥之器物或惡之故有道者不處君子居則貴左用兵則貴右兵者不祥之器非君子
之器不得已而用之恬淡為上勝而不美而美之者是樂殺人夫樂殺人者則不可得志於天下
矣吉事尚左凶事尚右偏將軍居左上將軍居右言以喪禮處之殺人之眾以哀悲泣之戰勝以
喪禮處之道常無名樸雖小天下莫能臣侯王若能守之萬物將自賓天地相合以降甘露民莫
之令而自均始制有名名亦既有夫亦將知止知止218-168-45-117.dynamic.hinet.net海

[㊣塞破超人００９]

Post by rendering
每個人大腦都不太一樣 思考方式也不同
gsj 應該是老手了 會這麼肯定地否定一些東西 一定有過人之處

是啊，不讀PL的老手，輕視計算機概論的老手，敝帚自珍的老手，
把我高中時候看雜誌就知道的事情，拿來當他的創見，對別人暮鼓晨鐘的老手，
還真是過人啊。

Post by rendering
不一樣的想法 能帶來思考 這是很好的

那叫思而不學好不好 -_-

---

那麼容易被假先知迷惑
難怪有那麼多人看葉教授
還可以叫太太一塊看 太太不看就打人 鬧到離婚在所不惜
　
--
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
 我們要保證一切的利益都歸於國家與黨。 
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Mk.3(N)  journeyman  - Moderator, Military Board
2-16-2K orig., 9-26-01 dropback 中央大學松濤風情資訊站

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 218-162-234-235.dynamic.hinet

[㊣塞破超人００９]

Post by Yukuan
也許我們太平凡了吧！
Von Neumann 不是也說過：
不用組合語言 coding 不是好的 programmer 嗎？ :)

Von Neumann作古的時候我們都還沒出生 拉那種古代人出來是要幹嘛
他那時候寫的軟體專案最好是比得上現在的複雜度啦

還跟gsj相比哩 少笑死人了
你如果有本事跟他一樣
黑板擦五六次、還記得五六次以前寫在右上角的公式是什麼
那倒是可以把這句話當教條
不然這句話了不起表示他天才的潔癖而已 永遠不表示凡人可以像他那樣努力

引喻失義
　
--
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
 我們要保證一切的利益都歸於國家與黨。 
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Mk.3(N)  journeyman  - Moderator, Military Board
2-16-2K orig., 9-26-01 dropback 中央大學松濤風情資訊站

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 218-162-234-235.dynamic.hinet

[三億兩千萬大散戶]

Post by ㊣塞破超人００９
Von Neumann作古的時候我們都還沒出生 拉那種古代人出來是要幹嘛
他那時候寫的軟體專案最好是比得上現在的複雜度啦
　

我猜以前寫程式大多時間都花在一個byte一個byte斤斤計較
現在則是東西太多太雜了根本學不完
--
夫兵者不祥之器物或惡之故有道者不處君子居則貴左用兵則貴右兵者不祥之器非君子
之器不得已而用之恬淡為上勝而不美而美之者是樂殺人夫樂殺人者則不可得志於天下
矣吉事尚左凶事尚右偏將軍居左上將軍居右言以喪禮處之殺人之眾以哀悲泣之戰勝以
喪禮處之道常無名樸雖小天下莫能臣侯王若能守之萬物將自賓天地相合以降甘露民莫
之令而自均始制有名名亦既有夫亦將 203-204-133-140.adsl.static.giga.net.tw海

[南無阿彌陀佛]

※ 引述《***@bbs.csie.ncu.edu.tw (㊣塞破超人００９)》之銘言：
: > 也許我們太平凡了吧！
: > Von Neumann 不是也說過：
: > 不用組合語言 coding 不是好的 programmer 嗎？ :)
: Von Neumann作古的時候我們都還沒出生 拉那種古代人出來是要幹嘛
: 他那時候寫的軟體專案最好是比得上現在的複雜度啦
: 還跟gsj相比哩 少笑死人了
: 你如果有本事跟他一樣
: 黑板擦五六次、還記得五六次以前寫在右上角的公式是什麼
: 那倒是可以把這句話當教條
: 不然這句話了不起表示他天才的潔癖而已 永遠不表示凡人可以像他那樣努力
: 引喻失義
: 　

插句題外話
這位Von Neumann
是我的偶像
真的不能以常人來看待他
別說黑板擦幾次

曾經讀過報導
好幾年前 讀過一次的書
他可以從頭背出來給你聽
他是過目不忘的 而且不用費力

他的名言 不光只是 「不會寫組語的 算不上是程式設計師」
更有「寫程式？用機械語言就可以了呀...」

這是我看過的報導 不曉得有沒有誇張
他是可以看 binary code 及寫 binary code 的怪物....


--
㊣Origin:《 成大計中 BBS 站 》[bbs.ncku.edu.tw] 來源:[218-171-251-45.dynamic]

[新的人生]

Post by rendering
※ 引述《ykjiang (Yukuan)》之銘言：
: 不用那麼酸吧，大家純粹討論。
: 雖然我不認同 gsj 的說法，
: 但我卻能理解他為什麼這麼說。
: 也許我們太平凡了吧！
: Von Neumann 不是也說過：
: 不用組合語言 coding 不是好的 programmer 嗎？ :)
推 不用這麼酸
每個人大腦都不太一樣 思考方式也不同
gsj 應該是老手了 會這麼肯定地否定一些東西 一定有過人之處
不一樣的想法 能帶來思考 這是很好的

到底這個指標指的是什麼東西
是程式語言(C) 的 Point , 還是指電腦硬體架構的 Address

如果是前者, 和 OS 有關,

如果是後者, 和硬體有關.
但是絕對不是都是 32bits, 也不是和 Address Bus 有絕對的關係.

如果要搞清楚指標是什麼東西,
只要學會計算機組織, 再看過一次 Assembly , 再寫一隻簡單的 C
Deassembly, 就知道什麼是指標了.
這是苦功, 不過保證不需要思考, 就學會了.

如果要學 OO 內的指標, 印像中 Design Patterns 就有講到(老人的印像
不可靠)

講到這個, 如果現在大學畢業生, OS 學好, 計算機組織學好, C/C++ 學好
保證就業輕鬆. 產業界欠人欠的兇呀.
--
以上的文字都是誤會
看到的一切都是幻覺
--
※ Origin: 土匪．山寨 <bbs.techarea.org / poorman.twbbs.org> 
◆ From: richliu.techarea.org

[新的人生]

Post by 三億兩千萬大散戶

Post by ㊣塞破超人００９
Von Neumann作古的時候我們都還沒出生 拉那種古代人出來是要幹嘛
他那時候寫的軟體專案最好是比得上現在的複雜度啦
　

我猜以前寫程式大多時間都花在一個byte一個byte斤斤計較
現在則是東西太多太雜了根本學不完

你害我想到小時候是拿 80x86 Instruction Set 寫程式比賽
再來算, 誰用的 instruction/clock 少.

現在來看這種行為, 實在很豬頭.
不僅僅是指令都是 1 clock 結束, 加上 pipeline/prefetch 等功能....

不過那個年代也因為如此, 早就知道演算法的重要性, clock 少沒有用
演算法正確才是王道.....
--
以上的文字都是誤會
看到的一切都是幻覺
--
※ Origin: 土匪．山寨 <bbs.techarea.org / poorman.twbbs.org> 
◆ From: richliu.techarea.org

[汀]

Post by 南無阿彌陀佛
插句題外話
這位Von Neumann
是我的偶像
真的不能以常人來看待他
別說黑板擦幾次
曾經讀過報導
好幾年前 讀過一次的書
他可以從頭背出來給你聽
他是過目不忘的 而且不用費力
他的名言 不光只是 「不會寫組語的 算不上是程式設計師」
更有「寫程式？用機械語言就可以了呀...」
這是我看過的報導 不曉得有沒有誇張
他是可以看 binary code 及寫 binary code 的怪物....

machine code 跟 assembly code 差只差在有沒有 assembler 自動查表轉換，
和一些簡單的 pseudo instruction，
再來就是一些 macro 而已。

只要會用 assembly code 寫程式的人，
自然就會用 machine code 寫程式，
這沒有什麼好奇怪的，
op code 跟 operands 的 bit 數算好切開，
然後對表查一查而已，
倒不是什麼神奇的事蹟。

--
Name: Tseng, Ling-hua E-mail Address: ***@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
※ Origin: 交大資工鳳凰城資訊站 <bbs.csie.nctu.edu.tw> 
◆ From: 218-171-138-13.dynamic.hinet.net

[try or test]

Post by s***@kkcity.com.tw

Post by try or test

Post by 璉璉
?
Fortran 不是有向量計算？
最早免費的平行運算函式庫及跨電腦的 PVM (分散式運算)， Fortran 不都可以用？
不過內建語法是沒有啦...

VECTOR FORTRAN 是用在 Vector Computer 不是 Distributed Processor
System . PVM 還是無法讓傳統寫好的 FORTRAN Program 擺上去就能跑, 對於
不是 Shared Memory 的多處理機還是有困難的.

microtasking
但是最好重寫吧 (fortran-d), 再厲害的 compiler 也不能幫你改演算法
研發新工具也是很重要, 值得花錢花人的
很多圖形處理就是天文學系弄出來的, NMR 也是靠自己發明演算法

台灣可有研發過任何堪用的程式語言工具 ? 世界上多處理機的系統
很多, 但有那幾種語言工具是物理, 化學界肯一致(多數就好)接受的 ?

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234

[try or test]

Post by Yukuan
Von Neumann 不是也說過：
不用組合語言 coding 不是好的 programmer 嗎？ :)

用記憶體(當時是用音波管當 Shifter Register Memory)儲存程式
碼代替插線跳線板(這就相當於現在的 PROM)的, 就是這位數學家提出
的. 所以今天的循序指令電腦多數還是被稱為 Von Neumann type
machine.
Assembler 轉譯器與組合語言就是他發明的, 是今天所有 Symbolic
Programming Language 的老祖宗, 他的時代如果不用符號化指令寫程式
就是機器碼與跳線板了.

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234

[暗黑貴公子]

※ 引述《***@ptt.cc (rendering)》之銘言：
: 推 不用這麼酸
: 每個人大腦都不太一樣 思考方式也不同
: gsj 應該是老手了 會這麼肯定地否定一些東西 一定有過人之處
: 不一樣的想法 能帶來思考 這是很好的

哈哈

如果你知道 gsj 的豐功偉業, 我相信你會把話收回去 ...

不一樣的想法很好, 前提是 "符合邏輯" 及有著 "能說服他人" 的理由
不然就等於虎爛 ...

真的不必要浪費大家的時間來撰寫討論 "程式語言空想世界" :p


至於 gsj 前面提到的 32 bit, 這也是他鬧出的 #define 大笑話
可以利用 google 翻閱看看

最後, 程式語言只是個工具, 不合用就換別套, 真的不用反過來反過去的
因為這是 "浪費時間" 的行為

況且, 它是不會為個人反對而改變架構
所以囉, 能改變的是自己面對 "程式語言" 的態度

--
※ Origin: 鳥窩 (BirdNest.twbbs.org) ◆ From: cszone

[暗黑貴公子]

※ 引述《***@ptt.cc (Yukuan)》之銘言：
: 不用那麼酸吧，大家純粹討論。
: 雖然我不認同 gsj 的說法，
: 但我卻能理解他為什麼這麼說。
: 也許我們太平凡了吧！
: Von Neumann 不是也說過：
: 不用組合語言 coding 不是好的 programmer 嗎？ :)

Von Neumann 會說出這段話, 我不意外, 因為當時的時空背景考量
當時 "硬體" 尚未發達, 所以使用 Assembly 的份量相當重

所以, 現在呢? :)

--
※ Origin: 鳥窩 (BirdNest.twbbs.org) ◆ From: cszone

[暗黑貴公子]

※ 引述《***@bbs.poorman.org (新的人生)》之銘言：
: 到底這個指標指的是什麼東西
: 是程式語言(C) 的 Point , 還是指電腦硬體架構的 Address
: 如果是前者, 和 OS 有關,
: 如果是後者, 和硬體有關.
: 但是絕對不是都是 32bits, 也不是和 Address Bus 有絕對的關係.
: 如果要搞清楚指標是什麼東西,

指標是人定義出來用來方便 "閱讀/撰寫" 程式碼用的
跟原開發公司有關, 因為產品規格是他們定的

只是原開發公司通常會考量其平台及其他因素, 將其指標 size 定義成方便程式撰寫
的大小

範例 :

1.以 C 來說, 早在好幾年前, 64 bit 的指標已經制定規格
2.現行的 Windows, 有些 API 所使用的定義指標就是 64 bit

: 只要學會計算機組織, 再看過一次 Assembly , 再寫一隻簡單的 C
: Deassembly, 就知道什麼是指標了.
^^^^^^^^^^

更正一下, 是 disassembly :)

--
※ Origin: 鳥窩 (BirdNest.twbbs.org) ◆ From: cszone

[㊣塞破超人００９]

Post by try or test

Post by Yukuan
Von Neumann 不是也說過：
不用組合語言 coding 不是好的 programmer 嗎？ :)

用記憶體(當時是用音波管當 Shifter Register Memory)儲存程式
碼代替插線跳線板(這就相當於現在的 PROM)的, 就是這位數學家提出
的. 所以今天的循序指令電腦多數還是被稱為 Von Neumann type
machine.
Assembler 轉譯器與組合語言就是他發明的, 是今天所有 Symbolic
Programming Language 的老祖宗, 他的時代如果不用符號化指令寫程式
就是機器碼與跳線板了.

他盛年時確實如此，但是他1957年歿，1954年Fortran I誕生，所以他必定
直接或間接對高階語言表示過他的看法。

我這幾年看到好的Von Neumann 中文資料就是這一份，中央數學的單維彰老
師給他的計概講義編的補充教材。這個網站從2000年以後就沒什麼維護，很
多內容也還沒完成，像是Shannon 的傳記就沒有寫出來，非常可惜。

http://libai.math.ncu.edu.tw/bcc16/pool/3.02.shtml

引述其中一段如下

「von Neumann 對今日的電子計算機設計，有決定性的影響。但是他也
有看錯的時候。例如他不認為像FORTRAN 這樣的高階語言是必要的。
他認為直接用機器碼來寫程式就好了。 von Neumann有一個博士班學
生，因為用機器碼太煩了，著手設計組合語言。von Neumann 知道了
以後大為惱火，認為他不該把寶貴的時間浪費在這種無用的工具上。」

所以我認為他這是天才的怪癖。不是苦於工具沒到位，或者順應時勢，而是
以一種接近苦行的態度要求自己和別人。他天生聰明到不像人所以沒差，別
人跟他比總是魯鈍點，就比較難過了。
　
--
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
 我們要保證一切的利益都歸於國家與黨。 
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Mk.3(N)  journeyman  - Moderator, Military Board
2-16-2K orig., 9-26-01 dropback 中央大學松濤風情資訊站

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 218-162-234-235.dynamic.hinet

[try or test]

Post by ㊣塞破超人００９

Post by try or test
Assembler 轉譯器與組合語言就是他發明的, 是今天所有 Symbolic
Programming Language 的老祖宗, 他的時代如果不用符號化指令寫程式
就是機器碼與跳線板了.

他盛年時確實如此，但是他1957年歿，1954年Fortran I誕生，所以他必定
直接或間接對高階語言表示過他的看法。
我這幾年看到好的Von Neumann 中文資料就是這一份，中央數學的單維彰老
師給他的計概講義編的補充教材。這個網站從2000年以後就沒什麼維護，很
多內容也還沒完成，像是Shannon 的傳記就沒有寫出來，非常可惜。
http://libai.math.ncu.edu.tw/bcc16/pool/3.02.shtml
引述其中一段如下
「von Neumann 對今日的電子計算機設計，有決定性的影響。但是他也
有看錯的時候。例如他不認為像FORTRAN 這樣的高階語言是必要的。
他認為直接用機器碼來寫程式就好了。 von Neumann有一個博士班學
生，因為用機器碼太煩了，著手設計組合語言。von Neumann 知道了

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
這段文字怪怪的, 似乎 Von Neumann 不像是符號化指令與組譯器的發明人.
不過, 70 年代的組合語言教科書就已經是如此確定, 90 年代的計概則附上
圖片, 把 Von Neumann 的符號化組合語言及組譯器手寫文件附上.
不過, 有些事的背景與環境要在那個時空才有感覺, 假如用紙帶剪貼原始程
式與載入一個組譯器轉譯要花上幾小時, 那確實不如用人工翻譯好機器碼直
接用 console switch 手按輸入來得有效率. 電腦要有大容量的高速磁碟機
之後才會好用.

Post by ㊣塞破超人００９
以後大為惱火，認為他不該把寶貴的時間浪費在這種無用的工具上。」
所以我認為他這是天才的怪癖。不是苦於工具沒到位，或者順應時勢，而是
以一種接近苦行的態度要求自己和別人。他天生聰明到不像人所以沒差，別
人跟他比總是魯鈍點，就比較難過了。
　

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234

[汀]

Post by 三億兩千萬大散戶

Post by ㊣塞破超人００９
Von Neumann作古的時候我們都還沒出生 拉那種古代人出來是要幹嘛
他那時候寫的軟體專案最好是比得上現在的複雜度啦
　

我猜以前寫程式大多時間都花在一個byte一個byte斤斤計較
現在則是東西太多太雜了根本學不完

不要說專案複雜度，
Von Neumann 先生要是當時看得到 ia64 等等的 VLIW 架構，
他應該就不會想要說那句話了，
除非他真的那麼有耐心人工去做指令排程，
不但要一個 hazard 都沒有，
還要能發揮最高的指令層級平行化。

很多名人講出來的話都不是經過一般化處理過的，
並不見得那個時代講的在現代就有用，
所以中國很多古語都有「後人引伸為xxx的意思」這種現象。

--
Name: Tseng, Ling-hua E-mail Address: ***@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
╔═══╗ ┼────────────────────────╮
║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮
║ 年少║ ┼╮ < IP：140.119.164.16 > ╰─╮
╚╦═╦╝  ╰  ＊ From：218-171-138-13.dynamic.hinet.net 
 ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎ 

[Yukuan]

※ 引述《***@bbs.csie.ncu.edu.tw (try or test)》之銘言：
: > Von Neumann 不是也說過：
: > 不用組合語言 coding 不是好的 programmer 嗎？ :)
: 用記憶體(當時是用音波管當 Shifter Register Memory)儲存程式
: 碼代替插線跳線板(這就相當於現在的 PROM)的, 就是這位數學家提出
: 的. 所以今天的循序指令電腦多數還是被稱為 Von Neumann type
: machine.

　　也因這樣，教科書提到現在電腦架構的限制，都稱為 von Neumann
窠臼。
　　這真是讓我覺得不順眼的，因為像這種天才，不可能沒想到平行運
算的可能，事實上他也跟 Turing 一樣，想得比現在一般人都深入。

　　以下是一篇他相關論述的講稿：
The Computer and the Brain:
http://www.amazon.com/exec/obidos/tg/detail/-/0300084730/102-9909109-5470552?v=glance

: Assembler 轉譯器與組合語言就是他發明的, 是今天所有 Symbolic
: Programming Language 的老祖宗, 他的時代如果不用符號化指令寫程式
: 就是機器碼與跳線板了.

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.132.186.233

[ajax]

Post by 新的人生

Post by 三億兩千萬大散戶
我猜以前寫程式大多時間都花在一個byte一個byte斤斤計較
現在則是東西太多太雜了根本學不完

你害我想到小時候是拿 80x86 Instruction Set 寫程式比賽
再來算, 誰用的 instruction/clock 少.
現在來看這種行為, 實在很豬頭.
不僅僅是指令都是 1 clock 結束, 加上 pipeline/prefetch 等功能....
不過那個年代也因為如此, 早就知道演算法的重要性, clock 少沒有用
演算法正確才是王道.....

還有一位前輩, 朱邦復先生, 也是堅持使用組語的,
他出了一本書, 強調堅持使用組語的理由,
還計算不同的loop安排, cycle差多少,
他後來把一些資料放出來,
可是看他的程式, 只要jmp 幾次,
就已不知身在何處了.
要讓成果能夠流傳下去, 高階語言還是較佳的選擇.

--
PHP OpenWiki: http://if176.aca.ntu.edu.tw/openwiki
--
※ Origin: 交大資工鳳凰城資訊站 <bbs.csie.nctu.edu.tw> 
◆ From: if159.aca.ntu.edu.tw

[FreeZ]

Post by ajax
還有一位前輩, 朱邦復先生, 也是堅持使用組語的,
他出了一本書, 強調堅持使用組語的理由,
還計算不同的loop安排, cycle差多少,
他後來把一些資料放出來,
可是看他的程式, 只要jmp 幾次,
就已不知身在何處了.
要讓成果能夠流傳下去, 高階語言還是較佳的選擇.

有人在玩這個, 其實是件好事! 因為我們可以把那些
"人工最佳化" 過的 routines, 包起來 call 用.

在國內的討論站, 比較少看到網友在比誰寫的最短最快.
在國外的討論站, 就比較常看到.

當看到好用的東西時, 就把它撿起來, 包成元件、function !

平常沒事, 跟網友們玩 "人工最佳化" . 有 case 時,
就直接搜刮過來 call 用了, 那裡還需要自己來.

--
Free Tech (Win32Asm, Electronics..)
http://freetech.cjb.net/
Updated: April-15, 2004 / 14:35

[sjgau]

我覺得 一切的一切，要跟現實的需求吻合
先使用高階語言來實作演算法
沒有問題之後，看需要來增加速度
針對某些 經常使用的程式片段
把compile 出來的組合語言
拿來用 人工重寫

如果不需要的話，就直接可以交差
我之前的方式，一個問題的解決
可以橫跨 PE2, fortran, pascal, AutoCAD LISP
然後，user 感覺不出來

我給他一個 batch file
全自動的在 週而復始，
時間上面的花費，user 可以接受就好了



※ 引述《***@bbs.csie.nctu.edu.tw (ajax)》之銘言：
: ※ 引述《***@bbs.poorman.org (新的人生)》之銘言：
: > 你害我想到小時候是拿 80x86 Instruction Set 寫程式比賽
: > 再來算, 誰用的 instruction/clock 少.
: > 現在來看這種行為, 實在很豬頭.
: > 不僅僅是指令都是 1 clock 結束, 加上 pipeline/prefetch 等功能....
: > 不過那個年代也因為如此, 早就知道演算法的重要性, clock 少沒有用
: > 演算法正確才是王道.....
: 還有一位前輩, 朱邦復先生, 也是堅持使用組語的,
: 他出了一本書, 強調堅持使用組語的理由,
: 還計算不同的loop安排, cycle差多少,
: 他後來把一些資料放出來,
: 可是看他的程式, 只要jmp 幾次,
: 就已不知身在何處了.
: 要讓成果能夠流傳下去, 高階語言還是較佳的選擇.

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 210.243.237.65

[sjgau]

我從 1989 年就開始看 OO 的書
看到現在
OO 還是 OO, 我還是我

但是，我女兒最近念 資工系
一開始就是 OO
她就很自然的接受 OO的觀念

後來，我去 清大的自強基金會聽課
VC + MFC 的課
雖然成果有限，但是
卻讓我了解，OO 的確是有需要

我寫過需要使用 stack 的程式
自己 matain 好幾個 stack 的時候，好累
但是，看老師用 OO 來包裝，
輕鬆愉快。

所以，我終於承認，
OO 有他的 實用價值


※ 引述《sjgau (sjgau)》之銘言：
: 我覺得 一切的一切，要跟現實的需求吻合
: 先使用高階語言來實作演算法
: 沒有問題之後，看需要來增加速度
: 針對某些 經常使用的程式片段
: 把compile 出來的組合語言
: 拿來用 人工重寫
: 如果不需要的話，就直接可以交差
: 我之前的方式，一個問題的解決
: 可以橫跨 PE2, fortran, pascal, AutoCAD LISP
: 然後，user 感覺不出來
: 我給他一個 batch file
: 全自動的在 週而復始，
: 時間上面的花費，user 可以接受就好了
: ※ 引述《***@bbs.csie.nctu.edu.tw (ajax)》之銘言：
: : 還有一位前輩, 朱邦復先生, 也是堅持使用組語的,
: : 他出了一本書, 強調堅持使用組語的理由,
: : 還計算不同的loop安排, cycle差多少,
: : 他後來把一些資料放出來,
: : 可是看他的程式, 只要jmp 幾次,
: : 就已不知身在何處了.
: : 要讓成果能夠流傳下去, 高階語言還是較佳的選擇.

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 210.243.237.65

[打球!]

Post by 國王的新衣

Post by rendering
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
啊 此話怎說

花時間去解決這本來就可以不存在的問題，本來就是浪費時間

因為你沒處理過巨大的,大量模組的,持續發展的專案,你才會覺得OO只是fancy


--
╭ From: plum.cs.nccu.edu.tw ◎──────────╮
└──◎  Origin:政大資科˙貓空行館  bbs.cs.nccu.edu.tw ┘

[rendering]

※ 引述《***@bbs.csie.nctu.edu.tw (ajax)》之銘言：
: 還有一位前輩, 朱邦復先生, 也是堅持使用組語的,
: 他出了一本書, 強調堅持使用組語的理由,
: 還計算不同的loop安排, cycle差多少,
: 他後來把一些資料放出來,
: 可是看他的程式, 只要jmp 幾次,
: 就已不知身在何處了.
: 要讓成果能夠流傳下去, 高階語言還是較佳的選擇.


推 不是推組語
是推朱邦復先生

Google 了一下
發現他是一位頗有成就的前輩
四十二歲學電腦
然後發明了倉頡輸入法
...

http://www.cbflabs.com/


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.222.148.171

[夜班玫瑰]

Post by sjgau
: 還有一位前輩, 朱邦復先生, 也是堅持使用組語的,
: 他出了一本書, 強調堅持使用組語的理由,
: 還計算不同的loop安排, cycle差多少,
: 他後來把一些資料放出來,
: 可是看他的程式, 只要jmp 幾次,
: 就已不知身在何處了.
: 要讓成果能夠流傳下去, 高階語言還是較佳的選擇.
推 不是推組語
是推朱邦復先生
Google 了一下
發現他是一位頗有成就的前輩
四十二歲學電腦
然後發明了倉頡輸入法
...
http://www.cbflabs.com/

幫您補充一下 後來朱先生和宏碁合作 推出一款「天龍中文字形產生器」
宏碁和當年的MPFII（小教授）搭配
在民國72年一組電腦+中文 要賣25000

朱先生認為中文字是祖先的遺產 不能拿來賣錢
憤而和宏碁分手 轉投入另一家新的軟體公司合作
推出了第一套台灣中文字形 飛碟2號

沒錯～～！！就是倚天中文


至於為何叫倚天？ 是不是要屠龍？
不在C++的討論範圍之內


唉～～我可憐的JAVA 會不會被.NET幹掉？

--

冷眼看裟婆

笑臉對人生
--
* Origin: 中山大學-美麗之島BBS * From: 59.113.172.222

[try or test]

Post by 夜班玫瑰

Post by sjgau
: 還有一位前輩, 朱邦復先生, 也是堅持使用組語的,
四十二歲學電腦
然後發明了倉頡輸入法
...
http://www.cbflabs.com/

幫您補充一下 後來朱先生和宏碁合作 推出一款「天龍中文字形產生器」
宏碁和當年的MPFII（小教授）搭配
在民國72年一組電腦+中文 要賣25000

宏碁買了朱先生的專利(中文鍵盤符號位置)裝到與電子所合作仿製的 Zilog
MDS 有碟系統, 每台價位是約 25 萬, 朱先生的中文是偏旁合成產生器, 流
傳出來的是以 64 KB 的 Z80 組語寫成的 Binary code, 內碼就是輸入序的
鍵盤字. 使用 7 segment LED 的小教授無法顯示中文, 必須使用 TV
Mornitor 與磁帶的 PA800 或有碟加裝 Z80 cpu 卡的 APPLE II 才能執行.

Post by 夜班玫瑰
朱先生認為中文字是祖先的遺產 不能拿來賣錢
憤而和宏碁分手 轉投入另一家新的軟體公司合作
推出了第一套台灣中文字形 飛碟2號
沒錯～～！！就是倚天中文

倚天中文軟碟版是在國喬中文軟碟之後, 這是使用資策會的 16*16 , 24*24
點矩陣字形用於 IBM 相容 PC , 內碼就改用 BIG5 代替不等長度的鍵入碼,
倚天軟體中文記取國喬的保護碟被破解, 硬體卡被盜拷的教訓, 就是兩片軟
碟 500 元.

從 Zilog 的天龍中文 到 倚天中文軟碟 之間 (1982-1986 ?) 有段時間朱先
生是遠避(聽說是票據法)到海外.

Post by 夜班玫瑰
至於為何叫倚天？ 是不是要屠龍？
不在C++的討論範圍之內
唉～～我可憐的JAVA 會不會被.NET幹掉？

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234

[國王的新衣]

Post by ajax
可是看他的程式, 只要jmp 幾次,
就已不知身在何處了.
要讓成果能夠流傳下去, 高階語言還是較佳的選擇.

一個程式如果的Function 的Call path 太多，讓你有雲深不知處的感覺
你可畫一張Call path drawing (Map)，那就非常清楚了
同樣的，如果Struct種類太多，關連性過於複雜，也可畫一張物件關連Map
(Object relative map) 就可一目了然了

這個動作對於開發大程式來說(1000行以上)，是非常需要且基本的動作
但是我從來沒有看到有一本書提到它，大概這些人也沒什麼寫大程式的經驗吧

對一個常在電腦上的 GUI上Click來，Click去的人來說，OO的觀念的確好上手
但我相信它適用的Domain 也就只有到這邊為止

Range 再擴大就有問題了

不管OO在高階上來帶來多好處，不要忘記一件事
高階的東西畢竟要由低階來實作完成

而低階到最後，CPU的運作都是循序式，而不是物件導向式
CPU內部的Address Segment 暫存器，
一開始就是分成Data Segment 及 Code Segment 兩大類

只要電腦還是三大元素的架構 (CPU、Memory、IO)
循序式的東西就永遠不死

我很早就說過OO的Class語法，將Code與Data 搞在一起，
這是從出發點就錯誤了，
程式語言與硬體開始有了 "不對稱 " 的問題
所以程式越是發展，毛病也就越多

你知不知道物件別名(Alias) 這種東西是怎麼來的嗎？
為什麼會有這種東西的存在？是為了加強程式語言的功能而存在的嗎？
有心人可以去查查原因，那是語法與硬體的不對稱性，造成了大漏洞
為了補丁，才有這種東西存在的。




--
Ξ Origin: 中興大學天樞資訊網 <bbs.nchu.edu.tw>
Ξ From : 220-138-241-227.dynamic.hinet.net
Ξ Modify: 2005/08/09 Tue 21:40:08

[Gundam Pilot]

Post by 國王的新衣
一個程式如果的Function 的Call path 太多，讓你有雲深不知處的感覺
你可畫一張Call path drawing (Map)，那就非常清楚了
同樣的，如果Struct種類太多，關連性過於複雜，也可畫一張物件關連Map
(Object relative map) 就可一目了然了
這個動作對於開發大程式來說(1000行以上)，是非常需要且基本的動作
但是我從來沒有看到有一本書提到它，大概這些人也沒什麼寫大程式的經驗吧
對一個常在電腦上的 GUI上Click來，Click去的人來說，OO的觀念的確好上手
但我相信它適用的Domain 也就只有到這邊為止

終於~~
傳說中的Domain出現了
可說是千呼萬喚使出來
最期待就是這句話了

不過...您對OO的了解只到GUI的呈獻嗎??
..那VB也算OO歐~_~|

Post by 國王的新衣
Range 再擴大就有問題了
不管OO在高階上來帶來多好處，不要忘記一件事
高階的東西畢竟要由低階來實作完成
而低階到最後，CPU的運作都是循序式，而不是物件導向式
CPU內部的Address Segment 暫存器，
一開始就是分成Data Segment 及 Code Segment 兩大類
只要電腦還是三大元素的架構 (CPU、Memory、IO)
循序式的東西就永遠不死
我很早就說過OO的Class語法，將Code與Data 搞在一起，
這是從出發點就錯誤了，

請用google搜詢一下MVC
Model-View-Controller
他會教您如何將Logic與Data和UI抽離

不過當然...以您對OO的了解,要弄懂MVC並實做他是有些許的困難啦

Post by 國王的新衣
程式語言與硬體開始有了 "不對稱 " 的問題
所以程式越是發展，毛病也就越多
你知不知道物件別名(Alias) 這種東西是怎麼來的嗎？
為什麼會有這種東西的存在？是為了加強程式語言的功能而存在的嗎？
有心人可以去查查原因，那是語法與硬體的不對稱性，造成了大漏洞
為了補丁，才有這種東西存在的。

--
╭┼ Origin:  幽谷˙反地球聯邦組織  aeug.twbbs.org 
┼┘ Author: GP03 從 zanka.idv.tw 發表

[㊣塞破超人００９]

Post by try or test

Post by 夜班玫瑰
幫您補充一下 後來朱先生和宏碁合作 推出一款「天龍中文字形產生器」
宏碁和當年的MPFII（小教授）搭配
在民國72年一組電腦+中文 要賣25000

宏碁買了朱先生的專利(中文鍵盤符號位置)裝到與電子所合作仿製的 Zilog
MDS 有碟系統, 每台價位是約 25 萬, 朱先生的中文是偏旁合成產生器, 流
傳出來的是以 64 KB 的 Z80 組語寫成的 Binary code, 內碼就是輸入序的
鍵盤字. 使用 7 segment LED 的小教授無法顯示中文, 必須使用 TV
Mornitor 與磁帶的 PA800 或有碟加裝 Z80 cpu 卡的 APPLE II 才能執行.

那更早了
用7seg的MPF-I沒真的進入過家庭或商用市場
而以上Ｙ氏講的天龍中文HCG套件
搭配的MPF-II一定要外接monitor或用RF adapter接電視才有顯示
我聽到的價格更貴 要五萬

同期這種家用電腦的中文系統也有別人在做 例如神通
而以我身為MPF-II owner的觀點來看，小教授輸小神通真是輸到脫褲都不夠
　
--
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
 我們要保證一切的利益都歸於國家與黨。 
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Mk.3(N)  journeyman  - Moderator, Military Board
2-16-2K orig., 9-26-01 dropback 中央大學松濤風情資訊站

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 218-162-234-235.dynamic.hinet

[打球!]

Post by 國王的新衣
我很早就說過OO的Class語法，將Code與Data 搞在一起，
這是從出發點就錯誤了，

這道理很淺,低階的東西更動的機會不高,可是上面的應用卻不停變更
循序式的東西當然不容易死,可是並不善於處理不停變更/更新的狀況

GUI可是大學問,不是甚麼點來點去那麼輕巧

--
運行的星星是我的身影 逝去的星星是我的眼淚 *
握在我手中的回憶 像是星星的碎片一樣散落了 * *
但是我依然相信 *   *
這是一個永遠不會醒來的夢 *  * *
......... * *
魎呼 永遠永遠的星之夢

--
╭ From: plum.cs.nccu.edu.tw ◎──────────╮
└──◎  Origin:政大資科˙貓空行館  bbs.cs.nccu.edu.tw ┘

[三億兩千萬大散戶]

Post by Gundam Pilot
請用google搜詢一下MVC
Model-View-Controller
他會教您如何將Logic與Data和UI抽離
不過當然...以您對OO的了解,要弄懂MVC並實做他是有些許的困難啦

用BCB寫程式常常都會把data跟UI混在一起
因為它的架構似乎就是引導你這樣去寫
如果又把data抽離好像又會多浪費記憶體空間多此一舉的感覺
這方面MFC的document-view架構或許比較好吧(我也不懂)
例如資料庫讀資料進來就show在StringGrid上
處理資料也都是直接從StringGrid的Cell中取出處裡
但是寫到後來會越來越亂
--
夫兵者不祥之器物或惡之故有道者不處君子居則貴左用兵則貴右兵者不祥之器非君子
之器不得已而用之恬淡為上勝而不美而美之者是樂殺人夫樂殺人者則不可得志於天下
矣吉事尚左凶事尚右偏將軍居左上將軍居右言以喪禮處之殺人之眾以哀悲泣之戰勝以
喪禮處之道常無名樸雖小天下莫能臣侯王若能守之萬物將自賓天地相合以降甘露民莫
之令而自均始制有名名亦既有夫亦將 203-204-133-140.adsl.static.giga.net.tw海

[汀]

Post by 國王的新衣
但是我從來沒有看到有一本書提到它，大概這些人也沒什麼寫大程式的經驗吧
對一個常在電腦上的 GUI上Click來，Click去的人來說，OO的觀念的確好上手
但我相信它適用的Domain 也就只有到這邊為止

其實我倒不覺得 OO 跟 GUI 有什麼直接的關連性，
也許是因為我從來都不寫 GUI，
也不用 IDE 開發程式，
但是卻常使用 OO 的關係。

如果 OO 會讓人有這種奇怪的想法，
我想這應該是商品化的 IDE 環境，
或是重視 GUI 設計的這個時代，
所帶給人的錯覺。

Post by 國王的新衣
Range 再擴大就有問題了
不管OO在高階上來帶來多好處，不要忘記一件事
高階的東西畢竟要由低階來實作完成
而低階到最後，CPU的運作都是循序式，而不是物件導向式

如果這樣想，
那就背離了高階語言當初被設計出來的目的和意義，
當然，若是你的專案與那些目的和意義無關，
你大可使用低階語言實作，
這也是為什麼現在只會低階語言的人還不會餓死的原因，
從來就沒有書上會告訴人說高階語言是解決一切問題的最佳工具。

高階語言本身是經過一些取捨後才被創造出來的，
使用的人必須自行評估這些取捨是否對目前的狀況來說很划算，
而非盲目的去使用高階語言。

Post by 國王的新衣
CPU內部的Address Segment 暫存器，
一開始就是分成Data Segment 及 Code Segment 兩大類
只要電腦還是三大元素的架構 (CPU、Memory、IO)
循序式的東西就永遠不死

但是，這跟高階語言存在的目的和意義並不相違。

Post by 國王的新衣
我很早就說過OO的Class語法，將Code與Data 搞在一起，
這是從出發點就錯誤了，
程式語言與硬體開始有了 "不對稱 " 的問題
所以程式越是發展，毛病也就越多

這倒沒有你想的那麼糟糕，
事實上使用 class 這種東西的人，
只要他也學過一些簡單的低階語言，
多多少少還是知道 class data meber 和 class member function 會放在哪，
把它們放在一起只不過是為了在語言層面，
就規定好哪些 data 只允許哪些 code 存取罷了，
可以避免有人拿不適當的 code 對不適當的 data 做運算，
這只是一種保護機制，倒也不是什麼危害觀念的重大陷阱。

另外，即使有些沒學過低階語言的人真的誤解了，
那也不過代表他們工作的需求並不需要懂到那麼低階，
因為每個人時間有限，
在這個時代有些人生來就是不需要懂那麼多，
只需要專心做好表層上的東西就好。

--
Name: Tseng, Ling-hua E-mail Address: ***@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
╔═══╗ ┼────────────────────────╮
║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮
║ 年少║ ┼╮ < IP：140.119.164.16 > ╰─╮
╚╦═╦╝  ╰  ＊ From：218-171-138-13.dynamic.hinet.net 
 ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎ 

[柔麗招來]

※ 引述《***@bbs.poorman.org (新的人生)》之銘言：
: ※ 引述《***@bbs.wretch.cc (三億兩千萬大散戶)》之銘言：
: > 我猜以前寫程式大多時間都花在一個byte一個byte斤斤計較
: > 現在則是東西太多太雜了根本學不完
: 你害我想到小時候是拿 80x86 Instruction Set 寫程式比賽
: 再來算, 誰用的 instruction/clock 少.
: 現在來看這種行為, 實在很豬頭.
: 不僅僅是指令都是 1 clock 結束, 加上 pipeline/prefetch 等功能....
: 不過那個年代也因為如此, 早就知道演算法的重要性, clock 少沒有用
: 演算法正確才是王道.....
assembly 還是有它的妙用, 可以拿來對 critical function 最佳化.
一個 function 被 call 個千萬次的時候, 每一行 code 可以說是寸土寸金.

而且, SIMD 有許多觀念也是從傳統的 assembly 來的.
比如說清空 register 用 xor 而非 mov, 可以減少 memory access.

而演算法還是有其極限, 相同的演算法還是可以有不同的 implement 方式.
同樣是整數乘法跟加法, 在 SIMD 裡用 pmull 或 pmadd 會有些差別.
同樣是浮點轉整數, 是否重設 rounding mode 速度可以差到三倍之多.

優秀的演算法可以讓效能大進, 而優秀的程式技巧可以錦上添花.
演算法廣為人知的時候, 要拼的就是程式技巧了.


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 210.85.8.143

[try or test]

Post by 國王的新衣
高階的東西畢竟要由低階來實作完成
而低階到最後，CPU的運作都是循序式，而不是物件導向式
CPU內部的Address Segment 暫存器，
一開始就是分成Data Segment 及 Code Segment 兩大類

======
code, data, stack 分開各放一堆是 X86 processor 的特有架構,
這是有原因的.
1. 呼應 High Level Language Compiler 產生的 code, data 就是分開的.
2. code , data 分離比較難發生 dirty program (把 code 當 data 處理)
現像.
3. code 與 data 的 fetch 可以分離, 平行. instruction code 較容易
pipeline prefetch 與 branch prediction.
4. Code Area 可以使用 ROM .
5. 隔離可防錯, 也易於除錯, 也配合下層的系統支援.

Post by 國王的新衣
只要電腦還是三大元素的架構 (CPU、Memory、IO)
循序式的東西就永遠不死
我很早就說過OO的Class語法，將Code與Data 搞在一起，
這是從出發點就錯誤了，
程式語言與硬體開始有了 "不對稱 " 的問題
所以程式越是發展，毛病也就越多

傳統的程式概念跟 Class Object 最接近的就是 OS 裡的 Synchronization
Monitor, 現代的 OO 配合分散式多處理(機)的用法, 把呼叫另一台機器(不同的
process 可以想像成是在不同的 Virtual Machine 上)Mornitor 所需要傳送參數
與資料的部份, 一律改用 message passing 的抽象概念來代替. 即使是單機上的
程式, 一旦涉及不同 Process 間的來往, 在不同 process 使用不同的 virtual
memory space 隔離使用下, 這是難有 shared memory 的做法與效率, 為了這個
分散隔離的缺點, user mode 下同一 process 的 multi-thread 就應運而生. 把
process 或 mornitor 都想像為隔離的 Virtual Machine , 每個 machine 有其
多個 code threads 或 function code procedure , 可使用 sharable data
memory . 這時候的一個 class 有很多 methods 就像一個 mornitor 提供有很多
procedure 可以從單一入口進入封裝的空間(含 code , data, stack)進行啟動
代理(invoking)的工作.
在 process , mornitor 或 virtual machine 的概念裡, 用到的 code ,
data 當然得擺在其勢力範圍可及之處, 所以 code 與 data 甚至臨時工作的
stack 都得封裝在一起.
OOP 強調的是抽象的概念, 不必去管跟實體是如何對應的, 當然, 抽象的
物件絕對得建立在實體之上, 近代化的 OO 是同時具有 shared memory (user
space multi-thread) 與 distributed processing (network message passing)
的二元性, 在何處該如何用, 那是 compiler 與 linker/binder 的事.
======
用組合語言(或機器碼)寫程式, 要怎麼擺, 怎麼傳送與叫用, 怎麼做記號
解譯, 都是可以 "無法無天" 的, 但也是雜亂無序的根源. 高階程式語言, 尤其
是 OO , 就是希望初學者只要有上層抽象概念後, "不知亦能行", 然後習慣了就
自然成為 "有文明素養" 的資訊良民.
在一個 single user space 下的應用程式, 只要沒有併行同步的需求, 使
用 shared memory 的概念是最簡潔仍然有高效的, 那就相當於把一個傳統的 C
程式, 共用到相同 data 的同一群 function code 全都塞在同一個 class 下就
可以了.
抽象化的高階語言最怕的就是跟其理念模式相違反的用法, 就像裝輪子的
機器人卻偏要叫他去爬樓梯. 不過, OO 卻像裝了腳也有輪子在上面的機器人, 怕
的是用錯道具. 組合語言則是一切道具都可以自己來, 但不會用現有的組裝就會
耗掉寶貴的生命時間.

Post by 國王的新衣
你知不知道物件別名(Alias) 這種東西是怎麼來的嗎？
為什麼會有這種東西的存在？是為了加強程式語言的功能而存在的嗎？
有心人可以去查查原因，那是語法與硬體的不對稱性，造成了大漏洞
為了補丁，才有這種東西存在的。

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234

[s***@kkcity.com.tw]

Post by try or test

Post by s***@kkcity.com.tw
microtasking
但是最好重寫吧 (fortran-d), 再厲害的 compiler 也不能幫你改演算法
研發新工具也是很重要, 值得花錢花人的
很多圖形處理就是天文學系弄出來的, NMR 也是靠自己發明演算法

台灣可有研發過任何堪用的程式語言工具 ? 世界上多處理機的系統
很多, 但有那幾種語言工具是物理, 化學界肯一致(多數就好)接受的 ?

用純 software 早已不夠, 都是靠 asic+專用 compiler
DNA 運算需要的東西, 核彈模擬需要的東西, 就算是電視的 MPEG codec
general purpose processor 當然不適用
作前瞻研究那還有一致的工具, 生產線才用一致的工具
臺灣現在沒有不代表不可以做, cray 的 team 也只有 7 個人
使用者不肯花錢卻迷信歐美比較多吧
--
┌─────◆ＫＫＣＩＴＹ◆─────┐ＫＫ免費撥接‧上網不用錢 。。。───┐
│ bbs.kkcity.com.tw │電話:449-1999 帳號:kkcity 密碼:kkcity│
└──《From:59.120.53.7 》──┘ 。。。──────────────＊╯

[try or test]

Post by s***@kkcity.com.tw

Post by try or test

Post by s***@kkcity.com.tw
microtasking
但是最好重寫吧 (fortran-d), 再厲害的 compiler 也不能幫你改演算法
研發新工具也是很重要, 值得花錢花人的

台灣可有研發過任何堪用的程式語言工具 ? 世界上多處理機的系統
很多, 但有那幾種語言工具是物理, 化學界肯一致(多數就好)接受的 ?

用純 software 早已不夠, 都是靠 asic+專用 compiler
DNA 運算需要的東西, 核彈模擬需要的東西, 就算是電視的 MPEG codec
general purpose processor 當然不適用
作前瞻研究那還有一致的工具, 生產線才用一致的工具
臺灣現在沒有不代表不可以做, cray 的 team 也只有 7 個人
使用者不肯花錢卻迷信歐美比較多吧

========
有這種想法與企圖絕對要肯定與鼓勵. 不過, 時間點應該是在 199X 的
初期, 我們今天多數學校的廁所是電動偵測沖水, 也供應衛生紙是那個時候
才開始普及的, 台灣要在科學的先進領域靠儀器設備而不是理論分析, 做前
無古人的探索, 那還要再加幾個 order 的財富.
在 1990 聽見 CRAY 公司的人說銀行團評估他們不如台灣的 ACER 時,
我們是愣住了, 但那些看財務報表的確實有過人之處.
CRAY 快敗時的研發 Team 確實只有十人不到, 不過, CRAY 從 CDC 起
家時並非如此. CRAY 公司是因 "日本第一" 賺錢之後, 跟美國搶 3C
(Computer, Car, Color TV)的龍頭寶座, 美國政府也採日本通產省補貼策
略, 不計代價扶植的國寶級產物.
現在的台灣資訊產業可能是求生存, 不萎縮, 賺到錢為第一要務 !


--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234

[W***@bbs.cs.nthu.edu.tw]

Post by 國王的新衣

Post by ajax
可是看他的程式, 只要jmp 幾次,
就已不知身在何處了.
要讓成果能夠流傳下去, 高階語言還是較佳的選擇.

一個程式如果的Function 的Call path 太多，讓你有雲深不知處的感覺
你可畫一張Call path drawing (Map)，那就非常清楚了
同樣的，如果Struct種類太多，關連性過於複雜，也可畫一張物件關連Map
(Object relative map) 就可一目了然了
這個動作對於開發大程式來說(1000行以上)，是非常需要且基本的動作
但是我從來沒有看到有一本書提到它，大概這些人也沒什麼寫大程式的經驗吧

相關類似的圖在OO的UML裡講到快爛掉了 你老兄從不看OO的書自然沒機會看到
典型的坐井觀天...

class diagram, object diagram, sequence diagram.
都可描述物件間的關連.. 拜託去翻翻書再來吧

前面有位網友說你是思而不學的 我覺得真的是說得貼切極了 ...

Post by 國王的新衣
對一個常在電腦上的 GUI上Click來，Click去的人來說，OO的觀念的確好上手
但我相信它適用的Domain 也就只有到這邊為止
Range 再擴大就有問題了

又來了... 過一段時間就來說笑...

Post by 國王的新衣
不管OO在高階上來帶來多好處，不要忘記一件事
高階的東西畢竟要由低階來實作完成
而低階到最後，CPU的運作都是循序式，而不是物件導向式
CPU內部的Address Segment 暫存器，
一開始就是分成Data Segment 及 Code Segment 兩大類
只要電腦還是三大元素的架構 (CPU、Memory、IO)
循序式的東西就永遠不死
我很早就說過OO的Class語法，將Code與Data 搞在一起，
這是從出發點就錯誤了，
程式語言與硬體開始有了 "不對稱 " 的問題
所以程式越是發展，毛病也就越多

寫了那麼久的程式你還是不懂什麼是Abstraction...
以及OO跟event driven 是兩回事..

我看你還是回去寫你的assembly language吧...

Post by 國王的新衣
你知不知道物件別名(Alias) 這種東西是怎麼來的嗎？
為什麼會有這種東西的存在？是為了加強程式語言的功能而存在的嗎？
有心人可以去查查原因，那是語法與硬體的不對稱性，造成了大漏洞
為了補丁，才有這種東西存在的。

誰誰誰看得懂的.. 解釋一下吧...
--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: NK219-91-111-135.adsl.dynamic.apol.com.tw

[try or test]

自認對 OO 精通的人應該要能回答 gsj 的質疑才是, 否則 OO 就如其音,
黑黑來, 黑黑去, 黑壓壓的一片.

Post by W***@bbs.cs.nthu.edu.tw

Post by 國王的新衣
不管OO在高階上來帶來多好處，不要忘記一件事
高階的東西畢竟要由低階來實作完成
而低階到最後，CPU的運作都是循序式，而不是物件導向式

物件導向 或 OOP 不知是否有特別強調 "非循序式" ? 印象中至少不是被
列為是 parallel programming 或 concurrent high level language .
學 OO 的要怎麼回答 ?

Post by W***@bbs.cs.nthu.edu.tw

Post by 國王的新衣
CPU內部的Address Segment 暫存器，
一開始就是分成Data Segment 及 Code Segment 兩大類
只要電腦還是三大元素的架構 (CPU、Memory、IO)
循序式的東西就永遠不死
我很早就說過OO的Class語法，將Code與Data 搞在一起，
這是從出發點就錯誤了，
程式語言與硬體開始有了 "不對稱 " 的問題
所以程式越是發展，毛病也就越多

寫了那麼久的程式你還是不懂什麼是Abstraction...
以及OO跟event driven 是兩回事..
我看你還是回去寫你的assembly language吧...

在 object 封裝的內部對 data , code 是可以雜亂交錯, 你中有我,
我中有你那樣的混在一起, 還是分堆但包在封袋裡 ? 顯然 gsj 指出
了 OO 讓人看不清楚無法理解的一面.

如果程式語言與電腦的實體是不對稱的, 那這個質疑是有道理的, 這
不能用 abstraction 一筆帶過, 否則會被懷疑 OOP 是有效率的嗎 ?
不然就是效率的稍微(這也得具體說明)犧牲, 可換來那些更值得的東
東 ? 譬如 Interactive 的 interpreter 相對於 compiler , 另外,
就是改善的趨勢會是甚麼 ? (譬如使用中間碼的 interpreter)

其次, 在那些地方或條件下, OOP 可以像一般的 C 使用 pointer
那樣方便的 reference structured data (如 array 或 record) ?

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234

[待救的小米]

※ 引述《***@bbs.csie.ncu.edu.tw (try or test)》之銘言：
: 自認對 OO 精通的人應該要能回答 gsj 的質疑才是, 否則 OO 就如其音,
: 黑黑來, 黑黑去, 黑壓壓的一片.
: 物件導向 或 OOP 不知是否有特別強調 "非循序式" ? 印象中至少不是被
: 列為是 parallel programming 或 concurrent high level language .
: 學 OO 的要怎麼回答 ?
目前電腦架構就是建築在循序上面
這不論是OO非OO都是一樣沒辦法改變的


: > 寫了那麼久的程式你還是不懂什麼是Abstraction...
: > 以及OO跟event driven 是兩回事..
: > 我看你還是回去寫你的assembly language吧...
: 在 object 封裝的內部對 data , code 是可以雜亂交錯, 你中有我,
: 我中有你那樣的混在一起, 還是分堆但包在封袋裡 ? 顯然 gsj 指出
: 了 OO 讓人看不清楚無法理解的一面.
將資料跟程式綁在一起 是OO的原則之一
以抽象概念來看
一個物體的性質(名詞, property)
動作(動詞, method)
將之綁自一起是符合抽象概念想法的
但這並不表示她們之間是雜亂無章的混在一起的
我舉個最簡單 目前很常被使用的例子
現今的商業網站架構 大部分都已經使用三層式架構
分成 表現層 邏輯層 資料庫存取層
而在資料庫存取層會實作與資料庫溝通的邏輯 並且將資料庫得出的資料物件
回傳給邏輯層
這樣的設計 會有每個物件代表資料物件
這些資料並不會雜亂無章的混在一起
只要設計得當 並且引入設計模式 以及軟體工程方法 例如重構等等
程式可以一直發展下去 並不會因未到最後變的太複雜 而無法維護
這就是OO想嘗試解決的一個問題

: 如果程式語言與電腦的實體是不對稱的, 那這個質疑是有道理的, 這
: 不能用 abstraction 一筆帶過, 否則會被懷疑 OOP 是有效率的嗎 ?
: 不然就是效率的稍微(這也得具體說明)犧牲, 可換來那些更值得的東
: 東 ? 譬如 Interactive 的 interpreter 相對於 compiler , 另外,
: 就是改善的趨勢會是甚麼 ? (譬如使用中間碼的 interpreter)
: 其次, 在那些地方或條件下, OOP 可以像一般的 C 使用 pointer
: 那樣方便的 reference structured data (如 array 或 record) ?
OO換來的東西 就我而言 有如宗教信仰一樣
信者恆信 不信者恆不信
因為這些直接帶來的效益加上周邊效益 我並沒有辦法量化秀給任何人看
因此我只能採取比較消極的態度
慎選合作夥伴 只要我的夥伴是相信我的 那我相信使用OO, UML, 設計模式, 重構
等等軟體工程方法 對我門團隊而言就是能夠帶來最大效益的

OO以及非OO
我們可以從市場上另外一個現象
PHP(ASP) & JAVA(ASP.NET)看出端倪
我相信大部分使用PHP(ASP)的專家
絕大部分是用Procedure方式思考的
一般情況下 HTML跟程式邏輯是混在一起的

若是使用到了J2EE, Java Bean, 或是ASP.NET開發方式
我也相信絕大部分是用OO方式來開發的
這時候可以引入MVC patern, 還有很多零零總總的設計模式
來幫助架構更容易維護 更容易被理解

我希望從這個現象 來討論幾個問題
1. 就我在業界的了解 使用PHP的比例是很高的
我相信這能夠代表著非OO語言比較容易上手
甚至到現在還是很多人在使用ASP
台灣網頁翻一下就知道 使用到ASP.NET的網站非常少
因此我覺得在上手程度來講 若是沒有一點程度 貿然使用OO並不會節省多少時間
或是帶來多少維護上的好處 光是閱讀文件 理解架構就耗掉太多時間
2. 循序式的語言很有可能就如gsj講的 是不會被消滅的
反而現在最大宗的Script Language 是PHP也不一定
因為連高中生都可以拿來寫網站
但使用人數多寡 對我而言是沒意義的 我也不想討論這個問題
Fortran會消滅嗎?Lisp會消滅嗎?總是會有人 或是老學者 會一直用下去的
就算OO有著效率上的缺點
但是在設計上的優點 gsj你是不能夠絕口不提的
你的論點永遠只繞在 "電腦的設計本質是循序"
"因此OO無用"
別的網友也講到了
你並沒有想要嘗試了解抽象化等等抽象概念
這樣子的討論永遠沒辦法有交集
你只特定攻擊某種類型的問題
但是另一部分的議題你是充耳不聞的

我的學位除了資訊科學之外 還有生物學位
我相信對人類而言 模仿 抽象的思考方式 是讓人類進步的主要動力之ㄧ
因此OO這種抽象化的萃取方式 是很符合人性的
就算在硬體本質上不對應 但對於人性對應 不是嗎?
其實還有很多議題可以討論 但我相信這是永遠都戰不完的
除非gsj你肯接受其他觀點 想要嘗試跳脫你的小圈圈 否則我覺得我寫再多都沒意義


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.132.155.71

[FreeZ]

Post by 待救的小米
我的學位除了資訊科學之外 還有生物學位
我相信對人類而言 模仿 抽象的思考方式
是讓人類進步的主要動力之ㄧ
因此OO這種抽象化的萃取方式 是很符合人性的
就算在硬體本質上不對應 但對於人性對應 不是嗎?

「 OO 很符合人性」, 這是喜歡 OO 的人的假設.

--
Free Tech (Win32Asm, Electronics..)
http://freetech.cjb.net/
Updated: April-15, 2004 / 14:35

[三億兩千萬大散戶]

Post by FreeZ
「 OO 很符合人性」, 這是喜歡 OO 的人的假設.

使用OO的確符合人性
基本上只要靠code hint再加上一些猜猜樂
也不用去記到底要用什麼method要傳哪些參數
只要記得主要的物件怎麼產生出來就行了

沒有OO的話
你要自己去找到底那個function叫什麼名字
要初始化哪些handle struct之類的參數然後傳進去

不過設計OO就不怎麼符合人性了
能設計出MFC VCL這些方便使用者使用的架構我想都是天才吧
--
夫兵者不祥之器物或惡之故有道者不處君子居則貴左用兵則貴右兵者不祥之器非君子
之器不得已而用之恬淡為上勝而不美而美之者是樂殺人夫樂殺人者則不可得志於天下
矣吉事尚左凶事尚右偏將軍居左上將軍居右言以喪禮處之殺人之眾以哀悲泣之戰勝以
喪禮處之道常無名樸雖小天下莫能臣侯王若能守之萬物將自賓天地相合以降甘露民莫
之令而自均始制有名名亦既有夫亦將 203-204-133-140.adsl.static.giga.net.tw海

[波特多]

※ 引述《***@bbs.wretch.cc (三億兩千萬大散戶)》之銘言：
: ※ 引述《***@we.are.the.world (FreeZ)》之銘言：
: > 「 OO 很符合人性」, 這是喜歡 OO 的人的假設.
: 使用OO的確符合人性
: 基本上只要靠code hint再加上一些猜猜樂
: 也不用去記到底要用什麼method要傳哪些參數
所謂的不用記是指什麼?
即使是OO，連參數都不用記的這種事情是怎麼做到的?

: 只要記得主要的物件怎麼產生出來就行了
: 沒有OO的話
: 你要自己去找到底那個function叫什麼名字
: 要初始化哪些handle struct之類的參數然後傳進去
你所謂的OO好像是單指物件的樣子?
即使是做成class了，要用的function也還是得找，何來不用記呢?

: 不過設計OO就不怎麼符合人性了
: 能設計出MFC VCL這些方便使用者使用的架構我想都是天才吧

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 219.84.97.227

[國王的新衣]

Post by 待救的小米
"因此OO無用"
別的網友也講到了
你並沒有想要嘗試了解抽象化等等抽象概念

我從來沒有反對抽象化的概念
將某些龐雜的事物化簡為抽象化的概念，的確是有它的好處與需求

問題是將事物抽象化的方式、模型有多種，
那一種才能最符合實際的狀況？或者是人類日常生活的習慣？
就如我以往所強調的：

對稱性很種要

你可以去觀察你的四周，人類社會組織的運作方式
包含你去考駕照、去餐聽吃飯、交女朋友等

不管這些事情有沒有訴之於條文，你可以發現一件事就是

它們都是 "循序化" 的一個過程

我不知道你拿一個與事實狀況不對稱的OO抽象模型來套用它會有什麼好處！
在我看來根本就是自找麻煩

如果對稱性夠，也不會有這麼多人摸了兩三年還不知道OO在作什麼
如果這個抽象模型，是與人類日常生活習慣是相近的，
為什麼會有這麼多人老是抓不到它的邏輯，反而是程式越寫越亂

當然我也不完全否認所謂的 "OO" 抽象模型也有它適用的地方
GUI可能是其中之一，但也僅限於此，超過這個範圍就完蛋了

對於OO的愛用者，我的建議是
當處理與GUI有關的議題時才可用，當處理與GUI無關的議題時不用
OO就像是老虎，將關在GUI的議題籠子裡才是安全的作法
放出GUI籠子以外，老虎就要吃人了，有傷害

循序化的系統就要用循序化程式語言，循序化的抽象模型來詮釋它
才是方便符合邏輯的方法

有關 "循序化抽象模型"，
你的腦袋可能還不知道有這種東西的存在吧！
所以才會以為循序化的程式語言都沒有抽象化模型
只有你們偉大的OO才有的這種看法

只要是循序化程式語言就很好用了，C就是我最常用的循序化程式語言
不像是有些人講的，非要扯到組合語言不可

在我的看法，組合語言之於C語言，它的強項在於
它可讓程式設計者
清楚的掌握程式碼或資料在記憶體中確切的Layout位置，尺寸大小
C 語言則不行，因為這些工作要透過Compiler來作
不過這並不會影響到循序化抽象模型的建立，反而是更方便

你可能不知道循序化程式，也有它的抽象模型
而且普遍用在大型系統的系統分析中，不是只有OO才有抽象模型

OO的抽象模型中，Class是物件
循序化的抽象模型也有物件，通常是指Struct

而且基於循序化的抽象模型，分析循序化系統就等於在分析程式一樣
實際系統與程式系統是One on One的對稱

所以如果有一家公司的行政作業流程如果要電子化，
系統分析完成的那一瞬間，也就幾乎等於程式架構完成了
只差訴諸於文字的程式映射
所以程式設計就變成一件很簡單的事


而且寫出來的程式在應用上，也完全符合使用者過去的習慣









--
Ξ Origin: 中興大學天樞資訊網 <bbs.nchu.edu.tw>
Ξ From : 218-169-63-22.dynamic.hinet.net

[國王的新衣]

Post by 三億兩千萬大散戶

Post by FreeZ
「 OO 很符合人性」, 這是喜歡 OO 的人的假設.

使用OO的確符合人性

當你深入了解之後，就會了解這純粹是一句 "廣告術語"

但這句話的確是吸引了不少人來學習OO

因為一般人總是把OO與使用GUI的便利性聯想在一起



--
Ξ Origin: 中興大學天樞資訊網 <bbs.nchu.edu.tw>
Ξ From : 218-169-63-22.dynamic.hinet.net

[rendering]

※ 引述《***@bbs.csie.ncu.edu.tw (try or test)》之銘言：
: 自認對 OO 精通的人應該要能回答 gsj 的質疑才是, 否則 OO 就如其音,
: 黑黑來, 黑黑去, 黑壓壓的一片.

OO 具有封裝性呀


: 物件導向 或 OOP 不知是否有特別強調 "非循序式" ? 印象中至少不是被
: 列為是 parallel programming 或 concurrent high level language .
: 學 OO 的要怎麼回答 ?

OO 全然沒有推翻循序性
OO 是「建立在循序性上」的「程式碼管理哲學」與「工程實務」


: > 寫了那麼久的程式你還是不懂什麼是Abstraction...
: > 以及OO跟event driven 是兩回事..
: > 我看你還是回去寫你的assembly language吧...
: 在 object 封裝的內部對 data , code 是可以雜亂交錯, 你中有我,
: 我中有你那樣的混在一起, 還是分堆但包在封袋裡 ? 顯然 gsj 指出
: 了 OO 讓人看不清楚無法理解的一面.

OO 的物件為雜亂交錯的 data 與 code 提供了單純而平面化的操作介面


: 如果程式語言與電腦的實體是不對稱的, 那這個質疑是有道理的, 這
: 不能用 abstraction 一筆帶過, 否則會被懷疑 OOP 是有效率的嗎 ?
: 不然就是效率的稍微(這也得具體說明)犧牲, 可換來那些更值得的東
: 東 ? 譬如 Interactive 的 interpreter 相對於 compiler , 另外,
: 就是改善的趨勢會是甚麼 ? (譬如使用中間碼的 interpreter)

OO 不是在討論程式執行的本質 循序化的執行早已是本然
OO 討論的是 data 與 code 的封裝性 物件的責任 物件間的關聯 介面的抽象性 ...
這些東西並不違反任何實體特質
討論的層次有所差異
「程式語言與電腦的實體是不對稱的」？ 我們得先思維這個命題是否正確

OOP 沒有損害到程式的執行效率
相同的事 要用循序性語言來做 不見得會比較有效率

會慢是來自於 design
你不能說我要讓程式碼受良好管理而不付出任何成本


: 其次, 在那些地方或條件下, OOP 可以像一般的 C 使用 pointer
: 那樣方便的 reference structured data (如 array 或 record) ?


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.222.148.171

[Har]

這個問題不需要爭吵﹐問一個簡單的問題就可以知道答案了。

台灣的大小軟件專案公司﹑SOHO﹐有多少公司是實際用 OOP 的理念來開發程式的﹖

來這邊的人﹐應該有很多是工作中的 programmer 吧﹖

說說你們工作上的需求就好。你們的老闆是否要求你們理解 OOP ﹖專案開發是否
有使用到 OOP ﹖

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 60.48.51.105

[reborn]

※ 引述《***@bbs.nchu.edu.tw (國王的新衣)》之銘言：
: ※ 引述《***@bbs.wretch.cc (三億兩千萬大散戶)》之銘言：
: > 使用OO的確符合人性
: 當你深入了解之後，就會了解這純粹是一句 "廣告術語"
: 但這句話的確是吸引了不少人來學習OO
: 因為一般人總是把OO與使用GUI的便利性聯想在一起
我想，使用OO，在設計階段時的一些違反直覺的架構，雖然很可能
會耗去不少時間（就算以非OO技術來設計，相信也要不少時間），
但是它主要帶來的好處就是面對需求變動時，所做的修改可以盡可
能的少，而這不就是我們夢寐以求的嗎？書籍中最常舉的例子，大
概就是以多型取代switch case吧？而這不就只是責任的觀念嗎？

當然，要設計出面對變動時不需修改太多的OO程式本身的確很不容易
，但是我們可以透過很多重構的手法來改善它，而循序式的程式經過
了這麼多年的研究，還是不容易做到後期的程式維護，我們常常還是
要深入每個曾經寫過的程式細節，然後才會發現，啊～這邊的邏輯修
改以後，那邊的flags要重設，並且在另一個迴圈裡要再加入一個判斷
，並且...隨著程式越來越大，每加入或修改一個小功能，要修改的地
方就越來越多，最後終於改不動了，專案便只得宣告失敗...

OO當然也會有類似的問題，但是它提供了"更多"的抽象化機制及間階層
的設立，讓架構的重新調整變得更方便，但是要付出的代價就是不斷的
學習以及對它一知半解的情況下，會帶來的災難。

但是就如同其他領域一樣，OO就是現代寫軟體的人的一項必備專業，
不只是GUI，只要想要利用更多的抽象化及間接性，就應該好好學習OO
所提到的許多"精神"，但是光是"精神"是不夠的，還必須有適切的語言
及平台搭配才行，不然依然是路途難行。

OO不見得是最好的軟體開發方式，但是絕對值得花時間學習，至少可以
聽得懂別人到底在講啥米碗公。


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.116.163.119

[跑步]

Post by 波特多
: 使用OO的確符合人性
: 基本上只要靠code hint再加上一些猜猜樂
: 也不用去記到底要用什麼method要傳哪些參數
所謂的不用記是指什麼?
即使是OO，連參數都不用記的這種事情是怎麼做到的?
: 只要記得主要的物件怎麼產生出來就行了
: 沒有OO的話
: 你要自己去找到底那個function叫什麼名字
: 要初始化哪些handle struct之類的參數然後傳進去
你所謂的OO好像是單指物件的樣子?
即使是做成class了，要用的function也還是得找，何來不用記呢?
: 不過設計OO就不怎麼符合人性了
: 能設計出MFC VCL這些方便使用者使用的架構我想都是天才吧

其實這個我大概知道 m 先生在說什麼
因為他慣用 BCB
那個工具的 code insight 和 parameter hint 功能確實很方便
使用上在很多時候真的可以不用背參數
因為 IDE 的 editor 很自動
(當然 VC 也不是沒有這些功能)

不過我也覺得不恰當的是
就算不寫物件導向程式
純粹寫循序式
IDE 還是有那些功能啊...

符合人性的是那些工具做得符合人性 (懶惰!? / 省時間!? / ..)
這跟使用者在用哪一種思維來寫程式是兩回事


--
 ＠, ●秘密情人● (bbs.cse.ttu.edu.tw) 
~\ ◆ Post From: 120.254.192.210.dynamic.ttn.net ◆

[波特多]

※ 引述《***@bbs.cse.ttu.edu.tw (跑步)》之銘言：
: 其實這個我大概知道 m 先生在說什麼
: 因為他慣用 BCB
: 那個工具的 code insight 和 parameter hint 功能確實很方便
: 使用上在很多時候真的可以不用背參數

我不知道他慣用的IDE是什麼，但我也猜他把IDE的功能誤解為OO的特性了。

即使是使用struct，BCB和VC的IDE也都會提示成員，我想表達的正是有些人
將OO的便利性和IDE的功能放在一起了。

OO是一套和傳統有異，且有相當程度互斥的coding風格，而且這套風格的學習
曲線並不簡單，先不論它的幫助能有多大，其互斥特性與學習曲線造成的影響
就先產生了明顯的壞處。

程式不是宗教，99%的時間我們都必須以現實為考量，而不是拿產能當祭品。

我並不是反對OO，相對的我認為應該徹底了解其針對封裝等問題改進的語法特
性及用法，至於其他的軟體工程部份則應取和傳統風格相容的部份，在不影響
產能的前提下改進程式的可維護性。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 219.84.97.227

[㊣塞破超人００９]

Post by FreeZ

Post by 待救的小米
我的學位除了資訊科學之外 還有生物學位
我相信對人類而言 模仿 抽象的思考方式
是讓人類進步的主要動力之ㄧ
因此OO這種抽象化的萃取方式 是很符合人性的
就算在硬體本質上不對應 但對於人性對應 不是嗎?

「 OO 很符合人性」, 這是喜歡 OO 的人的假設.

對我而言，OO提供一套比較合理的方法，方便管理資料型態，就是這樣。

We don't inspect objects; objects get themselves inspected.

我認同黑箱的存在，黑箱並非不可以打開修理，但是平常不需要修的時
候，它就是一箱，依照上面的開關按鈕操作就可以用。不用這種方法，
就是所有零件都攤開來，用的時候要自己費勁組合，浪費很多時間。

我對OO的認識很少，但是這一點對我使用上就有很大的幫助，使我省下
不少工夫在coding和debug 上面。在這樣的程度上我認為OO是人性的，
這是體驗，跟假設無關。至於其他抽象的延伸，我並不在意。OOP works
well enough as merely a simple tool.
　
--
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
 我們要保證一切的利益都歸於國家與黨。 
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Mk.3(N)  journeyman  - Moderator, Military Board
2-16-2K orig., 9-26-01 dropback 中央大學松濤風情資訊站

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 218-162-233-63.dynamic.hinet.

[冷]

oo是所謂的"封裝","繼承","多型"嗎?
如果是的話,那應該就扯不到硬體了..
在大陸叫做"面對對象的設計" =.=
有點像是....掛載模組的意思(而一個模組裡提供各種function) - 多型
而且可以用繼承的方式再次去修改產生另一個新的模組.. - 繼承
而且像c中有時要用extern，用封裝的話就可以獨立且不共用數值..- 封裝
阿 這是我寫java && mfc 後的想法...
有錯的話...我也沒辦法 =.=

Post by 波特多
: 其實這個我大概知道 m 先生在說什麼
: 因為他慣用 BCB
: 那個工具的 code insight 和 parameter hint 功能確實很方便
: 使用上在很多時候真的可以不用背參數
我不知道他慣用的IDE是什麼，但我也猜他把IDE的功能誤解為OO的特性了。
即使是使用struct，BCB和VC的IDE也都會提示成員，我想表達的正是有些人
將OO的便利性和IDE的功能放在一起了。
OO是一套和傳統有異，且有相當程度互斥的coding風格，而且這套風格的學習
曲線並不簡單，先不論它的幫助能有多大，其互斥特性與學習曲線造成的影響
就先產生了明顯的壞處。
程式不是宗教，99%的時間我們都必須以現實為考量，而不是拿產能當祭品。
我並不是反對OO，相對的我認為應該徹底了解其針對封裝等問題改進的語法特
性及用法，至於其他的軟體工程部份則應取和傳統風格相容的部份，在不影響
產能的前提下改進程式的可維護性。

--
* Origin: 中山大學-美麗之島BBS * From: 210.68.185.124

[國王的新衣]

Post by rendering
OO 的物件為雜亂交錯的 data 與 code 提供了單純而平面化的操作介面
OO 不是在討論程式執行的本質 循序化的執行早已是本然
OO 討論的是 data 與 code 的封裝性 物件的責任 物件間的關聯 介面的抽象性 ...

以上這些特性，循序化就作不到嗎？
Win32 API 難道就不是單純平面化的抽象操作介面嗎 ？

介面設計的好不好，與設計者的架構思維比較有關
腦袋不清楚，用什麼程式語言設計程式都是鴉鴉烏




--
Ξ Origin: 中興大學天樞資訊網 <bbs.nchu.edu.tw>
Ξ From : 220-139-18-191.dynamic.hinet.net

[新的人生]

Post by 國王的新衣

Post by rendering
OO 的物件為雜亂交錯的 data 與 code 提供了單純而平面化的操作介面
OO 不是在討論程式執行的本質 循序化的執行早已是本然
OO 討論的是 data 與 code 的封裝性 物件的責任 物件間的關聯 介面的抽象性 ...

以上這些特性，循序化就作不到嗎？
Win32 API 難道就不是單純平面化的抽象操作介面嗎 ？
介面設計的好不好，與設計者的架構思維比較有關
腦袋不清楚，用什麼程式語言設計程式都是鴉鴉烏

看起來你應該是那一個腦袋不是很清楚的.

OO 和你所謂 "循序化"程式 的想法就是不一樣.

拿個最簡單的, 你的循序化程式怎麼管理 Memory Allocate
所有的 struct 都要自己寫 function 去 malloc()
等到不用了, 再呼叫 free()

在 OO 的世界內, 只要你的 class 寫好了 new/delete
物件生成的時候, 自然就會 new ,
物件消失時, 自然就會 delete

Memory 的控管一切都是這麼自然, 就像大自然萬物生老病死.
這是 OO 帶給初學者最美妙的禮物.

你所謂的 "循序化" 程式要控制 Memory . 你能夠準確的了解 struct 的生與死嗎?

--
以上的文字都是誤會
看到的一切都是幻覺
--
※ Origin: 土匪．山寨 <bbs.techarea.org / poorman.twbbs.org> 
◆ From: richliu.techarea.org

[波特多]

※ 引述《***@bbs.nchu.edu.tw (國王的新衣)》之銘言：
: ※ 引述《***@ptt.cc (rendering)》之銘言：
: > OO 的物件為雜亂交錯的 data 與 code 提供了單純而平面化的操作介面
: > OO 不是在討論程式執行的本質 循序化的執行早已是本然
: > OO 討論的是 data 與 code 的封裝性 物件的責任 物件間的關聯 介面的抽象性 ...
: 以上這些特性，循序化就作不到嗎？
: Win32 API 難道就不是單純平面化的抽象操作介面嗎 ？
: 介面設計的好不好，與設計者的架構思維比較有關
: 腦袋不清楚，用什麼程式語言設計程式都是鴉鴉烏

這話雖然沒錯，但卻不實際。

與其說OO是一個能設計出良好介面的coding方式，不如說它是一個強迫使用良好
coding方式的風格，也因此對OO了解不夠深入的人，OO可說是無用的。

這也是OO像一種宗教多過於coding風格的原因?

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 211.22.3.203

[波特多]

※ 引述《***@bbs.poorman.org (新的人生)》之銘言：
: 看起來你應該是那一個腦袋不是很清楚的.
: OO 和你所謂 "循序化"程式 的想法就是不一樣.
: 拿個最簡單的, 你的循序化程式怎麼管理 Memory Allocate
: 所有的 struct 都要自己寫 function 去 malloc()
: 等到不用了, 再呼叫 free()
: 在 OO 的世界內, 只要你的 class 寫好了 new/delete
: 物件生成的時候, 自然就會 new ,
: 物件消失時, 自然就會 delete
: Memory 的控管一切都是這麼自然, 就像大自然萬物生老病死.
: 這是 OO 帶給初學者最美妙的禮物.
: 你所謂的 "循序化" 程式要控制 Memory . 你能夠準確的了解 struct 的生與死嗎?

以這樣的想法去寫目前實作出來的OO，你的程式會死得不明不白…

即使是OO，變數也是有生命週期的，不考慮這問題而把責任交給OO，沒想過這責任
也不是由語言在做，而是OS階層的問題嗎?

變數要new就要有delete，除了java這類有GC的語言外，OO並不會幫你完成這些事。

無論是哪種coding style，都應該要清楚了解自己的程式做了什麼事。

這種把OO當成是不必動腦就能用的神奇工具的態度，正是讓人誤解OO的原因。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 211.22.3.203

[新的人生]

Post by 波特多
以這樣的想法去寫目前實作出來的OO，你的程式會死得不明不白…
即使是OO，變數也是有生命週期的，不考慮這問題而把責任交給OO，沒想過這責任
也不是由語言在做，而是OS階層的問題嗎?
變數要new就要有delete，除了java這類有GC的語言外，OO並不會幫你完成這些事。
無論是哪種coding style，都應該要清楚了解自己的程式做了什麼事。
這種把OO當成是不必動腦就能用的神奇工具的態度，正是讓人誤解OO的原因。

當然,
在 construct 時 alloc memory.
在 destructor 時 free memory .
如果再配合變數的生命週期, 那不就不需要去煩惱很多事情.

OO 其實沒有很神奇, 只是從傳統的 SA/SD 角度看, OO 的確是不太一樣.

不過讓人誤解 OO 並不會是我,
很多人看看洪XX的書, 就說我會 OO 了, 這個還比較可怕吧.

或許我 OO 學得久了,
早期看 The C++ Programming Language 2nd (3nd 是買葉秉哲翻的中譯本了)
同時期還有世紀末軟體革命
高煥堂的 OOA/OOD 等等.

也許我的 OO 和現代學的 OO 不一樣也說不一定 :D
-
--
以上的文字都是誤會
看到的一切都是幻覺
--
※ Origin: 土匪．山寨 <bbs.techarea.org / poorman.twbbs.org> 
◆ From: richliu.techarea.org

[rendering]

※ 引述《***@bbs.nchu.edu.tw (國王的新衣)》之銘言：
: ※ 引述《***@ptt.cc (rendering)》之銘言：
: > OO 的物件為雜亂交錯的 data 與 code 提供了單純而平面化的操作介面
: > OO 不是在討論程式執行的本質 循序化的執行早已是本然
: > OO 討論的是 data 與 code 的封裝性 物件的責任 物件間的關聯 介面的抽象性 ...
: 以上這些特性，循序化就作不到嗎？

當然做得到的 :)

OO 是建立在循序化上的
所以循序化絕對做得到


: Win32 API 難道就不是單純平面化的抽象操作介面嗎 ？

是的 :)
我非常喜歡 Win32 API 的特計


: 介面設計的好不好，與設計者的架構思維比較有關
: 腦袋不清楚，用什麼程式語言設計程式都是鴉鴉烏

OO 應該分 OOA OOD 與 OO Language
用 C 來實作 OOA OOD 並沒有什麼不可以的

gsj 大大呀
您到底是反對 OOD 還是 OO Language
這點要分清楚
為物件(struct)畫關連圖已慢慢踏入 OOD 的層次 ...


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.222.148.171

[www.dev.idv.tw]

Post by 波特多
: Memory 的控管一切都是這麼自然, 就像大自然萬物生老病死.
: 這是 OO 帶給初學者最美妙的禮物.
: 你所謂的 "循序化" 程式要控制 Memory . 你能夠準確的了解 struct 的生與死嗎?
以這樣的想法去寫目前實作出來的OO，你的程式會死得不明不白…
即使是OO，變數也是有生命週期的，不考慮這問題而把責任交給OO，沒想過這責任
也不是由語言在做，而是OS階層的問題嗎?
變數要new就要有delete，除了java這類有GC的語言外，OO並不會幫你完成這些事。

這句話不完全正確....
用auto_ptr去new出來的物件，就不用由programmer自己去delete。


--
Gary W. Lee
URL: http://www.dev.idv.tw/
A web site about C/C++, Tcl, Python, wxWidgets, UNIX/Linux, Windows ..., etc.
--
※ Origin: 元智大學 風之塔 <bbs.yzu.edu.tw> 
※ From : asgarthr.sentelic.com
※ X-Info: Re: [請益] 一個非專業初學者請益如何學習C++
※ X-Sign: 11FM6JGCgPWSqUHUKiMw (05/08/11 17:29:20 )