標籤：

C++17 有哪些值得注意的新特性？

11-26

Stroustrup: Thoughts on C++17

不要想啦，C++ 17 毛都沒有。。。沒有 Module， 沒有 Coroutine， 沒有 Ranges，沒有 Reflection，沒有 Contracts，沒有……
唯一有希望的 Concepts 爭議很大。。也玄。
Network TS 也玄。
所以，……

--------------------------------------------------------------------------------------------------------------------------------
我的天，看到這個問題我激動得不知道說些什麼好。在 BS 的那篇 Thoughts about C++ 17 裡面已經提到了很多提案了。我說一點我研究過的吧，算是拋磚引玉：
先說一些開胃菜吧。

  • 模板的模板參數允許使用 typename（之前僅允許使用 class）
  • 修改了 initializer_list 的推導原則：

For copy-list-initialization, auto deduction will either deduce a std::initializer_list (if the types of entries in the braced-init-list are all identical) or be ill-formed otherwise.

For direct list-initialization:
1.For a braced-init-list with only a single element, auto deduction will deduce from that entry;
2.For a braced-init-list with more than one element, auto deduction will be ill-formed.

  • 還解決了迷之 ill-formed/UB（這個詳細請自行閱讀http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4089.pdf）

unique_ptr& ptr1(new Foo*[10]);
Foo const * ptr = ptr1[9];

  • 嵌套的 namespace:

namespace A::B::C {
//…
}

相當於：

namespace A {
namespace B {
namespace C {
//…
}
}
}

  • Fold Expressions：

template&

auto sum(T... s){

return (... + s);

}

再說說大的：

  • Concepts

在CppCon 2014裡面BS發表了主題為 Make Simple Things Simple 的演講，裡面提到了Concepts。根據他的意思，我們以後可以這麼寫代碼：

注意！Sortable可不是Java/C#里的Interface，它叫做Concept。

  • Module

對於Module也可以說是呼聲極高了，可以大幅加快編譯速度，帶來相當多的好處，不過我對於Module的提案沒有太多研究。

  • Contracts

Contracts 目前的提案是N4415。大概意思就是為每個函數指定一個 pre-conditions 與 post-conditions。大概像是這樣：

T operator[](size_t i) [[expects: i &< size()]];

ArrayView(const vector& v) [[ensures: data() == v.data()]];

那麼不滿足這些conditions會發生什麼呢？提案中說是「implemention-defined」。而且應該允許每個TU獨立打開所有的測試，關閉所有，打開/關閉pre，打開關閉post。

  • Unified Call Syntax

這個真的是太優美了。HS和BS分別提了一篇提案，後來倆人又一起弄了一篇提案。這個說的是什麼呢，就是統一f(x,y)與x.f(y)，這樣就不用std::begin一個，container.begin()又一個了。HS的提案中提到了這樣的應用場景：

void f(FILE* file)
{
fseek(file,9,SEEK_SET);
}

//proposed new C++ code
void f(FILE* file)
{
file-&>fseek(9,SEEK_SET); //nice autocomplete after "-&>"
}

不過現在這個提案還有很多細節在商討。
說了一些我了解的Core Language特性，說一些庫的東西吧！先說點小東西

  • std::invoke

讓我們看看如何實現一個apply:

template &
constexpr decltype(auto) apply_impl(F f, Tuple t, std::index_sequence&)
{
return std::invoke(std::forward&(f), std::get&(std::forward&(t))...);
// Note: std::invoke is a C++17 feature
}
template &
constexpr decltype(auto) apply(F f, Tuple t)
{
return apply_impl(std::forward&(f), std::forward&(t),
std::make_index_sequence &< std::tuple_size&&>::value &> {});
}

INVOKE的概念一直在標準裡面，這回終於有了真正的invoke了。

  • void_t

有了Expression SFINAE和void_t，寫模板真的是方便了太多了。就像這樣：

template&
struct reference_type
{
using type = decltype(*declval&()); // no reference, use operator*
};

template&
struct reference_type&
&>
{
using type = typename Iterator::reference; //I have a reference
};

再說說大的。目前這些都屬於 TS 。

  • 利用variable templates：

