为啥“transform(s.begin(),s.end(),s.begin(),tolower)”编译不成功？

Posted 2023-02-23

【中文标题】为啥“transform(s.begin(),s.end(),s.begin(),tolower)”编译不成功？

【英文标题】：Why can't "transform(s.begin(),s.end(),s.begin(),tolower)" be complied successfully?为什么“transform(s.begin(),s.end(),s.begin(),tolower)”编译不成功？

【发布时间】：2011-07-29 04:42:58

【问题描述】：

给定代码：

#include <iostream>
#include <cctype>
#include <string>
#include <algorithm>
using namespace std;

int main()

     string s("ABCDEFGHIJKL");
     transform(s.begin(),s.end(),s.begin(),tolower);
     cout<<s<<endl;

我得到错误：

没有匹配函数调用transform(__gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, <unresolved overloaded function type>)

“未解析的重载函数类型”是什么意思？

如果我用我写的函数替换tolower，它就不再出错了。

【问题讨论】：

main 的返回类型是int，C++ 中的返回类型必须是显式的。一些编译器允许发布的代码，但它是非标准的，它可能会与新的编译器版本或其他编译器中断。

@DavidRodríguez-dribeas C 或 C++ 不需要从 main 返回，它隐式返回 0。请参阅此答案的 cmets：***.com/a/33442842/2642059

【参考方案1】：

尝试使用::tolower。这解决了我的问题。

【讨论】：

@liu：就像@David 写的那样——“::”从全局命名空间中选择tolower

这个答案没有回答这个问题——为什么它不起作用？

取决于您的编译器。 MSVC 19 似乎没有问题。如果您检查cppreference's note，它会显示如何正确使用带有std::tolower 的transform 的具体示例。 话虽如此 cppreference 似乎说函数签名是相同的（cctype，ctype），所以我实际上不确定为什么它不会编译，例如 clang。

好的，所以。做了一些挖掘。在 std 中有一个版本的 tolower 接受const locale&，因此 transform 无法推断要使用两个重载中的哪一个。由于 tolower 的全局命名空间版本没有重载，所以它工作得很好。话虽如此，msvc 似乎没有这个问题 - 除非你包括 .

【参考方案2】：

让我们看一个选项列表，从最差的开始到最好的。我们将在此处列出它们并在下面讨论它们：

transform(cbegin(s), cend(s), begin(s), ::tolower) transform(cbegin(s), cend(s), begin(s), static_cast<int(*)(int)>(tolower)) transform(cbegin(s), cend(s), begin(s), [](const unsigned char i) return tolower(i); )

---

您问题中的代码transform(s.begin(), s.end(), s.begin(), tolower) 将产生如下错误：

没有匹配函数调用transform(std::basic_string<char>::iterator, std::basic_string<char>::iterator, std::basic_string<char>::iterator, <unresolved overloaded function type>)

您得到“未解析的重载函数类型”的原因是 std 命名空间中有 2 个 tolowers：

locale 库定义了template <typename T> T tolower(T, const locale&) cctype 库定义了int tolower(int)

1 是solution offered by davka。它利用locale 的tolower 未在全局命名空间中定义这一事实来解决您的错误。

根据您的情况locale 的tolower 可能值得考虑。你可以在这里找到tolowers 的比较：Which tolower in C++?

---

不幸的是，1 依赖于在全局命名空间中定义的cctype 的tolower。让我们看看为什么不是这样：

你使用#include <cctype> 是正确的，因为#include <ctype.h> 在C++ 中已被弃用：http://en.cppreference.com/w/cpp/header

但 C++ 标准在 D.3[depr.c.headers]2 中声明了标头中的声明：

未指定这些名称是否首先在命名空间std 的命名空间范围 (3.3.6) 内声明或定义，然后通过显式使用声明 (7.3.3) 注入全局命名空间范围

因此，我们可以保证我们的代码独立于实现的唯一方法是使用来自namespace std 的tolower。 2 是solution offered by David Rodríguez - dribeas。它利用了static_cast 可以：

用于通过将函数到指针转换为特定类型来消除函数重载的歧义

在我们继续之前，让我评论一下，如果您发现 int (*)(int) 有点令人困惑，您可以阅读更多关于函数指针语法 here 的内容。

---

遗憾的是，one other issue 带有 tolower 的输入参数，如果是：

不能表示为 unsigned char 且不等于 EOF，行为未定义

您正在使用string，它使用以下类型的元素：char。 char 的标准状态具体为 7.1.6.2[dcl.type.simple]3：

char 类型的对象是否表示为有符号或无符号数量是实现定义的。 signed 说明符强制对 char 对象进行签名

因此，如果实现将char 定义为signed char，则1 和2 都会导致所有与负数对应的字符出现未定义行为。 （如果使用 ASCII 字符编码，则负数对应的字符为Extended ASCII。）

在将输入传递给tolower 之前，可以通过将输入转换为unsigned char 来避免未定义行为。 3 使用通过值接受 unsigned char 的 lambda 实现这一点，然后将其传递给 tolower 隐式转换为 int。

为了保证所有兼容实现的定义行为，独立于字符编码，您需要使用transform(cbegin(s), cend(s), begin(s), [](const unsigned char i) return tolower(i); ) 或类似的东西。

【讨论】：

我也想知道。

