![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Oficialmente, sim. Extra-oficialmente, muitas coisas indicam que ela existe:
Há uma indicação suficiente e abrangente de que não há coletor de lixo no emcool - apagar é obrigatório após novo.
Há uma indicação suficiente e suficiente de que não há coletor de lixo no emcool - apagar é obrigatório após novo.
Até onde me lembro, um dos desenvolvedores reconheceu que existe um coletor de lixo. Mas para o usuário isso "mais ou menos não existe".
Bem, sobre o par new-delete - Eu sou a favor disso. Em caso geral, os objetos que solicitaram recursos devem ser responsáveis por eles. Há exceções, como "fábrica de objetos" - mas aí é especificamente assumido que a responsabilidade pelos objetos criados é de quem solicitou esses objetos à fábrica.
Não gosto da situação em idiomas onde há novidades e a eliminação não é necessária, pois o "sistema limpará". Isto não só reduz potencialmente o desempenho (quando objetos desnecessários ainda não são removidos), mas também relaxa o codificador, permitindo que ele não se preocupe com as conseqüências de suas ações.
Eu realmente não gosto da situação em idiomas onde há novidades, mas não é necessário excluir, dizendo "o sistema removerá desnecessário". Isto não só reduz potencialmente o desempenho (quando objetos desnecessários ainda não são removidos), mas também relaxa o codificador, permitindo que ele não se preocupe com as conseqüências de suas ações.
A produtividade, por outro lado, é geralmente melhorada. A remoção manual leva muito tempo na linha principal. + a eliminação é feita elemento por elemento. Compare as duas versões do roteiro neste tópico, por exemplo. A diferença de velocidade é várias vezes. A eficiência da memória também aumenta. Porque o coletor de lixo move objetos compactados uns com os outros. Se você administrá-lo manualmente, ele cria furos de memória livres que não são tão fáceis de reutilizar. Além disso, o catador de lixo trabalha em um fio diferente. O tempo básico não é desperdiçado. Ao todo, um mais.
A produtividade, ao contrário, é geralmente aumentada. A remoção manual leva muito tempo no fluxo principal. + a eliminação é feita elemento por elemento. Compare duas versões do roteiro neste tópico, por exemplo. A diferença de velocidade é várias vezes. A eficiência da memória também aumenta. Porque o coletor de lixo move objetos compactados uns com os outros. Se você administrá-lo manualmente, ele cria furos de memória livres que não são tão fáceis de reutilizar. Além disso, o coletor de lixo trabalha em um fio diferente. O tempo básico não é desperdiçado. Em resumo, é apenas uma vantagem.
Vasily, desculpe-me, mas você não entende nada do que está tentando falar. De forma alguma e de forma alguma.
Ao menos leia a Wikipedia o que é um coletor de lixo. Sua principal peculiaridade é que ela remove objetos, com os quais se perdeu a comunicação.
Somente neste caso, seria chamado de coletor de lixo. Esses dois roteiros são de uma história diferente. O dom de Deus não deve ser confundido com um ovo.
E por que um catador de lixo aumentaria repentinamente a produtividade? É mais um acolchoamento entre o código útil e o hardware, e não um acolchoamento fraco.
Até onde eu me lembro, um dos desenvolvedores admitiu que existe um coletor de lixo. Mas, para o usuário, "meio que se foi".
///
Este deve ser o "coletor de lixo" que dá uma mensagem sobre vazamento de memória no final do trabalho.
Talvez até apague objetos abandonados. Mas mesmo que os remova, há um grande
diferença - ela só os elimina no final do trabalho. E se em um ciclo multi-militar forem criados novos objetos?
novos objetos? O programa será inoperante, não terá memória suficiente.
Um verdadeiro montador apaga objetos perdidos durante a operação do programa, não
somente no final do programa. É por isso que um estilo especial de programação é permitido.
podemos multiplicar os objetos em qualquer condição e em qualquer quantidade.
A produtividade, ao contrário, é geralmente aumentada. A remoção manual leva muito tempo no fluxo principal. + a eliminação é feita elemento por elemento. Compare duas versões do roteiro neste tópico, por exemplo. A diferença de velocidade é várias vezes. A eficiência da memória também aumenta. Porque o coletor de lixo move objetos compactados uns com os outros. Se você administrá-lo manualmente, ele cria furos de memória livres que não são tão fáceis de reutilizar. Além disso, o coletor de lixo trabalha em um fio diferente. O tempo básico não é desperdiçado. Ao todo, um mais.
Hmm... E em um coletor de lixo, a eliminação é não-elementar? Sem mencionar que outro fio, quando não há núcleos livres, é realizado pelo mesmo núcleo, e retarda o fio principal.
Em minha opinião, em geral, com cuidadosa consideração, a remoção do lixo pelo usuário é sempre mais eficiente do que a remoção pelo catador de lixo. Entretanto, se você não se importa, o coletor de lixo certamente ganha.
É por isso que não gosto do coletor de lixo, porque ele incentiva este tratamento mais indiferente dos recursos.
Este deve ser o "assembler" que dá a mensagem sobre vazamentos de memória quando o trabalho é terminado.
Provavelmente até apaga objetos sobrando. Mas mesmo que os apague, há um grande
diferença - ela só os elimina no final do trabalho. E se em um ciclo multi-militar forem criados novos objetos?
novos objetos? O programa será inoperante, não terá memória suficiente.
Um verdadeiro montador apaga objetos perdidos durante a operação do programa, não
somente no final do programa. É por isso que um estilo especial de programação é permitido.
podemos multiplicar os objetos em qualquer condição e em qualquer quantidade.
É isso mesmo. É por isso que não gosto de trabalhar com assembler - o usuário não presta atenção, quantos objetos ele criou e onde.
Basicamente, ele até simplifica o desenvolvimento de alguma forma - não é preciso lembrar de apagar o ocupado. O construtor encontra o momento em que o objeto não é mais referenciado, e o remove. Mas esta posição me repugna. É por causa desta posição que temos programas que rodam cada vez mais devagar, que precisam de mais e mais poderosos recursos de hardware para tarefas de complexidade semelhante.
Vasily, sinto muito, mas você não entende nada sobre o que está tentando argumentar. Nada e de forma alguma.
Hmmm... E no coletor de lixo está a eliminação não-elementar? Sem mencionar o fato de que outro fio, quando não há núcleos livres - é feito pelo mesmo núcleo, e abranda o fio principal.
Em minha opinião, no caso geral, com cuidadosa consideração, a remoção de lixo pelo usuário é sempre mais eficiente do que a remoção pelo catador de lixo. Entretanto, se você não se importa, o coletor de lixo certamente ganha.
É por isso que eu não gosto do coletor de lixo, ele encoraja este mesmo tratamento indiferente dos recursos.
Em vez de fazer suposições sobre como funciona um coletor de lixo, basta comparar a velocidade da remoção automática de objetos com a remoção manual. Todas as fantasias desaparecerão de uma só vez.
comparar as velocidades de remoção automática de objetos e remoção manual de objetos.
A resposta é de preferência imediata. Nem sempre há tempo para experiências.