STL的缺陷[关闭]答案

【问题标题】：Defects of the STL [closed]STL的缺陷[关闭]
【发布时间】：2011-05-06 03:21:41
【问题描述】：

虽然 C++ 标准库是非常通用且高效的库，但其接口的一些小细节似乎令人失望。

算法不能直接使用容器。 std::sort(myvec.begin(), myvec.end()); 而不是 std::sort(myvec);（我真的不明白为什么没有从一开始就提供第二种形式）
大多数接受字符串的函数成员需要const char * 而不是const std::string&。（C++字符串是std::string，至少应该有重载）

据我所知，这两个小缺陷应该在c++0x 标准中得到纠正。

您还能看到其他这些小缺陷吗？
为什么你认为这是一个缺陷？
有一天会改正吗？

（当然这里的争论不是支持或反对泛型编程，实际上也不是关于一般设计问题。只是缺少重载，缺少算法版本，不方便的接口......）

【问题讨论】：

应该是CW，或者关闭。
@sbi: 是this is what you're looking for吗？
copy_if 和 iota 丢失。如果这个问题是一个有用的资源，也许它应该开始列出对 C++0x 中的标准容器和算法所做的更改，而不是邀请数十或数百个答案列出每个一。
@Alf：这是对 CW 机制的最新更改，AFAIK 仅通过对元数据问题的编辑“宣布”，大多数人根本不会阅读，更不用说那个确切的问题。我不确定用户阅读整个元数据的频率是多少，以确保他们最喜欢的功能没有消失，但人们了解此类功能更改的方式不可避免地是尝试使用它们，或谈论他们，并被一个碰巧知道的人告诉他们已经走了:-)
@Alf：我认为 SO 更倾向于实用性。我不认为我同意这种趋势，但在我看来，如果 Ugo 真的在设计一种语言，那么他可以提出有关语言设计的问题。所以有一定的推理空间。然而，关于 C++（或任何其他现有系统）可以/应该如何改进（对于“改进”的价值）的推测性讨论是不受欢迎的。而且我不认为这种变化仅仅是因为 C++0x 已经击中 FCD ;-) 而且我不太喜欢 meta 的工作方式，但它比 SO 使用 uservoice 时要好。

标签： c++ stl c++11 defects

【解决方案1】：

算法不能直接使用容器。 std::sort(myvec.begin(), myvec.end());而不是 std::sort(myvec);

这实际上是一个特性（它允许循环遍历 C 数组），尽管正如 GMan 在评论中所说，它可以改进。

大多数采用字符串的函数成员需要 const char * 而不是 const std::string&

这是完全错误的，因为大多数 STL 函数不是成员，它们中的大多数不是函数，而是函数模板，而且（几乎？）它们都不处理字符串独家。
（您可能在谈论文件流，它是 标准库 的一部分，但不是源自 STL 的标准库的那部分。当然，有原因他们被制作成使用const char*，尽管这也可以改进。）

看来，正如许多批评 STL 的人一样，您对它的了解还不够，无法做到这一点。这并不意味着没有什么可批评的。但是，就像在其他领域一样，在你去做这件事之前，你至少应该知道事情为什么会这样。

【讨论】：

@sbi：你错过了重点。这不是关于为什么应该有 std::sort(container.begin(), container.end())，而是为什么也不应该有 std::sort(container)。我没有真正看到这个问题，因为添加自己的问题很容易。
@DeadMG：即使不是大多数，STL 的许多算法都很容易编写。然而它们在标准库中。所以这不是一个有效的论点。
@sbi 不要这样想。我已经使用标准库很长时间了，我不批评它。你是对的，第二点是指 IOstream 库。
@sbi：我不同意。我在 SO 上看到很多帖子询问如何编写链接列表，我开始认为它提供了一些好的基础知识是一件好事。此外，std::sort(container) 重载特别易于编写，因为您可以将其委托给现有的 std::sort，而如果您必须实现原始的，您会必须写一个实际的排序。
OP 应该需要像Boost.Range 这样的接口。

【解决方案2】：

关于sort等算法，只要定义你喜欢的包装器就行了。

如果你不喜欢定义单独的包装器，那么定义一个宏

#define ALL_OF( container ) startOf( container ), endOf( container )

使用合适的 startOf 和 endOf 函数模板，这对原始数组和标准库容器都适用。

即你的第一个问题不是问题。

关于const char* 参数，它们不是string const& 通常不是问题。但是，如果标准库有一个标准的低开销字符串载体并被使用，那就太好了。这是一个真正的问题，例如不支持宽字符串。文件流构造器（Windows 代码必须使用非标准扩展）：这种情况下，对于执行环境，正确的程序不能仅使用标准库在标准 C++ 中表达。

当然，main 也是如此，这是一个跨越核心语言和库的问题。

【讨论】：

同意第一个问题不是问题，但不鼓励宏观“解决方案”...
@Oli：你愿意解释一下你为什么这么认为吗？
@Alf P. Steinbach：首先，您不能将宏放在命名空间中，并且在您的宏中，任何替换为container 的内容都将被评估两次。（顺便说一句，我没有对帖子投反对票。）
@Alf：嗯，在 C++ 上下文中反对宏的常见论点。对于初学者来说，它不是类型安全的，并且可能导致难以调试的编译器错误（尽管我承认无论如何您都可以通过模板获得这些...）。顺便说一句，投反对票的不是我。
@Alf：如果函数f 返回vector&，那么sort(ALL_OF(f(blah))) 执行该函数两次是宏方法的弱点。不是一个无法解决的问题，当然，用户总是可以给从函数返回的名称。一个体面的范围抽象会更好，尽管要实现数百或数千倍的工作。如果“没有人知道它做了什么”，那只是宏文档的一个弱点；-p