討論:C++
C++屬於維基百科技術主題的基礎條目擴展。請勇於更新頁面以及改進條目。 本條目頁屬於下列維基專題範疇: |
|||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
前面 Jackcsk 認為 (int main() 函式期待一個int回覆,不回覆可以,但可能會購成未預期的結果,也不是一個良好的編程習慣), 這應該是一個誤解,因為 int main() 這個函數比較特殊,在 ISO C++ 98 standard 的 43 頁, 3.6.1 節 這樣寫到, A return statement in main has the effect of leaving the main function (destroying any objects with automatic storage duration) and calling exit with the return calue as the argument. If control reaches the end of main without encountering a return statement, the effect is that of executing
return 0;
VC6 里不寫 return 0 是會產生一個 warning, 但是 VC7 已經對此做了修正,如果不寫 return 0, 隱式的會產生一個 return 0 的邏輯,這是符合 C++ 98 標準的。 --雲風 06:45 2004年5月18日 (UTC)
為什麼使用C++(半角的+)命名會不行呢(變成C_編程語言)?Samuel 2003年6月25日 11:32 (UTC)
- 欸,用中文的+,好主意。對,+ 和 / 還有一些符號WP有其他特別作用,所以無法顯示。 --Menchi 2003年6月25日 11:46 (UTC)
- 這樣不行的,以後如果再英文字母/數字/符號什麼的應該怎麼辦?(如C#,3DNow!等)全半角混用肯定不是一個好主意,體現不了百科全書的權威性。我想知道英文wikipedia是怎麼處理這類條目的?Frank 11:57 2004年4月30日 (UTC)
- 半角的+已可以作為條目SYSS Mouse 04:30 2006年1月10日 (UTC)
為什麼看不到詳細的C++教程,wiki對事物的闡述不應留於表面,否則不是很沒意義,以後有空了我準備加一些對C++的學習。
- 我個人覺得在wiki上加入教程沒有意義,倒是一個引用一些個大家公認的經典書籍,例如 TCPL , D&E。對 C++ 語言本身以及歷史發展有參考價值。 --雲風 10:56 2004年4月30日 (UTC)
在 hello world 例子程序里,不要用 endl。endl 是在換行的同時,調用 flush(),這是一個 很慢的操作,是不必要的操作,很多程序因此而造成性能問題,都是由於寫者不理解 endl 到底是 什麼,到處亂寫 endl。
要換行,就寫 "\n",\n 就是幹這個用的,不需要其他更複雜的東西。
std::endl並無不妥
個人認為原來的例子中使用std::endl並無不妥,實際上每一個輸出的語義群結束,我們應該調用輸出流的flush()以確保顯示。這不是該考慮效率的地方,我們必須首先確保邏輯正確,不是嗎?當然,在這個極其簡單的例子中不調用也不會有問題,flush()會在程序退出的過程中被調用。但顯然原來的std::endl具有更加明晰豐富的語義,不知道Tx是否同意我的看法。
--Zeraph 16:17 2004年6月1日 (UTC)
同意。這只是例句,這樣使用的人也相當多,並無不妥。Djyang 17:56 2004年6月1日 (UTC)
你說的是,我當時只是感到和自己平常書寫習慣不一樣,就動手改了,呵呵。Caoi 07:46:07 2005年11月15日 (UTC)
關於 Bjarne 的讀音
根據C++主網頁里的FAQ,Bjarne 這個字應讀成 Be-ar-neh或By-ar-ne,所以以我看名字譯成"比加尼"好象不對,譯成"比雅尼"可能更好。
- (:)回應:已經改為「比雅尼」。--Hy48 13:06 2006年10月5日 (UTC)
tests for bugzilla:
例子
這個條目的例子似乎太多了....... 沒有需要把有 "using namespace std" 跟沒有 "using namespace std" 都寫一次. 如果是想講 import namespace 的話, 應該多寫一段講解
- 這是百科,應該着重介紹C++的特徵,一個hello world就夠了 精英王子 2012年6月9日 (六) 01:56 (UTC)
過時的內容
暫時移動到這裡,誰有確切的資料可以改動後寫回去。
- 遺憾的是,由於C++語言過於複雜,以及他經歷了長年的演變,直到現在(2004年)只有少數幾個編譯器完全符合這個標準。
--Zibingrong 6:55 2009年6月24日 (UTC)
- 現在也是如此,最典型的一點是,模板的export除了Comeau還沒有哪個編譯器支持。所以簡單地把2004改為2009沒有什麼不妥。 Devilphoenix (留言) 2009年9月26日 (六) 09:04 (UTC)
- 不同意(不論是哪個「現在」)。2003年WG21/N1426已經明確提議反對export繼續保留在標準中;後續的投票也支持了這點。事實上ISO C++11已經移除了export特性。此外注意,每一個新的正式標準會取消舊版本的有效性(在草案中沒有體現)。如果僅指編譯器,那麼在C++14沒有正式出版的情況下,G++和Clang++都已經(宣稱)符合現行正式標準。幻の上帝(留言) 2014年9月25日 (四) 13:59 (UTC)
合併
大家同意把Const合併到本條目嗎?--210.6.97.73 2009年9月17日 (四) 07:39 (UTC)
- const並非C++獨有,若要進行相關合併,也該是創建一個「常量」並與數學常量消歧義,再把const合併過去。 Devilphoenix (留言) 2009年9月26日 (六) 09:06 (UTC)
錯誤的鏈接
文中提到MPL程序庫,但是給的鏈接其實是Mozilla Public License的頁面,請誰修改一下比較好。(Mikeshi 2010年4月26日(一) 04:41 (UTC)
- 已經修改連結至Boost函式庫頁面,麻煩看看是不是對的。 (Andymememe Peace! 2016年7月5日 (二) 01:24 (UTC))
超過三年的錯誤
我在編輯摘要中打錯了,翻看修訂歷史,是超過三年也沒有修正該錯誤才是。--LungZeno(talk) 2010年10月31日 (日) 17:42 (UTC)
爭議段中的回應沒有必要且過於個人化
對於幾種爭議的觀點。最後有三個回應,沒有必要且太個人化,希望刪除
(-)反對:不同意該段落中存在明顯有爭議的觀點(雖然表達方式不一定妥當);明確個人化的觀點已經清楚地和具體的人對應(雖然諸如Linus Torvalds的說法仍然需要補充來源)。這些意見因為歷史顯著性,不適合刪除。若對其它內容有意見,具體是哪幾個爭議的觀點,請清楚地引用。如果是指最近被回退的部分,有很清楚的一些間接證據表明被保留的段落甚至更加不可靠(例如所謂「面向過程」涉嫌原創研究)。最後,請不要在留言中遺漏簽名。-- 幻の上帝(留言) 2022年7月24日 (日) 05:32 (UTC)
下面這一句與主題無關,我已將其刪除
Forrester最新的調查顯示,C++、微軟Visual Basic和Java是眾多公司產品體系的首選語言。對100家公司的調查顯示,C/C++、Visual Basic和Java在產品體系中的使用比例分別是59%、61%和66%。 --110.206.10.119(留言) 2013年12月29日 (日) 10:24 (UTC)
Samsung
Notes 2603:6011:AE01:86E4:18DE:82C1:E4A8:E9CD(留言) 2021年11月11日 (四) 05:33 (UTC)