主页 / user-4437653

Sven Sandberg's questions

Martin Hope
Sven Sandberg
Asked: 2025-04-29 00:01:27 +0800 CST
  • 6

标准是否要求operator->()为非连续的末端迭代器定义？

背景：

  • operator*()无论迭代器属于哪种类别，当迭代器指向末尾之后的值时，都允许表现出未定义的行为。这一点在https://en.cppreference.com/w/cpp/iterator的“可解引用性和有效性”一节中明确指出：“对于迭代器 i ，如果表达式 *i 已定义，则该值被称为可解引用的。标准库从不假设末尾之后的值是可解引用的。”
  • 编辑：此点的结论是错误的：请参阅下面的答案。对于连续operator->()迭代器，我认为当迭代器指向末尾之后时，不允许出现未定义的行为。这可以从 cppreference 中的两个部分推断出来：(1) 在https://en.cppreference.com/w/cpp/iterator/contiguous_iterator上，“语义要求”部分定义了不可解引用的迭代器c，并说明了std::to_address(c)暗示std::to_address(c)不会出现未定义行为的要求。(2) 在https://en.cppreference.com/w/cpp/memory/to_address上，它提供了一个“可能的实现”，其中std::to_address依赖于operator->()。编辑：如果迭代器已定义，则“可能的实现”不使用；如果是这种情况，则似乎允许不为末尾迭代器定义 。operator->()pointer_traitsoperator->()

目前尚不清楚是否允许非连续operator->()迭代器实现，因此对于尾后迭代器，其行为是未定义的。以下是我找到的与此相关的各种“证据”/“提示”：

  • 非连续的 C++20 迭代器概念似乎根本不需要定义它。据我所知， https://en.cppreference.com/w/cpp/iterator/random_access_iteratoroperator->()中定义的所有要求，或者它们所依赖的要求，根本没有提到这一点。
  • 连续的 C++20 迭代器概念std::contiguous_iterator需要operator->()：如上所述，由于std::to_address必须定义 ，因此可以推断出 ，并且 的“可能实现”std::to_address使用operator->()。并且页面https://en.cppreference.com/w/cpp/memory/to_address明确提到std::contiguous_iterator。由于它没有提及其他迭代器类型，因此对于非连续迭代器 IIUC 来说，这并不意味着任何含义。
  • 旧式迭代器类别要求operator->()为 和 更强的 定义（参见https://en.cppreference.com/w/cpp/named_req/InputIteratorLegacyInputIterator上的表格），并且满足“前提条件：i 可解引用”的条件。换句话说，存在一个明确的例外，允许尾后迭代器表现出未定义的行为。我没有看到任何更强的旧式迭代器类别删除了这个前提条件（仅供参考，甚至https://en.cppreference.com/w/cpp/named_req/ContiguousIterator也没有，所以这看起来像是和之间的区别）。LegacyContiguousIteratorstd::contiguous_iterator
  • 另一方面，在https://en.cppreference.com/w/cpp/iterator的“可解引用性和有效性”部分中，它提到operator*()对于尾后迭代器不需要定义，但没有提到operator->()。因此，这可能表明允许对尾后迭代器进行某些操作未定义的例外不一定适用于operator->()。

所以，很容易让人感到困惑，我看到了不少与非连续迭代器、operator->()以及末尾过长相关的“证据”/“提示”。但据我所知，没有明确的要求规定非连续迭代器在operator->()指向末尾过长时是否允许表现出未定义的行为。有人能给出更明确的答案吗？

编辑：感谢几条有用的评论。提供一些背景信息，可能是为了回答一些回复：实际操作方面，稍微简化一下，我定义了迭代器包装器，即自定义迭代器类，其实现依赖于现有的（“包装的”）迭代器。包装的迭代器的类型作为模板参数给出，包装的迭代器作为构造函数参数给出。我粗心地认为我可以operator->()在包装器类中定义为&*wrapped_iterator。这在 clang、gcc、MSVC 发布版本，甚至在 MSVC 调试版本中对于非连续迭代器都有效。然而，它导致 MSVC 调试版本中对于连续迭代器的断言失败，在诸如std::vector::assign(first,last)first 和 last 是连续迭代器的包装器，以及 first 和 last 都是尾后迭代器的函数中。原因是 MSVCvector::assign调用了std::address_of(first) even if first==last，这是我没有预料到的。反过来，它为我的连续迭代器包装器address_of调用了。first.operator->()由于我已将其定义operator->()为&*wrapped_iterator，因此它会operator*在包装的迭代器中调用，而该迭代器在给定条件下的行为是未定义的。在这个特定情况下，它导致了断言失败，因为 MSVC 的调试模式有特殊的代码来检查类似这样的内容 ( _ITERATOR_DEBUG_LEVEL)。

所以我需要修改迭代器包装器的实现operator->()。我最初的想法是让它在包装的迭代器上调用。然而，这并不保证一定能实现（参见已接受的答案）。我需要做的是在包装的迭代器上operator->()调用。std::to_address

c++
Martin Hope
Sven Sandberg
Asked: 2024-12-10 20:11:31 +0800 CST
  • 6

我需要将指向成员函数的指针作为参数传递给其他函数。我习惯std::mem_fn将它们包装在函数对象中。

有时成员函数会有重载。我学习了两种语法形式来消除重载的歧义：

  • 为了消除模板成员函数的歧义，我使用了T::template member<template-args>指向成员的指针表达式。
  • 当所有重载都是非模板成员函数时，为了消除非模板成员函数的歧义，我将函数类型作为显式模板参数传递给mem_fn：mem_fn<return-type(args-types)>(pointer-to-member-expression)。

但是，当某些重载是模板成员函数时，应该使用什么语法来消除非模板成员函数的歧义？我的直接猜测无法编译：

#include <iostream>   // cout
#include <functional> // mem_fn

struct C {
    void f() { std::cout << "f()\n"; }
    void f(int) { std::cout << "f(int)\n"; }

    template <class T>
    void g(T) { std::cout << "g(T)\n"; }
    template <class T1, class T2>
    void g(T1) { std::cout << "g<T1,T2>(T1)\n"; }

    template <class T>
    void h(T) { std::cout << "h(T)\n"; }
    void h(int) { std::cout << "h(int)\n"; }
};

int main() {
    C c;
    // non-template member function vs non-template member function
    std::mem_fn<void()>(&C::f)(c);
    std::mem_fn<void(int)>(&C::f)(c, 1);

    // template member function vs template member function
    std::mem_fn(&C::template g<int>)(c, 1);
    std::mem_fn(&C::template g<int, int>)(c, 1);

    // non-template member function vs template member function
    std::mem_fn(&C::template h<int>)(c, 1);
    // gcc: error: no matching function for call to 'mem_fn<void(int)>(<unresolved overloaded function type>)'
    // clang: error: no matching function for call to 'mem_fn'
    // std::mem_fn<void(int)>(&C::h)(c, 1);

    return 0;
}

另请参阅： https: //godbolt.org/z/39dd569cK

值得一提的是，我使用 C++20，但在 C++11 中也看到同样的错误。

c++