Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Algo que você esqueceu sobre estruturas e classes (sem novidades) - ambos se destacam na pilha.
Não confundir com C++, é mais próximo de Sharp
Não confundir com C++, é mais próximo de Sharp
Esta é a sua fantasia, não a realidade.
Você não deve provar o que você mesmo não testou...
A criação de variáveis locais como objetos de estruturas e classes (sem novas) acontece na pilha.
Descrevi anteriormente comofuncionam os arrays no MT5.
Que chatice!
1 - Através da criação de objetos. 2 - simplesmente através de uma chamada de função normal. O primeiro número é o tempo em milissegundos, não preste atenção ao segundo.
É quase 10 vezes mais rápido (e às vezes mais de 10 vezes mais rápido). Que coisa triste... empilhar... pilha... ***A minha vida
Bem, por que não prestar atenção? Deixe-me adivinhar: INT_MAX uma vez realizou uma ação através da criação de um objeto temporário, e depois a mesma ação através de uma chamada de função?
Bem, é um resultado esperado, considerando que ainda estamos dançando em torno da criação da classe no tempo de execução (ainda devemos obter este cabo que se parece com um índice em algum recipiente).
PS. Onde está o código fonte para a reprodução?
PPS. Você tem certeza de que a função foi chamada? De qualquer forma, o otimizador também está neste código, não o fato de que haverá uma chamada de função em tempo de execução:
O fato de a UB estar em mql prova este código:
O fato de que a mql tem UB prova este código:
Você envolveu habilmente o compilador ao redor de seu dedo:
- o ramo falso é atirado porque não há quebra de enquanto(1) loop.
- true é devolvido porque as operações são realizadas em variáveis locais sem qualquer interação com o "mundo exterior" e a execução deste código também é descartada.
Você envolveu inteligentemente o compilador ao redor de seu dedo:
- o ramo falso é atirado porque não há quebra de enquanto(1) loop.
- true é devolvido porque as operações são realizadas em variáveis locais sem qualquer interação com o "mundo exterior" e a execução deste código também é descartada.
Não sou eu - é um dos exemplos na Internet. É a mesma coisa que os prós.
Por que não prestar atenção? Deixe-me adivinhar: INT_MAX uma vez realizou uma ação via criação de um objeto temporário e depois a mesma ação via chamada de função?
Em suma, este é um resultado esperado, levando em conta que ainda estamos dançando em torno da criação da classe em randomização (devemos obter este cabo que se parece com um índice em algum recipiente).
PS. Onde está o código fonte para a reprodução?
PPS. Você tem certeza de que a função foi chamada? De qualquer forma, o otimizador também está neste código, não o fato de que haverá uma chamada de função em tempo de execução:
O fato de a UB estar em mql prova este código:
Você está errado. Você não precisa adivinhar aqui, basta lembrar que ontem, em caso de problemas de memória, você pode olhar através das citações para ver do que se trata a discussão. Por que o resultado se tornou de repente esperado, se antes você alegou o contrário?
Sim, tenho certeza de que a função foi chamada. E todos vocês gostam de sonhar que eu sou um idiota? Por que a pergunta é apenas sobre a função, e talvez o objeto também não tenha sido criado? Ou você tem tanta certeza de que sabe como funcionam todos os compiladores?
Você pode explicar do que se trata, porque sou um pouco burro, já li isso três vezes - mas ainda não entendi...
Olhe as citações e veja do que estamos falando. O que eu citei, e em resposta ao que eu estava obtendo esta resposta a partir da citação.
Como Dimitri estava muito envergonhado para publicar seu código, eu mesmo tive que fazer 15 minutos de testes.
Oops. Com operações idênticas, a diferença é de apenas 30%.
A diferença de tempo de execução persiste mesmo sem toda essa confusão com variáveis estáticas e campos. É a diferença em microssegundos, não a porcentagem.
Conclusão: O custo de criar um objeto temporário na pilha é suficientemente pequeno no meu computador não é o mais rápido para ser cerca de 30-40 ns/pc (nanossegundo), por isso devo prestar atenção a ele na maioria dos casos.
PS. E eu pensei mal sobre os desenvolvedores, mas não, você simplesmente não tem que levar as pessoas à palavra deles e verificá-los))))
Como Dimitri estava muito envergonhado para postar seu código, eu mesmo tive que fazer 15 minutos de testes.
Oops. Com operações idênticas, a diferença é de apenas 30%.
A diferença de tempo de execução persiste mesmo sem toda essa confusão com variáveis estáticas e campos. É a diferença em microssegundos, não a porcentagem.
Conclusão: O custo de criar um objeto temporário na pilha é suficientemente pequeno no meu computador não é o mais rápido para ser cerca de 30-40 ns/pc (nanossegundo), por isso devo prestar atenção a ele na maioria dos casos.
PS. E eu pensei mal sobre os desenvolvedores, mas não, você simplesmente não aceita a palavra das pessoas e as verifica))))
E ainda mais fazer todo tipo de cálculos diferentes no interior, a diferença será ainda menor. De qualquer forma, este teste dificilmente pode ser chamado de teste de funcionalidade idêntica.
Além disso, os testes em si não são idênticos.