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
Se o número de objetos é conhecido antecipadamente e é constante durante a execução do programa, então não há necessidade de novos objetos. Em todos os outros casos, você precisa de novo.
Não, aqui está meu exemplohttps://www.mql5.com/ru/forum/160683/page861#comment_11840254
é conveniente passar parâmetros para o construtor e se o usuário alterar as configurações, é mais rápido matar a classe em OnDeinit() e depois criá-la com os novos parâmetros em OnInit()
;)
não, aqui está meu exemplohttps://www.mql5.com/ru/forum/160683/page861#comment_11840254
é conveniente passar parâmetros para o construtor e se o usuário alterar as configurações, é mais rápido matar a classe em OnDeinit() e depois criá-la com os novos parâmetros em OnInit()
;)
Os parâmetros também podem ser passados para o construtor sem novos parâmetros.
Os parâmetros podem ser passados para o construtor sem novos parâmetros.
Então, como você mudará os campos de classe (o usuário mudou as configurações da EA)? - Você vai escrever mais um método? Eu pensei na última página que você estava lutando por" mais umavariável para um ponteiro". "e aqui você tem todo um método!
;)
e? como você mudará os campos da classe (o usuário mudou as configurações da EA)? - Você vai escrever outro método? Eu pensei na última página que você estava lutando por" mais umavariável para o ponteiro". "com que você estava lutando, e aqui está todo um método!
;)
de jeito nenhum ;)
alterar as configurações da EA
de jeito nenhum ;)
alterar as configurações da EA
Uma emboscada fria.
Entretanto, eu preferiria acrescentar um método para alterar os parâmetros, mas não usar novos apenas por causa dos parâmetros.Uma emboscada fria.
No entanto, prefiro acrescentar um método para mudar os parâmetros, mas não use novos apenas por causa dos parâmetros.não usar novo é uma superstição? )))
imho, se for conveniente, você deve usá-lo! - Seu exemplo será reescrito em 2 cliques usando novo e tudo funcionará corretamente e lidará com a situação quando o usuário alterar as configurações
não usar novo é superstição? )))
imho, se for conveniente, você deve usá-lo! - Seu exemplo será reescrito em 2 cliques usando novo e tudo funcionará corretamente e lidará com a situação quando o usuário alterar as configurações
Não é superstição, apenas preguiça, historicamente, devido às circunstâncias. Você tem que escrever apagar e fazer isso em Deinit(). Mas a função Deinit() não estava no modelo por padrão. Agora eu olho - o modelo EA tem Deinit(), mas não estava lá antes.
Não é superstição, apenas preguiça, historicamente, devido às circunstâncias. Devemos escrever apagar, e fazer isso em Deinit(). Mas a função Deinit() não estava presente no modelo por padrão. Estou procurando agora - há Deinit() no modelo EA, mas ele não estava lá antes.
Não escreva apagar - tudo vai funcionar corretamente, este pecado (quero dizer superstição) ) ) assumirá o terminal e murmurará no registro "48 bytes de memória vazada", "2 objetos do tipo CX à esquerda" e "objetos não apagados à esquerda".
HH: no modelo indicador não há nenhum Deinit() - isto é irritante
não escrever apagar - tudo vai funcionar corretamente, este pecado (quero dizer superstição)) ) assumirá o terminal e murmurará em seu registro "48 bytes de memória vazada", depois "2 objetos do tipo CX à esquerda" e "objetos não apagados à esquerda".
SZY: em um modelo de criação do indicador não há nenhum Deinit() - ele estica
Funcionará sem apagar, mas é inútil. Mas será que o terminal resolve este problema? Ele apenas relata vazamentos de memória, mas não dedica os mesmos objetos.