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

Novo comentário
 

Quanto a ocultar o nome da variável:

simpleton já escreveu sobre compilador de informações, situação semelhante com gcc e clang. Ao compilar em um modo muito rigoroso (em termos de presença de mensagens):

gcc(clang) -Wall -Wextra

o compilador não se queixa sobre esta questão. Reclamações sobre ocultação são ativadas com uma opção separada -Wshadow. Isto é, a verificação em si não é difícil em compiladores de c++ (exceto MSVC). Mas eu não vi nenhuma idéia (baseada no gcc, por exemplo, qt creator, blocos de código ...) onde -Wshadow é ativado por padrão.

Por quê? Provavelmente, porque para a maioria das pessoas a utilidade desta mensagem é questionável.

 
Pavlick:

Quanto a ocultar o nome da variável:

simpleton já escreveu sobre compilador de informações, situação semelhante com gcc e clang. Ao compilar em modo muito rigoroso (em termos de presença de mensagens):

Você parece confundir o enganoso "modo de compilação rigoroso" e o trabalho real dos analisadores estáticos, pois nunca os utilizou.

O compilador completa a compilação em 1-2 minutos, enquanto os analisadores trabalharão por várias horas (PVS Studio) ou dezenas de horas (CPP Check) no mesmo código. Daí uma qualidade e profundidade de resultados tão diferentes.

 

Saudações a todos.

Já faz quase um ano que o "louco" e marasmo das inovações na MQL4 não parou. "Mas ainda está lá! (с).

Antes costumavam culpar "Metaquotes" por linguagem pobre, agora os culpam por "água" excessiva. Os problemas não diminuíram.

Posso acrescentar o seguinte de mim.

Para comerciantes, não programadores e programadores novatos, um algoritmo e código simples pode ser implementado.

Se você tem uma grande base de índices, corujas, etc. que não se compilam nas novas construções, então faz sentido olhar de perto e "sacudir seus cofres". Certifique-se de guardar as coisas mais úteis e não perca tempo para reescrevê-las e debugá-las para novas construções.

Os verdadeiros programadores experientes ou aqueles que querem se tornar eles, sempre seguem inovações, insetos e falhas são seu pão. É escrever código sem bugs que conta como uma boa programação. Se você não tem energia, tempo, possibilidade ou desejo de compreender todas as inovações do "Metakvot", use a linguagem em que você é fluente. As DLLs não foram abolidas, conecte seus próprios algoritmos ajustados.

 
Andrei01:

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 para a qualidade do código são muito altos. Além disso, uma casca funcional é parte integrante de qualquer desenvolvimento de código de projeto de chips. Por outro lado, muitos programadores quando escrevem projetos de software usuais não têm sequer idéia sobre tais testes funcionais, isto é, 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 economiza 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 inicial.

Os ambientes de teste são ambientes de teste. Um ambiente de teste está "confinado" ao produto que está testando.

Referia-me a ferramentas gerais - aquelas que "não têm idéia" sobre o produto a ser analisado e, portanto, podem analisar e encontrar problemas em qualquer produto.

 
Renat:

Simples, que bobagem.

"Que bobagem" parece implicar um completo descompasso de atitudes.

Renat:

Quando você chegar ao nível de controle de qualidade total, somente então você o entenderá. Mas, enquanto você permanecer no nível de percepção de um único programador egoísta, você continuará pensando "é razoável não me controlar, deixe que o controle seja feito por utilitários separados, nunca dirija utilitários".

Então por que o "controle de qualidade total" permite um nível de controle de qualidade tão baixo?

Por exemplo:

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }

public:
  static void method1() {
    //A a; // 'A::A' - cannot call private member function      3.mq4   10      7
  }

  static void method2() {
    A *a = new A; // А здесь private member function великолепно вызывается
    delete a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method1();
  A::method2();
}

O construtor é chamado quando um objeto é criado no método2:

00:50:23 Script 3 EURUSDm,M5: loaded successfully
00:50:23 3 EURUSDm,M5: initialized
00:50:23 3 EURUSDm,M5: A::A()
00:50:23 3 EURUSDm,M5: uninit reason 0
00:50:23 Script 3 EURUSDm,M5: removed

Por que tudo está bem quando um objeto é criado dinamicamente, ou seja, o construtor privado está disponível pelo método do objeto, mas quando o objeto é criado automaticamente, o construtor privado de repente fica indisponível?

Pessoalmente desisti de fazer algo um pouco mais complicado do que simples na MQL, porque é muito difícil para mim: estou sempre me deparando com algo que não funciona.

