2.從操作方式分，包括鼠標操作，鍵盤命令操作，繪圖板操作。 建議可從鼠標操作開始（照樣離不開鍵盤輸入一些二級命令、數據等等），同時熟悉一些同等功能的鍵盤命令。


3.從對象的繪製編輯形式分，包括二維對象，三維對象。 先學二維。 三維部分分為實體和曲面，交互進行就可。


 


入了門之後，可以進行以下內容：


1.怎麼輸出。 從產品輸出種類分包括工程圖（二維）輸出，模型（主要為三維）和渲染圖輸出。


具體輸出操作包括列印輸出，模型格式轉換（傳遞給三維建模、動畫、渲染軟件如3DSMAX,Lightscape等）其他格式轉換（可編輯的文本如DXF）等等。


2.按你的專業內容收集編輯一些常用模型、模塊，建立自己的庫。


 


進進學習班可以，但除了入門之外，不要指望什麼，那裡師資混雜，手藝高低不一，短短時間，只能是入門而已。


找一本好的教材如《使用手冊》，常備一本《命令參考手冊》，便於查詢。


總之，從繪圖編輯命令入手，從二維到三維，循序漸進，熟記一些常用命令，做一些範例，和人多請教交流，常上相關網站看看


 


 


（推薦ABBS建築論壇或eNet網絡學院）。


 


大約半年即可。 定一個6個月計劃吧，會成功的！ [JF1] 


 


 


機械ACAD需要兩方面知識：1.機械製圖和識圖。 要求會幾何（平面幾何和立體幾何，加上坐標知識）這完全可以自學。 2.ACAD的操作知識。


學習CAD並不難，惟一方法是勤奮。


機械製圖有專用軟件，建議還是先學習AutoCAD軟件


AutoCAD軟件目前見到的是2007版,這個版本在三維模型建構和內置渲染器操作方式上變動很大，建議還是從2004~2006版開始學。


CAD高手主要的操作方式是鍵盤命令（可以自己編輯快鍵方式）。


1.CAD從使用功能分，包括繪製，編輯（包括修改），系統操作，渲染，LISP編程（高級操作部分）。 建議你先學好繪製和編輯（包括修改）。 這兩個部分內容交互進行就可。


2.從操作方式分，包括鼠標操作，鍵盤命令操作，繪圖板操作。 建議可從鼠標操作開始（照樣離不開鍵盤輸入一些二級命令、數據等等），同時熟悉一些同等功能的鍵盤命令。


3.從對象的繪製編輯形式分，包括二維對象，三維對象。 先學二維。 三維部分分為實體和曲面，交互進行就可。


 


 


目前設計師就業形勢非常明朗，08年10月份開始受到 經濟危機 的影響， 房地產行業 低迷，無論房地產商如何降價，可是我們老百姓買房的人並不多，大家都在觀望，看房價什麼時候可以降到最低，那麼在09年3月，購房風潮開始，隨著房地產行業的回暖，買房的人多了，那麼裝飾企業對於設計師的需求量也大大增加。


室內設計 是一個高薪的行業也是一個自由的行業，當然這是跟能力分不開的。 一個國家的發展跟它的物質面貌緊密相隨，物質面貌的體現在於它設計的合理化，現在國家經濟發展越來越好，重裝飾輕裝修更加符合現代人的追求，所以說，無論在大城市還是小鄉鎮，總體來說設計行業的前景還是讓人充滿希望的。


室內設計是一門實操性很強的專業， 室內設計培訓 屬於 職業教育 ，它要求設計師除了具備一定的設計理論知識、創新思維 能力、良好的藝術素養和手工製圖能力外，還要掌握 裝飾材料 、施工工藝、製圖標準以及相應行業規範。


室內設計師 這個職業對美術基礎的要求有這樣一句話“你不要夢想著去當畫家，但是你可以努力使自己成為一名合格的美工 ”，優秀的室內設計師是需要創意的，太多的機械美只會壓抑我們的靈感。


 


發工具大比拚之Visual C++ vs. Delphi(一)   
作者： 紫雲英、曾登高     

