Pergunta datilografada - página 3

Novo comentário
 
Ilya Malev:

O erro de descasamento do modelo deve provavelmente ocorrer no momento da compilação.


Mas na situação em que há um objeto de matriz

Tal erro não deve ocorrer porque no primeiro caso a chamada de Array[int] é usada como parâmetro esquerdo de operação = e não é variável de tipo duplo, enquanto no segundo caso é a direita, e o parâmetro esquerdo é variável de tipo duplo.

Você não ouve, não deve fazer nada - a sobrecarga do tipo é proibida e está explicitamente escrita no padrão C++ (e µl como C+++ similar - provavelmente também):

Certain function declarations cannot be overloaded:

- Function declarations that differ only in the return type, the exception specification (18.4), or both
cannot be overloaded.

A razão provável é explicada acima. Portanto, seu operador[] é inválido.

 
pavlick_:

Você não ouve, não deve fazer nada - a sobrecarga por tipo é proibida e está explicitamente escrita no padrão C++:

A razão provável que eu dei acima. Portanto, seus operadores[] são inválidos.

Eu não estava respondendo sobre o padrão, mas sobre a lógica baseada no senso comum. Sua definição de causa "provável" não invalida meus argumentos. A possibilidade de sobrecarregar uma operação de datilografia (inclusive implícita) não contradiz o padrão citado, pois é uma operação de sobrecarga de fundição para um tipo particular explicitamente definido a partir do contexto.

Talvez eu não tenha sido muito claro, mas este esclarecimento, espero, o torne mais claro.


P.S. É claro, meu código fictício contradiz o padrão. Mas se você precisar de decifrá-la (porque eu estava descobrindo por mim mesmo como formular a pergunta com mais precisão), ela deveria ter este aspecto:

class Array{

public:

Array *operator[] (int i){ id = i; return GetPointer( this ); }

double operator double(){ return data[i]; }

Array *operator=(double d){ data[id]=d; return GetPointer( this ); }

private:

double data[10];

int id;

};



int OnStart(){

  Array array;

  double d=123.456;

  array[5]=d;

  d=array[5];

}
 
Se você defende o tipo de operador(), tudo bem. Se você advoga a indentação a partir de prós, então eu sou contra (permitindo sobrecarga por tipo de retorno) para resolver algum problema particular (que provavelmente poderia ser resolvido de forma diferente e mais bela - de alguma forma eu nunca cheguei a ele como no primeiro posto).
 
pavlick_:
Se você defende o tipo de operador(), tudo bem. Se você advoga a indentação a partir de prós, então eu sou contra (permitindo sobrecarga por tipo de retorno) para resolver algum problema particular (que certamente pode ser resolvido de forma diferente e mais bela - de alguma forma eu nunca torci de tal forma como no primeiro posto).

Sim. No final, sou totalmente a favor da introdução do operador datilógrafo. Porque resolve exatamente o problema, o que afirmei no post inicial, apenas de uma forma mais "convencional" (se encaixa nas normas, e provavelmente mais correta em geral).

 
Ilya Malev:

P.S. É claro que meu código inventado é contra o padrão.

Por que ela contradiz o padrão, é perfeitamente válida nos prós e contras. E não há nenhuma doca em mcl.
 
pavlick_:
Por que é contraditório, em plenos termos é bastante válido. E em mql não há nenhuma doca.

Porque originalmente existiam duas funções de operador[] idênticas com tipo de retorno diferente (eu o consertei na segunda versão). Isto é proibido pela norma. Não é proibido digitar (implicitamente também), eles simplesmente ainda não tiveram tempo de implementá-lo. Tendo em conta a impressionante taxa de desenvolvimento do mql5, tenho certeza de que ele será implementado mais cedo ou mais tarde. Especialmente se outra pessoa, além de mim, prestar atenção no fórum.

 
Ilya Malev:

Porque havia duas funções de operador[] idênticas com tipo de retorno diferente. Isto é proibido pela norma. Não é proibido digitar (mesmo implicitamente), eles simplesmente ainda não tiveram tempo de implementá-lo. Levando em conta a grande velocidade de desenvolvimento do mql5 tenho certeza de que ele será implementado mais cedo ou mais tarde. Especialmente se outra pessoa além de mim prestar atenção no fórum.

Refiro-me ao último código - está tudo bem.

 
pavlick_:

Refiro-me ao último código - tudo bem.

Está tudo bem, mas ainda não funciona em mql5. Vamos seguir e esperar por inovações em mql5. É esta incapacidade de implementar adequadamente um objeto de array, devido à incapacidade de lidar com um tipo de usuário da mesma forma que com um array comum, que tem me incomodado pessoalmente por muito tempo. Quando você faz sua própria matriz, ela se revela defeituosa desde o início, não possuindo as mesmas propriedades de usabilidade que as incorporadas.

 
Ilya Malev:

Está tudo bem, mas ainda não funciona em mql5. Vamos seguir e esperar por inovações em mql5. É esta incapacidade de implementar adequadamente um objeto de array, devido à incapacidade de lidar com um tipo de usuário da mesma forma que com um array comum, que tem me incomodado pessoalmente por muito tempo. Quando você faz sua própria matriz, ela se revela inicialmente defeituosa, não tendo a mesma usabilidade que uma matriz incorporada.

Bem, não estou esperando grandes milagres, a linguagem não está mais sendo desenvolvida, duvido que eles adicionem um operador fantasma. Aqui eu sou especificamente destacado pela incapacidade de fazê-lo dessa forma:

class Q {};

Q q;
// что то делаем и решаем переинициализировать q
q = Q();  // ошибка, нужно извратиться:

Q temp;
q = temp;

mas é inútil dizer, eu acho que é inútil.

 
pavlick_:

Bem, não estou esperando grandes milagres, a linguagem não está mais desenvolvida, duvido que eles adicionem um operador fantasma. O que me incomoda em particular é a incapacidade de fazer isso dessa forma:

Mas é inútil falar sobre isso, eu acho.

Não está muito claro qual é o problema. A inicialização do objeto não poderia ser implementada em um método separado como o Init(), talvez até mesmo em um método virtual?

12345678910
Novo comentário