问题标签 [boost-units]

今天我boost-units第一次使用，我对结果非常满意。

不幸的是，我对operator<<给定单位的显示并不完全满意。

以下代码打印m s^-2在控制台上：

我想知道是否有一种简单的方法可以将输出更改为类似m/(s^2)或什至m/s^2. 我认为，这种表示形式可能更容易阅读。

我正在尝试boost-unit用于我的一个项目。在这个项目中，速度、加速度、角速度等几个量用 SI-System 基本单位表示。(m/s, m​​/s^2, 弧度/s^2)

用户使用 GUI 界面来绘制这些数量。比方说角速度。GUI 应允许用户动态更改基本单位，他有以下选项：

长度：米，厘米，毫米

时间：s、ms、min、h

角度：弧度、度

为了boost-unit用于我的项目，我需要一个通用函数将数量转换5*m*s^-2*rad为5*1000/M_PI*180*mm*s^2*deg.

但是我完全失去了编写这个函数的最佳方法。

我认为它必须是这样的：

whereH1和H2are 的类型homogeneous_system，可以由make_system.

我试图弄清楚是否boost-unit可以在我的一个项目中使用。大部分功能我都很满意。但是我真的无法自己制作一个功能。

特别是，我正在寻找一个易于使用的功能，它可以让我拥有给定数量的某个基本单位的力量。它在某种程度上与 pow 函数相反。实际上，io.hpp实现了类似的东西，但我既不想在那里复制和粘贴所有东西，也不想深入研究这个模板代码。

getPow下面描述的功能是否有简单的解决方法？

在我的程序中，我想利用 boost::units 进行类型安全计算和自动转换。作为该库的新手用户，我对它的工作原理以及为什么禁止隐式类型转换有一个基本的了解。

现在我可以写这样的代码

其中my_mass将以千克和my_force牛顿表示。但是为了方便与仅接受的其他库进行交互double，我更喜欢以千牛顿为单位的力（同样，以兆帕斯卡为单位的压力）。所以我这样做：

哪个有效，但会强制进行显式转换。正确地，以下代码无法编译：

因为它代表一种隐式转换。那么我的问题是：有没有办法配置库，以便以选择的比例单位表示数量？

毕竟，“公斤”就是这种情况，所以我研究了scaled units，但我似乎找不到让它起作用的方法。这个想法本来是定义一个自定义系统，但由于质量、力和压力是相互关联的，所以这是不可能的，正如这里解释的那样。

我正在尝试将 Boost.Units 与 Eigen 3.3.1 一起使用，但是在按照此处的说明以及在周围找到的一些信息之后，我仍然无法弄清楚如何使 norm() 工作。

这是我到目前为止所拥有的（对于长代码块感到抱歉）：

但这无法编译（gcc 5.4.0），并出现类似错误

无法转换“boost::units::sqrt...（一些无法解读的模板错误）”

和

无法转换“Eigen::internal::abs2_impl ...（一些晦涩的模板错误）”

在我的一个项目中，我需要确定相当复杂单位的转换因子。我能够使用出色的 boost 库编写静态转换函数，以防静态定义的单位Boost.Units。

在我的情况下，用户在运行时输入转换的类型，所以我需要一个动态转换函数。一个好的解决方案应该使用Boost.Units. 这可能吗？

我自己的最终解决方案

经过一番思考，我能够为我的问题得出以下部分解决方案，这足以满足我的需求。我依靠boost-spirit解析单位字符串，使这项任务确实非常容易。很棒的图书馆！

解析单元字符串可能是其他人可能感兴趣的常见任务。因此，我在此处发布我的最终解决方案，包括一些用于说明的测试。最重要的功能是convertUnit计算从一个单位到另一个单位的转换因子，如果这种转换是可能的。

单元解析器.cpp

单元解析器.h

UnitParserCatch.cpp

我正在尝试为系统创建derived_dimension质量boost::units流量si。我找不到任何有关如何执行此简单任务的文档。这是我到目前为止所拥有的，但我在编译过程中遇到了错误。

这就是我得到错误的方式：

错误：C2338（is_simply_convertible::value == true）

我有一个使用 Boost.Unit 的非常简单的用例，但不确定是否有更好/更简单的方法来完成同样的工作。

我想在相同的单位之间进行转换，但比例不同。例如，赫兹到千赫到兆赫。

根据我的理解，我首先必须用我的特定比率定义单位：

然后创建代表单位的数量：

最后是一些常量和文字：

现在我可以使用数量：

这是应该如何使用 Boost.Unit 还是我错过了一些可能使它更容易使用的东西？

是否没有已经定义的单位/数量可以在隐藏在标题中的某个地方使用？还是应该对我使用的所有单位都这样做？

