【问题标题】:STL Extension/Modification Best PracticeSTL 扩展/修改最佳实践
【发布时间】:2016-04-23 16:57:47
【问题描述】:

我已经用 C++ 编写了几个月了,现在我已经足够适应它了,可以开始实现我自己的库,其中包含我发现自己一次又一次重用的东西。困扰我的一件事是,您总是必须为 std::accumulatestd::fill 等函数提供开始和结束迭代器......

完全没有提供合格容器的选项,一遍又一遍地编写开始和结束只是一种烦恼。所以,我决定将此功能添加到我的库中,但我遇到了问题,我想不出这样做的最佳方法。以下是我的一般解决方案:

1.宏

- 封装整个函数调用的宏
前任。 QUICK_STL(FCall)

- 一个接受容器、函数名和可选参数的宏
前任。 QUICK_STL(C,F,Args...)

2。包装函数/函子

- 一个接受容器、函数名和可选参数的类
前任。 quick_stl(F, C, Args...)

3.重载函数

- 重载命名空间 std 或我的库命名空间中的每个函数

namespace std { // or my library root namespace 'cherry' 
    template <typename C, typename T>
    decltype(auto) count(const C& container, const T& value);
}



我通常会避开宏,但在这种情况下,它肯定可以节省 很多 被编写的代码行数。关于函数重载,我想使用的每个函数都必须重载,这不会真正扩展。不过,这种方法的好处是您保留了函数的名称。有了完美的转发和decltype(auto),重载变得容易了很多,但仍然需要时间来实现,如果添加了另一个函数,就必须修改。至于我是否应该重载std 命名空间,我对在这种情况下是否合适持怀疑态度。

在 STD 命名空间中重载函数最合适的方法是什么(注意这些函数只会作为原始函数的代理)?

【问题讨论】:

  • 我通常会避开宏 啊,很好...... 但在这种情况下,它肯定可以节省很多代码行从被写出来。 Nooooo!!!这是个陷阱!!!

标签: c++ visual-c++ c++14


【解决方案1】:

你需要阅读这个:Why do all functions take only ranges, not containers?

还有这个:STL algorithms: Why no additional interface for containers (additional to iterator pairs)?

我已经用 C++ 编写了 几个月,我感觉很舒服 现在已经足够了,可以开始实现我自己的库了...

让我看看光明的一面,然后说......我们中的一些人以前去过那里...... :-)

困扰我的一件事是,您总是必须提供一个 函数的开始和结束迭代器,如 std::accumulate,std::fill 等...

这就是为什么你有 Boost.Ranges 和 Eric 提议的 ranges 似乎无法进入 C++17 的原因。

Macros

  1. 包装函数/函子

还不错...只要您做得正确,您就可以做到,这就是 Ranges 对容器的作用...参见上述实现

  1. 重载函数

    • 重载命名空间std中的每个函数...

不要那样做...... C++ 标准不喜欢它。

看看标准怎么说

$17.6.4.2.1 如果 C++ 程序将声明或定义添加到命名空间 std 或其中的命名空间,则其行为未定义 命名空间 std 除非另有说明。程序可以添加模板 将任何标准库模板特化为仅命名空间 std 如果声明依赖于用户定义的类型并且 专业化符合标准库的要求 原始模板,未明确禁止。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-10-29
    • 2011-11-05
    • 1970-01-01
    • 2011-04-08
    • 1970-01-01
    • 2016-11-18
    • 1970-01-01
    相关资源
    最近更新 更多