@exilit 我相信这是最好的答案。我花时间为一个问题添加了一个答案，即使它永远不会被接受，因为我觉得所有其他答案都以一种或另一种方式不足。有一个人只是开车投票是……可悲的。无论如何感谢您的确认。很高兴知道有人关心我为提高答案质量所做的努力。

@TonvandenHeuvel 谢谢，我也认为它是最完整的。但我认为我们不会看到它被接受，因为 the OP 自 2014 年以来就没有出现过。

【参考方案3】：

问题很可能与tolower 的多个重载有关，编译器无法为您选择一个。您可以尝试对其进行限定以选择它的特定版本，或者您可能需要提供一个函数指针强制转换来消除歧义。 tolower 函数可以出现在<locale> 标头以及<cctype> 中（多个不同的重载）。

试试：

int (*tl)(int) = tolower; // Select that particular overload
transform(s.begin(),s.end(),s.begin(),tl );

这可以通过强制转换在一行中完成，但可能更难阅读：

transform(s.begin(),s.end(),s.begin(),(int (*)(int))tolower );

【讨论】：

但是不要忘记，如果任何 char 值为负数（它们可以在大多数现代系统上，例如，如果任何重音字符存在）。

@James Kanze：好点子，我决定通过阅读原始帖子（其中明确包含 cctype，而 locale 不包含）来实现超载。此外，语言环境中的函数需要多个参数，这意味着代码会增加不相关的复杂性，使用 bind 或 bind2nd 以提供默认的 locale...

@liu：请注意，使用::tolower 将在不同的编译器中工作，但这不是标准的。基本上大多数编译器，当你包含cctype时，编译器需要提供int std::tolower(int)，但不需要添加int ::tolower(int)，不同的编译器将提供具有相同实现的两个函数（一个其中一个将转发给另一个）但这不是必需的，并且可能会随着下一个编译器版本（或者如果您更改编译器）而改变

@liu 使用::tolower 并不能解决问题。使用 char 参数调用 ::tolower 是未定义的行为。您需要将其包装在一个函数对象中，该对象将char 转换为unsigned char。或者接受 David Rodríguez 关于<locale> 中的版本所提到的所有复杂性。

@davka 该标准明确规定，对于任何tolower 参数：“不能表示为无符号字符且不等于EOF，行为未定义”因此将扩展ASCII 传递给tolower 是潜在的未定义行为：***.com/a/37438120/2642059

【参考方案4】：

David 已经确定了问题，即：

<cctype>'s int tolower(int c) <locale>'s template <typename charT> charT tolower(charT c, locale const& loc)

使用第一个要容易得多，但是当您处理带符号字符中的低 ascii (0-127) 以外的任何其他内容时，就会出现未定义的行为（不幸的是）。 顺便说一句，我建议将char 定义为无符号。

模板版本会很好，但是你必须使用bind来提供第二个参数，而且它一定很丑......

那么，我可以介绍一下Boost String Algorithm 库吗？

更重要的是：boost::to_lower :)

boost::to_lower(s);

表现力是可取的。

【讨论】：

1) 你能解释一下I do recommend defining char as unsigned 是什么意思吗？ 2) boost::to_lower 是否假设某些字符集，例如latin-1?

@davka: 1) C++ 标准没有准确说明char 是有符号还是无符号。如果你想确定，你可以限定它。但是，如果使用否定的char 调用，许多函数（如int tolower(int)）具有未定义的行为......在你的编译器上查找它，可能有一个开关或一个健全的默认值。 2) boost::to_lower 基于 C++ tolower 函数，因此依赖于 std::locale 和 ctype 方面。请注意，这些方面无论如何都无法处理多字符编码...

谢谢，我仍然没有得到第一名。我知道char 依赖于实现。你是在建议typedef unsigned char char吗？合法吗？

@davka：不，这是不合法的。编译器通常有开关让你决定，例如gcc 有-fsigned-char 和-funsigned-char。

@davka：正确。并且你需要提防 3rd 方库：为了 3rd 方库之间能够顺利交互，以及你的程序，都应该赋予char 相同的含义。您需要查看他们的文档以了解他们是否明确说明或检查代码以了解他们是否做出假设：while((c = getchar()) == EOF) 是带有-funsigned-char 的无限循环，因为getchar() 返回int，而不是char（而EOF 是-1）

【参考方案5】：

从 gcc 4.2.1 浏览我的 <ctype> 标头，我看到了：

// -*- C++ -*- forwarding header.

// Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
// Free Software Foundation, Inc.

...

#ifndef _GLIBCXX_CCTYPE
#define _GLIBCXX_CCTYPE 1

#pragma GCC system_header

#include <bits/c++config.h>
#include <ctype.h>

// Get rid of those macros defined in <ctype.h> in lieu of real functions.
#undef isalnum
#undef isalpha

...

#undef tolower
#undef toupper

_GLIBCXX_BEGIN_NAMESPACE(std)

  using ::isalnum;
  using ::isalpha;

...

  using ::tolower;
  using ::toupper;

_GLIBCXX_END_NAMESPACE

#endif

所以看起来tolower 存在于std（来自<cctype>）和根（来自<ctype.h>）命名空间中。我不确定#pragma 的作用。

【讨论】：

编译指示向 gcc 发出该文件是系统头文件的信号。这通常会影响诊断，因为编译器对捆绑的头文件发出警告被认为是不好的风格，不应更改。