我是否需要知道/记住 Kilo 是否scale<10, static_rational<3>已经定义和可用？

我刚开始使用 boost-units，我试图了解我应该编写什么代码来获得单位之间的转换因子。按照运行时单元示例，我设法获得了 base_units 所需的内容。

例如，对于长度，我可以轻松地获得从英寸到米的转换因子，如下所示：

这最终允许我定义任意数量的缩放单位，并获得所有需要的转换因子。

例如，在速度的情况下，在相关标题中声明为“meter_per_second”单位，我无法弄清楚如何检索转换因子以将其转换为 kmh 或 mph。我想我需要定义自己的英里/小时单位，这导致需要定义（或检索）英里和小时的定义，并将它们放在一起。

我应该如何达到预期的结果？

当使用具有使用 clang 和级别优化的值类型的constexpr增强 boost.units的克隆时，我看到大约 10% 的运行时开销。这与我一直在研究的库的一些更复杂的应用程序一起出现。鉴于这种情况，我有两个问题我真的很想解决并希望得到帮助：float-O3

1. Boost 单元应该是一个零开销的库，那么为什么我会看到开销呢？
2. 更重要的是，除了不使用 boost.units 之外，我怎样才能让开销消失？

细节...

我一直在研究用 C++14 编写的交互式物理引擎。由于它使用了许多不同的物理量和单位，我喜欢使用 boost.units 提供的编译时强制单位和量。不幸的是，启用升压单元似乎伴随着这种运行时成本。该引擎附带一个基准应用程序，该应用程序使用谷歌的基准库来提供这种洞察力，并且需要一些更复杂的模拟才能看到开销。

目前，由于开销的原因，引擎默认构建时不使用升压单元。通过定义正确的预处理器宏名称，可以使用增强单元构建引擎。我使用如下代码实现了这种切换：

我对UNIT宏所做的事情让我觉得有点怀疑，因为它采用了增强单元类型并将其转化为值。然而，这使得在使用或不使用 boost 单元之间切换更容易，因为无论哪种方式的表达式都可以在3.0f * Second没有警告的情况下编译。检查 clang 和 gcc 对这些表达式的作用似乎证实它们足够聪明，可以避免运行时乘法3.0f * 1.0f，并且只是将表达式识别为3.0f. 无论如何，我想知道这是否是开销的原因，或者是否是我所做的其他事情。

我还想知道问题是否源于constexpr我正在使用的增强代码，或者该代码的作者是否对这种开销有任何想法。在互联网上搜索时，我发现提到了普通升压单元库的开销，因此似乎可以安全地假设增强单元没有故障。我的询问中提出的一个建议（感谢 GitHub 用户 muggenhor）如下：

我预计这可能是由编译器完成的内联量引起的。由于操作符的包装函数，这至少添加了一个函数调用，每个操作需要内联。对于取决于子表达式结果的表达式，这需要首先内联子表达式。因此，我希望内联传递的最小数量能够正确优化您的代码，使其等于生成的表达式树的深度......

对我来说，这听起来像是一个非常可行的理论。不幸的是，我不知道如何测试它，而且我承认我现在更喜欢挖掘自己的代码而不是 clang/LLVM 代码。我试过使用-inline-threshold=10000，但这似乎并没有让开销消失。至少就我对 clang 的理解而言，我不认为这会特别增加内联传递的数量。还有另一个命令行参数吗？或者在clang的源代码中是否有参数可以让我将其作为重新编译clang并尝试修改后的编译器的起点？

我的另一个理论是使用是否float是问题所在。我可以重建我的物理引擎来double代替使用，并比较启用和不启用增强单元支持的构建之间的基准测试结果。我在使用时发现double开销至少似乎减少了。我想知道double即使我float在它的quantity模板中使用提升单元是否也在使用，这可能会导致开销。

最后，我performance使用增强功能构建了 boost 单元的示例，并使用和constexpr运行它。没有任何开销的可靠迹象，这似乎消除了我的问题理论。doublefloatfloat

更新数据和代码

在这方面得到了一些更孤立的数据和代码，我似乎看到了超过 10% 的开销......

一些基准数据Length基本上是boost::units::si::length：

相关代码的样子：

以此作为对我的提示，我使用以下代码检查了Godbolt，以查看 clang 5.0.0 和 gcc 7.2 会生成什么：

我看到生成的程序集在这两个函数之间以及在 clang 和 gcc 之间看起来完全不同。这是来自 clang 的相关程序集的要点（这里的 boost 内容简单地显示为length）：

这两个使用-O3优化的编译器不应该为length版本返回相同的程序集float吗？问题是他们没有完全优化到与 for 相同的代码float吗？似乎这就是问题所在，如果是这样的话，那就是进步，但我仍然想弄清楚可以做些什么来真正实现零开销。