Erros, bugs, perguntas - página 2532

[Georgiy Merts]

Igor Makanu:

tudo funciona, mas as arrays que serão amortecedores indicadores devem ser descritas com o público modificador

Sim, é claro.

É claro que o acesso público aos membros da classe não é bom, mas o principal problema - o acesso aos dados da matriz sem cópia é resolvido.

Obrigado, a questão está esclarecida.

[Влад]

Se a questão estiver resolvida, pode ajudar-me? Para vocês, mamutes da programação, é como uma palheta...

[Igor Makanu]

Georgiy Merts:

É claro que o acesso público aos membros da classe não é bom, mas o principal problema - o acesso aos dados da matriz sem cópia está resolvido.

Vejo muitos vídeos no YouTube, deparei-me com um canal de um programador inteligente, e lembro-me da frase: "o código deve, antes de mais nada, cumprir a sua tarefa!

Não trabalha num grande projecto, pois não? - Sabe porque é que este membro da classe é definido e pode controlar o acesso ao mesmo sem a ajuda do compilador, não sabe? ;)

[Aleksei Beliakov]

@Ilyas,construção actualizada do mt4

código que funcionou bem após erros de compilação e de execução

[Vladimir Simakov]

Igor Makanu:

Vejo muitos vídeos no YouTube, deparei-me com um canal de um bom programador, e lembro-me da frase: "o código deve, antes de mais nada, cumprir a sua tarefa!

Não trabalha num grande projecto, pois não? - Sabe porque é que este membro da classe é definido e pode controlar o acesso ao mesmo sem a ajuda do compilador, não sabe? ;)

De facto, o acesso aos membros da classe é melhor ser implementado através de métodos e ter menos desreferenciação em tempo de execução, utilizar em linha com os métodos get.

[Georgiy Merts]

Igor Makanu:

Vejo muitos vídeos no YouTube, deparei-me com um canal de um bom programador, e lembro-me da frase: "o código deve, antes de mais nada, cumprir a sua tarefa!

Não trabalha num grande projecto, pois não? - Sabe porque é que este membro da classe é definido e pode controlar o acesso ao mesmo sem a ajuda do compilador, não sabe? ;)

NÃO.

Antes de mais, o código deve ser transparente e compreensível, fácil de manter. E depois, se não cumprir a sua tarefa, será imediatamente visível.

Mas quando o código é preenchido com muitos lugares com construções potencialmente inseguras que causam erros muito subtis e não óbvios, nunca se pode ter a certeza de que "o código cumpre a sua tarefa".

E quando se trabalha num grande projecto não se pode passar sem ele, em muitas empresas existem directrizes oficiais relativas à notação, declarações, o que pode e não pode ser declarado como acções e assim por diante. Claro que, quando se trabalha sozinho, declara-se um membro da classe, sabe-se para que serve e sabe-se como se vai utilizá-lo. Excepto que qualquer código, por mais complexo que seja, mesmo quando feito por um programador, tende a mudar a arquitectura. E pessoalmente não me consigo lembrar o quê, onde, como e para quê. Ao mesmo tempo, sobrecarrego generosamente o código com comentários detalhados. E ainda assim, voltando a outros fragmentos após meio ano, passo muito tempo a compreender porque foi feito assim e não de uma forma diferente. Sem comentários não seria capaz de compreender de todo o meu próprio código.

Claro que, se tiver a memória de Peter Konov, não tem de se preocupar em partilhar o acesso, tornar todas as variáveis globais - e usar tudo o que precisa, sempre que quiser. No entanto, a minha memória é muito pior, e já posso esquecer as subtilezas de um procedimento numa semana. Por conseguinte, há muito que desenvolvi o princípio de que em qualquer lugar de código deve haver exactamente tanto quanto eu preciso aqui e não mais uma única variável. A melhor maneira é converter tudo em interfaces virtuais e dividir ao máximo as áreas de responsabilidade de cada classe (mas é claro que deve haver uma medida, de modo a não lidar mais com estes invólucros do que com códigos úteis).

Recorde-se que a falta de apontadores para os criadores justifica "cuidar dos programadores", para que não se use acidentalmente um apontador para uma matriz que já não é relevante. Bem, eles explicaram que "se escrever com aulas, já é suficientemente hábil para usar apontadores, enquanto os matrizes estão disponíveis para principiantes, e não queremos que eles tenham problemas quando querem usar apontadores para matrizes... sem indicações, é isso"...

[Georgiy Merts]

Vladimir Simakov:
Geralmente, é melhor implementar o acesso aos membros da classe através de métodos, e para evitar a desreferenciação em tempo de execução, utilizar em linha com os métodos get.

É isso mesmo. E normalmente estou inclinado a fazê-lo. Raramente uso membros da classe pública, só tenho acesso a eles com métodos em linha. Só em casos especiais, como com estas matrizes de indicadores, tenho de usar o público...

[Georgiy Merts]

Влад:
Se a questão estiver resolvida, pode ajudar-me? Para vocês, mamutes da programação, é como uma traça...

No seu caso, organize um loop while() em vez de um loop for().

Verificar se há algum sinal de fim de piscar.

Mas sobre "piscar com frequência variável" - algo estranho... Não vejo quaisquer erros na mosca, deve piscar com bastante frequência.

Embora duvide que seja sensato criar e apagar objectos gráficos em vez de os tornar invisíveis. Mas, parece que não se pode tornar um objecto invisível. Portanto, tudo o que resta é apagar.

[Igor Makanu]

Georgiy Merts:

Claro que, se tiver uma memória como a de Peter Konov, não tem de se preocupar com a separação de acesso, tornar todas as variáveis globais - e usar tudo o que precisa, sempre que quiser.

Nunca treino memória, uso variáveis globais apenas como último recurso, o código por vezes até me parece redundante, mas os fragmentos de código são portáteis para outro projecto,

Normalmente uso nomes longos de funções e variáveis, por isso posso ler o que já escrevi antes:

void CGrid::Scenario_01(int ordernumber)//------ Сценарий ReOpenBUY & ReOpenSELL
  {
   int set         = Order[ordernumber].StateOrderNumberSetting;
   double pr       = Order[ordernumber].StateOrderStartPrice;
   double vol      = Order[ordernumber].StateOrderLot;
   double volcoeff = dealssettings[set].volcoeff;
   double profit,openprice;
   Order[ordernumber].GetCloseOrderInfo(profit,openprice);
   double l=CalcLot(dealssettings[set].volratio,vol,volcoeff,profit);
   deal=new Cdeal(set,dealssettings[set].dealtype,l,pr,dealssettings[set].closepips,magic);
   Order.Delete(ordernumber); 
   Order.AddValue(deal);
  }

Outra questão é que não aderi ao estilo OOP - não embrulho tudo em classes, uso os estilos de procedimento e OOP num único programa ao mesmo tempo, é mais conveniente e mais rápido formar um programa a partir de blocos prontos, o que quer que esteja em falta adiciono ou modifico blocos prontos para a tarefa

[Alexey Navoykov]

Vladimir Simakov:
e para uma menor desreferenciação em tempo de execução, utilizar em linha com os métodos get.

Inline é, na minha opinião, uma relíquia. O compilador enuncia tudo na perfeição, pelo que não há necessidade de sobrecarregar o código. E na MQL este especificador não é nada, acrescentado apenas para fins de compatibilidade (não sei para quê, se alguém poderia declarar tal macro por si próprio).