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

Novo comentário
 
Igor Makanu:

Atualmente, eu gostaria de anexar o formulário VS ao .dll ao MT5 de uma maneira simples )))) - Eu quero envolver os manipuladores de botões em uma classe e chamá-los atravessando uma matriz de funções de manipuladores, e quero ter no código EA principal a possibilidade de escrever os mesmos nomes de funções que em VS, ou seja, button2_Click() ....button2_Click()

SZY: Este é um problema daEOP))))

Sem ofensa, mas isso me faz lembrar muito:


1
 
Ilya Malev:

- Criar estruturas automáticas dentro de um OOP dinâmico é um absurdo

Então, empilhar objetos: obj de minha classe; é um absurdo? Então eu sou um deficiente :)

 
pavlick_:

Então, empilhar objetos: obj de minha classe; é um absurdo? Então, eu sou um artesão :)

Existem todos os tipos de tarefas. Você pode praticar retórica por muito tempo, se você não descrever tarefas específicas, você pode inventar qualquer coisa...

Sim, os objetos "empilháveis" (automático, você quer dizer?) são basicamente um disparate. Na minha humilde opinião, que não é de forma alguma a verdade e certamente não em última instância...
 
Um curinga precisa de um objeto que não desempenhe a função principal do OOP - a propriedade do polimorfismo? Você não atribuirá nenhum objeto com propriedades diferentes dependendo do conteúdo a tal variável. Você não será capaz de mapear outro objeto para esta "variável" na lista. Por que você precisa de objetos? Não é melhor usar estruturas em vez disso? Talvez porque as estruturas µl não possam retornar referências a si mesmas. E com eles começa uma coisa escura com constante criação-destruição- auto-cópia etc.
 
Ilya Malev:
Você quer um objeto que não cumpre a função principal do OOP - a propriedade do polimorfismo? Você não atribuirá nenhum objeto com propriedades diferentes dependendo do conteúdo a tal variável. Você não será capaz de mapear outro objeto para esta "variável" na lista. Por que você precisa de objetos? Não é melhor usar estruturas em vez disso? Talvez porque as estruturas µl não possam retornar referências a si mesmas. E com eles começa uma coisa escura com constante criação-destruição- auto-cópia etc.

Como viver sem polimorfismo ... E se eu lhe dissesse que podemos fazer sem polimorfismo em >90% dos casos? Tomemos o "princípio da inversão de dependência SÓLIDO", se formos progers decentes, devemos criar abstrações, métodos virtuais em todos os lugares (o que implica em altas despesas gerais, é claro). Os adeptos do C# escreveriam algo como isto https://pro-prof.com/forums/topic/dependency-inversion-principle. Ou poderíamos pegar os modelos e escrever algo como:

class Lamp {
public:
    void activate();
    void deactivate();
};
template <typename T>
class Button {
    Button(T& switchable)
        : _switchable(&switchable) {
    }
    void toggle() {
        if (_buttonIsInOnPosition) {
            _switchable->deactivate();
            _buttonIsInOnPosition = false;
        } else {
            _switchable->activate();
            _buttonIsInOnPosition = true;
        }     
    }
private:
   bool _buttonIsInOnPosition{false};
   T* _switchable; 
}
int main() {
   Lamp l;
   Button<Lamp> b(l)

   b.toggle();
}


O botão também é independente de detalhes, sem todo o polimorfismo e interfaces. O polimorfismo tem seu próprio nicho, mas é muito mais estreito do que dizem.

ZS: bem, ninguém o proíbe:

derived1 obj1;
baseclass *p1 = &obj1;
derived2 obj2;
baseclass *p2 = &obj2;
pass_through_generalized_algoritm(p1);
pass_through_generalized_algoritm(p2);
 
É claro que podemos prescindir do polimorfismo, mas para este caso é muito mais honesto e lógico usar estruturas simples em vez de objetos, caso contrário, estaremos pregando com um microscópio. Para ser mais preciso, no caso do µl5, preferimos contornar "características de implementação" que não permitem utilizar plenamente estruturas não-objetos (impossibilidade de passar ponteiros para elas, ao contrário dos objetos). Este é um problema completamente diferente, não é mais OOP, mas apenas OO
 
pavlick_:

ZS: bem, ninguém o proíbe:

Ninguém proíbe todo tipo de muletas e esquemas, mas por quê? Por exemplo: será divertido quando seu auto-objeto de repente se autodestrói quando você menos espera, não é mesmo?

 
O objetivo do OOP não é usar seu método escolhido de pressionar o botão, que você também pode implementar através de modelos ou indicadores de função, mas apenas aplicar a qualquer objeto do sistema métodos como lista, que permitem auto-organizar em estruturas de lista e criar seleções arbitrárias no momento certo, sem nenhuma muleta como CArrayObj, etc. e os métodos de sobrecarga associados, como Select, Query, Compare, Sort, etc. (e até mesmo Clone/Cópia, quando cada objeto pode decidir sem sua participação se deve ser copiado para uma lista/arranjo ou não, e se copiado, como deve ser copiado).
 
Ilya Malev:

Ninguém proíbe a confecção de muletas e esquemas, mas por quê? Por exemplo: será engraçado quando seu auto-objeto de repente se autodestrói quando você menos espera, não é mesmo?

Porque um objeto de pilha é muito mais rápido que um objeto em uma pilha(alocação de memória). Autodestruição? - Isso é algo novo :). Mas às vezes é necessário, é claro - o número de objetos é conhecido apenas em tempo de execução, por exemplo.

ZS: você pode ficar mais à vontade caso contrário, é um assunto pessoal.

 
Ilya Malev:
O objetivo do OOP não é usar seu método escolhido de pressionar o botão, que você também pode implementar através de modelos ou indicadores de função, mas apenas aplicar a qualquer objeto do sistema métodos como lista, que permitem auto-organizar em estruturas de lista e criar seleções arbitrárias no momento certo, sem nenhuma muleta como CArrayObj, etc. e os métodos de sobrecarga associados, como Select, Query, Compare, Sort, etc. (e até mesmo Clone/Cópia, quando cada objeto pode decidir sem sua participação se deve ou não copiá-lo para uma lista/arranjo, e se deve copiá-lo, como).

Eu escrevi - o polimorfismo tem seu próprio nicho, não estou discutindo. Mas a prática mostra (minha pessoalmente, pelo menos) que não é tão significativa. Tenho muito mais probabilidade de resolver problemas com os modelos.

1...11121314151617181920
Novo comentário
Razão: