OOP, modelos e macros em mql5, sutilezas e usos - página 9

Novo comentário
 
Ilya Malev:

Eu tenho "transbordamento de pilha" )

Acho que afinal é uma barata...

Bem, não é o compilador, mas em tempo de execução. O compilador deve reagir.

Eis o que eu tentei no VS 2010:

class A
 {
  public:
   virtual int f2() = 0;
 };

class B : public A
{
 public:
  virtual int f2() { return A::f2(); }
};

B b;

Eu recebo um erro de compilação: Erro 1 erro LNK2001: símbolo externo não resolvido "public: virtual __thiscall A::f2(void)".

Mas o Metaeditor não dirá uma palavra. Não é bom.

 
Acontece que chamar uma função de antepassado com = 0 transforma-se em chamar a si mesmo. Se você mesmo apanhar este erro, talvez possa se beneficiar dele...
 
Alexey Navoykov:

É assim que o compilador deve reagir.

Eu tentei isso na VS 2010:

Eu recebo um erro de compilação: Erro 1 erro LNK2001: símbolo externo não resolvido "public: virtual __thiscall A::f2(void)".

O Metaeditor não dirá uma palavra. Não é bom.

Alexey, por favor me explique, por que se o mql é uma cópia do C, ele deve necessariamente ser absolutamente idêntico e um passo para a esquerda, um passo para a direita - pelotão de fuzilamento?

Só porque os desenvolvedores foram descuidados? Mas qualquer idioma é construído sobre laços e condições. Todo o resto está no trailer. Por que ninguém exige que qualquer outro idioma seja semelhante ao C na parte OOP ou de qualquer outra forma?

 
Alexey Viktorov:

Alexey, você pode me explicar por que se o mql é como o C, então deve ser absolutamente idêntico e um passo para a esquerda, um passo para a direita - pelotão de fuzilamento?

Só porque os desenvolvedores foram descuidados? Mas qualquer idioma é construído sobre laços e condições. Todo o resto está no trailer. Por que ninguém exige que qualquer outro idioma seja semelhante ao C na parte OOP ou de qualquer outra forma?

Não se trata de ser completamente idêntico. Trata-se de funcionalidade que é implementada deve funcionar corretamente e de forma consistente. Mas primeiro você grita: mostre-me outra linguagem que funcione de forma diferente. E então quando C++, que funciona de maneira diferente (corretamente), é dado como exemplo, você começa uma velha reclamação sobre como MQL não é C++ e não deve ser idêntico. Você deve se decidir
 
Alexey Viktorov:

Você pode nos mostrar um exemplo quando tudo isso pode facilitar a escrita do código, encurtá-lo ou pelo menos protegê-lo de erros? E, por favor, não funções abstratas, mas funções próximas às condições reais de comercialização em um Expert Advisor ou indicador.

De jeito nenhum. Os caras estão apenas tentando colocar suas fantasias em realidade.

 
Dmitry Fedoseev:

De jeito nenhum. Os caras estão apenas tentando esticar suas fantasias para a realidade.

Parece-me um exercício muito útil - esticar a fantasia para a realidade. Esse é o ponto de desenvolvimento!
Discussão muito esclarecedora. (risos): Obrigado.
 
Alexey Navoykov:

Sim, mas há muito tempo venho utilizando uma opção alternativa: todas as interfaces são originalmente projetadas como uma classe de modelo intermediário:

Desta forma, você pode criar uma cadeia de herança que consiste em qualquer número de tais interfaces. Sim, é claro que não se pode fazer dynamic_cast com eles, mas não é tão freqüentemente necessário. A tarefa principal é passá-los para funções.

Eu li com atenção, é um movimento interessante, a propósito. Eu não tinha pensado nisso antes =) Eu também experimentarei, quando quiser...

 
Nikolai Semko:
Quanto a mim, um exercício muito útil - para esticar a fantasia sobre a realidade. Esse é o ponto de desenvolvimento!
Uma discussão muito esclarecedora. Obrigado.

E o mais importante - frutífero! Os desenvolvedores nos ouviram e decidiram consertar este bug que todos vêm tropeçando há anos.

Mas a atitude destrutiva de alguns usuários do fórum é certamente surpreendente - eles não se desenvolvem e tentam dificultar outros com notável persistência.

 

>> Sim, é claro que você não pode fazer dynamic_cast com eles, mas não é uma necessidade tão freqüente.

Por que você não o faz, sem problemas ) Mas então seu principal pesadelo aparece - a não detecção de erros de fundição na fase de compilação :)

 
Ilya Malev:

>> Sim, é claro que você não pode fazer dynamic_cast com eles, mas não é uma necessidade tão freqüente.

Por que você não o faz, sem problemas ) Mas então seu principal pesadelo aparece - a não detecção de erros de fundição na fase de compilação :)

E não faz sentido em geral, de qualquer forma, porque a cadeia sucessória poderia ser do jeito que você quisesse: quer fosse Interface<CBase> ou Interface<C<B<CBase>>>>, temos inúmeras variantes. Teremos que lançar CBase de forma consistente a todas as variantes possíveis, o que é irrealista.

Lembro-me de planejar implementar o armazenamento de informações sobre interfaces no próprio objeto de classe e, além dos blocos de interface existentes, fazer classes de interface independentes, que funcionariam como um invólucro sobre nosso bloco. Mas então cheguei à conclusão de que tudo isso era desnecessário e desnecessário. Na prática, eu nunca vi a necessidade de lançar uma classe base para qualquer interface, simplesmente não faz sentido. A única opção é descobrir se a classe suporta esta interface para fins de depuração, mas não precisamos de fundição para isso.

12345678910111213141516...28
Novo comentário
Razão: