为什么使用 boost::ice_or 而不是 ||和 boost::ice_and 而不是 &&在启用_如果?

发布于 2024-10-25 03:21:57 字数 35 浏览 1 评论 0原文

正如问题所述,人们使用结构版本而不是正常条件是否有原因?

As question states, is there a reason why people use the struct version over the normal conditionals?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

方觉久 2024-11-01 03:21:57

摘自整数常量表达式的 Boost 编码指南

不要在整型常量表达式中使用逻辑运算符;请改用模板元编程。

标头包含许多解决方法模板,它们履行逻辑运算符的角色,例如代替:

<块引用>

INTEGRAL_CONSTANT1 || INTEGRAL_CONSTANT2

用途:

<块引用>

::boost::type_traits::ice_or::value

基本原理:许多编译器(特别是 Borland 和 Microsoft 编译器)往往不将涉及逻辑运算符的整型常量表达式识别为真正的整型常量表达式。该问题通常仅在整型常量表达式嵌套在模板代码深处时才会出现,并且很难重现和诊断。

所以我想说永远不要在兼容的编译器上。 (但如果您需要支持不兼容的编译器,请使用它。)

An excerpt from the Boost Coding Guidelines for Integral Constant Expressions:

Don't use logical operators in integral constant expressions; use template meta-programming instead.

The header contains a number of workaround templates, that fulfil the role of logical operators, for example instead of:

INTEGRAL_CONSTANT1 || INTEGRAL_CONSTANT2

Use:

::boost::type_traits::ice_or<INTEGRAL_CONSTANT1,INTEGRAL_CONSTANT2>::value

Rationale: A number of compilers (particularly the Borland and Microsoft compilers), tend to not to recognise integral constant expressions involving logical operators as genuine integral constant expressions. The problem generally only shows up when the integral constant expression is nested deep inside template code, and is hard to reproduce and diagnose.

So I'd say never on a compliant compiler. (But if you need to support non-compliant compilers, use it.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文