Perguntas de Iniciantes MQL5 MT5 MetaTrader 5 - página 192

Novo comentário
 

Comecei a aprender OOP e não consigo ultrapassar o seguinte obstáculo. O seguinte guião é um exemplo:

CSum result;
void OnStart()
  {
//---
  }
//+----------------------------------------+
class CSum
  {
public:
   int               Calculate(int A,int B);
  };
//---
int CSum::Calculate(int A,int B)
  {
   return(A+B);
  }

Sem a linha "CSum result;", o compilador não gerará um erro. Mas causa um erro:

Por favor, diga-me o que está errado. Pareço ter declarado correctamente o objecto de classe.

 
paladin800:

Comecei a aprender OOP e não consigo ultrapassar o seguinte obstáculo. O seguinte guião é um exemplo:

Sem a linha "CSum result;", o compilador não gerará um erro. Mas causa um erro:

Diga-me o que está errado. Pareço ter declarado correctamente o objecto de classe.

Uma variável do tipo CSum (resultado) é declarada antes de ser feita a descrição CSum, o que significa que o compilador ainda não conhece este tipo. Insira o CSum logo no início do ficheiro.
 
Lone_Irbis:
Além disso, quanto pode/deveria ser explorado o sistema global de variáveis? É possível sobrecarregar algo desta forma, ou existe um limite? Por exemplo, digamos duas ou mais centenas de variáveis (das quais cerca de metade se transformam em input e de volta, dependendo de que peça de código requer testes) e cerca de uma dúzia e meia de pequenas arrays a nível global - é muito ou pouco? ^^' E se houver duas ou três vezes mais enquanto se afina o sistema? E se não tivermos de nos entusiasmar tanto, existe alguma forma mais simples de lidar com o intercâmbio de dados entre uma dúzia de subsistemas diferentes, muitos dos quais exigem os resultados uns dos outros?
Não, não há. As variáveis globais são utilizadas para outros fins. Utilizar classes para descrever subsistemas. E é melhor evitar usar arrays e variáveis globais no seu conjunto.
 
C-4:
Uma variável do tipo CSum (resultado) - é declarada antes de ser feita a descrição CSum, o que significa que o compilador ainda não conhece este tipo. Insira o CSum logo no início do ficheiro.
Oops, funcionou. Coloco a classe no fim do código por analogia com a colocação de funções. Não esperava que, para uma turma, uma tal encomenda fizesse a diferença.
 
paladin800:
Oops, funcionou. Coloco a classe no final do código, semelhante à colocação de funções. Não esperava que uma tal encomenda fizesse a diferença para a classe.
Sim, infelizmente, a ordem de precedência é importante. O caso mais difícil é quando duas classes utilizam uma à outra simultaneamente. Qualquer que seja a classe que introduzimos em primeiro lugar, a segunda classe será desconhecida para o compilador e gerará um erro. Neste caso, não se pode prescindir da declaração de classe. No seu caso, é melhor separar o CSum num ficheiro separado, por exemplo Sum.mqh e incluí-lo usando o ditado #include "Sum.mqh".
 
C-4:
Não, não deve. As variáveis globais são utilizadas para outros fins. Utilizar classes para descrever subsistemas. E é melhor não usar arrays e variáveis globais de todo.
Claro que compreendo que é uma boa ideia utilizar as aulas, mas continuo a ser um pouco preguiçoso, considerando que é mais familiar sem elas, e elas parecem funcionar em qualquer caso. Mas estou apenas curioso, qual é a sua vantagem? Desde que se saiba com certeza que o código é escrito por um autor exclusivamente para si próprio e nunca será útil fora de um programa em particular? Sempre pareceu que as aulas só fazem sentido se estiver a escrever para alguém/alguém/vendido, enquanto que para si próprio como passatempo não fará muita diferença. Para além da estética e "mais ou menos" geral, existe algum sentido prático para se envolver em todas estas classes-estruturas? Velocidade? Algo mais?
 
Lone_Irbis:
Claro que compreendo que seria bom lidar com aulas, mas ainda assim sou demasiado preguiçoso, considerando que é mais familiar sem elas, e elas parecem funcionar de qualquer forma. Mas estou apenas curioso, qual é a sua vantagem? Desde que se saiba com certeza que o código é escrito por um autor exclusivamente para si próprio e nunca será útil fora de um programa em particular? Sempre pareceu que as aulas só fazem sentido se estiver a escrever para alguém/alguma coisa/vender, enquanto para si próprio como passatempo não fará muita diferença. Para além da estética e "mais ou menos" geral, há algum sentido prático para se envolver em todas estas classes-estruturas? Velocidade? Algo mais?

