- 主题:how c++20 change the way wcode
C++现在的复杂度不能忍了.正确的抽象会让语言规则变得简单.
现在的SFINAE啊type_traits啊真的是正确的抽象吗?
C++要么新出来个大佬简化挽救这一切.
要么就半身入土进垃圾堆.
--
FROM 73.63.209.*
SFINAE和type_traits更多地时候是让库更不容易误用，接近白名单的做法。感觉不是为了提供更好的抽象...
你的类想和iterator兼容，ok，请自己举手，定义这些个member type
不这样的做法：
一是不用template而是用interface：application一般这样做，反正application一般不是hotpath
二是不施加这个type traits定义，对不对随缘。好一点的留下一个文档说vector<bool>和普通的vector<XXX>不一样，不好的就变成一个undocumented feature, 或者StackOverflow上一个高分问答...
一句话就是非library少用
【 在 allegro 的大作中提到: 】
: C++现在的复杂度不能忍了.正确的抽象会让语言规则变得简单.
: 现在的SFINAE啊type_traits啊真的是正确的抽象吗?
: C++要么新出来个大佬简化挽救这一切.
: ...................
--
FROM 75.31.75.*
这个问题不止是C++遇到，其他语言比如python,javascript也面临同样的问题：工具变异太快，开发人员为了升级疲于奔命，消耗了原本可以用于创造积累的时间精力。
【 在 allegro (静水流深) 的大作中提到: 】
: C++现在的复杂度不能忍了.正确的抽象会让语言规则变得简单.
: 现在的SFINAE啊type_traits啊真的是正确的抽象吗?
: C++要么新出来个大佬简化挽救这一切.
: ...................
--
FROM 114.85.147.*
我觉得 c++ template 太丑是因为它是生造出来的另外一门语言，寄生于原始类 c 的 c++ 语法里面。它的作用很单一，只为了在编译期生成另外一门语言的代码。
把 c++ template 看成独立的函数式编程语言来分析的话，会发现它的制作水平比 javascript 还差。现在 traits 这类东东，相当于其它语言的 interface，很快这门语言还会补上更多其它面向对象和函数式语言必备的东东，早晚有一天，还会加上函数式编程语言必备的宏。
【 在 allegro (静水流深) 的大作中提到: 】
: C++现在的复杂度不能忍了.正确的抽象会让语言规则变得简单.
: 现在的SFINAE啊type_traits啊真的是正确的抽象吗?
: C++要么新出来个大佬简化挽救这一切.
: ...................
--
FROM 112.47.122.*
C++已经变得越来越陌生了
如果他们愿意把Python的语法直接拿过来，加上强制类型，做成一个高性能的编译型Python，我觉得更有用
【 在 libgcc 的大作中提到: 】
:
https://b23.tv/4Q8yqo--
FROM 123.114.39.*
我正在思考这个方向，但没那么简单啊。
Python 通过反射和 metaclass 这些技巧，让编程变得简单。
而 C++，不管你用什么语法，为了运行效率考虑，都需要类似于宏或者模板。不然搞定不了 list<int> 这种数据类型。
【 在 likely (thinker) 的大作中提到: 】
: C++已经变得越来越陌生了
: 如果他们愿意把Python的语法直接拿过来，加上强制类型，做成一个高性能的编译型Python，我觉得更有用
--
FROM 59.60.56.*
现在的复杂度？
SFINAE和type_traits恐怕都有二十年历史了
【 在 allegro 的大作中提到: 】
:
: C++现在的复杂度不能忍了.正确的抽象会让语言规则变得简单.
: 现在的SFINAE啊type_traits啊真的是正确的抽象吗?
:
: C++要么新出来个大佬简化挽救这一切.
--
FROM 120.21.13.*
刚刚被这个坑了，boost新出的json，默认支持所有标准和类似标准类型的无限嵌套，很好。对用户类型的支持是通过ADL查找的，然后QString由于没有namespace特化函数只能放在全局空间，有时候能正确转成json的string，但有时候被转成json array。现在还是没想到不改库文件的解决方案。
【 在 lambdai 的大作中提到: 】
: SFINAE和type_traits更多地时候是让库更不容易误用，接近白名单的做法。感觉不是为了提供更好的抽象...
:
: 你的类想和iterator兼容，ok，请自己举手，定义这些个member type
: ....................
--
FROM 118.235.8.*
SFINAE倒是很自然
int f(int);
float f(float);
template<typename T> typename T::result_type f(T);
short n = (short)f((short)0);
没有SFINAE的话，最后一行就出错了。你对某些T加一个重载，结果重载对其它类型都不可用了。这不能接受。
除非你强制使用concept，把模板从编译时的无类型（“动态类型”）语言改成有类型（“静态类型”）语言。或者把重载改成不在编译时解决。
不然，“无类型元语言+编译时重载”这个组合就需要类似SFINAE的东西。
正如语言既有无类型也有有类型一样，元语言选择无类型也不见得错吧。
【 在 allegro 的大作中提到: 】
: C++现在的复杂度不能忍了.正确的抽象会让语言规则变得简单.
: 现在的SFINAE啊type_traits啊真的是正确的抽象吗?
: C++要么新出来个大佬简化挽救这一切.
: ...................
--
FROM 58.37.61.*