　　引言 

　　“visual c++與delphi之比較”最近在csdn的論壇上的討論非常火熱，本文將以一個程序員的角度，從技術水平、功能、性能、易用性、穩定性、發展歷程和前景等方面，以visual c++ 6和delphi 5為代表，盡可能客觀地比較介紹visual c++和delphi這兩大主流開發工具的優缺點，其中將涉及到語言、應用框架、控件、編譯和連接、集成界面、調試、 com、數據庫開發等。 本文還將對如何選擇使用這兩個開發工具提出一些建議。   

　　值得一提的是，由於c++builder與delphi同為inprise公司產品，它們除了使用的語言不同，其餘特性幾乎都相同。 因此本文對c++builder程序員和學習者也有參考價值。   

　　語言：存在即是合理 

　　首先聲明常被混淆的一點：vc和delphi本身不是語言，而是開發平台。 它們所用的語言分別是略作擴展的c/c++和object pascal。 我在網上常看到有人問應該學c/c++還是vc，這個問題很好回答：如果你學vc你就必須得學c/c++，或者說你學會了vc也就學會了c/c++了。

　　言歸正傳，我們來比較一下c++和object pascal的優缺點。 有人認為object pascal是“玩具語言”，c++才是“專業語言”，這是不對的。 單從語言本身看，object pascal與c++屬同一重量級。 它們都是完全支持面向對象的語言，都紮根於“歷史悠久”的面向過程的語言。 c++是由c發展而來的，object pascal由pascal進化而來。 它們都有很強的靈活性，都有自己的特長和不足。 比如說，object pascal不支持多重繼承、模板、操作符重載、內聯函數定義、預處理、宏、全局靜態類變量、嵌套類定義，等等，而這些都是c++支持的。 但同樣地c++也不支持object pascal的虛構造函數、過程嵌套、內置集合類型、內置字符串類型、 "finally "構造等等，在rtti方面object pascal也比c++做得好。 但這些並不重要，因為可以通過其它方式達到同樣的目的，比如c++可以通過類擴展支持集合、字符串，object pascal可以通過“interface”多重繼承，等等。 關鍵是二者都可以很好地完成你手頭的任務，這就夠了。

　　但是，僅僅比較語言本身是不夠的，還得看它們的被接受和流行程度，學習曲線，發展前途，可移植性等，以及，很重要但常常被忽略的一點：與開發環境(指vc與delphi)及其應用框架的“磨合”程度。 

　　vc和delphi作為開發平台，很重要的一點就是提供了一個“無所不包”的應用框架：vc的mfc和delphi的vcl。mfc是用c++寫的，vcl是用object pascal寫的。 當然，我們都知道，c++的使用範圍比object pascal廣得多，移植性也好得多。 這本來是優點，但很有意思的是，正因為如此，微軟寫mfc時必須考慮最大限度減少對語言本身的改動，而把功夫下在源代碼級，以便能盡可能支持ansi等標準，結果導致mfc的封裝複雜而不直觀。 (尤其是它對消息的封裝，下文還會提到。)太多的宏定義和含義模糊且自動生成、不得改動的註釋使mfc乃至vc讓很多新手望而生畏，不敢“下水”深入學習。 而object pascal幾乎是inprise“專用”的，不必考慮“標準”問題，因此inprise寫vcl時就把全部精力放在了結構與性能上，結果語言與框架的磨合程度非常好。 vcl框架的結構清晰，vcl代碼的可讀性非常好。 許多人說delphi比較容易上手，也是這個緣故。 天下沒有白吃的午餐。 你要工業標準嗎？ 你要可移植性嗎？ (關於可移植性和兼容性，下文會詳細比較。)那麼請面對mfc的“天書”級代碼吧。

　　編譯和連接：the need for speed   