Pelo contrário. Quando se escreve um projecto personalizado, o cliente exige frequentemente o código fonte. E depois tem de retirar funções das classes e inseri-las no código fonte. É melhor dar ao cliente um ficheiro em vez de arrastar uma montanha das suas bibliotecas, que contêm um grande número de funções, que não são utilizadas no trabalho passado para o cliente. Ou seja, é melhor utilizar uma programação estruturada a pedido.

Para as suas próprias necessidades, é melhor usar o OOP - aí tudo é auto-suficiente e não tem de se preocupar em passar o código fonte.

 
artmedia70:

Pelo contrário. Quando se escreve um projecto personalizado, o cliente necessita frequentemente do código fonte. E depois tem de retirar funções das classes e inseri-las no código fonte. É melhor dar ao cliente um ficheiro em vez de arrastar uma montanha das suas bibliotecas, que contêm um grande número de funções, que não são utilizadas no trabalho passado para o cliente. Ou seja, é melhor utilizar uma programação estruturada para um cliente.

É melhor usar o OOP para as suas próprias necessidades - todo o seu material está lá, e não tem de se preocupar com a transferência do código fonte.

Hmmm... Bem, talvez assim :) Isto é, claro, o princípio parece tentador. em teoria. Especialmente tendo em conta que não posso fazer um único ficheiro sem quaisquer estruturas ou classes. A questão é que escrevo principalmente por interesse, testando as minhas próprias teorias aleatórias e inventando bicicletas sem fim. Em paralelo, estudo apenas o que começa a ser necessário para implementar a ideia. Tudo isto está a acontecer no âmbito de uma única aprendizagem e experiência de Expert Advisor - inicialmente um simples martin, mas agora é mais um escalper multifuncional no rebento (e já teoricamente lucrativo). Assim, a dada altura, o robô tornou-se trivialmente demasiado grande. >.> Quando a maior parte do tempo foi gasto apenas a rolar a roda do rato em busca do pedaço de código certo, tive a ideia "genial" de o transformar em ficheiros separados (13 partes conectáveis de momento), apenas agrupando funções pelo seu conceito geral. Como o analisador de notícias aqui, o processamento de níveis ali, outro com controladores de alce, estatísticas separadamente, etc. Mas nessa altura o meu entusiasmo para lidar com o OOP não era suficiente.

Então o meu problema parece ser que estou apenas a agarrar cada ideia que me ocorre e a completá-la em cima de um robô existente num robô bastante... sequência caótica. O resultado é bastante bizarro, com todos os tipos de interruptores e combinações de modos, muitos dos quais são deixados por fazer. O quadro completo é complementado por cento e cinquenta variáveis globais, que têm de ser removidas dos inputs, só para não demorar tanto tempo, sendo impressas no visualizador do testador no início. Mais, é claro, montanhas de lixo e rudimentos de ideias abandonadas ou redesenhadas.

E parece ser uma boa altura para classificar todo este monte de lixo e colocar tudo nas aulas (e primeiro ler pelo menos um artigo sobre o OOP sem adormecer no processo)... Mas estou confuso com a quantidade de trabalho a ser feito e, ahem, a sua relação com o sentido potencial de tudo isto. Isto para concluir tudo nas aulas - parece não ser uma tarefa tão volumétrica... Mas faria sentido, por exemplo, despejar tudo numa fila em público, ignorando todas estas coisas privadas/protegidas? Como é isso melhor do que ter uma pasta com um monte de .mph's e uma dúzia de funções comuns cada uma, se de qualquer forma acabam todas num só robô?

 
Lone_Irbis:

Aconselho-o a fazer um único modelo, que já tem todos os passos necessários para a inicialização, ligação, recolha de dados sempre necessários, etc...

Veio-me à mente uma ideia inesperada - carregar um modelo, renomeá-lo e escrever nele apenas o que é relevante para essa ideia em particular. E as funções que utiliza sempre, em qualquer código, devolvendo os mesmos dados em qualquer situação - coloque-as em classes. E tudo se encaixará de imediato. Também se podem estruturar directórios. Em {\i1}peritos\i1}criar (tenho assim) uma pasta chamada Encomendas, onde também coloco todos os ficheiros pertencentes a diferentes clientes em pastas separadas, tenho uma pasta chamada Ideias, Testes, etc.

Desta forma, é possível manter as coisas em ordem.

 
Infelizmente, mesmo aprendendo formalmente o OOP, não será capaz de construir um programa OOP. Pelo contrário, é preciso entrar na filosofia desta abordagem, e este é o nível seguinte após a obtenção do conhecimento formal. Afinal de contas, precisa mesmo dele? Mas, se fizer perguntas sobre como fazê-lo melhor, significa que sente que a forma escolhida não é a melhor. Em qualquer caso, a escolha é sua.
1...185186187188189190191192193194195196197198199...1503
Novo comentário
Razão: