Qual é a diferença conceitual entre finalmente e um destruidor?

Primeiro, estou ciente de Por que não existe uma construção 'finalmente' em C ++? mas uma longa discussão de comentários sobre outra questão parece justificar uma pergunta separada.

Além do problema que finallyem C # e Java pode existir basicamente apenas uma vez (== 1) por escopo e um único escopo pode ter vários (== n) destruidores de C ++, acho que eles são essencialmente a mesma coisa. (Com algumas diferenças técnicas.)

No entanto, outro usuário argumentou :

... Eu estava tentando dizer que um dtor é inerentemente uma ferramenta para (Release semântica) e, finalmente, é inerentemente uma ferramenta para (Commit semântica). Se você não vê o porquê: considere por que é legítimo lançar exceções umas sobre as outras em blocos finalmente e por que o mesmo não é para destruidores. (Em certo sentido, trata-se de dados versus controle. Destrutores são para liberar dados, finalmente é para liberar controle. Eles são diferentes; é lamentável que o C ++ os una.)

Alguém pode esclarecer isso?

• Transação ( try)
• Saída / resposta de erro ( catch)
• Erro externo ( throw)
• Erro do programador ( assert)
• Reversão (o mais próximo pode ser proteção de escopo em idiomas que os suportam nativamente)
• Liberando recursos (destruidores)
• Fluxo de controle independente de transação diversa ( finally)

Não é possível apresentar uma descrição melhor do finallyque o fluxo de controle independente de transações diversas. Ele não necessariamente mapeia tão diretamente para qualquer conceito de alto nível no contexto de uma mentalidade de transação e recuperação de erros, especialmente em uma linguagem teórica que possui destruidores e finally.

O que me falta mais inerentemente é um recurso de linguagem que representa diretamente o conceito de reverter efeitos colaterais externos. Guardas de escopo em linguagens como D são a coisa mais próxima que consigo pensar que chega perto de representar esse conceito. Do ponto de vista do fluxo de controle, uma reversão no escopo de uma função específica precisaria distinguir um caminho excepcional de um regular, enquanto simultaneamente automatiza a reversão implicitamente de quaisquer efeitos colaterais causados ​​pela função, caso a transação falhe, mas não quando a transação for bem-sucedida. . Isso é fácil o suficiente com destruidores se, digamos, definirmos um valor booleano como succeededtrue no final de nosso bloco try, para impedir a lógica de reversão em um destruidor. Mas é uma maneira bastante indireta de fazer isso.

Embora possa parecer que isso não pouparia muito, a reversão de efeitos colaterais é uma das coisas mais difíceis de corrigir (ex: o que torna tão difícil escrever um contêiner genérico seguro para exceções).

De certa forma, eles são - da mesma maneira que uma Ferrari e um trânsito podem ser usados ​​para beliscar as lojas por um litro de leite, mesmo que sejam projetados para diferentes usos.

Você pode colocar uma construção try / finalmente em todos os escopos e limpar todas as variáveis ​​definidas no escopo finalmente para emular um destruidor de C ++. Conceitualmente, é isso que o C ++ faz - o compilador chama automaticamente o destruidor quando uma variável sai do escopo (ou seja, no final do bloco do escopo). Você teria que organizar sua tentativa / finalmente, para que a tentativa seja a primeira coisa e, finalmente, a última em cada escopo. Você também teria que definir um padrão para cada objeto para ter um método de nome específico que ele usa para limpar seu estado que você chamaria no bloco final, embora eu ache que você possa deixar o gerenciamento de memória normal fornecido pelo seu idioma. limpe o objeto agora esvaziado quando quiser.

No entanto, não seria fácil fazer isso, e mesmo que o .NET tenha introduzido o IDispose como um destruidor gerenciado manualmente e usando blocos como uma tentativa de tornar esse gerenciamento manual um pouco mais fácil, ainda não é algo que você gostaria de fazer na prática. .

Do meu ponto de vista, a principal diferença é que um destruidor em c ++ é um mecanismo implícito (invocado automaticamente) para liberar recursos alocados enquanto a tentativa ... finalmente pode ser usada como um mecanismo explícito para fazer isso.

Nos programas c ++, o programador é responsável por liberar recursos alocados. Isso geralmente é implementado no destruidor de uma classe e é feito imediatamente quando uma variável sai do escopo ou quando a exclusão é chamada.

Quando em c ++, uma variável local de uma classe é criada sem o uso newdos recursos dessas instâncias são liberadas implícitas pelo destruidor quando há uma exceção.

// c++
void test() {
    MyClass myClass(someParameter);
    // if there is an exception the destructor of MyClass is called automatically
    // this does not work with
    // MyClass* pMyClass = new MyClass(someParameter);

} // on test() exit the destructor of myClass is implicitly called

Em java, c # e outros sistemas com gerenciamento automático de memória, o coletor de lixo dos sistemas decide quando uma instância de classe é destruída.

