建站
咨詢
售后
建站咨詢
新聞中心
下面講述有關C++復雜性的問題，實際上C++復雜性是一個距離應用相當遙遠的非?；A的程序庫，其主體部分只相當于Java中System和Util兩個package，接下來進行詳細說明。
站在用戶的角度思考問題，與客戶深入溝通，找到碑林網站設計與碑林網站推廣的解決方案，憑借多年的經驗，讓設計與互聯網技術結合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網站建設、成都做網站、企業(yè)官網、英文網站、手機端網站、網站推廣、申請域名、雅安服務器托管、企業(yè)郵箱。業(yè)務覆蓋碑林地區(qū)。
或有人說C++之關鍵缺陷是沒有統(tǒng)一完整的類庫支撐，Bjarne Stroustrup即強調此因素。然而這其實只不過是一個結果，而不是原因。正是因為語言太復雜，才無法在有效期內開發(fā)出高質量的大一統(tǒng)的類庫。
C++復雜，并非是其體積龐大之必然結果。復雜是對結構混亂無序程度的描述，規(guī)模大，結構不見得必然復雜。C++的復雜，也并不是如很多人所認為，是若干種編程范式（paradigms）的并存而至。事實上，現代實用編程語言至少有2-3種范式才能登大雅之堂。以范式數量論，Python和Ruby等新型動態(tài)語言的范式甚至多于C++，然而它們卻以簡單和開發(fā)效率高著稱。
C++復雜的根源在于三大約束：與C的完全兼容、靜態(tài)類型檢查、最高性能。在三大約束下，C++未能完善對于面向對象思想的支持，未能建立強大的動態(tài)能力，從而使得C++在OO這個單項上存在本質缺陷。
事實上，C++的過程、OB模型相當成熟和穩(wěn)定，而泛型模型，就單項來說，除了語法丑陋之外也沒有大的問題。缺陷集中體現在OO模型的實現，并因此干擾了其他幾個范式的完整程度。
然而，OO的缺陷絕非設計者的偏執(zhí)，其原因在于三大約束。如果堅持三大約束，則即使再重新設計一次，結果也與今日相差不遠。Stroustrup在多種場合表示，對C++的設計沒有大的后悔之處，意思就是這個。侯捷先生早在2001年初即對我說，C++在OO上不及Java，當時體會不深。
認為沒有大一統(tǒng)的單根類庫會使設計更加靈活，后來又認為憑借GP可以抵消OO的不足甚至超越之，現在看來即使不是不可能，這條道路也必然是艱辛異常，成敗難以預料。又因為上述所有因素的綜合作用，C++基礎類庫的建設只能進行到很低的高度上就停下來，因為再往上走就面臨重重困境和無窮無盡的爭論。
C++復雜性實際上是一個距離應用相當遙遠的非常基礎的程序庫，其主體部分只相當于Java中System和Util兩個package。而C++寧可停在這樣的低層次，也不愿意放棄三大約束中的任何一個。這種執(zhí)著使得高層標準庫設施的建立異常困難，使用也不容易。Boost庫中相當部分組件的易用性不佳。
模板的復雜語法與三大約束也有直接的關系。另一個原因是Bjarne在發(fā)明模板時目標單純。C#和Java加入泛型機制的時候。沒有繼承C++最好的經驗，卻不約而同地繼承了C++模板機制中最壞的部分——語法，短期來看，喪失了一次改革的良機。長遠來看，必成累贅。
C++中的多種范式并行，是一些最復雜問題的表面原因。以至于Doug Lea建議在一個項目里只堅持一個范式。但是這仍然只是表象。歸根結底還是因為OO的缺陷，使得與其它范式合作時困難成倍放大。故自接受Doug Lea思想以來，我的C++（乃至其他現代語言，尤其是Python等多范式語言）的開發(fā)設計思路是：
1. 首先選定一種思維方式（即范式），盡可能只用這一種思維方式解決問題；
2. 如果在局部遇到其他思維方式更得力的問題，則經慎重考慮后，可以將另一種風格包裝在局部，解決局部問題。但整個系統(tǒng)在某一層次之上看來，應當是統(tǒng)一一致的。一般對C++復雜性說明，應以OB為基本風格。除非有類似MFC那樣龐大而成熟的OO庫支持，不應貿然在整體上使用OO風格。
3. 多種風格混用，除非有已被充分討論并驗證的方案（即成熟模式），可提供單一風格不能提供的較大優(yōu)勢，否則應極力避免。當然鼓勵在研究中探索，但實踐是另一回事。
文章名稱：關于C++復雜性問題解析
文章出自：http://www.5511xx.com/article/dpsdeec.html