Mas eu não tenho tais problemas com os compiladores C/C++.

E o problema "é razoável não me controlar, deixar que o controle seja separado, nunca executar utilidades" está diretamente relacionado à psicologia. Aqui a psicologia precisa ser corrigida para que o programador possa se forçar, em vez de tentar ajustar a tecnologia à psicologia, a fim de contornar esta psicologia.

Eu não invento, algumas utilidades são usadas com sucesso na minha frente regularmente, e o resultado de seu trabalho também é usado com sucesso mais tarde para eliminar bugs.

Renat:

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

Talvez as prioridades sejam deslocadas para acrescentar e melhorar à custa da qualidade. Mas então não é mais um controle total da mesma.

Renat:

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

Neste caso refiro-me à disponibilidade de construtor privado a partir de métodos de objetos não apenas para o caso de criação de objetos dinâmicos - haverá alguma melhoria na operabilidade da linguagem?

Renat:

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

Ok, vamos assumir que "C++ é perigoso e suicida" e "MQL é absolutamente seguro".

Por que se tomaria como base para a MQL uma linguagem que está tão longe do critério de segurança do que se queria, ou seja, criar uma linguagem "absolutamente segura" baseada exatamente na linguagem "perigosa e suicida"?

 
Pavlick:

OK?


Olá, Pavlik!

sou eu novamente Panza!

Estive testando seu código para chamar o script em diferentes mt4

e eu descobri algumas coisas estranhas!

Seu código funciona bem no MT4 build 670 da Pepperston

(Austrália), mas não quer trabalhar no MT4 build 670 Alpari!

user32.dll échamadoestranhamenteem alpari!

As 2 primeiras dlls são chamadas (embora isso não estivesse no código!)

então auser32.dllé chamada,mas ela é jogada em uma biblioteca!

mas você também precisa chamá-lo da biblioteca!

Parece que a Alpari está lutando com a chamada.

ou seja, há uma interferência de código óbvia!

Eu anexei 2 fotos para comparação!

desejo sucesso!

Panza

oo-bild zu gross!

MT4-Pepperstone-user32.dll

MT4-Alpari-KERNEL32.dll,GDI.dll,E:\metaQuotes\Terminal\F................OBO\MQL4\Libraries\user32.dll

















 
simpleton:

"Que bobagem" - isto aparentemente significa um completo descompasso de posições.

Isto significa que alguém é conscientemente mais experiente em direcionar o lançamento de múltiplos produtos de software para um mercado concorrente.


Por que o "controle de qualidade total" permite um nível de controle de qualidade tão baixo?

Não há necessidade de passar de uma discussão de princípios gerais de controle de qualidade para as deficiências específicas de uma solução específica. Tal método é inaceitável, pois é sempre possível encontrar qualquer falha em qualquer produto.

Por exemplo:

O construtor é chamado quando um objeto é criado no método2:

Por que tudo está bem quando um objeto é criado dinamicamente, ou seja, o construtor privado está disponível pelo método de objeto, mas quando um objeto é criado automaticamente, o construtor privado de repente fica indisponível?

Isto é apenas uma conseqüência da superproteção"o método de classeestática não tem o direito de entrar no conteúdo da classe". Neste caso, no entanto, o controle de acesso precisa ser afrouxado.

Pessoalmente desisti de fazer algo um pouco mais complexo do que simples na MQL, porque é muito difícil para mim: estou sempre me deparando com algo que não funciona.

Dê-me um exemplo de trabalho, não um caso de "eu torci as coisas de propósito, fechei os acessos e depois comecei a apelar para um comportamento de fronteira".


Não tenho tais problemas com os compiladores C/C++, no entanto.

Os problemas lá são de um tipo diferente. E eles são intencionalmente maiores por ordens de magnitude se você levar em conta que não usa analisadores estáticos.


E o problema "é razoável não me controlar, deixar que o controle seja separado, nunca executar utilidades" está diretamente relacionado à psicologia. Aqui a psicologia precisa ser corrigida para que o programador possa se forçar, em vez de tentar ajustar a tecnologia à psicologia, a fim de contornar esta psicologia.

Eu não invento, utilidades individuais são utilizadas com sucesso diante dos meus olhos, e o resultado de seu trabalho também é utilizado com sucesso posteriormente para eliminar bugs.

Talvez as prioridades sejam deslocadas para acrescentar e melhorar à custa da qualidade. Mas então não é mais um controle total da mesma.

