Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Eu o teria feito desta maneira:
Acho este estilo desconfortável. Ou seja, se trata de "canetas de feltro".
Então você também quer avisos? Qual é este duplo padrão: em ambos os lugares o comportamento é inequívoco, mas com parênteses você é contra as advertências e aqui você é a favor?
Você precisa de um aviso para que não cometa erros difíceis de encontrar. Portanto, a dificuldade é uma avaliação subjetiva. Assim, com parênteses você não comete erros, e aqui você pode. E para mim é o contrário.
Então, a qual de nós as regras de emissão de advertências devem ser ajustadas?
Você parece não entender o ponto. A fundição dinâmica deve ser sempre uma operação explícita. Em qualquer linguagem normal, seja ela C++, C#, Java ou qualquer outra linguagem OOP, tal código não será compilado. Esta é a base de um OOP confiável. Mas foi esquecido aqui por alguma razão. Não achei que a comparação de parênteses fosse apropriada aqui de forma alguma.
A base dos fundamentos de um OOP confiável.
A base sem ambigüidade.
Não vejo o ponto de referência do código (embora eu também não utilize bibliotecas padrão). Se colocar um objeto em um array envolve a criação de uma cópia dele, então o método de atribuição ou construtor de cópia deve ser declarado e descrito explicitamente nesta classe, caso contrário, nenhum invólucro ajudará de qualquer forma. Se você só precisa colocar uma referência a um objeto em uma matriz, você não precisa de nenhum invólucro (por quê?).
Para que você precisa de uma matriz desse tipo? Por ser quase análogo a um vetor plus, deve funcionar como vetor<int>, vetor<nome_da_classe>, vetor<nome_da_classe*>. Se você pode implementá-lo sem embrulho por meio do µl, bom para você (não acho que você possa). Você não tem como correr através de array e chamar destruidores ( _data[i].~Destr() ), nenhuma especialização parcial e nenhum truque SFINAE. Este invólucro torna o conjunto adequado para apontar para objetos na pilha sem quebrar a possibilidade de trabalhar com vetor<int>, por exemplo.
vector<unique_ptr<my_class>> v1;
vector<my_class> v2;
vector<int> v3;
ZS: o que dizer, vetor<nome_da_classe*> não funcionará como esperado, mesmo em plumas (chamada do destrutor no final da vida útil do vetor) ele também precisa de invólucro.
Isso vai funcionar? )
P.S. Por analogia, uma função pode devolver qualquer coisa em vez de vazia, e não é necessário SFINAE.
No lado positivo, a eliminação do vazio* é UB.
A propósito, eu nunca tinha pensado nisso antes, obrigado pela dica. Acontece que a exclusão neste caso é semelhante à livre(). Deveria ser proibida, já que a exclusão é posicionada para objetos e simplesmente libera as regras de desvio de memória.
Embora os destruidores também sejam chamados aqui, mas em caso de portabilidade do código para C++, pode-se encontrar problemas.
Sim, isso serve. Mas ainda precisamos de embrulho: afinal de contas, precisamos de uma matriz universal, então às vezes ela tem indicadores que precisam ser apagados, e às vezes não (bem, apenas um monte de indicadores - o resultado de encontrar algo em outra matriz).
Bem, ninguém proíbe passar a opção adicional ao criar uma matriz - seja para apagar elementos ao apagá-la ou não, e fazê-lo ligado ou desligado por padrão (a seu gosto). Afinal, você nunca pode adivinhar se deseja ou não apagar itens)).
P.S. A propósito, embrulhar um ponteiro antes de colocá-lo em um array não resolverá a questão de se você precisa ou não deletar seu objeto base ao deletar o array)Os parênteses adicionais eliminaram completamente a influência das prioridades lingüísticas. Tudo se torna completamente inequívoco. Isto torna 100% confiável que nada se quebrará após a próxima construção.
Com isto em mente, vou resumir:
Se eu não o declarei corretamente - por favor, me corrija - tornei meu conceito curto e inequívoco onde avisos sobre parênteses são necessários
Bem, ninguém proíbe passar uma opção adicional ao criar uma matriz - seja para apagar elementos ao apagá-la ou não, e fazê-lo ligado ou desligado por padrão (a seu gosto). Porque é difícil adivinhar, caso você apague ou não os itens)).
Em geral, sim, você pode fazer isso dessa maneira.
Se você não o embrulha, não o apaga, se o embrulha, o apaga, é cristalino.
ZS: mas se o fizesse, faria o mais parecido possível com o padrão mais biblioteca (nomes, comportamento, etc.), então não tenho escolha. Por que se preocupar em criar outra especificação quando tudo já está escrito?