　　不同的語言帶來的另一個不同是，編譯和連接的速度的不同，以及執行速度的不同。 delphi的編譯和連接速度，毫不誇張地說，比vc快幾十倍。 即使把vc的incremental link選項打開，delphi的編譯和連接速度仍比vc快好幾倍。 並不是說微軟的編譯器不行，這是由c++的複雜性決定的。 模板的處理、預處理和宏的展開都是很費時的。 前文不是提到object pascal沒有模板、預處理和宏嗎？ 這本來是缺點，但帶來的一個好處就是編譯速度極快。 至於編譯完的二進制代碼，在打開相同的優化選項的情況下，delphi和vc執行速度並沒有太大的差別。

　　為了克服編譯的速度問題，c++編譯器一般需要增強的連接器和預處理機制。 但是預處理機制仍然存在若干問題：

　　１）程序調試的斷點行可能和代碼行不同。 
　　２）沒有將最新的代碼信息綜合進去。 
　　３）容易產生錯誤的邏輯。 
　　４）因為讀錯文件頭而很容易產生類似“unexpected end of file”的錯誤。 

　　兩個編譯器有個共同點是都能識別無用的“死”代碼，比如一個沒有用的函數等等。 編譯後的程序將不包含這些多餘的信息。 delphi在這方面作得更加出色。 它可以讓你在編輯器中可視化地提示出那行代碼是“活”的、那行代碼是“死”的。 這樣你就能整理出最精簡的代碼。

　　delphi在編譯後將在左邊顯示一個小藍點表示這行代碼是“活”的。 visual c++做不到這點。 delphi編譯後的可執行文件至少有200k（如果不使用vcl，僅僅使用winapi，文件的大小將大大縮小）。 但是visual c++編程使用mfc編譯後的可執行文件通常只有幾十k，主要是因為微軟已經將系統運行庫包含在windows系統了（borland公司曾經和微軟協商這個接口，但是微軟利用操作系統的優勢不願意公開）。 同樣道理，使用bde開發的的數據庫程序必須附帶3 -5m 的額外系統文件，也是非常不協調的。

　　非常有趣的是，delphi能夠使用由c++ builder創建的的obj文件，但是使用上受很大的局限性。 

　　順便提一下vc的“edit and continue”功能。 在調試中，這個功能是可以大幅度節省時間的，但仍不能和delphi的閃速編譯比。

　　最後，visual c++的編譯和連接時的錯誤信息比delphi要詳細和具體的多。 特別是使用atl開發更加如此。  


 


 


開發工具大比拚之Visual C++ vs. Delphi(二)   


　　應用框架：mfc？ 有kfc流行嗎？

　　應用程序框架(application frame)，有時也稱為對象框架。 visual c++採用的框架是mfc。 mfc不僅僅是人們通常理解的一個類庫。 (同樣，delphi的vcl也不僅僅是一個控件庫，儘管它的名字叫“可視控件庫”。)你如果選擇了mfc，也就選擇了一種程序結構，一種編程風格。 mfc早在windows 3.x的時代就出現了，那時的visual c++還是16位的。 經過這些年的不斷補充和完善，mfc已經十分成熟。 但由於原型出現得比較早，mfc相比於vcl落後了一個時代。 儘管微軟對mfc的更新沒有停止，我也經常讀到“只要windows不過時，mfc就不會過時”之類觀點的文章，但就像inprise(原borland)的owl框架的淡出一樣，mfc的淡出也是早晚的事。 其實mfc是和owl同一個時代的產物。 owl已經不在了，mfc怎能不“居安思危”呢？ 如果mfc青春永駐，微軟的開發人員也不會“私自”開發出基於atl的wtl呀。 當然，wtl的地位不能和mfc比，它並不是微軟官方支持的框架，封裝的功能也相當有限。 但至少也反襯出了mfc存在的不足。

