Enquanto a seção "perguntas acima de 50" está aberta, deixem-me interjetar minhas próprias perguntas no assunto de fundições.
- Quais são algumas maneiras de melhorar o código em termos de tolerância a falhas ou não-redundância?
- É necessário oCheckPointer()!=POINTER_INVALID check? Ou definitivamente não é necessário? Explique por quê.
- Trazer a não-constrição, para que seja possível chamar de métodos não-constritivos. Os métodos não-constritivos podem ser chamados diretamente no método Comparar ? ou seja, se livrar do amarelo destacadoconst ?
Enquanto a seção "perguntas acima de 50" está aberta, deixem-me interjetar minhas próprias perguntas no assunto de fundições.
- Quais são algumas maneiras de melhorar o código em termos de tolerância a falhas ou não-redundância?
- É necessário o CheckPointer()!=POINTER_INVALID check? Ou definitivamente não é necessário? Explique por quê.
- Trazer a não-constrição, para que seja possível chamar de métodos não-constritivos. Os métodos não-constritivos podem ser chamados diretamente no método Comparar ? ou seja, se livrar do amarelo destacadoconst ?
É mais ou menos o mesmo que o seu, só que com menos letras. É uma questão de gosto, quem gosta mais, mas eu removi a variável extra (muito provavelmente teria sido removida pelo compilador dentro da estrutura de otimização).
A respeito da minha verificação do !nó. Deve ser substituído por CheckPointer(node)==POINTER_INVALID, mas é uma sobrecarga - uma chamada de função. Mesmo que seja alinhada, ainda assim é pelo menos desreferenciada e verificada a bandeira de status. Se apenas biblioteca ou concreto, você escreveu um programa de comparação de métodos, melhor !nodo e em código para observar o ponteiro inválido. Se você é preguiçoso demais para ficar atento aos ponteiros ou se é uma biblioteca para os pontos fracos, apenas CheckPointer(node)==POINTER_INVALID.
Se você remover o especificador constante que você destacou, não poderá chamar estes métodos de um objeto constante.
UPD: a verificação destacada pode ser removida, pois está nos chamados métodos.
Enquanto a seção "perguntas acima de 50" está aberta, deixem-me interjetar minhas próprias perguntas no assunto de fundições.
- Quais são algumas maneiras de melhorar o código em termos de tolerância a falhas ou não-redundância?
- É necessário o CheckPointer()!=POINTER_INVALID check? Ou definitivamente não é necessário? Explique por quê.
- Trazer a não-constrição, para que seja possível chamar de métodos não-constritivos. É possível chamar um método não-constante diretamente no método Comparar ? ou seja, para se livrar do amarelo destacadoconst ?
A idéia é escrever dois métodos da mesma função com e sem o corpo constante - para dizer de forma suave - não vale a pena))))
Mas a probabilidade de encontrar dois métodos é próxima de zero.... Porque a possibilidade de existência doCChartObjectRectangle::Preço - sem constância no corpo - acho que é improvável.
A chamada desta função do exterior não tem nenhum efeito. Isto é, o const funciona apenas com funções internas e garante que nada foi escrito na memória do objeto (não alterou o valor da variável). Em outras palavras, não se pode chamar Set(a) durante a const... Muitas vezes, em alguma confusão, para ter certeza de que esta função não sobrescreva nada, você pode organizar rapidamente estas consignações (embora esta seja provavelmente minha eliminação).
Considere que os consignatários devem ser empurrados apenas para todos os lugares sem obter)))) para facilitar a verificação posterior de algo.
O CheckPointer()!=POINTER_INVALID precisa de um cheque?
E porque não.... fazer um CheckPointer(T) { retun CheckPointer(T)!=POINTER_INVALID } O compilador deve torná-lo o mais simples possível. E vai ficar ainda melhor.
É mais rápido.
int a[1000];
for (int i=0; i<ArraySize(a); i++)....
или
for (int i=ArraySize(a); i>=0; i--)....
дак вот разницы не должно быть вообще
Bem, eu não mudei muito.
template<typename T>
bool Check(T *a) {returnCheckPointer(a)!=POINTER_INVALID;};
class CChartObjectRectangleX : public CChartObjectRectangle
{
#define ME CChartObjectRectangleX
public:
void ME(){};
virtualint Compare(const CObject *node,constint mode=0) const
{
const ME*nc=dynamic_cast<const ME*>(node);
return Check(nc)?mode==0?CompareDate(nc):CompareValue(nc):0;
}
virtualint CompareDate(const ME *node) const {return (this.Time(1)-node.Time(1));}
virtualint CompareValue(const ME *node) const {return ((this.Price(1)-node.Price(1))*10/Point()); }
#undef ME
};
Parece ser o mesmo que o seu, só que com menos letras. Portanto, é uma questão de gosto, mas eu removi a variável extra (muito provavelmente, o compilador a teria removido como parte da otimização).
A respeito da minha verificação do !nó. Deve ser substituído por CheckPointer(node)==POINTER_INVALID, mas é uma sobrecarga - uma chamada de função. Mesmo que seja alinhada, ainda assim é pelo menos desreferenciada e verificada a bandeira de status. Se apenas biblioteca ou concreto, você escreveu um programa de comparação de métodos, melhor !nodo e em código para observar o ponteiro inválido. Se você é preguiçoso demais para ficar atento aos ponteiros ou se é uma biblioteca para os pontos fracos, apenas CheckPointer(node)==POINTER_INVALID.
Se você remover o especificador constante, não poderá chamar estes métodos de um objeto constante.
demorei muito tempo para abrir a aba
Acho que 4 anos de faculdade não acrescentaram muito ao meu conhecimento (a explicação está ficando para trás no lixo).
a variante sem a constituição já que a classe base não tem referência aos parâmetros de entrada também funcionará corretamente, embora este não seja um estilo muito inteligente
Para login e uso do site MQL5.com, você deve ativar o uso de cookies.
Ative esta opção no seu navegador, caso contrário você não poderá fazer login.
Você entrou na conta. A autenticação de dois fatores foi desativada. Configure-a novamente e escaneie um novo código QR ou continue com a autenticação de dois fatores desativada.
não importa o que inicializar lá, mesmo int - qualquer número para chamar este construtor em particular
e escolhi 0,0 para evitar erros de impressão - qualquer dígito, ou seja, 0,0. É mais difícil escrever e imprimir mal do que 123
(duplo)0
mas também não assim)))) só agora olhou para o código normalmente, ainda há uma maneira de olhar para ele de forma anormal))(duplo)0
não
Eu só escrevo 0,0 - não são esperados outros números - não há sequer uma variável no construtor
em geral, como um estilo de autor da moda, talvez não seja o melhor
o ponto não é o x) mas que pode haver um flutuador no receptor, e também não é confiável especificar 0,0
0,0 é duplo inequívoco para o compilador, o flutuador será 0,f
crédito)
Enquanto a seção "perguntas acima de 50" está aberta, deixem-me interjetar minhas próprias perguntas no assunto de fundições.
- Quais são algumas maneiras de melhorar o código em termos de tolerância a falhas ou não-redundância?
- É necessário oCheckPointer()!=POINTER_INVALID check? Ou definitivamente não é necessário? Explique por quê.
- Trazer a não-constrição, para que seja possível chamar de métodos não-constritivos. Os métodos não-constritivos podem ser chamados diretamente no método Comparar ? ou seja, se livrar do amarelo destacado const ?
Enquanto a seção "perguntas acima de 50" está aberta, deixem-me interjetar minhas próprias perguntas no assunto de fundições.
- Quais são algumas maneiras de melhorar o código em termos de tolerância a falhas ou não-redundância?
- É necessário o CheckPointer()!=POINTER_INVALID check? Ou definitivamente não é necessário? Explique por quê.
- Trazer a não-constrição, para que seja possível chamar de métodos não-constritivos. Os métodos não-constritivos podem ser chamados diretamente no método Comparar ? ou seja, se livrar do amarelo destacado const ?
É mais ou menos o mesmo que o seu, só que com menos letras. É uma questão de gosto, quem gosta mais, mas eu removi a variável extra (muito provavelmente teria sido removida pelo compilador dentro da estrutura de otimização).
A respeito da minha verificação do !nó. Deve ser substituído por CheckPointer(node)==POINTER_INVALID, mas é uma sobrecarga - uma chamada de função. Mesmo que seja alinhada, ainda assim é pelo menos desreferenciada e verificada a bandeira de status. Se apenas biblioteca ou concreto, você escreveu um programa de comparação de métodos, melhor !nodo e em código para observar o ponteiro inválido. Se você é preguiçoso demais para ficar atento aos ponteiros ou se é uma biblioteca para os pontos fracos, apenas CheckPointer(node)==POINTER_INVALID.
Se você remover o especificador constante que você destacou, não poderá chamar estes métodos de um objeto constante.
UPD: a verificação destacada pode ser removida, pois está nos chamados métodos.
Enquanto a seção "perguntas acima de 50" está aberta, deixem-me interjetar minhas próprias perguntas no assunto de fundições.
- Quais são algumas maneiras de melhorar o código em termos de tolerância a falhas ou não-redundância?
- É necessário o CheckPointer()!=POINTER_INVALID check? Ou definitivamente não é necessário? Explique por quê.
- Trazer a não-constrição, para que seja possível chamar de métodos não-constritivos. É possível chamar um método não-constante diretamente no método Comparar ? ou seja, para se livrar do amarelo destacado const ?
A idéia é escrever dois métodos da mesma função com e sem o corpo constante - para dizer de forma suave - não vale a pena))))
Mas a probabilidade de encontrar dois métodos é próxima de zero.... Porque a possibilidade de existência doCChartObjectRectangle::Preço - sem constância no corpo - acho que é improvável.
A chamada desta função do exterior não tem nenhum efeito. Isto é, o const funciona apenas com funções internas e garante que nada foi escrito na memória do objeto (não alterou o valor da variável). Em outras palavras, não se pode chamar Set(a) durante a const... Muitas vezes, em alguma confusão, para ter certeza de que esta função não sobrescreva nada, você pode organizar rapidamente estas consignações (embora esta seja provavelmente minha eliminação).
Considere que os consignatários devem ser empurrados apenas para todos os lugares sem obter)))) para facilitar a verificação posterior de algo.
O CheckPointer()!=POINTER_INVALID precisa de um cheque?
E porque não.... fazer um CheckPointer(T) { retun CheckPointer(T)!=POINTER_INVALID } O compilador deve torná-lo o mais simples possível. E vai ficar ainda melhor.
É mais rápido.
Bem, eu não mudei muito.
Este é todo o seu código.
Parece ser o mesmo que o seu, só que com menos letras. Portanto, é uma questão de gosto, mas eu removi a variável extra (muito provavelmente, o compilador a teria removido como parte da otimização).
A respeito da minha verificação do !nó. Deve ser substituído por CheckPointer(node)==POINTER_INVALID, mas é uma sobrecarga - uma chamada de função. Mesmo que seja alinhada, ainda assim é pelo menos desreferenciada e verificada a bandeira de status. Se apenas biblioteca ou concreto, você escreveu um programa de comparação de métodos, melhor !nodo e em código para observar o ponteiro inválido. Se você é preguiçoso demais para ficar atento aos ponteiros ou se é uma biblioteca para os pontos fracos, apenas CheckPointer(node)==POINTER_INVALID.
Se você remover o especificador constante, não poderá chamar estes métodos de um objeto constante.
demorei muito tempo para abrir a aba
Acho que 4 anos de faculdade não acrescentaram muito ao meu conhecimento (a explicação está ficando para trás no lixo).
a variante sem a constituição já que a classe base não tem referência aos parâmetros de entrada também funcionará corretamente, embora este não seja um estilo muito inteligente
Também uma variante do mesmo código.
É o mesmo com os contras.