Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Como é que devolvo uma referência em parâmetros de função?
Este tipo de código causa problemas:
CMy* obj; // global bool func(CMy* obj) { ... obj = new CMy(); ... }
Acesso aoponteiro inválido quando se tenta trabalhar com obj.
Tentei adicionar um &.
Funciona. Não encontrei o retorno de referência nos parâmetros de função na documentação.
Por analogia, encontrei este tópico em C++: http://stackoverflow.com/questions/5286453/returning-a-pointer-as-a-function-parameter
Mas ** não funciona aqui. *& em vez disso?
5.00.630 x64
Não consegui encontrar um retorno de referência nos parâmetros da função na documentação.
Como é que devolvo uma referência em parâmetros de função?
Este tipo de código causa problemas:
Acesso ao ponteiro inválido quando se tenta trabalhar com obj.
Tentei adicionar um &.
Funciona. Não encontrei o retorno de referência nos parâmetros de função na documentação.
Por analogia, encontrei este tópico em C++: http://stackoverflow.com/questions/5286453/returning-a-pointer-as-a-function-parameter
Mas o seu ** não funciona. *& em vez disso?
5.00.630 x64
IMHO (foi há muito tempo).
Não se pode passar um ponteiro através de argumentos, mas sim criar uma referência. Não se pode ligar uma nova instância de uma classe a uma referência. Isso deixa o seguinte caminho:
Sou um proponente do OOP, porque compreendi a conveniência de programar de baixo para cima. Desde interfaces de interacção de objectos até à implementação de classes.
IMHO (foi há muito tempo).
Não se pode passar um ponteiro através de argumentos, pode-se criar uma referência. Não se pode vincular uma nova instância da classe a uma referência. Isso deixa-nos com esta opção:
Defini a questão de forma incorrecta.
Passar um ponteiro por referência. Será que se pode usar a variante *& e não a cobrirão em outras versões? Em C++, uma tal construção parece ser legal.
Está a referir-se a ele: Guia de referência MQL5 / Noções básicas de linguagem / Tipos de dados / Referências. Modificador & e palavra-chave isto?
Quem me dera que houvesse a informação certa...
No artigo
https://www.mql5.com/ru/docs/basis/function/ParameterPass
pode também acrescentar informações sobre como trabalhar com objectos.
Não é uma interface externa à classe?
Que diferença faz para os objectos? Uma interface nesta interpretação é um tipo de dados, porque a sua descrição define de forma suficientemente clara as propriedades dos objectos. E, de facto, define o comportamento externo dos objectos.
Nos materiais que citei, os adversários do OOP mencionaram que é impossível criar imediatamente a estrutura de classes sem implementar o algoritmo, razão pela qual o ambiente OOP praticou tão frequentemente a refactoring e porque é que as classes dificultam o desenvolvimento com o seu eterno redesenho. E isto é realmente verdade. Quando se implementa algo novo e não se compreende a que pode levar, é preciso refazer as aulas e mais do que uma vez.
Criar uma boa arquitectura de classe é um obstáculo para os principiantes. Em essência, o objectivo da programação OOP é escrever a sua própria"linguagem", uma linguagem que seja fácil e rápida de criar no futuro. A interface é a essência de uma linguagem que foi concebida para a tarefa. A interface, de facto, não deve ser entendida como uma construção "do tipo" da classe, como um contrato para a classe, que deve ser executado em código (em MQL, não existe e o papel da interface pode ser fracamente executado por métodos virtuais).
Por exemplo, pode criar uma "linguagem" para a criação de novos EAs que lhe permita montar o esquema geral de EAs a partir de objectos em poucas linhas. Os sinais e condições podem ser usados já prontos, ou pode desenvolver as suas próprias classes de sinais e criar a sua própria biblioteca por analogia. Esta possibilidade é fornecida pelo MQL5 Wizard.
Muitas vezes, o esquema da aplicação já foi desenvolvido e a "programação OOP" resume-se essencialmente à utilização de classes existentes com graus de liberdade limitados para escrever a sua própria funcionalidade - isto é conveniente. É por esta razão que as estruturas são tão populares. De facto, escrever algo próprio é criar uma classe herdeira de uma das classes de enquadramento, e escrever a implementação de certos métodos backend na mesma, que já estão incorporados na lógica global de aplicação (OnInit, OnTick, por exemplo).
...
Criar uma arquitectura de classe competente é um obstáculo para os principiantes. Em essência, o significado da programação OOP é escrever a sua própria"linguagem", uma linguagem sobre a qual é conveniente e rápida de criar mais tarde. A interface é a essência de uma linguagem que foi concebida para a tarefa. Interface não deve ser entendida como uma construção de "tipo" da classe, como um contrato para a classe, que deve ser executado em código (em MQL, não existe, e o papel da interface pode ser validado por métodos virtuais).
...
O objectivo do OOP é antes o de escrever a sua própria arquitectura. Assim que tivermos uma arquitectura clara, concisa e intuitiva, tudo se encaixa e nem a complexidade do projecto nem o seu alcance são mais factores limitativos. No entanto, para conseguir esta arquitectura muito clara, é necessário reescrever as aulas uma a uma, aproximando-nos mais deste ideal inicialmente vago.