Início / coding / Perguntas / 79343344
Accepted
Konvt
Asked: 2025-01-10 00:12:57 +0800 CST

Problema com o tipo de parâmetro do construtor de exceção na biblioteca padrão

  • 772

Na biblioteca padrão, o tipo de parâmetro do construtor da classe de exceção, como std::runtime_error, segue este padrão:

runtime_error( const std::string& what_arg ); // (1)
runtime_error( const char* what_arg );        // (2)
runtime_error( const runtime_error& other );  // (3)

O que me confundiu é que (1) foi usado const std::string&em vez de std::string, o que obviamente resulta em uma operação de cópia adicional dentro do construtor.

Se o tipo de parâmetro fosse std::string, não apenas evitaria uma operação de cópia extra, mas também seria noexcept; o que é uma conclusão que percebi recentemente:

Se uma função marcada como noexcepttiver um parâmetro de um tipo que pode gerar uma exceção durante sua construção, mesmo que seja garantido que a exceção será gerada, ela não fará com que o programa seja encerrado devido a uma exceção.

Isto é confirmado pelo programa de teste .

Então, por que a lista de parâmetros do construtor de exceção da biblioteca padrão não usa std::string? Ou meu entendimento e conclusão, assim como o programa de teste, estão incorretos, mesmo que seja um comportamento indefinido?

c++

1 respostas

  1. Best Answer

    O que me confundiu é que (1) usou const std::string& em vez de std::string, o que obviamente resulta em uma operação de cópia adicional dentro do construtor.

    Acho que você está assumindo que isso std::runtime_erroré implementado com uma std::stringvariável de membro para armazenar what(). Este não é necessariamente o caso, por exemplo , libstdc++ tem um __cow_stringtipo de membro especial , libc++ usa um std::__libcpp_refstringtipo de membro especial , MSVC usa um __std_exception_datatipo.

    Ter uma sobrecarga tomando std::stringpor valor introduziria, na verdade, uma cópia extra para implementações que não têm um std::stringmembro (uma cópia para o temporário std::stringe uma segunda para o formato interno). Uma sobrecarga de referência de valor r pelo menos não teria nenhuma desvantagem sobre a constreferência, mas acho que ninguém sentiu que isso vale o esforço de padronização desde que os valores r foram adicionados em c++11 (presumivelmente porque nenhuma implementação realmente usa um std::stringmembro).

    Exceções geralmente não são implementadas usando std::stringmembros para evitar os problemas que você mencionou. As alocações podem falhar ao criar exceções (especialmente se a exceção estiver sendo gerada devido ao esgotamento da memória), então geralmente há algum alocador especializado usado que não falhará mesmo se não houver espaço de heap geral disponível.

    • 5

relate perguntas