Sven Sandberg's questions

O padrão exige que isso operator->()seja definido para iteradores não contíguos do tipo past-the-end?

Fundo:

• Independentemente da categoria do iterador, é permitido operator*()exibir comportamento indefinido quando o iterador aponta para o passado-do-fim. Isso é explícito em https://en.cppreference.com/w/cpp/iterator , seção "Desreferenciabilidade e validade", que diz: "Valores de um iterador i para os quais a expressão *i é definida são chamados desreferenciáveis. A biblioteca padrão nunca assume que valores passado-do-fim são desreferenciáveis."
• EDIT: A conclusão neste tópico está errada: veja minha resposta abaixo. Para iteradores contíguos , acredito que não é permitido operator->()exibir comportamento indefinido quando o iterador aponta para o passado-do-fim. Isso pode ser inferido de duas seções em cppreference: (1) Em https://en.cppreference.com/w/cpp/iterator/contiguous_iterator , a seção "Requisitos semânticos" define o iterador não desreferenciável ce estabelece requisitos para std::to_address(c)os quais implica que std::to_address(c)não exibe comportamento indefinido. (2) em https://en.cppreference.com/w/cpp/memory/to_address, ele fornece uma "Possível implementação" onde std::to_addressdepende de operator->(). EDIT: A "possível implementação" não usa operator->()caso pointer_traitsseja definida para o iterador; se for esse o caso, parece permitido operator->()não ser definida para iteradores finais.

É menos claro se iteradores não contíguos podem implementar operator->()de forma que seu comportamento seja indefinido para iteradores que terminam no final. Aqui estão várias "evidências"/"dicas" que encontrei relacionadas a isso:

• Conceitos de iteradores C++20 não contíguos parecem não exigir que isso operator->()seja definido. Isso simplesmente não é mencionado entre todos os requisitos definidos em https://en.cppreference.com/w/cpp/iterator/random_access_iterator , ou os requisitos dos quais dependem, AFAICS.
• O conceito de iterador contíguo em C++20, std::contiguous_iterator, requer operator->(): como mencionado acima, isso pode ser inferido, pois std::to_addressdeve ser definido, e a "Possível implementação" para std::to_addressusos operator->(). E a página https://en.cppreference.com/w/cpp/memory/to_address menciona explicitamente std::contiguous_iterator. Como não menciona outros tipos de iteradores, isso não implica nada para iteradores não contíguos, se bem me lembro.
• As categorias de iteradores legados exigem que operator->()seja definido para LegacyInputIteratore mais forte (veja a tabela em https://en.cppreference.com/w/cpp/named_req/InputIterator ) e isso é qualificado pela "Pré-condição: i é desreferenciável". Em outras palavras, há uma exceção explícita que permite que iteradores que terminam no passado exibam comportamento indefinido. Não vejo essa pré-condição removida para nenhuma das categorias de iteradores legados mais fortes (a propósito, nem mesmo https://en.cppreference.com/w/cpp/named_req/ContiguousIterator , então isso parece uma diferença entre LegacyContiguousIteratore std::contiguous_iterator).
• Por outro lado, em https://en.cppreference.com/w/cpp/iterator , seção "Desreferenciabilidade e validade", menciona-se que ______ operator*()não precisa ser definido para iteradores que terminam no passado, mas não menciona _______ operator->(). Portanto, isso pode sugerir que a exceção que permite que algumas operações em iteradores que terminam no passado sejam indefinidas não se aplica necessariamente a operator->()_______.

Portanto, é fácil se confundir, e vejo bastante "evidência"/"dicas" relacionadas a iteradores não contíguos, operator->()e passado-do-fim. Mas não há nenhum requisito explícito, até onde consegui encontrar, que determine se iteradores não contíguos podem exibir comportamento indefinido quando operator->()o iterador aponta para passado-do-fim. Alguém tem uma resposta mais definitiva?

Editar : Obrigado por vários comentários úteis. Para dar um contexto, possivelmente respondendo a algumas das respostas: O lado prático, um pouco simplificado, é que eu defini wrappers de iteradores , ou seja, classes de iteradores personalizadas cuja implementação depende de um iterador existente ("encapsulado"). O tipo do iterador encapsulado é fornecido como um parâmetro de modelo e o iterador encapsulado é fornecido como um argumento do construtor. Eu, descuidadamente, presumi que poderia definir operator->()na classe encapsuladora como &*wrapped_iterator. Isso funcionou no clang, gcc, na compilação de lançamento do MSVC e até mesmo na compilação de depuração do MSVC para iteradores não contíguos. No entanto, resultou em falhas de asserção na compilação de depuração do MSVC para iteradores contíguos, em funções como std::vector::assign(first,last)onde first e last são wrappers em torno de iteradores contíguos e first e last são ambos iteradores passados ​​do fim. O motivo foi que o MSVC vector::assigninvoca std::address_of(first) even if first==last , o que eu não previ. Por sua vez, address_ofinvocado first.operator->()para o meu wrapper de iterador contíguo. Como eu havia definido operator->()como &*wrapped_iterator, ele invoca operator*o iterador encapsulado cujo comportamento sob as condições fornecidas é indefinido. Neste caso específico, resultou em uma falha de asserção, porque o modo de depuração do MSVC tem um código especial que verifica coisas como esta ( _ITERATOR_DEBUG_LEVEL).

Então, preciso alterar a implementação de operator->(). no meu wrapper de iterador. Minha primeira ideia era fazer com que ele invocasse operator->()o iterador encapsulado. No entanto, não há garantia de que isso seja definido (veja a resposta aceita). O que preciso fazer é invocar std::to_addresso iterador encapsulado.

Preciso passar ponteiros para funções membro como parâmetros para outras funções. Eu costumo std::mem_fnenvolvê-los em objetos de função.

Às vezes, as funções membro têm sobrecargas. Aprendi duas formas de sintaxe para desambiguar as sobrecargas:

• Para desambiguar funções de membro de modelo, eu uso T::template member<template-args>a expressão ponteiro-para-membro.
• Para desambiguar funções de membro não-modelo quando todas as sobrecargas são funções de membro não-modelo, passo o tipo de função como argumento de modelo explícito para mem_fn: mem_fn<return-type(args-types)>(pointer-to-member-expression).

Mas qual sintaxe deve ser usada para desambiguar uma função membro não template quando algumas sobrecargas são funções membro template? Meu palpite direto não compila:

#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;
}

Veja também: https://godbolt.org/z/39dd569cK

A propósito, eu uso C++20, mas vejo os mesmos erros também em C++11.