Já é apenas um jogo de palavras. Sua posição já foi claramente delineada anteriormente "não posso ser controlado", então sim "na frente de alguém, em algum lugar está usando, mas ninguém está em cima de mim com um bastão e eu não estou usando".


E melhorias em termos de operabilidade da linguagem - neste caso refiro-me à disponibilidade de construtor privado a partir de métodos de objetos não apenas para o caso de criação de objetos dinâmicos - já terá?

E você gosta de fazer dispositivos de tropeçar deliberadamente em seus programas "simples": "Vou esconder o construtor em privado, criar um método estático e depois usá-lo para cinzelar dentro do construtor escondido"?


Ok, vamos assumir que "C++ é perigoso e suicida" e "MQL é absolutamente seguro".

Por que se levaria uma linguagem tão longe do critério de segurança como base para o MQL, ou seja, criar uma linguagem "absolutamente segura" com base na linguagem muito "perigosa e suicida"?

Você é capaz de encontrar uma "base diferente" para uma linguagem genérica?

Para que qualquer outro programador possa receber o idioma e começar a escrever nele com prazer após algumas horas e não jogá-lo fora com repugnância e repreensão? Os comerciantes olharam para a linguagem fácil e a jogaram fora, enquanto a MQL4/MQL5 está sendo usada e desenvolvida com muito prazer.

Os idiomas mais comumente usados são baseados nos princípios básicos das construções, como em C/C++. Assim, pegamos a conhecida estrutura, removemos as coisas mais perigosas com links, acrescentamos DRM e recebemos uma linguagem segura e protegida.

Como resultado, estamos em alta e os concorrentes estão indo na direção errada, mas mais barata, como eles pensam.

 
Renat:
Isso significa que alguém tem mais experiência em gerenciar o lançamento de muitos produtos de software em um mercado competitivo.

A propósito, sobre a experiência gerencial. Há 5 anos, discutimos no fórum mql5 sobre as perspectivas do MT5, eu disse então que o tempo dirá. Cinco anos se passaram e vemos que a comunidade rejeitou o MT5. A experiência gerencial não garante contra erros. Mesmo que se tenha experiência em uma área, ainda se pode cometer erros. Sobre o tema do mercado concorrente, ou melhor, concorrentes, no final das contas.

Entretanto, neste caso, não é uma questão de experiência em muitos produtos de software, mas da qualidade do produto e, em particular, do compilador e das ferramentas e métodos para alcançar alta qualidade.

Renat:
Não devemos mover a discussão dos princípios gerais de controle de qualidade para falhas específicas em uma solução particular. Você não pode fazer isso porque é sempre provável que você encontre todas as falhas em cada produto.


Isto é apenas uma conseqüência da superproteção "o método de classe estática não tem o direito de entrar no conteúdo da classe". Embora, neste caso, seja necessário afrouxar o controle de acesso.

Não estou traduzindo, princípios gerais, teoria - não para a teoria em si, mas para a aplicação na prática. Você não encontrará "falhas" tão graves nos mesmos compiladores de C/C++.

Se você diz que neste caso "um método de classe estática não tem o direito de entrar no conteúdo da classe", então por que no caso da criação de objetos dinâmicos já tem esse direito?

E quanto ao fato de um método não estático comportar-se exatamente da mesma maneira?

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }

public:
  void method() { // Метод - обычный, никакой не статический
    A a;
  }

};

/******************************************************************************/
void OnStart() {
}

Os mesmos erros:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

OK, vamos considerar uma proibição de "subir no conteúdo da classe":

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }
  A(const A &a) { Print("A::A(const A &)"); }
  void operator =(const A &a) { Print("A::operator =()"); }
  void f() { Print("A::f()"); }

public:
  static void assign(A &l, const A &r) {
    l = r;
  }

  static void method() {
    A *p = new A, b(p);

    b = p;
    b.f();
    delete p;
  }

};

O objeto b é criado chamando o construtor da cópia, então uma atribuição é realizada chamando "operador =", o método f() é chamado, e todos estes construtores, operadores e métodos são privados, o que significa que o método estático método() é permitido para "acariciar a classe":

00:59:18 Script 3 EURUSDm,M5: loaded successfully
00:59:18 3 EURUSDm,M5: initialized
00:59:18 3 EURUSDm,M5: A::A()
00:59:18 3 EURUSDm,M5: A::A(const A &)
00:59:18 3 EURUSDm,M5: A::operator =()
00:59:18 3 EURUSDm,M5: A::f()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: uninit reason 0
00:59:18 Script 3 EURUSDm,M5: removed

