Declarando variáveis atrás do laço ou dentro do laço? - página 9

Novo comentário
 
Vict:

Eu não entendo, não é mesmo?

Duvido que você não soubesse.

É compreensível.

Eu gostaria de algo assim:

.......
int tipa_var;
// бла-бла-бла
..................
// кирдык, дальше она не нужна
удаляю tipa_var
 
Сергей Таболин:

Isso é compreensível.

Eu gostaria de algo como:

Bem, coloque os blocos, é o que eu sempre faço.

int long_lining_var;
/*block*/ {
        int tipa_var;
        ...
} // кирдык, дальше она не нужна

Ou dois parênteses são demasiados )?

 
Vict:

Bem e organizar os blocos, isso é o que eu sempre faço.

Ou dois parênteses são demasiados )?

Não é só muita coisa... É como o Everest na sua cabeça... )))))))))

É isso que a velhice significa - sempre pensei que "dois parênteses" deveriam abrir-se com algo.

E que eles podem simplesmente "localizar" algum código - não tenho certeza....

Viva e aprenda! Louvor ... eu )))) - Fico sempre feliz em saber o que eu não sabia.

E obrigado! )))))))))

 
Igor Makanu:

1953-2008 pai

sogro 1953-2019

Meus pêsames e condolências. Sou um ano mais novo, ou até menos. Portanto, não preciso mais encher meu vocabulário.

 
Alexey Viktorov:

Meus pêsames e condolências. Sou um ano mais novo, ou até menos. Portanto, não preciso mais encher meu vocabulário.

OK

não se trata de vocabulário, trata-se de entender que você foi introduzido à computação há mais de 30 anos e havia linguagens de programação simples, Pascal, Basic, Fortran, Assembler e...

mas o fato de agora você usar Windows - clique no mouse - obter o resultado ou android/appletophone..... é o mérito dos programadores que não estão sentados em velhas linguagens eficientes, mas estão escrevendo muitas e muitas soluções de software, graças ao OOP e a outros paradigmas de programação

Novos estilos de programação aumentam a velocidade do desenvolvimento de software, e isto é mais importante que o desempenho, porque não é um fato que o novo software será procurado pelo mercado (usuários), e o tempo está correndo? - Quais das empresas que desenvolvem software estão prontas para desenvolver uma única solução de software para toda a história da empresa? - Se o mercado (usuários) aceitam a idéia de um novo software - então, e somente então, faz sentido lutar pelo desempenho do software, mesmo que você o reescreva em Assembler!

Desenvolvedores de compiladores, RAD, frameworks e outras ferramentas também ajustam seus produtos às tecnologias em demanda, ou seja, no final pensando que o OOP é algo terrivelmente lento ou usando funções auxiliares curtas não é uma solução eficaz.... , e se eu escrever um "pedaço de código linear" - será eficaz, mas não de fato, e muito provavelmente será o oposto

tal história ;)

 
Igor Makanu:

OK

não se trata de vocabulário, trata-se de entender que você foi introduzido à computação há mais de 30 anos e havia linguagens de programação simples, Pascal, Basic, Fortran, Assembler e...

mas o fato de agora você usar Windows - clique no mouse - obter o resultado ou android/appletophone..... é o mérito dos programadores que não estão sentados em velhas linguagens eficientes, mas estão escrevendo muitas e muitas soluções de software, graças ao OOP e a outros paradigmas de programação

Novos estilos de programação aumentam a velocidade do desenvolvimento de software, e isto é mais importante que o desempenho, porque não é um fato que o novo software será procurado pelo mercado (usuários), e o tempo está correndo? - Quais das empresas que desenvolvem software estão prontas para desenvolver uma única solução de software para toda a história da empresa? - Se o mercado (usuários) aceitam a idéia de um novo software - então, e somente então, faz sentido lutar pelo desempenho do software, mesmo que você o reescreva em Assembler!

Desenvolvedores de compiladores, RAD, frameworks e outras ferramentas também ajustam seus produtos às tecnologias em demanda, ou seja, no final pensando que o OOP é algo terrivelmente lento ou usando funções auxiliares curtas não é uma solução eficaz.... , e se eu escrever um "pedaço de código linear" - será eficaz, mas não de fato, e muito provavelmente será o oposto

essa é a história ;)

Eu concordo com tudo, exceto com uma coisa. A MQL é uma linguagem puramente orientada a software. Então, por que tentar espremer algo que não é necessário? Não há razão para tentar processar alguns cálculos o mais rápido possível, se muitos milissegundos, e às vezes até segundos, passarem de tique para tique.
 
