Características da linguagem mql5, subtilezas e técnicas - página 213

Novo comentário
 
A100 #:

E não há necessidade de alterar o comportamento das funções existentes - basta acrescentar novas funções correctas (com algum prefixo/sufixo) e declarar as funções anteriores obsoletas com um aviso correspondente

Destruir todo o sentido de FileReadArray? Pense nestas funções como uma cópia de segurança de um pedaço de memória. Apenas bytes.

 
fxsaber #:

Destruir todo o objectivo do FileReadArray? Pense nestas funções como uma cópia de segurança de um pedaço de memória. Apenas bytes.

Então, quer primeiro criar dificuldades para si próprio através de um acesso à memória "directo", const e depois superá-las heroicamente?

Tenho uma abordagem diferente - se tal necessidade surgir, isso significa que o programa foi mal concebido desde o início

 
A100 #:

Isto é, propõe-se primeiro criar dificuldades para si próprio através de um processo privado, const

Obtenho sempre grandes benefícios do privado/const. Permitem-lhe controlar muito bem a arquitectura do programa.

e depois vencê-los heroicamente com acesso "directo" à memória?

Nenhuma superação. Tudo é muito simples e lógico.

A minha abordagem é diferente - se tal necessidade surgir, significa que o programa foi concebido erradamente desde o início.

Compreendo que estão prontos para escrever tudo numa pilha (sem privado/const), privando a comodidade do controlo arquitectónico em nome da "pureza" do OOP.

 
Ilyas #:

O Arquivo... apareceu quando a privacidade e a constância não existiam, ainda não pensámos em mudar este comportamento, uma vez que não o consideramos crítico.

CharArray<->Struct apareceu recentemente, mas funcionam bem com private/const. Esperemos que não venham a ser revistas.

 
Para a limpeza de códigos, os métodos de serialização e desserialização devem ser escritos para estruturas. Então não haverá conflito de privacidade, e os campos constantes não são constantes se puderem ser alterados durante a desserialização
 
fxsaber #:

Compreendo que está pronto a escrever tudo numa pilha (sem privado/const), privando a comodidade do controlo arquitectónico em nome da "pureza" do OOP.

Compreende mal - do ponto de vista do OOP o objecto é auto-suficiente (não precisa de funções externas) - por isso não há conflito com o privado. E se houver um conflito com const, como correctamente observado:

Foi você que as fez artificialmente
 
fxsaber #:

Compreendo que está pronto a escrever tudo numa pilha (sem privado/const), privando a comodidade do controlo arquitectónico em nome de OOP "puro".

Está disposto a utilizar quaisquer brechas de acesso directo à memória por conveniência em vez de utilizar uma abordagem canónica menos conveniente mas mais segura.

 
TheXpert #:

pelo contrário. está disposto a utilizar quaisquer brechas de acesso directo à memória por conveniência em vez de utilizar a abordagem canónica menos conveniente mas mais segura.

Dois pedidos:

  1. Mostrar o código para guardar e carregar a estrutura.
  2. Um exemplo dos perigos da abordagem não canónica.
 

Bem, é um insecto feroz. Exemplo:

class C{
   static uint count;
   const uint number;
public:
   C():number(++count){PrintFormat("C[%i]",number);}
  ~C(){PrintFormat("~C[%i]",number);}
   uint Number() const {return number;}
};
uint C::count=0;

void OnStart()
{
  C c[3]={};
  for(int i=0;i<ArraySize(c);Print(c[i++].Number()));
}
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]

A memória é atribuída, o destruidor é chamado quando é libertado (o que indica o comportamento esperado de acordo com a RAII), mas o construtor é esquecido de ser chamado quando o objecto é criado)))

 

Nunca o tinha visto antes.

1...206207208209210211212213214215216217218219220...247
Novo comentário