Vejamos outro exemplo, muito próximo ao primeiro:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Erro de compilação, - tanto o construtor como o destruidor não estão disponíveis:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

Agora, sem alterar nada, inicialize a variável com um valor diferente do valor padrão no construtor:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a(1);
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Agora o exemplo compila e executa:

00:20:35 Script 3 EURUSDm,M5: loaded successfully
00:20:35 3 EURUSDm,M5: initialized
00:20:35 3 EURUSDm,M5: A::A(int i = 1)
00:20:35 3 EURUSDm,M5: A::~A()
00:20:35 3 EURUSDm,M5: uninit reason 0
00:20:35 Script 3 EURUSDm,M5: removed

Como um método estático se tornou subitamente permitido para "entrar no conteúdo da classe"?

É bastante óbvio que não se trata de uma "superproteção" neste caso, mas de um bug trivial. O controle de qualidade total é uma afirmação um tanto estrondosa, mas os fatos são coisas teimosas.

Renat:
Dê um exemplo de trabalho, não um caso de "eu torci as coisas dessa maneira de propósito, fechei os acessos, e depois comecei a apelar para o comportamento de limite".

Por favor, um singleton clássico, ou seja, o singleton Myers descrito na seção de exemplo C++ do link:

class OnlyOne
{
public:
        static const OnlyOne& Instance()
        {
                static OnlyOne theSingleInstance;
                return theSingleInstance;
        }
private:        
        OnlyOne(){};
        OnlyOne(const OnlyOne& root);
        OnlyOne& operator=(const OnlyOne&);
};

Ele se traduz até mesmo em MQL4++ com o novo recurso aberto:

#property strict

/******************************************************************************/
class OnlyOne
{
public:
        static OnlyOne *Instance()
        {
                static OnlyOne theSingleInstance(1);
                return GetPointer(theSingleInstance);
        }
private:        
        OnlyOne(int i = 0) { Print("Создан"); };
        ~OnlyOne() { Print("Уничтожен"); };
        OnlyOne(const OnlyOne &);
        void operator=(const OnlyOne &);
};

/******************************************************************************/
void OnStart() {
  OnlyOne *p = OnlyOne::Instance();
}

Ela compila e executa:

01:31:49 Script 3 EURUSDm,M5: loaded successfully
01:31:49 3 EURUSDm,M5: Создан
01:31:49 3 EURUSDm,M5: initialized
01:31:49 3 EURUSDm,M5: uninit reason 0
01:31:49 3 EURUSDm,M5: Уничтожен
01:31:49 Script 3 EURUSDm,M5: removed

Tentativas de criar um objeto de qualquer outra forma que não seja chamar OnlyOne::Instance() resultará em um erro de compilação.

E sobre o assunto "eu torci as coisas tão deliberadamente, fechei os acessos, e então comecei a apelar para o comportamento de limite" - alguma coisa foi usada de forma imprópria?

Existem mecanismos no idioma - tenho o direito de usá-lo como eu quiser dentro dos limites permitidos pelo idioma. Pelo menos é assim com os compiladores C++.

Se houver erros na implementação do idioma, bem, sim, erros. Você está falando de controle de qualidade total - assim, na prática, livre-se de erros de implementação no compilador MQL4++, de modo que os erros são quase tão difíceis de encontrar como nos compiladores C++, uma vez que você tem tal controle. Ainda acredito que o analisador não vai ajudar a se livrar de erros como os que eu demonstrei.

Renat:
E você gosta de colocar passos deliberados em seus programas "simples" "esconder construtor em particular, criar um método estático e depois esculpir o construtor escondido dele"?

Não se trata do que eu gosto ou não gosto. Há uma ferramenta. Por que eu deveria me recusar a usar todas as suas capacidades?

Neste caso, não é nem mesmo "eu gosto". É Myers, aliás, quem gosta tanto. E de alguma forma, ninguém tenta acusá-lo de tentar "tropeçar deliberadamente" nos compiladores de C++.

Renat:
Você é capaz de criar uma "estrutura diferente" para idiomas genéricos?

Para que todos os outros programadores pudessem receber um idioma e começar a escrever nele com prazer após algumas horas e não jogá-lo fora com repugnância e repreensão? Os comerciantes olharam para a linguagem fácil e a jogaram fora, enquanto os MQL4/MQL5 são usados e desenvolvidos alegremente.