Alexey Viktorov:
Então, por que tentar espremer algo dele que ele não precisa? Para que serve tentar fazer alguns cálculos o mais rápido possível, se muitos milissegundos, às vezes até segundos, passam de tique para tique.

Algumas pessoas fazem seu trabalho como se estivessem em uma linha de montagem - eles recebem o TOR (ou sua idéia), eles fazem o resto - eles recebem o TOR...

e alguns estão constantemente procurando uma maneira de fazer esse trabalho na metade da próxima vez em seu tempo livre

E alguns estão sempre procurando uma maneira de acelerar a execução de cada fragmento de código e depois encontrar uma estrutura de chamada ideal para aumentar o desempenho

só há - cada um tem seu próprio caminho? ))))

 
Igor Makanu:

O fator humano tem um efeito aqui, algumas pessoas fazem seu trabalho como em uma linha de montagem - eles recebem seus ToR, eles fazem o próximo trabalho - eles recebem seus ToR...

Alguns estão constantemente procurando uma maneira de fazer isso funcionar duas vezes mais rápido na próxima vez que tiverem tempo livre

E alguém está constantemente procurando uma maneira de tornar cada fragmento de código mais rápido, e então encontrar a melhor estrutura de chamadas para torná-lo mais rápido

Acho que só há - cada um tem seu próprio caminho? ))))

Em suma, esta é uma discussão inútil. Você perde tanto tempo tentando descobrir o que o cliente quis dizer com este código que talvez tenha que reescrever o código várias vezes. Então, com que rapidez você precisa escrevê-lo? Fazer o que você entendeu e depois tentar descobrir o que o cliente quis dizer quando se candidatou à arbitragem?

E em geral, eu estava falando apenas de contenção. Não há necessidade de sobrecarregar o código no MQL, muitas vezes com criações de objetos inúteis.

Há muitos exemplos de inutilidade, mas não me apetece discutir mais este tópico.

 
Igor Makanu:

dá, string e impressão não é um indicador de manuseio variável

'tst.mq5' tst.mq5 1 1

possível uso da variável não-inicializada 'c' tst.mq5 16 10

possível uso da variável não-inicializada 'e' tst.mq5 20 17

código gerado 1 1

0 erro(s), 2 advertência(ões), 526 msec decorridos 1 3

Ok, ele dá quando você usa explicitamente não-inicializado nos cálculos. Isso é bom.

 
Igor Makanu:

OK

não se trata de vocabulário, trata-se de entender que você foi introduzido à computação há mais de 30 anos e havia linguagens de programação simples, Pascal, Basic, Fortran, Assembler e...

mas o fato de agora você usar Windows - clique no mouse - obter o resultado ou android/appletophone..... é o mérito de programadores que não estão sentados em velhas linguagens eficientes, mas estão escrevendo muitas e muitas soluções de software, graças ao OOP e a outros paradigmas de programação

Novos estilos de programação aumentam a velocidade do desenvolvimento de software, e isto é mais importante que o desempenho, porque não é um fato que o novo software será procurado pelo mercado (usuários), e o tempo está correndo? - Quais das empresas que desenvolvem software estão prontas para desenvolver uma única solução de software para toda a história da empresa? - Se o mercado (usuários) aceitam a idéia de um novo software - então, e somente então, faz sentido lutar pelo desempenho do software, mesmo que você o reescreva em Assembler!

Desenvolvedores de compiladores, RAD, frameworks e outras ferramentas também ajustam seus produtos às tecnologias em demanda, ou seja, no final pensando que o OOP é algo terrivelmente lento ou usando funções auxiliares curtas não é uma solução eficaz.... , e se eu escrever um "pedaço de código linear" - será eficaz, mas não de fato, e muito provavelmente será o oposto

essa é a história ;)

Quando fui contratado, trabalhei principalmente no campo de embedded, dsp etc., embora eu possa fazer coisas de desktop e banco de dados, não me lembro agora. Bem, no nível embutido, a mudança para OOP muitas vezes reduz o desempenho pela metade ou duas vezes. Houve muito trabalho com assembler, você lê o código gerado em asm e você vê que há tantos gestos desnecessários. Mas tudo isso é uma bagatela em nossa realidade. Quando eu comprar uma placa de vídeo decente, poderei escrever para o OpenCL. Eu vou ficar legal ))

1234567891011
Novo comentário