// c#
void test() {
    MyClass myClass = new MyClass(someParameter);
    // if there is an exception myClass is NOT destroyed so there may be memory/resource leakes

    myClass.destroy(); // this is never called
}

Não há mecanismo implícito para isso, então você deve programar isso explicitamente usando try

// c#
void test() {
    MyClass myClass = null;

    try {
        myClass = new MyClass(someParameter);
        ...
    } finally {
        // explicit memory management
        // even if there is an exception myClass resources are freed
        myClass.destroy();
    }

    myClass.destroy(); // this is never called
}

Que bom que você postou isso como uma pergunta. :)

Eu estava tentando dizer que destruidores e finallysão conceitualmente diferentes:

• Destrutores são para liberar recursos ( dados )
• finallyé para retornar ao chamador ( controle )

Considere, digamos, este pseudocódigo hipotético:

try {
    bar();
} finally {
    logfile.print("bar has exited...");
}

finallyaqui está resolvendo inteiramente um problema de controle e não um problema de gerenciamento de recursos.
Não faria sentido fazer isso em um destruidor por vários motivos:

• Não coisa está sendo "adquirido" ou "criado"
• A falha na impressão no arquivo de log não resultará em vazamentos de recursos, corrupção de dados etc. (supondo que o arquivo de log aqui não seja retornado ao programa em outro local)
• É legítimo logfile.printfracassar, enquanto a destruição (conceitualmente) não pode fracassar

Aqui está outro exemplo, desta vez como em Javascript:

var mo_document = document, mo;
function observe(mutations) {
    mo.disconnect();  // stop observing changes to prevent re-entrance
    try {
        /* modify stuff */
    } finally {
        mo.observe(mo_document);  // continue observing (conceptually, this can fail)
    }
}
mo = new MutationObserver(observe);
return observe();

No exemplo acima, novamente, não há recursos a serem liberados.
De fato, o finallybloco está adquirindo recursos internamente para atingir seu objetivo, o que poderia falhar potencialmente. Portanto, não faz sentido usar um destruidor (se o Javascript tiver um).

Por outro lado, neste exemplo:

b = get_data();
try {
    a.write(b);
} finally {
    free(b);
}

finallyestá destruindo um recurso b,. É um problema de dados. O problema não é devolver o controle corretamente ao chamador, mas evitar vazamentos de recursos.
Falha não é uma opção e nunca deve (conceitualmente) ocorrer.
Cada lançamento de bé necessariamente associado a uma aquisição e faz sentido usar o RAII.

Em outras palavras, apenas porque você pode usar para simular ou isso não significa que ambos são um e o mesmo problema ou que ambos são soluções apropriadas para os dois problemas.

A resposta do k3b realmente expressa bem:

um destruidor em c ++ é um mecanismo implícito (invocado automaticamente) para liberar recursos alocados enquanto a tentativa ... finalmente pode ser usada como um mecanismo explícito para fazer isso.

Quanto a "recursos", gosto de me referir a Jon Kalb: RAII deve significar aquisição de responsabilidade é inicialização .

De qualquer forma, quanto ao implícito versus explícito, isso parece realmente ser:

• Um d'tor é uma ferramenta para definir quais operações devem acontecer - implicitamente - quando a vida útil de um objeto termina (o que geralmente coincide com o final do escopo)
• Um bloco de finalmente é uma ferramenta para definir - explicitamente - quais operações devem acontecer no final do escopo.
• Além disso, tecnicamente, você sempre pode jogar de finalmente, mas veja abaixo.

Eu acho que é isso para a parte conceitual, ...

... agora há IMHO alguns detalhes interessantes:

• O try / catch / finalmente está ausente, pois não há nenhum faultbloco para executar o código que só deve ser executado no caso de uma saída de escopo excepcional.
• Destrutores podem ser usados ​​para construir finalmente máquinas - veja SCOPE_EXIT, SCOPE_FAILe SCOPE_SUCCESS na biblioteca de loucuras . Consulte Andrei Alexandrescu: tratamento de erros no fluxo de controle C ++ / declarativo (realizado na NDC 2014 )
• SCOPE_EXIT pode replicar, finalmente, apenas muito, já que é tecnicamente perfeitamente aceitável lançar, embora simplesmente não funcione de forma confiável a partir de um destruidor.
• No entanto , parece-me que as pessoas tendem a pensar que jogar de dentro finalmente é uma má ideia de qualquer maneira .

Também não acho que o c'tor / d'tor precise conceitualmente "adquirir" ou "criar" qualquer coisa, além da responsabilidade de executar algum código no destruidor. Qual é o que finalmente também faz: execute algum código.

E, embora o código em um bloco finalmente possa certamente gerar uma exceção, isso não é suficiente para dizer que eles são conceitualmente diferentes acima de explícito versus implícito.

(Além disso, não estou convencido de que o código "bom" deva ser lançado finalmente - talvez essa seja outra questão.)