　　我以為，最能體現一個應用程序框架的先進性的是它的委託模型，即對windows消息的封裝機制。 對windows api的封裝就不用說了吧。 大同小異，也沒什麼技術含量。 如果高興，你也可以自己寫一個類庫來封裝。 但對windows消息驅動機制的封裝就不是那麼容易的了。 最自然的封裝方式是採用虛成員函數。 如果要響應某個消息就重載相應的虛函數。 但出乎我的意料，mfc採用的是“古老”的宏定義方法。 用宏定義方法的好處是省去了虛函數vtable的系統開銷。 (由於windows的消息種類很多，開銷不算太小。)不過帶來的缺點就是映射不太直觀。 對於mfc，則是“太不直觀”了。 它的消息映射代碼雖然是可見的，但“勸君莫碰”。 好在vc的classwizard可以自動生成消息映射代碼，使用起來還算方便。 但和vcl的委託模型相比，mfc的映射方法就顯得太落後了。 而delphi的object pascal因為沒有“標準負擔”，語言引入了組件、事件處理、屬性等新特性。 由於功夫做在編譯器級，生成的源代碼就顯得十分簡潔。 似乎vc是“讓框架遷就語言”，而delphi是“讓語言遷就框架”。

　　我想舉一個對字符串操作的封裝的例子來說明mfc和vcl的優缺點。 在mfc中，cstringlist類有加入、獲取、刪除等功能，但vcl的tstringlist類除了上述功能還有排序、從逗號分隔的字串讀入、流輸入輸出等功能。 但同樣的字符串替換功能，vcl的stringreplace要比mfc的cstring::replace慢2~3倍。 總的來說，vcl的封裝比mfc更為高層，更為抽象，但不可避免地帶來的問題是某些部分執行效率比mfc略低。 這就像低級語言(如彙編)的執行效率比高級語言(如basic)高，但編程效率較低。 魚和熊掌不可兼得嘛。

　　vcl比之mfc的另一優點是對異常處理的支持，而一大缺點是對多線程支持差。 vcl的大部分都不是針對多線程優化的。 雖說vcl提供了簡化多線程操作的類，但只是工作者線程(worker threads)使用起來比較簡單。 如果線程要和界面打交道的話事情就變得麻煩了，因為除了應用程序的主線程，任何線程不能訪問任何可視的vcl部件。 你不得不使用synchronize方法等待主線程處理它的消息，然後在主線程中訪問vcl部件。 而mfc就沒有這樣的限制。

　　穩定性與完善程度：vc是老大哥 

　　vc要比delphi穩定和完善。 vc的發展歷史比delphi長，微軟的總體實力比inprise強。 vc的框架mfc經歷了那麼多年的發展和完善，功能非常全面，而且十分穩定，bug很少。 其中你可能遇到的bug更少。 而且有第三方的專門工具幫助你避開這些bug。 如此規模的一個類庫，能做到這一點不容易。 不要小看了這一點，很多專業程序員就是為這個選擇vc的。 因為儘管vcl比mfc的抽象程度高，封裝較為高層​​，但由此帶來的開發效率的提高對高手來說畢竟是有限的。 而如果你遇到一個怪問題，調試了半天，發現不是你的代碼有錯，而是vcl的bug，你作何感想？ 雖說遇到這類問題的可能性很小，但對vcl的形象的影響可不小。 delphi的ide太佔資源，啟動速度太慢，和某些顯卡驅動程序衝突，vcl中有bug，調試器不夠健壯，對不穩定的第三方控件沒有防護措施……問題多多，在這方面delphi不如vc。 希望inprise能更上一層樓。 順便說一下，我在網上看到有些人極言delphi的不穩定，說幾分鐘出現20多次非法操作。 delphi的確不如visual c++穩定，但也不至於如此呀。 我估計是那位朋友的delphi裝了某些有問題的第三方控件，導致了delphi的頻頻出錯。 不妨卸下那些控件試試？   

　　可移植性：立足現實，放眼未來 

