FórumSeções

Bug de compilador com parâmetro de modelo = vazio* - página 7

Novo comentário
Alexey Navoykov:

Eu o teria feito desta maneira:

Acho este estilo desconfortável. Ou seja, se trata de "canetas de feltro".

fxsaber:

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.

Alexey Navoykov:

A base dos fundamentos de um OOP confiável.

A base sem ambigüidade.

Ilya Malev:

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) também é necessário embrulhar.
pavlick_:

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? )

template<typename T>
void del(T par){printf("%s не удаляем",typename(T));}

template<typename T>
void del(T *par){printf("%s удаляем",typename(T));delete par;}

class A{public:void~A(void){printf("удаляем %i",&this);}};

void OnStart()
 {
  int var1;
  A *var2=new A;
  del(var1);
  del(var2);
 }

P.S. Por analogia, uma função pode devolver qualquer coisa em vez de vazia, e não é necessário SFINAE.

Sim, está bem. Mas ainda precisamos de um invólucro: precisamos de uma matriz universal, então às vezes ela tem indicadores que precisam ser apagados, e às vezes não (bem, apenas um conjunto de indicadores - o resultado de encontrar algo em outra matriz).
pavlick_:

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.

pavlick_:
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)
fxsaber:

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:


A100
Desenvolvedores
fxsaber
parênteses
somente em lugares onde são indispensáveis
talvez mesmo em lugares onde a MQL4 era diferente antes
eles são necessários em todos os lugares
avisos desnecessários
não necessário
somente em lugares onde a MQL4 era diferente antes
necessário em todos os lugares
prioridades
é necessário
necessário
não necessário em princípio (porque os parênteses os substituem)

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

Ilya Malev:

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.

P.S. A propósito, só porque você embrulha um ponteiro antes de colocá-lo em um array, a questão de se você precisa ou não apagar seu objeto base ao apagar o array não vai ficar mais clara))


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?

1234567891011121314...20
Novo comentário