Início / coding / Perguntas / 79293674
Accepted
xmllmx
Asked: 2024-12-19 17:07:11 +0800 CST

`std::function` foi descontinuado por `std::copyable_function` em C++26?

  • 772

C++26 fornece std::copyable_function [cppref link] . No entanto, o existente std::functionjá é copyable. Então, tenho 3 perguntas:

  1. Quais são as principais vantagens de std::copyable_functionmais de std::function?

  2. Invocar um vazio std::copyable_functioné indefinido, enquanto invocar um vazio std::functionlançará uma exceção. Qual é a lógica por trás disso?

  3. Foi std::functiondescontinuado std::copyable_functionem C++26?

c++

1 respostas

  1. Best Answer

    Quais são as principais vantagens de std::copyable_functionmais de std::function?

    São dois.

    Primeiro, não há target()API, o que geralmente não era super útil de qualquer maneira, então há menos sobrecarga porque std::copyable_functionnão é preciso rastrear algo que std::functiono fez. Mas isso é menor.

    O mais importante é a superfície da API. std::functionParece com isso:

    struct function<R(Args...)> {
    R operator()(Args...) const;
};

    O operador de chamada (1) sempre conste (2) nunca noexcept. (1) é um problema porque você ainda pode invocar uma constfunção que não seja membro sem querer.

    std::copyable_functionparece com isso:

    struct copyable_function<R(Args...) cv ref noexc> {
  R operator()(Args...) cv ref noexc;
};

    O que significa que, por exemplo, copyable_function<void(int)>tem um operador não- const, não- noexceptcall, mas copyable_function<void(int) const noexcept>tem um que é ambos conste noexcept. Tudo isso é especificável.

    Isso torna o uso claro e descritivo... e mais correto!

    Invocar um std::copyable_function vazio é indefinido, enquanto invocar um std::function vazio lançará uma exceção. Qual é a lógica por trás disso?

    Pode-se argumentar que invocar um vazio std::functioné um bug. Há muitas pessoas que acham que lançar para sinalizar erro do programador é uma maneira ruim de fazer isso - chamá-lo de comportamento indefinido significa que a implementação pode afirmar.

    Foi std::functiondescontinuado std::copyable_functionem C++26?

    A resposta literal para essa pergunta é: não. Mas talvez a pergunta mais interessante seja: deveria ter sido? À qual eu ainda responderia não.

    Há uma quantidade muito grande de código que usa std::functione uma grande porcentagem dele provavelmente está correta. Também não é uma simples renomeação para transição, já que muitos usuários vão querer mudar de function<R(Args...)>para copyable_function<R(Args...) const>. Mas também muitos usuários vão querer mudar para move_only_function<R(Args...) const>em vez disso.

    Provavelmente é uma boa ideia realmente fazer essas mudanças (especialmente se você não precisa de target(), o que... ninguém precisa). Mas elas não são tão urgentes que você realmente queira um [[deprecated]]aviso sobre isso. Parece mais uma sugestão discreta de modernização.

    Na verdade, há dois níveis aqui:

    1. Aé ruim (possivelmente ativamente prejudicial), Bé estritamente superior, por favor troque.
    2. Aestá bem, Bestá melhor. Prefira Bem código novo, mas Anão é prejudicial.

    A transição de auto_ptr<T>para unique_ptr<T>se encaixa nessa primeira categoria. A transição de function<R(Args..)>para copyable_function<R(Args...) const>(ou move_only_function<R(Args...) const>, ou às vezes até function_ref<R(Args...) const>) para mim é mais como a segunda categoria. Aestá bom. Não grite comigo por ainda usá-lo em código antigo.

    • 8

relate perguntas