不认同你的说法，C++ 只有一个绝对值，那就是std::abs
缺陷报告(defect report)的解决方案里说了，
既然cmath、cstdlib里abs不一致，
那就在它们两个里面都加上各自的重载函数声明。

至于你说的最佳实现，那是C的方式，那里还有一大堆abs等着你。

【 在 DoorWay (DoorWay) 的大作中提到: 】
: 谢谢花宝贵的时间来验证。
: 我在另一楼的结论：
: [b]我琢磨来琢磨去，我觉得 abs , std::abs留给整型， fabs()留给float/double最佳实践。
: ...................
--
修改:easior FROM 183.131.109.*
FROM 183.131.109.*

就个人理解，std:fabs、std::fabsl、std::fabsf 之类的存在，只为兼容 C 的古典语法。
既然 C++ 有重载机制，一个 std::abs 就足以干所有的活了，非常简明。
当然这一切取决于标准怎么说，不同的编译器有不同的扩展，
Apple Clang std::abs 行为特别奇怪（甚至不符合名空间规则）！

其实你的发言很矛盾，一会嘲笑 C++ 的abs很复杂，
一会有推崇多个 abs 函数。

当然，个人观点或编译器行为不代表标准C++。

【 在 DoorWay (DoorWay) 的大作中提到: 】
: 不懂你的意思啊。可能我
: “C++ 只有一个绝对值，那就是std::abs” -- 这是什么意思？std::fabs也是标准库提供的啊——你是有什么特殊的考虑吗？
: "缺陷报告(defect report)的解决方案..." -- 这个我理解是，定义不一致的问题，c++11已经修复了。但引入了新问题, 即fabs进int出double的问题。不知那个 Apply To是这样理解的不，我是强行阅读，理解有点费劲哈。
: ...................
--
修改:easior FROM 183.131.109.*
FROM 183.131.109.*

另外，Apple Clang，和 cpprefrence页面上的选项，Clang 5，是一回事吗？
还是类似 Chrominum 和 Chrome？
【 在 easior 的大作中提到: 】
: 就个人理解，std:fabs、std::fabsl、std::fabsf 之类的存在，只为兼容 C 的古典语法。
: 既然 C++ 有重载机制，一个 std::abs 就足以干所有的活了，非常简明。
: 当然这一切取决于标准怎么说，不同的编译器有不同的扩展，
: ...................
--
FROM 61.185.187.*

总结你我easior的观点，五个维度：

正确： 行为统一，比如不要double截成float函数行为不要出错，没有溢出等。
统一： 形式统一，都用 std::abs（或者哪一种)。通过重载提供。
清晰： 使用者与读者，清楚入参类型与返回类型。
方便： 标准库里提供。
简洁： 短的好。

结合下来，应该是标准库提供个模板函数， 进去T，出来T。并规定实现。
当来我不是数值计算专家，不知有没有进去T1，出来T2的个性需求。

---
类似的问题还有PI.  
我看reddit讨论17/20标准，都是std要不要包含vector3d matrix 类了。
正： 要包含。使用方便，不用每次着急忙慌的包含头文件、手撸一个struct{x,y z}
反： 不包含。你无法选择一个最佳实【现】。标准库提供一个“低”效的实现，会传染、拉低其它更优实现。

我认为这是个标准库标到哪里的问题，容易争议。
原因是标准库名字起的太大，标准。叫实用库，或者Util库，就没有这种思辨负担了。

我支持加。办法比如，扶正boost库的地位；再发展boost库的对等库，实用库1，实用库2，实用库3……

另外俩众所周知的因素：1 cpp要兼容旧代码的包袱 2 语言的零负担设计原则：zero-overhead principle: What you don't use, you don't pay for。
也是cpp发展到如今局面的因素。其实退一步看，语言的作用还是太有限了。还有硬件、操作系统啥的。

【 在 origin008 的大作中提到: 】
: 在自己的头文件上，加个abs模板函数处理各种特化情况是不是更好？
--
FROM 61.185.158.*