Início / coding / Perguntas / 78011571
Accepted
Jeroen Boschma
Asked: 2024-02-17 17:23:42 +0800 CST

O destruidor é eliminado quando o construtor está ausente?

  • 772

O código abaixo reproduz o problema que tenho, MSVC 2022:

#include <iostream>

struct A {
    static void message()
    {
        std::cout << "A::message()\n";
    }

    struct B {
        B() {}
        ~B()
        {
            A::message();
        }
    };

    static inline B b;
};
 
int main()
{
}

Com o código acima vejo, como esperado, a mensagem aparecendo. No entanto:

  1. Se eu remover o construtor B(), o destruidor ~B()parece ter sido eliminado porque a mensagem desaparece.
  2. Se eu adicionar uma propriedade fictícia int dummy;à estrutura B, a mensagem aparecerá novamente.

Perguntas para as quais realmente não consegui encontrar resposta:

  1. Parece-me que sem o construtor B()e sem propriedades B, o compilador simplesmente rotula a classe Bcomo vazia e simplesmente a ignora completamente. Isso está correto?
  2. Está em algum lugar documentado que isso pode ocorrer? Dado o conteúdo do destruidor, acho que isso nunca deveria acontecer.
  3. Como posso garantir que sempre funcionará corretamente, não apenas para o compilador que estou usando no momento. Definir o construtor é B()suficiente ou devo também tornar Bnão vazio com a propriedade fictícia int dummy;?
c++

1 respostas

  1. Best Answer

    A diferença está em ter ou não binicialização estática .

    Se uma variável de duração de armazenamento estático tiver inicialização estática, ela será inicializada antes de qualquer outra variável de duração de armazenamento estático sem inicialização estática (ou seja, inicialização dinâmica ).

    Em particular, há outro objeto importante de duração de armazenamento estático definido em <iostream>, ou seja, uma instância de std::ios_base::Init. A inicialização de um objeto desse tipo causa a inicialização dos fluxos IO padrão (por exemplo, std::cout). Ele também é responsável por liberar todos esses fluxos quando a última instância deles for destruída.

    Portanto, para ver sua saída, você deve ter certeza de que o std::ios_base::Initobjeto foi destruído após seu arquivo b. No entanto, a ordem de destruição é inversa à ordem de inicialização. Portanto, se btiver inicialização estática, mas o std::ios_base::Initobjeto tiver inicialização dinâmica, então é o contrário. Se bnão tiver inicialização estática, então será ordenado corretamente, SOMENTE se ba definição de existir em cada unidade de tradução que inclui (direta ou indiretamente) <iostream>, após a primeira inclusão. Isso ocorre porque você usou inline, o que faz com que a inicialização dinâmica seja bapenas parcialmente ordenada .

    Geralmente, se a inicialização de uma variável estática de duração de armazenamento for uma expressão constante, então a variável terá inicialização estática. Esse é o caso aqui se você não declarar nenhum construtor.

    Se a inicialização não for uma expressão constante, então ela geralmente tem inicialização dinâmica, exceto que, desde que não altere os valores resultantes das variáveis ​​estáticas de duração de armazenamento após sua inicialização, a implementação é livre para escolher a inicialização estática para qualquer tal variável. Se você usar um não constexprconstrutor ou deixar um membro não inicializado, você terá esta situação.

    Portanto, para obter o pedido correto com segurança, você precisa garantir que bnão haja inicialização estática. Devido à margem de manobra dada à implementação, isso é um pouco complicado. Fazer algo no Bconstrutor do que obviamente só pode acontecer em tempo de execução deve ser suficiente (por exemplo, chamar algum IO), mas da forma como o padrão especifica isso atualmente, é difícil ter certeza absoluta porque as diferenças nos efeitos colaterais não são consideradas. Consulte a edição aberta 1294 do CWG .

    Uma alternativa melhor pode ser adicionar um std::ios_base::Initobjeto como membro a B, para que um desses objetos seja certamente mantido ativo enquanto bo destruidor de está em execução.

    Além disso, como você pode ver acima, a construção e destruição de variáveis ​​​​de duração de armazenamento estático em C++ é bastante complicada. Se você puder, seria muito mais simples simplesmente declarar bcomo uma staticvariável não local em main. Geralmente não há nenhuma garantia de que a static inlinevariável seria construída antes da primeira não inicialização ou uso de mainqualquer maneira (isso é definido pela implementação).

    Observe que não verifiquei se essa é realmente a causa no caso do MSVC. A resposta é baseada em considerações teóricas do padrão e no que uma implementação poderia fazer.

    Além disso, estou usando minha interpretação de [basic.start.term]/3 , que li como significando que a ordem de destruição das variáveis ​​inicializadas estaticamente é ordenada com as variáveis ​​inicializadas dinâmicas de acordo com sua ordem real de inicialização. Outra interpretação que pude ver no texto é que a ordem de destruição é como se todas as variáveis ​​tivessem sido inicializadas dinamicamente de acordo com as regras de ordem de inicialização reversa para inicialização dinâmica. Infelizmente, o texto não me parece claro e pelo menos o GCC e o Clang parecem seguir a última interpretação. Nesse caso você não veria o seu problema.

    • 5

relate perguntas