Perguntas sobre OOP em MQL5 - página 8
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
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".
HH: no modelo indicador não há nenhum Deinit() - isto é irritante
Por que não criar um objeto em vez de um ponteiro? Então também não resmungará - o subsistema terminal irá rastreá-lo e pregá-lo quando necessário.
Funcionará sem apagar, mas não adianta. Mas será que o terminal resolve este problema? Ele apenas relata vazamentos de memória, mas não dedica os mesmos objetos.
O terminal se encarregará de apagar os objetos criados por novos, caso as indicações para eles sejam empilhadas em um objeto conhecido pelo terminal, por exemplo, ArrayObj, List, etc...
Por que não criar um objeto em vez de um ponteiro? Então também não resmungará - o subsistema terminal irá rastreá-lo e pregá-lo quando necessário.
porquehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
O terminal se encarregará de apagar os objetos criados por novos, caso as indicações para eles sejam empilhadas em um objeto conhecido pelo terminal, por exemplo, ArrayObj, List, etc...
nem sempre a destruição conveniente sem supervisão, mas terei que verificar, talvez eu esteja errado - raramente uso CObject
porquehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
Este é um caso muito especial e grotescamente simplificado. Para criar um objeto que não pode ser alterado, de modo que para mudar seus campos, é preciso pregá-lo para baixo e criar um novo...
E se precisarmos mudar alguns campos de objeto e deixar outros campos com as informações necessárias? IMHO - melhor cuidar da interatividade e gerenciabilidade de cada objeto (graças à herança), do que sentar-se com uma arma e atirar nos coelhos a cada espirro.
Embora, para ser justo - às vezes é mais rápido matar e criar um novo, do que procurar o objeto desejado entre um grande número e mudá-lo. A menos, é claro, que haja uma ligação direta com ele.
Bem, este é um caso muito especial e grotescamente simplista, na minha opinião. Para criar um objeto absolutamente imutável, de modo que para mudar os valores de seus campos é preciso pregá-lo para baixo e dar à luz um novo...
E se precisarmos mudar alguns campos de objeto e deixar outros campos com as informações necessárias? IMHO - melhor cuidar da interatividade e gerenciabilidade de cada objeto (graças à herança), do que sentar-se com uma arma e atirar nos coelhos a cada espirro.
Embora, para ser justo - às vezes é mais rápido matar e criar um novo, do que procurar o necessário entre um grande número e mudá-lo. A menos, é claro, que você tenha uma ligação direta com ela...
hmmm, você está muito longe da base.... sim, mas não dessa forma ))))
como é conveniente, é assim que você deve usá-lo! - e estes exemplos do "primeiro livro didático c++" podem ser extraídos em sua experiência durante toda sua vida.... como exemplo, desmontei uma parte decente do código do @fxsaber e me fiz usar #define tanto quanto possível - os códigos não só se tornaram mais curtos, mas realmente mais legíveis e eliminaram os erros de digitação - eles ensinam tanto assim em livros em C++? ;)
Embora, para ser justo - às vezes é mais rápido matar e criar um novo, do que procurar um necessário entre um grande número e mudá-lo. É claro, se não houver um endereçamento direto...
e sobre o básico do livro... De acordo com as "boas regras de criação" na programação, é esperado o seguinte: você deve declarar uma variável e inicializá-la imediatamente (isso permite evitar bugs ao depurar), no OOP o construtor serve para esses fins - você criou um objeto e inicializa tudo
se você precisa "puxar o código inteiro após um simples objeto", você precisará de um método para reiniciar todos os campos de classe - por que duplicar isto? - kill/create = resultado.... mas novamente, é uma questão de gosto e religião.
porquehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
nem sempre confortável com a destruição sem supervisão, mas terei que verificar, talvez eu esteja errado - raramente uso CObject
Mas você usa listas. E aí é a mesma coisa. Bem, a menos que a bandeira de gerenciamento de memória FreeMode() não seja reinicializada para a lista - neste caso, o terminal não vai rastrear - tudo é feito pelo usuário. Mas esta situação é necessária para poder mudar, apagar, classificar e fazer algo mais com uma cópia da lista - na verdade a lista é criada com apontadores para objetos, e se você criar uma nova lista uma cópia de uma das listas, e começar a modificar objetos na nova lista (há apontadores para objetos), então na lista original também os objetos serão modificados (porque trabalhamos com apontadores). Isso é para manter o original e mexer na sua cópia, então você precisa soltar a bandeira de gerenciamento de memória para uma cópia: FreeMode(false) - então a cópia torna-se uma cópia independente, e você pode trabalhar com segurança com os objetos nela contidos, sem afetar o original. E lembre-se, que quando você destravar a cópia da lista do subsistema terminal, então para a exclusão de objetos de lista agora nós mesmos nos responsabilizamos. Você pode rastreá-la e excluí-la no OnDeinit(), no caso mais simples e se a lista de cópias for conhecida antes, ou criar uma lista de objetos, que sempre coloca listas recém criadas, não conhecidas antes com a bandeira do gerenciamento manual de memória. Então o terminal rastreará este objeto de lista e apagará corretamente as listas nele empilhadas.
O terminal assumirá a exclusão de objetos criados por novos, caso as indicações para eles sejam empilhadas em um objeto conhecido pelo terminal, por exemplo, ArrayObj, List, etc...
Então também não haverá mensagem de vazamento.
Então também não haverá um relatório de vazamento.
Sim, não vai. Porque não haverá vazamento.
Se nós criamos um novo objeto em algum lugar e recebemos um ponteiro para ele, devemos apagar este objeto pelo ponteiro dado. Isso significa que precisamos rastrear o ponteiro. Para este fim, as listas ou conjuntos de apontadores de objetos, oferecidos em SB, são muito boas. Mas você também pode se encarregar do rastreamento e controle dos objetos recém-criados. Mas, quanto a mim, por que escrever toneladas de código se ele já está fornecido?
então eles devem apagar este objeto por este ponteiro.
Mas, quanto a mim, por que escrever toneladas de código se ele já está fornecido?
De que toneladas estamos falando? Tudo que você perdeu é relatado pelo terminal e o local para apagá-lo também é conhecido - OnDeint() .... Então esta discussão se resumiu a uma discussão de um cavalo esférico no vácuo? )))
hmm, você só pode estar brincando comigo..... assim, mas não assim ))))
como é conveniente, é assim que você deve usá-lo! - e estes exemplos do "primeiro livro didático s++" podem ser extraídos em sua experiência durante toda sua vida.... como exemplo, desmontei uma parte decente do código do @fxsaber e me fiz usar #define tanto quanto possível - os códigos não só se tornaram mais curtos, mas realmente mais legíveis e eliminaram os erros de digitação - eles ensinam tanto assim em livros em C++? ;)
E sobre o básico do livro... As boas regras de criação dizem: proclamar uma variável e inicializá-la imediatamente (isto permite evitar bugs ao depurar), no OOP o construtor serve para este fim - você criou um objeto e inicializa tudo
se você precisa "puxar o código inteiro após um simples objeto", você precisará de um método para reinicializar todos os campos de classe - por que duplicar isto? - kill/create = resultado.... mas novamente, é uma questão de gosto e religião.
Não estou falando da reinicialização completa de um objeto, mas parcial - quando um par de campos precisa ser mudado e o resto de dezenas de campos ainda armazenam as informações de que você precisa... Podemos ou não querer mudar os campos, mas precisamos de métodos para mudá-los. A menos que - novamente - estejamos falando de um simples objeto com um campo. Se houver dois ou mais - talvez você já precise mudar um, deixando os outros inalterados.
Mas talvez estejamos falando de coisas diferentes?