Os idiomas mais difundidos são baseados nos princípios básicos das construções como em C/C++. Assim, tomamos uma estrutura familiar, removemos as coisas mais perigosas com referências, adicionamos DRM e obtivemos uma linguagem segura e protegida.

Como resultado, estamos no topo, enquanto nossos concorrentes estão indo na direção errada, mas mais baratos, como eles pensam.

Não é uma tarefa fácil e não pode ser resolvida logo de cara. É preciso fazer algum esforço aqui, e não um esforço pequeno. A grande maioria dos usuários de MQL não são programadores. Isto deve ser levado em conta no projeto lingüístico. Mas a tarefa pode ser resolvida, tenho certeza.

Se algo bastasse, seria suficiente acrescentar algumas estruturas à antiga MQL4 e limpar algumas coisas como prioridades às operações, como foi feito para a MQL4++ e isso seria um compromisso razoável. O sucesso do MT4 foi em grande parte devido à falta de "esperteza" da linguagem. Este não é o caso agora. E há muito mais erros na implementação do compilador, porque a MQL4++ é muito mais complicada do que a antiga MQL4 e a equipe de desenvolvimento quase não mudou muito.

Renat:
Como resultado, estamos do lado positivo enquanto nossos concorrentes estão indo na direção errada, mas mais baratos, como eles acreditam.

Aqui é onde eu concordo com você, mas acho que é principalmente porque os concorrentes estão fazendo coisas incompreensíveis.

 
Renat:
Isto significa que alguém é conscientemente mais experiente em direcionar o lançamento de muitos produtos de software para o mercado concorrente.


Não precisamos mudar o tópico da discussão dos princípios gerais de controle de qualidade para falhas específicas de uma solução específica. Tal método é inaceitável, pois é sempre possível encontrar qualquer falha em qualquer produto.

Isto é apenas uma conseqüência da superproteção "um método de classe estático não tem o direito de entrar no conteúdo da classe". Embora, neste caso, seja necessário afrouxar o controle de acesso.

Dê-nos um exemplo de trabalho, não um caso de "torci tudo de propósito, acessos trancados e depois recorri ao comportamento de contorno".


Os problemas lá são de um tipo diferente. E eles são intencionalmente maiores por ordens de magnitude se você levar em conta que não usa analisadores estáticos.


Este já é apenas um jogo de palavras. Sua posição já foi claramente delineada anteriormente "não posso ser controlado", então sim "na frente de alguém, em algum lugar usando, mas ninguém está em cima de mim com um bastão e eu não estou usando".


Você gosta de colocar passos deliberados em seus programas "simples" "esconder construtor em particular, criar um método estático e depois esculpir o construtor escondido dele"?


Você é capaz de criar uma "base diferente" para línguas de plano comum?

Para que qualquer outro programador possa receber uma linguagem e começar a escrever nela com prazer após algumas horas e não jogá-la fora com repugnância e repreensão? Os comerciantes olharam para a linguagem fácil e a jogaram fora, enquanto os MQL4/MQL5 são usados e desenvolvidos alegremente.

As línguas mais difundidas são baseadas nos princípios básicos de construção como em C/C++. Assim, pegamos a conhecida estrutura, removemos as coisas mais perigosas com links, acrescentamos DRM e conseguimos uma linguagem segura e protegida.

Como resultado, estamos no topo, enquanto nossos concorrentes estão indo na direção errada, mas mais baratos, como eles pensam.

 

Olá membros do fórum!

Eu gostaria de aproveitar a presença de Renate neste fio

Eu gostaria de fazer algumas sugestões para melhorar o MT4!

Todos sabem que, com o tempo, o MT4 funciona cada vez pior.

então ele não obedece ao rato - finito!

Precisamos mudar para um novo MT4 e remover

todo o material (indicadores, eXperts)!

Este é um trabalho de um dia!

Embora agora existam programas de reparo para DL, DRIVER, etc...

Por que não fazer um compilador para o MT4?

Você tem que ter 2 МТ4 (um válido e o outro funcional)

e compará-los periodicamente e corrigir erros no MT4 de trabalho.

A segunda sugestão é construir não apenas gráficos de preços, mas

produzir preços multiplicados por gráficos de crescimento de volume!

Dessa forma, você ficaria imediatamente visível o que está acontecendo (comércio real ou de dinheiro

stopes)

acho que é fácil para pessoas com alto nível de compreensão!

Panza

1...45678910111213141516
Novo comentário
Razão: