向Boost-1.65.1的过渡和出现的错误

去年(已经过去了整整一年),我们还是切换到了新版本的Boost-1.65.1,在引擎盖下,您会发现我们遇到的三个Boost Bug。 还必须提及的是,在此之前,我们的软件中使用了boost -1.62.1,因为boost版本1.65.1之前出现了一些错误。

我们的项目有一个特殊的集成团队,其主要任务是将所有软件迁移到新版本的库,Visual Studio,低级组件的新版本(基本,大多数其他组件都依赖于此)等。 集成团队还负责消除所有出现的问题,必要时自然在组件维护者的帮助下。 因此,我特别记得的错误。

Boost ::文件系统中的错误


此错误足够快地浮出水面。 搜索给定文件名的完整路径时,测试开始崩溃并显示“访问冲突”。 该函数调用boost ::文件系统::存在,程序崩溃。 运行更多测试,发现更多类似情况,并且在所有情况下,都对全局变量进行了boost :: filesystem :: existed调用。 显然,boost变量的生命周期发生了一些变化。 检出错误的票证很容易在boost :: filesystem ::存在的 Google中找到错误票证

事实证明,此错误从1.64版本开始得到了增强。 实际上,问题出在make_permissions调用中(用于文件系统::存在)。 在1.64中,make_permissions的实现已更改,现在使用全局变量,这意味着在初始化全局变量或对象时尝试调用filesystem ::存在时,make_permissions中使用的全局变量可能尚未初始化。 因此,尝试访问未定义的变量将引发异常。

解决方法
对于仅使用全局变量一次的测试,它们将被转移到相应的测试中并成为局部变量。 甚至不用问为什么以前没有这样做,我不是这段代码的维护者。

在其他情况下,使用单调

Boost :: Python中的错误


在使用boost :: python的测试中,发现了一个奇怪的东西。 当您对文字(例如,“ 40 + 2”)对eval()进行平凡的调用时,所有规则。 并且,如果您定义变量,然后在表达式中使用它们,则会收到一条消息,提示计算使用未定义的变量(错误:[名称]未定义)。 为了解决这个问题,我花了更多时间。 我在加速跟踪器中找不到解决此问题的票证,因此我不得不寻求该组件团队的帮助。 有关该错误的信息很快在github上找到。

碰巧在评估的实现中,没有使用全局和局部对象。 希望在不重新编译源代码的情况下找到修复的方法, 团队工作顺利,团队休假了:)

解决方法
但是后来我想起了boost-1.65.1的发行说明,并且肯定存在boost :: python的东西。

万岁,有办法! 在添加支持char const *参数的eval的新实现时允许该错误,该错误现在在具有字符串参数的eval的旧实现中被调用(特别小心的人可能会注意到通过github链接在代码中对该函数的调用)。 并且新功能有望正常工作。

提升:: numpy


这是我最不喜欢的部分。 boost :: python ::数字已被删除,现在boost :: python :: numpy出现了。 但是使用数字的代码必须进行大量重新设计,因为重点不仅在于重命名名称空间,还在于实现对象。

另外,助推器的标题中存在误导信息,误导了我。
根据源代码中的注释,已经在numpy :: initialize()中进行了import_array()调用:

namespace boost { namespace python { namespace numpy { /** * @brief Initialize the Numpy C-API * * This must be called before using anything in boost.numpy; * It should probably be the first line inside BOOST_PYTHON_MODULE. * * @internal This just calls the Numpy C-API functions "import_array()" * and "import_ufunc()", and then calls * dtype::register_scalar_converters(). */ BOOST_NUMPY_DECL void initialize(bool register_scalar_converters=true); }}} // namespace boost::python::numpy 

但实际上,事实证明,需要import_array()。

此外,测试更改存在问题,因为测试根本没有覆盖numpy的代码段(以前使用boost :: python :: numeric),并且代码本身也用于其他组件。 因此,仅在测试相应组件时才发现问题。 集成团队不需要编写组件测试,这种情况是团队本身的遗漏。 哇,我从他们那里听说我破解了他们的代码。 但是在团队抱怨之后,他们终于用测试覆盖了他们的代码。 但是,怨恨依然存在(在下一次迁移中,团队不想让我的同事使用他们的组件,因为他们提到上次我们为他们破坏了代码。Sasha,soryan!但是经过三天的谈判,他们放弃了)。

结论


完成工作后,我可以为自己记下一些好处,因为boost以前很少使用(主要是std),所以迁移中可以强调很多。 这很有趣,但是事实是,出于这样的原因,出于某种原因,您默认会成为许多同事的“助推专家”,并且调和后,还会再询问您有关此问题的时间。

顺便说一下,近年来,许多公司开始积极地放弃boost并在可能的情况下替换std库,或者在标准库中没有任何功能的情况下替换其他内容。 而且我们也没有站在一边。 该过程已开始,但尚未完成,仍然有很多工作要做。

Source: https://habr.com/ru/post/zh-CN436828/


All Articles