Erros, bugs, perguntas - página 2564

Novo comentário
 
Igor Makanu:

?

é uma situação estranha, tudo fora da classe tem estado a trabalhar há muito tempo com os staichiqs. e estou apenas a fazer um grande alarido sobre isso.... Só por diversão, reproduza você mesmo o código:

Vê uma instância de objecto? e existe em MQL ;)

SZZ: E existe a nível de ajuda ... qual é a sua carne comigo?

https://www.mql5.com/ru/docs/basis/oop/staticmembers

pr


imp

 
Andrey Barinov:

Todas as mesmas regras se aplicam à estática (privada, protegida, pública), apenas não requerem a criação de objectos.

Não em geral: por exemplo, um statik público não pode ser restringido numa classe derivada

 
Andrey Barinov:



hmmm... Como explicar o absurdo da situação... Sugeri-lhe que lesse os posts dos administradores (desenvolvedores), mostrei-lhe a ajuda que eles escreveram, o que quer de mim com as suas fotografias?

Não creio que seja por isso, leio o fórum e ajudo, e faço como recomendado pelos programadores. Se achar necessário, escreva ao "comité de protecção das normas C++", à ONU... Bem, pelo menos o administrador no PM, se não puder, mas depois tranque a mensagem dos programadores e siga o seu caminho!

ZS: Eu de alguma forma consigo inserir o código fonte e não imagens, porque não o fez?

int print(int value)
{  Print(value,":",__FUNCTION__); 
 return(value);
}
class A
{
private:
   static int        a1;
   static void       inc_a1(){a1++; Print("a1 = ", a1);}
protected:
   static int        a2;
public:
   static int        a3;

};
//+------------------------------------------------------------------+
static int A::a1 = print(1);
static int A::a2 = print(2);
static int A::a3 = print(3);

//+------------------------------------------------------------------+
void OnStart()
{

A::inc_a1();
A::inc_a1();
A::inc_a1();

}

2019.09.17 22:11:49.534 tst (EURUSD,H1) 1:imprimir

2019.09.17 22:11:49.535 tst (EURUSD,H1) 2:imprimir

2019.09.17 22:11:49.535 tst (EURUSD,H1) 3:imprimir

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 2

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 3

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 4

ZS: a situação é bastante cómica, eu queria ajudar, agora estou a arranjar desculpas.... porquê? - bem, acerta no carril para a verdade...pisar no ancinho....
 
Igor Makanu:

O único erro no código está no acesso ao método privado. Este insecto apareceu recentemente.

 

A função ChartOpen retorna sempre 0 no serviço. Embora o próprio gráfico se abra.

#property service

//int OnInit()
void OnStart()
  {
   long Otvet= ChartOpen(Symbol(),PERIOD_D1);
   Print("Otvet=",Otvet);

  // return(INIT_SUCCEEDED);
  }
 
fxsaber:

O único erro no código está no acesso ao método privado. Este insecto apareceu recentemente.

Pensei que me tinha esquecido de algo, por isso reli novamente como se comporta a estática em C#https://metanit.com/sharp/tutorial/3.6.php

Os membros da classe estática são comuns a todos os objectos da classe, pelo que se deve referir a eles pelo nome da sua classe:

Note-se que os métodos estáticos só podem referir-se a membros de classe estáticos. Não podemos abordar métodos não estáticos, campos, propriedades dentro de um método estático.


Em MQL, a estática é inicializada antes de correr OnInit() , agora vamos discutir a visibilidade global de métodos privados de estática.... este comportamento da estática em MQL - se usar estática, significa que não usamos características de protecção de dados de uma classe, imho

qual é o tamanho de um insecto? - a forma como os programadores o farão, eu disse que o comportamento nas operações de contexto é determinado pelo programador (o operador de resolução de contexto é o operador com a maior prioridade na língua! ), e o compilador irá ajudar correctamente - bem, como acontece))))