namespace std {
namespace experimental {
inline namespace fundamentals_v2 {

// See C++14 §20.10.4.1, primary type categories
template & constexpr bool is_void_v
= is_void&::value;
template & constexpr bool is_null_pointer_v
= is_null_pointer&::value;
//....

  • filesystem
  • network
  • Ranges

Ranges！這個我必須說一說。我們經常寫

std::sort(std::begin(v),std::end(v),std::greater&<&>{});

那個begin end太煩了。Ranges就是為了解決這個問題：

std::sort(v,std::greater&<&>{});

當然遠遠不止這點，Ranges 裡面的東西還可以花樣組合。你還可以寫出這樣的東西：

int total = accumulate(view::iota(1) |
view::transform([](int x){return x*x;}) |
view::take(10), 0);

其實背後的概念還是挺多的，例如 Iterable 等等。詳細的可以去看Ranges for the Standard Library, Revision 1 。

  • Type-erased Allocator

這個真的是深得我心啊！我最近正在按照目前的TS Draft實現這個東西。就是說一個vector:

std::vector&&> v1;
std::vector&&> v2;
v1 = v2;//Error

由於Allocator屬於類型的一部分，導致不同Allocator的vector不能copy啊等等。而且個人認為std::allocator有點雞肋。這回好了，有了一個叫做memory_resource的抽象類：

class memory_resource {
// For exposition only
static constexpr size_t max_align = alignof(max_align_t);

public:
virtual ~memory_resource();

void* allocate(size_t bytes, size_t alignment = max_align);
void deallocate(void* p, size_t bytes,
size_t alignment = max_align);

bool is_equal(const memory_resource other) const noexcept;

protected:
virtual void* do_allocate(size_t bytes, size_t alignment) = 0;
virtual void do_deallocate(void* p, size_t bytes,
size_t alignment) = 0;

virtual bool do_is_equal(const memory_resource other) const noexcept = 0;
};

之後有五種內置的多態allocator：

  • new_delete_resource()，使用::operator new/delete
  • null_memory_resource()，使用allocate就會拋出std::bad_alloc
  • synchronized_pool_resource
  • unsynchronized_pool_resource
  • monotonic_buffer_resource

有一個pmr::polymorphic_allocator的類滿足Allocator requirements，將一個memory_resource包裝起來：

#include &

namespace std {
namespace experimental {
inline namespace fundamentals_v2 {
namespace pmr {

template &
using deque = std::deque&&>;

} // namespace pmr
} // namespace fundamentals_v2
} // namespace experimental
} // namespace std

#include &

namespace std {
namespace experimental {
inline namespace fundamentals_v2 {
namespace pmr {

template &
using forward_list =
std::forward_list&&>;

} // namespace pmr
} // namespace fundamentals_v2
} // namespace experimental
} // namespace std

當然，我只是說了我了解的。還有很多其他的並發、並行演算法、SIMD vector、string_view/array_view、optional/variant/any我沒有做深入了解，就不誤導大家了。

其實現在的proposal很多很多，不出意外也會有相當一部分沒時間加進c++17。c++17會是一個大更新，下一個小修補會是c++20

我個人認為從發展角度來說，c++目前最需要的，是module，網路庫，以及更完善的並行庫。我只稍微搬一下Stroustrup桑今年最新提交的提案，提到了他認為的c++17是需要包括哪些東西。

全文具體鏈接。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4492.pdf

首先，C++永久性的目的就是運行效率。無論怎麼設計都不會違背這一點。

Whatever we do, we should preserve C++』s fundamental strengths:
? A direct map to hardware (initially from C)
? Zero-overhead abstraction (initially from Simula)
Depart from these and the language is no longer C++.

1. 關於大規模軟體系統的支持

  • Modules：不出意外，這個呼聲太高了。不但是編譯速度，就連最基礎的One Definition Rule的各種規則都能搞死人。最新的2篇modules提案：
    http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4465.pdfhttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4466.pdf說起來簡單，實現起來麻煩。目前提案者正在Visual C++中實現這些提案。因為這個呼聲很高，有理由相信進入c++17的可能性很大。雖然目前進展還不是很快的感覺。看proposal目前還有一些小的design decision沒有明確下來，例如是否需要interface這個關鍵字之類的。

    有了modules寫出來的代碼是什麼樣子呢，大概是這個樣子，

    import std.vector;
    import std.string;
    import std.iostream;
    import std.iterator;

    怎樣寫module呢？

    //abc.cpp （文件名無需和module名重合）
    module abc;
    struct internal { };
    int internal_f() { }
    export namespace abc
    {
    class abc { };
    }

    注意C++的module僅僅只是編譯範疇的，並不是二進位範疇的。效率為王。

  • Contracts：經過11年被洗禮之後，這次加進來問題應該不大了。最新的提案：

    http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4415.pdf

    出來時間比較久了，大家也都知道是幹嘛的，也有劉雨培童鞋說過最新提案，我就不多說了，其實Contracts簡化後也是蠻複雜的，但基本上即使你從沒接觸過，讀懂別人寫的代碼的難度也不大。

  • A type-safe union：也就是variant，基本上是在往functional-programming上靠。

    Stroustrup桑還給了一個鏈接，13年他的一個學生（？）的論文，一個c++的pattern matching庫，蠻坑的。我覺得不進行大改善，這個pattern matching庫進入c++的標準可能性不大。

    好奇的童鞋們不用找了，我拷個最簡單的例子出來。有了variant之後，這個match庫可以match類型+值。不過僅僅是庫而不是語言層面的支持，真是不倫不類啊。

    int factorial(int n) {
    int m;
    Match(n) {
    Case (1) return 0;
    Case (m) return m*factorial(m-1);
    Case (_) throw std::invalid_argument("");
    } EndMatch
    }

2. 關於並行

  • 基礎網路庫：這個太需要了，沒有基礎網路庫，其他任何網路相關的操作都是空中樓閣。

    基於boost::asio的最新提案，

    http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4478.html

    boost::asio的async模型基本是callback。但這個proposal其實並不是簡單的boost::asio直接拷貝過來，除了基本的asio之外，還基於future和co-routine加了不少料。

    例如，基於future的async模型，

    std::future& fut =
    socket.async_read_some(buffer(buffer_space), use_future);

    // ...

    std::size_t length = fut.get();

    複雜一點還可以這樣，

    socket.async_read_some(buffer(buffer_space), use_future).then([](std::size_t) {});

    例如，基於co-routine的async模型（例子是stackful的，stackless需要語言層面支持）。

    void coro_connection(tcp::socket socket, yield_context yield)
    {
    try
    {
    std::vector& buffer_space(1024);
    for (;;)
    {
    std::size_t length = socket.async_read_some(buffer(buffer_space), yield);
    uppercase(buffer_space.begin(), buffer_space.begin() + length);
    async_write(socket, buffer(buffer_space, length), yield);
    }
    }
    catch (std::system_error e)
    {
    // ...
    }
    }

    基本上可以看出網路庫是一個async模型的大雜燴，只要你有，我就支持。

    最後，這個proposal還加了一些高級的庫（無需關注底層細節）。

    tcp::iostream s("www.boost.org", "http");

    s &<&< "GET / HTTP/1.0 "; s &<&< "Host: www.boost.org "; s &<&< "Accept: */* "; s &<&< "Connection: close "; std::string header; while (std::getline(s, header) header != " ") std::cout &<&< header &<&< " "; std::cout &<&< s.rdbuf();

  • SIMD vector：數學計算啊，遊戲啊，沒什麼好說的，研究這方面的自然懂，不研究的這個概念也沒啥複雜的。下面這個提案提出一個matrix 類，乘法等操作利用simd搞計算。

    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4492.pdf

  • Improved Future: 基本上都是微軟根據.Net經驗提出來的。就比如網路庫的.then，就是基於此。你可以async_read( ).then().then().then()，等等。具體看proposal吧，蠻簡單易懂的。

    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3857.pdf

  • Co-routines：主體也是微軟搞出來的提案，基本和.net一樣的語法。在VC++上已經有實現。本來這東西就分stackful還是stackless。微軟應該是比較傾向於stackless的，google一人也提出了stackful和stackless的語法可以統一的一個提案。具體還未定。很可能是都支持，用戶可自由選擇的。其實微軟的提案還是比較吸引人。關鍵字：await，yield

    https://isocpp.org/files/papers/N4402.pdf

    我要多說一些，因為蠻有意思，

    複製一下微軟的design goal：

    * Highly scalable (to billions of concurrent coroutines)
    * Highly efficient resume and suspend operations comparable in cost to a function call overhead
    * Seamless interaction with existing facilities with no overhead
    * Open ended coroutine machinery allowing library designers to develop coroutine libraries exposing various high-level semantics, such as generators, goroutines, tasks and more
    * Usable in environments where exception are forbidden or not available

    就看他的design goal就很想敢用了

    寫出來的代碼什麼樣子呢？await和yield關鍵字其實.net, python啊，java啊之類的也都有，沒什麼好解釋的，要說下generator和goroutine，你沒看錯，是類Go語言的goroutine支持。

    generator:

    generator& fib(int n) {
    int a = 0;
    int b = 1;
    while (n-- &> 0) {
    yield a;
    auto next = a + b;
    a = b;
    b = next;
    }
    }

    goroutine:

    goroutine pusher(channel& left, channel& right)
    {
    for(;;) {
    auto val = await left.pull();
    await right.push(val + 1);
    }
    }
    int main() {
    static const int N = 1000 * 1000;
    std::vector&&> c(N + 1);
    for(int i = 0; i &< N; ++i) goroutine::go(pusher(c[i], c[i + 1])); c.front().sync_push(0); std::cout &<&< c.back().sync_pull() &<&< std::endl; }

  • Trasactional Memory: 底部支持，沒什麼好說的。基本是板上釘釘。
  • Parallel STL

    基本上就是並行實現的stl，可以選擇模式，例如sort

    sort(begin(v), end(v)); //無並行
    sort(seq, begin(v), end(v)); //無並行
    sort(pal, begin(v), end(v)); //並行
    sort(par_vec, begin(v), end(v)); //並行矢量化
    execution_policy exec=seq; //動態決定
    if (v.size() &> 1000) exec = par;
    sort(exec, begin(v), end(v));

3. 語言用法簡化

  • Concepts: 不說了
  • Ranges: 也有童鞋說過了，不說了。總體來說ranges就是一對數[i, j),或者一對iterator。需要對STL庫進行添加支持針對Ranges的操作。例如你可以sort(v),而無需sort(begin(v), end(v))
  • Default comparisons：就是說會自動生成operator &>, ==之類的。對用戶自定義move或者copy的不會自動生成。
  • Uniform call syntex：也有童鞋說過了。

    目前這個提案大概是確認了：如果f(x,y),那麼就先找函數，如果函數沒有，再找x.f(y)。而x.f(y)相反，找不到類x的f函數，再去找
    f(x,y)函數。也有另外一個選擇，就是x.f(y)和f(x,y)所有符合的全部放到一起然後做overloading
    resolution。這樣可能會破壞現有的代碼。還有2年時間可以討論選哪種。

  • Operator dot： 沒什麼可說的
  • array_view和string_view: 蠻有意思的東西。

    假設你有一個字元串「abcde, xyz"，目前來說，如果你實現一個函數，從逗號分割這個字元串，你會得到2個字元串"abcd", "xyz"。但如果有了string_view，你會得到2個string_view，每個string_view裡面是一個(start, size)對，這樣就節省了多個字元串拷貝。

    array_view可以更有意思，

    auto M = 32;
    auto N = 64;
    auto v = vector&(M * N);
    auto av = array_view&({M, N}, v);

    你要問為啥不直接 vector&&>，因為這樣無法保證內存連續分配啊。

  • stack_array：還沒有proposal
  • optional，和variant類似吧。目前沒有proposal，除非pattern matching被加到c++17中去了，否則不太可能17里實現。

以上就是stroustrup桑眼裡的c++17應該大概支持這些。當然不是一個完整列表，不包括一些庫的改進和語法小改進。

距這個問題提出的2015年7月又過去了半年。我來介紹一下最近半年adopted的一些新提案：

Source_location
experimantal的東西，在constexpr的幫助下有了編譯期（而不是預處理期）的文件信息。調試可能會更加方便一些。

struct source_location {
constexpr source_location() noexcept;
constexpr uint_least32_t line() const noexcept; //行數
constexpr uint_least32_t column() const noexcept; //列數
constexpr const char* file_name() const noexcept; //文件名
constexpr const char* function_name() const noexcept; //所在的函數名
static constexpr source_location current() noexcept; //當前source_location，如果用在函數默認參數里會是調用處的source_location

__has_include

#if __has_include(&)
# include &
# define have_optional 1
#elif __has_include(&)
# include &
# define have_optional 1
# define experimental_optional 1
#else
# define have_optional 0
#endif

vector, list, forward_list 的不完全類型支持
MSVC STL, libstdc++, and libc++其實都已經支持了，這次寫進標準了。

struct Entry
{
std::list& messages;
// ...
};

register關鍵字被廢除
出於兼容性考慮，目前在考慮有extern "C"的函數可以繼續使用register關鍵字。

bool的++操作被廢除
萬惡之源：++true == true

noexcept被作為類型系統的一部分
但是指向noexcept函數的指針可以隱式轉換成普通函數指針。（屬於Qualification Adjustment，Rank是Exact Match）
PS： 看一看STL中is_function有多少個版本的特化？如果沒有上面這條隱式轉換的話，版本數會加倍。

conjunction, disjunction與negation模板
類型即值

template& struct conjunction; //當且僅當所有B::value都是true時繼承bool_constant&，否則是bool_constant&
template& struct disjunction; //或
template& struct negation; //非

TS的網路庫（第7版）被採納
不太了解，還是看原文吧：
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0112r1.html

TS的task_block被採納
並行遍歷二叉樹：

template&
int traverse(node *n, Func compute)
{
int left = 0, right = 0;
define_task_block([](task_block tb) {
if (n-&>left)
tb.run([] { left = traverse(n-&>left, compute); });
if (n-&>right)
tb.run([] { right = traverse(n-&>right, compute); });
});
return compute(n) + left + right;
}

謝邀，貌似常見的特殊函數也會在C++17中成為標準庫的一部分Mathematical special functions

這麼多人，這麼多人在這裡開腦洞，為什麼不去做一個可以編譯的Python！

沒人喜歡那個「類模板類型參數推導」嗎？終於構造函數也可以直接推導出類模板參數了。其實只是方便了一丟丟，但是代碼看起來好看了點兒。比如寫tuple和pair的時候完全不用管類型是什麼，直接構造就行了，看起來還是不錯的。而且這個肯定是在C++17中的。
之前都是靠一個函數來幫忙實現這個功能。
===============
看來最近關注C++17的人不多啊，前一段時間貌似定下來了，跟之前討論的差不多，看到了concept，modules，ranges，networking這些都提出來了，不過還看到了reflection，貌似未來是編譯器端實現，但是不知道會不會像Java的那樣還挺好用的。不過想想就得為實現編譯器的童鞋們的頭髮捏一把汗。

整理自botondballo 的博客Trip Report: C++ Standards Meeting in Kona, February 2017

八成出不了大新聞，等C++20啦。。。

C++17是語言小修改（相對C++14，大概20幾條）、標準庫增加比較多（大概200多條）。

C++20將會是可以和C++11可以媲美的大發展。

個人越來越喜歡現代C++，其在保證性能的情況下提供足夠的抽象，值得一學。很多函數式功能以及DSL用現代C++都可以比較方便的搞出來。而且可以根本不用直接new/delete，以前的內存泄漏等事件在C++11後只有遵循新標準就基本可以杜絕。

有人在CppCon上問BS說Mozila公司搞的那個怎麼樣，BS回答的大意是很多人想搞出C++ killer，但至今沒實現，造一個語言不難，但killer需要用戶base。Mozila的那個如果可以不斷搞簡單點也許用的人會多一些，如果不能降低複雜度的話必失敗無疑。

Btw, BS一貫不喜歡Java，認為是一個錯誤的解決方案。

作為一個普通的不得不用C艹的猿，那些神奇的特性，我幾乎是用不到啊/(ㄒoㄒ)/~~
C艹真要出，還是出一個類似Java的代碼文檔吧，這樣編譯器可以更好地支持自動補全。Java也是越更新越大，但是每次更新，新的庫很快就會被加入到生產環境，因為人們很快就能知道它怎麼用。對於C++，每次更新帶來一坨坨新的命名空間、類、函數、對象，各種IDE只有謎一樣參數類型的和迷一樣變數名的自動補全根本沒法用。一個不常用的API，只能上網搜，用戶接受一個新特性需要很久很久。
一個沒有新用戶加入的語言，真的是難以為繼的。現在如果不是一坨坨的底層開發用到的庫因為各種原因不得不用C艹，我想C艹開發者的數量肯定還會銳減吧。

應該搞ABI統一。這些語言特性越搞越複雜，在不能統一ABI的情況下那就是路越走越窄。

為啥？ABI不統一，各種不兼容，鏈接失敗，跨編譯器失敗，跨版本失敗，乃至跨編譯條件失敗，都不兼容產品發布哪能辦？只能做C版本API發布。好了，C發布了再搞文件頭封裝C++給人用。。。有病。。。

於是其他語言封裝也是基於C的，不幹C++鳥事。好了，C++就成了一種只對開發人員滿足自己大腦神經網路拓撲結構（概念抽象）的工具了，沒有實際社交用途了。自然是用的人越來越少。最後淪落為少數精英偷懶寫模板的工具。

同樣是C++程序員，可能互相看不懂對方代碼。。。

我的天，17都出來了，我14還沒用過，，

越來越像scala，haskell了，我還是用我的fp吧。
比如optional，表示有值或無值
variant表示左右值，某個變數可以是int。
標準庫和module不加，編譯慢到髮指，一群老頭子還在加語法糖。
遲早要被rust爆的體無完膚

其實上，每次C艹新標準可以分成三類，隨手打的，分類下舉例不完全，權當拋磚引玉

背景知識（請認真上網檢索以下兩條，如果你不明白他們的確切含義和影響）：
目前常見C艹工具鏈(MSVC/g++/Clang)均在C艹標準支持之外有自己的擴展
C艹無ABI規範

1. 新語言特性 - PLD 層面
11/14: R-ref、initialize_list(這貨其實到17還是一半殘廢)、lambda
17: concepts、contracts
這類特點是，在C艹標準提出前已有的工具鏈不支持(實驗產品不算)。引入它們能給性能（優化）或工程帶來好處。

這類是C艹新標準的重中之重，也是C艹標準更新的最大意義，也是C艹被rust爆菊爆的最嚴重的重災區

2. 新語言特性 - flatform 結合層面
11/14: thread-local var， long long int
17: SIMD
這類特點是，其實常見C艹工具鏈到早就支持支持再支持了，C艹新標準只是統一了一下語法，cross-platform不用寫那麼丑的ifdef了。ABI沒有統一，所以大家還是各家工具鏈出來的自己玩自己的蛋去吧（雞生蛋蛋生雞的蛋，不要想歪）

工程實踐上沒有任何意義（都早就工具鏈支持了，而且寫個wrapper來包裝一下也就基本沒有cross-platform的問題了），但是教學上至少能讓那些不hands-on的同學們知道這些機制，知道『哦，計算機還可以這樣處理數據』

3. 雜
標準庫新加的——你沒加之前我們有boost，有各種輪子，像BS大爺現在供職的這種大公司肯定會為了address C艹的工程/性能issue有大量的私有輪子
語法糖新加的——可以讓新手少犯點錯
編譯機制(C艹17 modules)——其實意義很大，但來的太晚了。不可能為了支持modules去改每一個現有的庫

太雜了，所以放在一起說。這部分基本上都還比較重要，然而都有一個問題，existing working dead code沒有任何動力為了這些新特性而migrate到C艹新標準的版本


事實上對於任何一個編程語言的實用性，都可以從這3個角度評價。
但C艹的第三個角度沒啥意義是因為C艹最大優勢是已有代碼的量。你看rust，要是他在「雜」這類里做的不如C艹的話，前兩個再好也肯定沒人鳥他

我想說乃們什麼時候增加一個提高編譯速度的特性好嗎？比如模塊。好吧，模塊已經確定沒有了。

還在不停地給世界上最複雜編譯速度最慢的語言增加更複雜編譯速度更慢的特性，我的2690 v3已經吃不消了好嗎。。。。

std::apply 很不錯，以前要寫十行代碼的工作，現在一兩行搞定

C11都沒學會，c17就要來了么！

C++17在作死的路上越走越遠，看看這些年C++的市場佔有率吧，C++需要的不是這些鳥特性，而是規範統一好用的庫啊，是對商業化開發的友好支持啊，真是日了狗了。

那些喜歡C++常用C++的，可不可以徵求大家意見自己做一套滿足大多數人想法的標準呢，把不好用，經常不用的語法、特性給去掉，把精華留下

人生苦短，C++不適合80後折騰了

推薦閱讀：

※你是如何自學 Python 的？
※編程零基礎應當如何開始學習 Python ？
※如何確定自己是否適合做程序員？
※為什麼尾遞歸優化似乎不常出現在非函數式語言的解釋器、編譯器中？
※怎樣讀《C++ 編程思想》？

TAG:編程語言 | C++ | C++ 標準 | C++17 |