为什么以这种方式使用迭代器？
下面是一个最小的代码，用于重新创建让我怀疑的条件：
#include <map>
#include <string>
int main()
{
std::map<std::string, std::string> mm;
mm.emplace("Hi", "asd");
mm.emplace("Hey", "asd");
mm.emplace("Hello", "asd");
std::map<std::string, std::string>::const_iterator it = mm.find("Hey");
it->second.size();
// A
//it->second.replace(0,1,"h");
//B
auto u = it->second;
u.replace(0,1,"h");
}
为什么在大小写A中传递常量作为参数而在大小写B中工作会出错？
错误的详细信息：
错误：将“const std:：basic_string”作为“std:：basic_string”的“this”参数传递
共有1个答案
原因很简单：it是一个常量迭代器，所以it-
当您处理以下事项时：
auto u = it->second;
auto推导为std::字符串和u从it-初始化
-
问题内容： 我一直想知道React钩子的命名。例如useEffect，名称如何暗示类似于componentDidUpdate或componentDidMount的名称？而且，在加载组件之后我们执行的这些操作不是副作用，而是主应用程序流程的一部分，那么为什么将这些称为副作用？ 问题答案： 为什么以这种方式命名React钩子使用XXX？ 从挂钩文档中，使用自定义挂钩 我必须以“ use”开头命名自定义
-
问题内容： 我正在研究Java标准库（6）中compare（double，double）的实现。内容为： 此实现的优点是什么？ 编辑：“优点”是一个（非常）错误的单词选择。我想知道这是如何工作的。 问题答案： @Shoover的答案是正确的（阅读它！），但是它还不止于此。 由于javadoc中的规定： “此定义允许哈希表正常运行。” 假设Java设计者决定采用与包装实例相同的语义来实现。这意味着将
-
我听说过很多次递归由于函数调用而很慢，但在这段代码中，它似乎比迭代解快得多。充其量，我通常期望编译器将递归优化为迭代（从程序集的角度来看，这似乎确实发生了）。 在这里组装：https://gist.github.com/PatrickAupperle/2b56e16e9e5a6a9b251e 我很想知道这里发生了什么。我相信这是一个复杂的编译器优化，我可以惊讶地了解。 编辑：我刚刚意识到我忘了提到
-
问题内容： 我有两个例子： 范例1： 范例2： 在 第二个 例子不工作，我想它做的事。我的意思是文件内容不为空，但好像zip文件已损坏。 我想告诉我第一个例子为什么不起作用。 问题答案： 必须在流的末尾执行多项操作以完成zip文件，因此必须正确关闭它。（一般来讲，按照惯例，每个流几乎都 应该 正确关闭。）
-
对于一个特定的问题，我有两种实现，一种是递归的，另一种是迭代的，我想知道是什么导致迭代解决方案比递归解决方案慢约30%。 给定递归解决方案，我编写了一个迭代解决方案，使堆栈显式化。 显然，我只是模仿递归的作用，所以当然Python引擎可以更好地优化以处理簿记。但是我们可以编写具有类似性能的迭代方法吗？ 我的案例研究是Euler项目的问题#14。 找到起始值低于一百万的最长Collatz链。 下面是
-
我知道这个问题在这个论坛上已经被问过好几次了。但我仍在发帖，因为没有一个答案看起来是具体的。专家们，你们能帮我理解什么时候使用迭代器吗。当我们有一个非常大的数据集时，我们是理想地使用它，还是当我们有大量数据要返回时，将其用作方法的返回类型？