funciona assim?

class A
  {
private:
   static void              My_function()
     {
      Print("^_^");
     }
  };
  
A a;
void OnStart()
  {
   A::My_function();
   a.My_function();  // 'A::My_function' - cannot access private member function        
  }

no seu conjunto, faz o trabalho


PS: actualizado para 2145 - o código com estática comporta-se da mesma forma, se ficar assim durante meio ano, verificar-se-á que este é o comportamento planeado da estática ;)

UPD: lembre-se, como gíria para tudo isto é chamado - truques sujos! ))) - Procure muitos exemplos na web, onde este comportamento é aceite como um padrão linguístico, e onde está ligado a um compilador específico do fabricante. Em Python, eval() não será a execução de código linear efectivamente quebrada? - bem, alguns fazem e outros não, porque o comportamento é imprevisível.


UPD: verificar no 2145 a minha pergunta de há um mês atráshttps://www.mql5.com/ru/forum/320733#comment_12989063

https://www.mql5.com/ru/forum/320733#comment_12958594

void OnStart()
  {
   double x=100.0;
   f(x);
  }
//_______________________________________________________________________
void f(bool v)
  {
  }
//_______________________________________________________________________

nada mudou, em bool ao verificar os tipos o compilador não aprendeu a escrever avisos - isto é muito desagradável, estava à procura de um erro no meu código, embora estivesse certo de que o compilador MQL verifica sempre a correspondência de tipo

 
Igor Makanu:

Quanto é que é um bug? - Seja o que for que os criadores lhe dêem a volta, é assim que vai ser.

É óbvio que o bug será corrigido.

Nada mudou, o compilador não aprendeu a escrever avisos em bool quando verifica os tipos

A fundição automática de apontadores e tipos numéricos para bool é muito conveniente.

 
Igor Makanu:

nada mudou, em bool ao verificar os tipos o compilador não aprendeu a escrever avisos - isto é muito desagradável, já estava à procura de um erro no meu código, embora tivesse a certeza de que o compilador MQL monitoriza sempre rigorosamente a correspondência de tipos

Não há perda de dados durante esta fundição. Ou 0 ou não 0.

Outro caso é quando duplo -> qualquer tipo inteiro (até int32, inclusive)

 
Slava:

Com esta fundição, não há perda de dados. Ou 0 ou não 0.

Outra coisa é quando se funde duplo -> qualquer tipo inteiro (até int32, inclusive)

mas ao contrário?

Estava à procura de um bug no meu código

No início escrevi um teste, mas usei primeiro int , depois desisti de usar bool, mas não consertei o código inteiro, não me lembro, mas foi assim:

void OnStart()
{  int x=100.0;
   f(x); }
//_______________________________________________________________________
void f(int  v)  //так тестил
{
   if(v>0) v++;

}

//_______________________________________________________________________
void f(bool  v)  // потом решил, что мне нужен флаг, а ниже забыл исправить код
{
   if(v>0) v++;

}
//_______________________________________________________________________


Estou pronto para tal comportamento agora, mas porque estou a escrever sobre isso...bem, na verificação das condições do MQL em if() - será que os tipos de controlo são rigorosamente controlados? qualquer uso de operações não-booleanas emitirá um aviso? - E da mesma forma que escrevi em C# na VS2017 - o meu código de exemplo não se compila e a MQL não lança um aviso. Na minha opinião, para aqueles que são novos na programação em MQL, tal comportamento implica algumas surpresas.

 
fxsaber:

É óbvio que o bug será corrigido.

Não vou argumentar, mas a minha opinião é que não se deve confiar no controlo do compilador quando se sai da classe através da estática, bem como utilizar o operador de resolução de contexto,

ou seja, se escrever um método/campo estático ou utilizar :::: - não confie no compilador

1...255725582559256025612562256325642565256625672568256925702571...3184
Novo comentário
Razão: