65,187
社区成员




std::transform(std::begin(a), std::end(a), std::begin(b), [](int a){return a + 50;});
c++14
std::transform(std::begin(a), std::end(a), std::begin(b), [](auto a){return a + 50;});
这一来,以后a的type改变的时候,我们就不用连lambda都一起改了
说穿了,那个auto就是一个template parameter而已
这是一个本来就该有的功能,c++11碍于一些技术障碍没来得及加进去
这你不用担心,错误讯息只会越来越容易阅读
c++的concepts有了很大的进展,最迟应该在c++17就会引入
以后我们再也不用学习如何解读那犹如密码般难读的错误讯息
不管那一门语言,随着发展标准一定是越来越厚的
时代在变,语言也在进化
就连c也是一直在扩充和改变
你问问看身边的人有谁懂c11多了什么东西?
为何?因为懒惰啊,新东西出来了又要重学
我又重“自以为的专家”降级成新手?
他们可不愿意花这些时间
只好拼命贬低新的发明了[/quote]
其实的确是作死,尽管对普通用户一般可以忽略。
标准和实现维护的成本越来越大,提交新特性考虑的兼容包袱越来越重。很多改变不是一开始就有明确的目的,而是发现了不协调的地方得修补。一个例子:xvalue的引入就是消除类型系统和左值性复杂交互(简化引用类型和左值的关系这点早在1992年就有paper提了)和冗余的失败。
另外,实际上至少标准库的一部分文本还是有很大冗余(就是“复制粘贴”,典型的如Clause 30里的一些requirements全是重复的)的,这部分倒真不一定“越来越厚”。
[/quote]
普通用户可以忽略就行了,编译器的实现什么的是别人的事情
重要的是让一般用户觉得这们语言越来越容易使用
http://www.lextrait.com/vincent/implementations.html
从这里可以看到很多重量级的大型软体还是采用c++
windows的OS甚至有越来越多代码采用c++
如果linus不是c++黑或c++小白
linux大概也早就跟windows,mac一样混入c++了(linux的codes已经是越来越难维护)
gcc受到竞争对手clang的刺激后更是加速向c++迈进
gcc48已经完全改由c++实现
std::transform(std::begin(a), std::end(a), std::begin(b), [](int a){return a + 50;});
std::transform(std::begin(a), std::end(a), std::begin(b), [](auto a){return a + 50;});
std::transform(std::begin(a), std::end(a), std::begin(b), [](int a){return a + 50;});
c++14
std::transform(std::begin(a), std::end(a), std::begin(b), [](auto a){return a + 50;});
这一来,以后a的type改变的时候,我们就不用连lambda都一起改了
说穿了,那个auto就是一个template parameter而已
这是一个本来就该有的功能,c++11碍于一些技术障碍没来得及加进去
这你不用担心,错误讯息只会越来越容易阅读
c++的concepts有了很大的进展,最迟应该在c++17就会引入
以后我们再也不用学习如何解读那犹如密码般难读的错误讯息
不管那一门语言,随着发展标准一定是越来越厚的
时代在变,语言也在进化
就连c也是一直在扩充和改变
你问问看身边的人有谁懂c11多了什么东西?
为何?因为懒惰啊,新东西出来了又要重学
我又重“自以为的专家”降级成新手?
他们可不愿意花这些时间
只好拼命贬低新的发明了[/quote]
其实的确是作死,尽管对普通用户一般可以忽略。
标准和实现维护的成本越来越大,提交新特性考虑的兼容包袱越来越重。很多改变不是一开始就有明确的目的,而是发现了不协调的地方得修补。一个例子:xvalue的引入就是消除类型系统和左值性复杂交互(简化引用类型和左值的关系这点早在1992年就有paper提了)和冗余的失败。
另外,实际上至少标准库的一部分文本还是有很大冗余(就是“复制粘贴”,典型的如Clause 30里的一些requirements全是重复的)的,这部分倒真不一定“越来越厚”。