富有活力的語言需要不斷改變和成長，C++也不例外。在本文中，Bjarne Stroustrup提出了自己對C++的設(shè)計和演化的看法。
為了讓編譯器、工具和類庫實現(xiàn)者跟上節(jié)奏，讓用戶吸收標準C++所支持的編程技術(shù)，在早有預計的、沉寂了幾年之后，委員會再次考慮語言擴展問題了。"擴展工作組"已經(jīng)建立了，它代替了"演化工作組"。名稱的改變（這是Tom Plum的建議）反映了更重要的是語言特性和標準類庫工具的集成。我仍然是該工作組的主席。我希望這可以確保C++版本的連貫性和最終結(jié)果的一致性。相似的，委員會成員資格也顯示了大量人員和組織的連續(xù)參與。幸運的是，也出現(xiàn)了很多新的面孔，為委員會帶來了新的影響和新的專家意見。
我們打算對語言本身的改變保持謹慎和保守，重點強調(diào)兼容性。主要的目的是把主要的努力引導到標準類庫的擴展上來。在標準類庫方面，我們的目標是大膽進取，利用一切機會。
對于標準類庫，我希望根據(jù)類庫技術(shù)報告的要素來建立它，使它成為一個用于系統(tǒng)編程的更廣泛的平臺。例如，我希望看到用于某些領(lǐng)域的類庫，例如目錄/文件夾操作、線程和套接字。我還希望委員會同情很多新的C++程序員，提供類庫工具支持背景不同的新手（不是新程序員和C的難民）。例如，我希望看到一個使用范圍檢查STL的標準方法。我對最頻繁地被請求添加到標準類庫中的標準GUI（圖形用戶接口）的期望值很低。但是，奇跡有時候也會發(fā)生--記得STL嗎？
對于語言本身，我希望重點強調(diào)支持泛型編程的特性，因為泛型編程是語言的使用取得進步的領(lǐng)域。此處，我將調(diào)查兩個關(guān)鍵部分：
·概念（Concepts）：用于模板參數(shù)的類型系統(tǒng)
·初始化器（Initializer）列表：初始化工具的泛化
與以往一樣，建議的數(shù)量仍然遠遠超出了委員會能夠處理和該語言能夠吸收的數(shù)量。請記住，接受所有好的建議是不可能辦到的。
該語言擴展以支持泛型編程的全部目標是為工具提供更大的一致性，允許我們用泛型直接表示用于解決問題的類。
我的其它優(yōu)先考慮（與更好地支持泛型編程一起）是更好地支持初學者。目前的建議有一種值得注意的傾向，即這些建議照顧了哪些提出和評估建議的專家用戶。有些簡單地幫助那些新手的建議經(jīng)常被忽略了。我認為這是一種潛在的致命的設(shè)計偏好。除非新手受到了充分的支持，否則只有很少人能夠成為專家。此外，很多人并不希望成為專家；他們希望仍然是"偶然的C++用戶"。例如使用C++進行物理計算或控制試驗設(shè)備的物理學家只有有限的學習編程技術(shù)的時間。計算機專家可能會在編程技術(shù)方面花費很多時間，而不僅僅是期望。我們必須消除那些采用優(yōu)良技術(shù)的不必要的障礙。
一個非常簡單的例子如下：
vector> v;
在98年的C++中，這會導致語法錯誤，因為>>是一個單獨的詞匯記號，而不是封閉模板參數(shù)列表的兩個>。V正確的聲明可能是：
vector< vector > v;
我把它看作是一種阻礙。我曾經(jīng)建議這個問題值得解決，但是當前的規(guī)則和演化工作組用一些很好的理由兩次拒絕了我的建議。但是，這些理由都是語言技術(shù)方面的，而新手（包括其他語言的專家）沒有興趣。不接受第一種（也是十分）明顯的v聲明浪費了用戶和教師的時間。我希望>>問題和其它相似的"阻礙"不要再出現(xiàn)在C++0x中。實際上，我與Francis Glassborow和其他人一起，正在試圖系統(tǒng)地消除最頻繁發(fā)生的這類"阻礙"。
為了讓編譯器、工具和類庫實現(xiàn)者跟上節(jié)奏，讓用戶吸收標準C++所支持的編程技術(shù)，在早有預計的、沉寂了幾年之后，委員會再次考慮語言擴展問題了。"擴展工作組"已經(jīng)建立了，它代替了"演化工作組"。名稱的改變（這是Tom Plum的建議）反映了更重要的是語言特性和標準類庫工具的集成。我仍然是該工作組的主席。我希望這可以確保C++版本的連貫性和最終結(jié)果的一致性。相似的，委員會成員資格也顯示了大量人員和組織的連續(xù)參與。幸運的是，也出現(xiàn)了很多新的面孔，為委員會帶來了新的影響和新的專家意見。
我們打算對語言本身的改變保持謹慎和保守，重點強調(diào)兼容性。主要的目的是把主要的努力引導到標準類庫的擴展上來。在標準類庫方面，我們的目標是大膽進取，利用一切機會。
對于標準類庫，我希望根據(jù)類庫技術(shù)報告的要素來建立它，使它成為一個用于系統(tǒng)編程的更廣泛的平臺。例如，我希望看到用于某些領(lǐng)域的類庫，例如目錄/文件夾操作、線程和套接字。我還希望委員會同情很多新的C++程序員，提供類庫工具支持背景不同的新手（不是新程序員和C的難民）。例如，我希望看到一個使用范圍檢查STL的標準方法。我對最頻繁地被請求添加到標準類庫中的標準GUI（圖形用戶接口）的期望值很低。但是，奇跡有時候也會發(fā)生--記得STL嗎？
對于語言本身，我希望重點強調(diào)支持泛型編程的特性，因為泛型編程是語言的使用取得進步的領(lǐng)域。此處，我將調(diào)查兩個關(guān)鍵部分：
·概念（Concepts）：用于模板參數(shù)的類型系統(tǒng)
·初始化器（Initializer）列表：初始化工具的泛化
與以往一樣，建議的數(shù)量仍然遠遠超出了委員會能夠處理和該語言能夠吸收的數(shù)量。請記住，接受所有好的建議是不可能辦到的。
該語言擴展以支持泛型編程的全部目標是為工具提供更大的一致性，允許我們用泛型直接表示用于解決問題的類。
我的其它優(yōu)先考慮（與更好地支持泛型編程一起）是更好地支持初學者。目前的建議有一種值得注意的傾向，即這些建議照顧了哪些提出和評估建議的專家用戶。有些簡單地幫助那些新手的建議經(jīng)常被忽略了。我認為這是一種潛在的致命的設(shè)計偏好。除非新手受到了充分的支持，否則只有很少人能夠成為專家。此外，很多人并不希望成為專家；他們希望仍然是"偶然的C++用戶"。例如使用C++進行物理計算或控制試驗設(shè)備的物理學家只有有限的學習編程技術(shù)的時間。計算機專家可能會在編程技術(shù)方面花費很多時間，而不僅僅是期望。我們必須消除那些采用優(yōu)良技術(shù)的不必要的障礙。
一個非常簡單的例子如下：
vector
在98年的C++中，這會導致語法錯誤，因為>>是一個單獨的詞匯記號，而不是封閉模板參數(shù)列表的兩個>。V正確的聲明可能是：
vector< vector
我把它看作是一種阻礙。我曾經(jīng)建議這個問題值得解決，但是當前的規(guī)則和演化工作組用一些很好的理由兩次拒絕了我的建議。但是，這些理由都是語言技術(shù)方面的，而新手（包括其他語言的專家）沒有興趣。不接受第一種（也是十分）明顯的v聲明浪費了用戶和教師的時間。我希望>>問題和其它相似的"阻礙"不要再出現(xiàn)在C++0x中。實際上，我與Francis Glassborow和其他人一起，正在試圖系統(tǒng)地消除最頻繁發(fā)生的這類"阻礙"。