　　inprise正在開發delphi的linux版本，代號為kylix。 也許通過kylix，用vcl構架編寫的windows程序向linux移植成為可能。 但這只是可能。 因為在目前inprise的兼容性工作做得併不好。 低版本的delphi不能使用高版本的vcl組件(這還別去說它)，而高版本的delphi竟然不能使用低版本的vcl組件。 真是豈有此理，我很少看見軟件有不向下二進制兼容的。 如果windows 98不能運行95的程序，windows 95不能運行3.x的程序，win 3.x不能運行dos程序，你還會用windows嗎？ 如果windows 95的程序必須經過重新編譯才能在98下運行，98會賣得那麼好嗎？ “同門兄弟”c++builder和delphi也不能互相使用對方的組件，甚至同一套vcl庫的文件名也不一樣。 所以一個組件有for d1/d2/d3/d4/d5/c1/c3/c4/c5這些不同版本是常有的事，而且隨著delphi和c++builder版本的升級可能還會增加。 希望inprise能先解決同門兄弟的兼容性問題。 而微軟的vc就沒有這類問題。 mfc1.0的程序也可以毫無障礙地在vc6.0下編譯通過。

　　集成界面：宏觀與微觀 

　　就大處說，vc的集成界面是不如delphi的。 delphi僅僅一個object inspector就可以將vc的一堆wizards比下去，何況它還有code explorer、todo list等。 但從小處，又可以看出delphi的不成熟。 比如“自動完成”功能的智能化程度和提示詳細程度不如vc，響應速度也沒有vc快。

　　visual c++所帶的msdn是一部“開發者的百科全書”，信息龐大，查詢方便，這方面比delphi更加專業。 很多幫助項都有源程序示範。

　　delphi的opentools是完全面向第三方的開放系統，開發者可以修改很多borland公司自身的功能，從ide的可擴充性上說delphi更好。 

　　調試：細微之處見真功   

　　visual c++和delphi的調試功能都非常強大，同時都具有單步可視化調試、斷點跟踪、運行時改變變量、鼠標指向可以得到變量值等等功能。 對dll的輸入輸出也能方便的管理，能夠進行源碼級別的調試。

　　相對而言，visual c++能夠更加方便地看到變量的變化情況，這包括對結構可以展開成數據樹，從而了解每一個變量的值，每一步調試，變化了的變量會加紅，從而使調試更加方便。 另外，visual c++的塊內存察看比delphi也要方便。   

　　當然，delphi也有很多體貼的細微之處，比如在線程調試的時候，delphi能夠很方便地察看線程的變化，visual c++確必須要彈出一個模式對話框。   


 


 


開發工具大比拚之Visual C++ vs. Delphi(三)   

　　數據庫開發：delphi一枝獨秀 

　　數據庫支持是delphi的強項。 這主要體現在delphi與bde的無縫集成，以及delphi提供的那一大堆現成的數據庫操作控件。 這是vc望塵莫及的。 目前delphi支持bde、ado、interbase三種數據庫訪問方式。 所有的方式都能拖拉到應用程序中實現可視化操作。 正是因為delphi對數據庫類的包裝，使得用戶操作數據庫不像在visual c++中必須從開始到最後都要干預。 明顯地提高了開發速度。

　　在delphi中使用webbroker控件還能很方便地構造出基於數據庫的web頁面，通過html管理web數據庫。 

　　visual c++訪問數據主要通過ado和oledb，很多activex控件也能添加數據庫功能。 但是沒有像paradox這樣的桌面數據庫，access相對太輕量級了。 也許sql server是不錯的選擇。   

　　com：新技術的力量 

　　com是組件對像模型的縮寫。 它是ole和activex技術的基礎，com定義了一組api和一個二進制標準，讓不同的編程語言、不同平台的彼此獨立的對象相互進行通訊。

　　com是microsoft制訂的行業標準。 但是，delphi也為com提供了強大的語言支持。 支持接口、variant、寬字符串功能。 這些對com的封裝確實比c++更方便。 比如在c++（沒有類框架）進行com編程時，變體定義為oaidl.h文件中德variant結構。 要處理變體，必須手工調整oleaut32.dll中variantxxxx() api函數對其進行初始化和管理，如variantinit()、variantcopy()、variantclear()等等。

　　visual c++實現com編程有一種特殊的方法就是使用atl。 atl使用visual c++特有的多重繼承來實現com接口。 雖然不見得實現com服務和控制更容易，但是atl和最新com技術的接口，基於模板的構造都比delphi強。 atl更有利於建立小巧、快捷的com組件程序。   

