Adeus robô - olá marasmus - página 10

 
borilunad:

Sr. Pansa! Porqué no usa el botón SRC para poner su código? Así mejor o Ud. tiene alguna duda?

Buena suerte!

Oi, borilunad!
quer perguntar onde você consegue o SRC?
panza
 
 
pansa:
Olá borilunad!
quer perguntar onde você consegue o SRC?
pansa

Quando você responder, olhe um pouco para cima e à esquerda do vídeo você verá um botão SRC! Clique nele e ele abrirá um perímetro para colar o código! Boa sorte!

A propósito, muito precisa e "eloquentemente" apontou a localização do SRC por Constantine!

 
7Konstantin7:

Olá Konstantin, como você está se saindo no comércio manual? Acho que você já se tornou um assassino, não é mesmo?
 
Renat:

Entendo que algumas pessoas ficarão histéricas depois de se familiarizarem com os analisadores estáticos.

Mas somente depois disso alguns entendem o que um compilador deve (exatamente deve) fazer. Estamos em 2014 e os compiladores comuns estão pelo menos 10 anos atrasados no controle de qualidade e se concentram apenas em otimizações.

Para informação: o compilador Intel C++ ainda não se recuperou de seus defeitos - ele gera constantemente erros internos de compilação em nossos projetos. Ou seja, não mastiga grandes projetos e produz seus próprios erros. E os mitos sobre suas extraordinárias propriedades otimizadoras também estão ultrapassados - todos os demais apertaram muito seus níveis de otimização.

Em uma linguagem tão perigosa e suicida como o C++, há tantas chaves e interruptores de compilação que programadores confiantes poderiam compilar toneladas de código antigo e copiar do nada sem cãibras nervosas :)

Um compilador, antes de mais nada, deve compilar em vez de analisar e deve compilar de preferência com boa qualidade, o que normalmente requer flexibilidade e personalização.

É razoável criar analisadores de código estático e outras ferramentas similares como utilitários separados cujas funções podem ser executadas com maior qualidade desta forma do que com o compilador.

É razoável entender que a análise estática do código e outras coisas úteis similares ajudam a detectar apenas alguns erros, ou seja, aqueles relacionados tanto à falta de atenção quanto à baixa habilidade de um programador. Erros de projeto, erros lógicos, erros do tipo "esqueceu de implementar" e outros erros similares não são detectados por analisadores estáticos ou ferramentas similares. Que é exatamente o que podemos ver no MT4.

Em sua época, o compilador da Microsoft também era fácil de "quebrar" por causa de erros internos. As novas versões também são mais estáveis, incluindo as da Intel. Quanto à otimização, você normalmente não precisa de nada extraordinário - apenas uma boa e sólida otimização - e a otimização da Intel é baseada no profundo entendimento da arquitetura e dos mecanismos de seus próprios processadores. Seria estranho pensar que seria pior para a Intel do que para os outros.

Os interruptores de compilação destinam-se principalmente a ajustar flexivelmente o compilador às (partes de) exigências de um projeto, e as opções para facilitar a compilação de códigos antigos são apenas um bônus adicional.

Se a linguagem C++ é tão perigosa e suicida, então por que a MQL4 baseada em C foi "melhorada" para MQL4++ e MQL5 baseada exatamente em C++?

 

simpleton:

É razoável entender que a análise estática do código e outras ferramentas úteis similares ajudam a detectar apenas alguns erros, ou seja, aqueles relacionados tanto à falta de atenção quanto à baixa habilidade dos programadores. Erros de projeto, erros lógicos, erros do tipo "esqueceu de implementar" e outros erros similares não são detectados por analisadores estáticos ou ferramentas similares. Que é exatamente o que você pode ver no MT4.

Os ambientes de teste são amplamente utilizados em produtos de software para verificação funcional de projetos de chips de software onde os requisitos de qualidade de código são muito altos. Além disso, a casca funcional é parte integrante do desenvolvimento de qualquer código para o projeto do chip. Por outro lado, muitos programadores nem sequer têm idéia sobre tais testes funcionais quando escrevem projetos de software usuais, é porque escrever tais testes do zero pode levar mais tempo do que quando se escreve o projeto em si e se justifica apenas quando há uma exigência de escrever código de alta qualidade ou quando há muitas versões do mesmo projeto. Por outro lado, um ambiente de teste habilmente escrito reduz significativamente o tempo de depuração e verificação de código.

A análise estática também é utilizada mas apenas como uma verificação de sintaxe muito superficial e primária.

 

Simples, que bobagem.

Quando você chegar ao nível de controle de qualidade total, somente então você o entenderá. Enquanto isso, você permanece no nível de percepção de um programador narcisista individual, e continuará a pensar "é razoável não me controlar, deixe o controle ser por utilitários separados, nunca dirija utilitários".

Ao contrário do C++, a MQL é absolutamente segura (se não houver saída para dll) devido à rejeição de links brutos, e em geral - é uma linguagem gerenciada.

 
Renat:

Ao contrário do C++, o MQL não é nada perigoso

As falhas no próprio compilador C++ são bastante raras.

As falhas do compilador MQL são uma ocorrência regular agora (já vi erros internos do compilador MQL com muito mais freqüência do que para a VS).

As falhas na execução do código MQL são também um fenômeno recorrente nos dias de hoje.

 

As falhas estão sendo tratadas, mas estamos acrescentando e melhorando muito em paralelo.

Haverá um lançamento do MT4 na sexta-feira com claras melhorias na velocidade de execução e testes.

 
Renat, eu quero: namespace, colagem em macros, inclusão múltipla de arquivos de cabeçalho, undef, união. Tudo como em C++.