A diferença entre externo e de entrada - página 5

Novo comentário
 
Alexey Navoykov:

Imagine que estas inicializações são feitas em diferentes arquivos. Então o resultado final dependerá da ordem na qual esses arquivos forem incluídos.

Bem - até mesmo insetos tão óbvios com estes externs

Portanto, escrevo que não faz sentido neles, são apenas para compatibilidade com o código antigo - substituir externamente por input e corrigir erros... propósito pouco claro.... o exterior não tem sentido - procure-o

 
Alexey Navoykov:

Infelizmente, a implementação de variáveis externas na MQL5 ainda não foi finalizada, e é por isso que eu não recomendo usá-la - pode causar problemas. Refiro-me à falta de controle sobre a inicialização obrigatória dessas variáveis uma única vez .

Por exemplo, você pode escrevê-lo de tal forma:

e não haverá erro. Imagine que estas inicializações sejam realizadas em diferentes plugins. Então o resultado final dependerá da ordem na qual esses arquivos forem incluídos.

Ou podemos escrevê-lo desta forma (arquivo executável):

aqui não inicializamos a variável externa, mas também não há nenhum erro.

Assim, não há controle sobre se as mesmas variáveis estão definidas em outros arquivos ou não. Você pode acidentalmente mudar seu nome, mas o programa se compilará como se nada tivesse acontecido, embora em outros arquivos tenhamos uma variável com um nome diferente.

No total, não cabe em lugar algum. É por isso que é melhor usar funções em vez de variáveis externas. É garantido que elas têm apenas uma definição, nem mais nem menos.

Com esta abordagem, você não deve usar um computador de forma alguma. Porque se você fechar os olhos e cutucar o teclado, você vai ter um disparate.

O verdadeiro problema no exterior ocorre quando se tenta fazer exterior a partir da entrada. Não me lembro dos detalhes, isso aconteceu há muito tempo. Como resultado, recusei de forma alguma o exterior, declarei uma variável simples no arquivo include e defini seu valor no inite EA através de uma chamada de função.

 
Igor Makanu:

lá você vai você - mesmo os bugs tão óbvios com estes externs

É por isso que estou escrevendo que não tem sentido neles, eles são apenas para compatibilidade com códigos antigos - substituir externos por entrada e corrigir erros... caso contrário a ajuda diz... propósito pouco claro.... exterior não faz sentido - não importa o quanto você olhe.

Há um sentido. No MT5 nos arquivos incluídos, o exterior não é de forma alguma introduzido.

 
Dmitry Fedoseev:

Faz sentido. No MT5, a entrada externa não é de modo algum uma entrada.

Por que você acrescentaria externs para incluir arquivos?

Não sei o que está acontecendo no mundo moderno da escrita de programas, mas aprendi a escrever em estilo procedural, e então comecei a usar o OOP. O primeiro e o segundo estilos implicam que cada unidade lógica deve ser totalmente funcional quando transferida para outro programa, ou seja, uma função é escrita - sua descrição (cabeçalho) contém todos os parâmetros que usa - não precisa de iprouts - você corta e cola esta função em outro arquivo, ela "moveu" como está - a mesma coisa com as classes.

E os próprios iprouts só devem criar a interface do usuário, devem ser sempre descritos no arquivo principal.


E usando externamente no arquivo include, imho maneira de ficar difícil de rastrear o bug,@Alexey Navoykov acima mostrou como isso acontece, infelizmente mais da metade dos nomes das variáveis todos os programadores têm a uma letra o mesmo nome, a diferença máxima no uso de letras maiúsculas/pequenas, como um exemplo MagicNumber ou Magic - se você olhar KB, então todas as outras variáveis, então em seu método é uma ameaça à "sombra" externa em sua variável, felizmente poucas pessoas agora usam ecterps

 
Igor Makanu:

por que adicionar iprtu's em incluir arquivos?

Não sei o que está acontecendo no mundo moderno de escrever programas, mas aprendi a escrever em estilo procedural, depois comecei a usar o OOP, tanto no primeiro quanto no segundo estilo está implícito que cada unidade lógica deve ser totalmente funcional quando transferida para outro programa, ou seja, você escreveu uma função - em sua descrição (no título) tem todos os parâmetros que usa - não precisa de iprouts - cortou esta função e inseriu em outro arquivo, "moveu" como está - o mesmo com as classes.

E os próprios iprouts só devem criar a interface do usuário, devem ser sempre descritos no arquivo principal.

Não é assim. Inclua arquivos de externs. Para que em incluir arquivos você possa usar as entradas declaradas no arquivo principal.

A propósito, é quase sempre necessário assim que você começa a usar arquivos incluídos.

 
Dmitry Fedoseev:

Não é assim. Adicionar externs para incluir arquivos. De modo que no arquivo de inclusão você possa utilizar as entradas declaradas no arquivo principal.

A propósito, isto é o que você precisa quase tão logo você começa a usar incluir arquivos.

dar um exemplo de porque o exterior deve ser utilizado

 
Igor Makanu:

dar um exemplo da adequação do uso de

Já existe há algum tempo.

 
Dmitry Fedoseev:

Você não deve usar um computador se adotar esta abordagem. Porque se você fechar os olhos e cutucar o teclado, você fica com porcaria.

É claro que vamos receber o lixo, mas ele dificilmente será compilado. A tarefa do compilador não é compilar lixo. E, neste caso, não o faz.
 
Dmitry Fedoseev:

Já está aqui há algum tempo.

É disso que estou falando.

Seu exemplo é a geração de bugs escondidos, nome variável x é freqüentemente usado.... escrito acima

Imho é suposto que seja assim:

extern int x;

int z()
  {
   static int x;
   x=122;
   return x;
  }
 
Igor Makanu:

É disso que estou falando.

Seu exemplo é a desova de insetos escondidos, o nome da variável x é freqüentemente usado.... escrito acima

Imho é suposto que seja assim:

De jeito nenhum. A variável x não deve estar disponível apenas em uma função, mas em todas as funções. E ainda mais - deve estar disponível no arquivo principal, bem como em todos os arquivos conectados.

1234567
Novo comentário