　　按照目前通用的觀點，visual c++應用到com服務程序更有優勢，delphi應用到com組件程序更合適。 

　　昨天，今天，明天   

　　技術的進步在很多時候是此消彼長的。 當初borland的turbo c和borland c++幾乎是c/c++程序員唯一的選擇。 微軟的quick c(現在還有人知道這個產品嗎？)和microsoft c/c++從來也沒有成為過主流。 但borland c++又流行了多少年呢？ 不久就被新崛起的microsoft visual c/c++壓下去了。 於是inprise(原borland)揀起了當年turbo pascal和borland pascal的輝煌(事實上borland的成名作就是第一個pascal編譯器)，全力推出了delphi。 delphi當初推出時被稱為vb殺手，但vb現在仍然活得挺好。 畢竟微軟是靠basic起家的嘛，vb不是那麼容易被打敗的。 inprise想了想不和vb爭了，使用delphi的ide和vcl配上c++語言，推出了c++builder，又向visual c++的市場發起了夾攻。 c++builder似乎是個不錯的折衷選擇了？ 再仔細想想！ c++builder的優點delphi都有，但delphi的優點c++builder未必有。 比如c++builder的編譯速度比vc還慢，哪能和delphi比？ 而且因為vcl是object pascal寫的，c++語言和vcl磨合得併不好。 c++builder的bug比delphi還多，甚至sample代碼中還有錯。vcl的部分功能不能使用，要靠嵌入pascal代碼訪問。 c++builder可用的第三方控件遠沒有delphi多。

　　唉，真是金無足赤。 microsoft和inprise，誰會笑在最後呢？

　　魚和熊掌：艱難的選擇   

　　選擇一個開發工具依賴於很多不同的因素，每個人都能因為某種語言的某個缺陷而放棄學習或使用這種語言。 任何程序員都希望自己喜歡的工具能達到理想的境界，通過上面不完善的比較，我想大家都有自己的看法。 我們認為影響大家選擇開發語言的因素主要包括：   

　　１）哪門語言更容易入門？   

　　學習一種語言需要投入大量的時間和精力。 開發程序的開發成本是值得考慮的現實。 一個熟練的delphi程序員和一個熟練的vc程序員工作效率是一樣的。 但是，成為熟練的程序員必須很快掌握一門語言的技巧。 不幸的是，目前熟練的visual c++程序員是十里挑一。 相對而言，delphi更適合初學者。   

　　２）哪門語言有更多可繼承的代碼？ 

　　語言代碼的可重用性是加快開發效率明顯方面，從早期的過程、函數到現在的組件技術都是朝這個目標在奮鬥。 這兩種語言對代碼重用的理解是不一樣的，delphi主要通過vcl控件來實現代碼重用，visual c++實現起來就比較複雜。   

　　３）語言自身的本性。 

　　就技術(主要指應用框架)來說，delphi目前領先於visual c++。 但穩定性和健壯性的不足又讓我對inprise“想說愛你不容易”。 而vc儘管發展到今日已十分完善，但mfc框架已是明日黃花了。 如果不使用mfc，目前又沒有合適的替代品。

　　根據你的需要和實際情況做選擇吧。 實際上visual c++和delphi也不是單單競爭關係。 它們在許多領域並不重疊，甚至是互補的。 到底怎樣取捨，要根據你的項目特性決定。 如果你開發系統底層的東西，需要極好的兼容性和穩定性，選visual c++吧。 你可以只調用windows的各種api，不用mfc。 如果你寫傳統的windows桌面應用程序，visual c++的mfc框架是“正統”的選擇；如果界面部分佔這個應用程序代碼比例較大的話，或者delphi中有相關功能的控件的話，delphi是事半功倍的選擇。 如果你為企業開發數據庫、信息管理系統等高層應用(“高層”是相對於“低層/底層”而言的，不是說技術高級或低級。)而且有比較緊的期限限制，選delphi比較好。 如果你熟悉的語言是object pascal，又不打算學複雜的c++，那麼delphi幾乎是唯一的選擇。 傳統的觀點是：delphi適合編寫internet/intranet、表格製圖、數據庫操作、高級用戶界面等等。 visual c++適合編寫設備驅動、com服務程序、科學計算、控制台（console）程序、wince的應用和一些小的工具等等。 應用範圍的不同要求好的程序員精通這兩門語言。

