看的想死
我是真的替你们感到眼睛累。。。手动狗头
另外提醒一下，双下划线和单下划线加大写字母开头的名称都是预留字，只有语言实现里面允许用（比如在 STL 或者 libc 中）
不在其位，别谋其政。如果不是开发基础库，那么用不着那些个。C++ 和 C 的妙处根部不在于用了多少它的特性，而在于如何用尽可能它的最简单的特性最高效的完成既定任务。
话一句话说，能用 struct 搞定的，别硬用 class 。能用普通函数搞定的，没必要非得 template 化。能用 C 风格的字符数组搞定，就没必要用 std::string 类。
简单是力量的保证。直白易懂是可持久可维护的护身符。
书上都说能用 std::string，不用 C 风格的字符数组；能用 std::array，不用 C 风格的数组
另外如果只考虑 IDE 本身，并且非要推荐的话：
假如没有特殊情况的话，比如 sublime text，相对来讲默认样式要养眼很多。
再现代化的就可以考虑 vscode 或者 Jetbrain 家的产品是否能满足你的开发要求。
我不懂 C/C++，所以考虑不到这些 IDE 是否适合对应的工作流。
其实标准库没有想象的难，因为标准库的实现的东西都有 cppreference 可以参考,各个模块之间耦合也不深，而且可以多个标准库(libc++,libstdc++,msvcSTL)和仿标准库(eastl, folly)交叉验证着读，除了 iostream 之类的糟粕以外，容器和算法读起来都应该不会有太多困难。
其他语言的类库也会大量的利用元编程技术,例如 Java 的 Spring(反射)和 Ruby on Rails.
当然,如果单纯看元编程的灵活性,在这方面最厉害的是 LISP 以及方言.
以上观点参考自松本行弘的<代码的未来>
啊？
class ApplicativeOps[M[_],A](ma:M[A])(implicit a:Applicative[M]){
def ~>[B](mb: M[B]):M[B] = a(a(a.pure((_:A) => (b:B) => b), ma),mb)
def andKeep[B](mb: M[B]):M[B] = ~>(mb)
def <~[B](mb: M[B]):M[A] = a(a(a.pure((a:A) => (_:B) => a), ma),mb)
def keepAnd[B](mb: M[B]):M[A] = <~(mb)
def <~>[B,C](mb: M[B])(implicit witness: <:<[A,B => C]): M[C] = apply(mb)
def apply[B,C](mb: M[B])(implicit witness: <:<[A,B => C]): M[C] = a(a.map(ma,witness),mb)
而 stl 是 standard TEMPLATE library 的缩写，标准库本来就是为了写成模板才写成这个样子的。
大多数语言的标准库：为了方便我们的使用者快速造车，我们先把 IO / 文件系统 / 网络库的轮子造好
c++的标准库： 卧槽我发现我们发明的模板好像能搞些骚操作，让我尝试实现一套无类型的数据结构
所以说这套库的意义和场景都远远不能覆盖实际开发，千万不要为了模仿 stl 把自己的代码搞得不伦不类
根据自己的需求，合理选择这些东西，才是正解。
其实你去看其他大一点的开源项目，核心逻辑可能你都懂，但代码看着还是难受，因为大量都是在处理你可能根本没想到的特殊情况。
C++随着几个标准更新和编译器变得越来越牛逼，现在已经逐渐变得不坑了。所以不要吐槽新标准，没人想回到连模版两个尖括号都没法连着写的时代吧？
@James369 你可能不知道，template 语法是图灵完备的。
见过别人写的编译期筛法素数表，搞出一堆 IsPrime<3, true> IsPrime<4, false> 这种类型
那才叫真炫技（确实毫无卵用）
如果一个 virtual function 调用的开销都无法接受，只能接受 template class 的 function 进行 inline 内联场景下，你们就知道 C++ 模板的价值了。对，我说的就是 C 语言的函数指针都比不上的部分。模板特例化可以把优化运用到极致。比如快排 C 语言版 qsort 得传进去一个函数指针，有一次函数调用。而 C++ 的 std::sort 完全可以内联掉比较器
再比如多维张量中，所有维度都已知长度的小张量可以在堆上分配内存，而有些维度未知长度的大张量可以使用堆内存。这样能得到更高的效率。
这个不能怪 vector，即使自己管理内存，需要重新分配空间时也有同样的问题。
应该看 clang 的 stl 库，清晰不少。
然后，boost 库才是真会看得怀疑人生，各种模板技巧，大量 N 层嵌套的宏。
std::string 作为处理字符串的类，横向对比 Python, Java 等类似的实现，就显得很残很废很单薄。是不是？
我个人的话：template 不说精通，让我写个 stl 没压力。
机器学习不算大牛，让我推导主流网络结构公式都没压力。我的研究方向是 deep Bayesian network