　　４）語言的前景和可擴充性。 

　　delphi是inprise的旗艦產品之一，前景應當還是比較樂觀的，而且inprise已經在向linux進軍了，而微軟還遲遲沒有動作。 遺憾的是，inprise公司delphi的創始人已經跳槽到微軟去主持visual j++項目了。 但願對inprise衝擊不會太大。

　　微軟的visual c++的前景又怎樣呢？ visual studio 7.0就要推出了。 這一版本將加強網絡開發的特性。 看來微軟雖然被判解體，開發實力可是一點沒打折扣。

　　另外，雖說mfc已稍顯落後，但不是說它不值得學。 事實上，不學mfc就等於沒學vc。 利用mfc框架開發程序仍然是目前開發桌面應用的主流模式，而且還會保持相當長的時間。 微軟公司ceo史蒂夫·巴爾默(steve ballmer)曾說，.net流行還得等2~3年。 那麼，mfc至少還有2~3年的生命空間。 在技​​術日新月異的it界，2~3年實在是很長一段時間了。 好好把握吧。 即使你不使用mfc框架，花點時間看一下mfc的封裝機制對你熟悉c++的oop機制和windows底層功能也是很有好處的。 而vcl的源代碼是object pascal的，對c/c++程序員就沒有這個“額外”的作用了。   


 


我和專業有個誤會--最容易被誤會的專業


【 字體大小 大 中 小 】


新華網甘肅頻道 （2007-02-02 16:21）       來源：


 


 


    對於考生來說，要在高考填報誌願上數百個形形色色的志願名稱中找到一個真正合自己心意，在校幾年既能學到東西，畢業後又能找到一份對口、滿意工作的專業，絕對是一件大傷腦筋的事。


 


    好多高校都會在臨近高考前夕到一些中學面向高三學生做宣傳，那時候大學和專業介紹的宣傳材料貼滿了校園，好多學生都圍著看。 介紹材料中充滿了高科技的概念名詞和專業術語，讓單純的高中生們雲裡霧裡。 個個專業都看起來很美，但究竟這個名稱下專業學的是什麼，有多大的發展前景，是不是自己所想像的那一個專業，就概莫能知了。


 


    五花八門的專業，有的可以從專業名稱和院系名稱，顧名思義地大概“猜”出專業性質、培養目標和教學內容，像船舶與海洋工程、光信息科學與技術、國際經濟與貿易、材料科學與工程、建築學，學習內容指向明確，行業特色鮮明，辨別容易。而有些專業名稱概念比較籠統，範圍又特別大，像安全工程、生物技術、金融工程、信息管理與信息系統……連老師都不能完全明白其所以然，便常常根據往屆弟子的報考來做大致推斷，指導效果不很理想，考生們更是只好跟著感覺走，抽彩般胡亂填報了。


 


    於是，就產生了種種誤會，比較典型的有以下幾種：


 


    最合乎情理的誤會——老專業、新名詞


 


    誤會這些專業，是合乎情理的——專業就是那個專業，名字一絲不錯，有的連就業單位都能蒙住，沒辦法，誰有那麼多能耐打探盡它的前世今生？


 


    這類專業俗稱“新瓶裝舊酒”。一是為提高生源質量，二是國家也要求專業名稱規範，很多高校刻意把專業與“貿易”、“信息”、“自動化”等聯繫起來，紛紛開設相關專業，一些名稱中帶有“國際” 、“信息”等時髦字眼的專業異常火爆。改名稱，也沒什麼不好，關鍵是看有沒有相對應的師資和教學實驗設備，但就目前情況來看，許多二三流的大學由於經濟因素，並未能及時培訓或者引進師資，實驗條件也不完善，甚至開的還是老課程，這就容易誤人子弟了。還有的雖然及時更新了��