Características del lenguaje mql5, sutilezas y técnicas - página 213

Nuevo comentario
 
A100 #:

Y no es necesario cambiar el comportamiento de las funciones existentes - basta con añadir nuevas funciones correctas (con algún prefijo/sufijo) y declarar obsoletas las anteriores con el correspondiente aviso

¿Destruir todo el sentido de FileReadArray? Piensa en estas funciones como una copia de seguridad de un trozo de memoria. Sólo bytes.

 
fxsaber #:

¿Destruye todo el sentido de FileReadArray? Piensa en estas funciones como una copia de seguridad de un trozo de memoria. Sólo bytes.

¿Así que primero quieres crearte dificultades a través de privados, const y luego superarlas heroicamente a través del acceso "directo" a la memoria?

Yo tengo un enfoque diferente: si surge esa necesidad, significa que el programa se diseñó incorrectamente desde el principio

 
A100 #:

Es decir, propones crear primero dificultades para ti mismo a través de la privada, const

Siempre obtengo un gran beneficio de los privados/constantes. Permiten controlar muy bien la arquitectura del programa.

y luego superarlos heroicamente con el acceso "directo" a la memoria?

No hay superación. Todo es muy sencillo y lógico.

Mi enfoque es diferente: si surge esa necesidad, significa que el programa se diseñó mal desde el principio.

Entiendo que están dispuestos a escribir todo en un montón (sin private/const), privando de la comodidad del control arquitectónico en aras de la "pureza" de la POO.

 
Ilyas #:

El archivo... aparecieron cuando la privacidad y la constancia no existían, no pensamos aún en cambiar este comportamiento, ya que no lo consideramos crítico.

CharArray<->Struct aparecieron recientemente, pero funcionan bien con private/const. Esperemos que no se revisen.

 
Para la limpieza del código, los métodos de serialización y deserialización deben ser escritos para las estructuras. Entonces no habrá conflicto de privacidad, y los campos constantes no son constantes si se pueden cambiar durante la deserialización
 
fxsaber #:

Entiendo que estás dispuesto a escribir todo en un montón (sin private/const), privando de la comodidad del control arquitectónico en aras de la "pureza" de la POO.

No entiendes - desde el punto de vista de la POO el objeto es autosuficiente (no necesita funciones externas) - por lo tanto no hay conflicto con private. Y si hay un conflicto con const, como se ha señalado correctamente:

Sois vosotros los que los habéis hecho artificialmente
 
fxsaber #:

Entiendo que estás dispuesto a escribir todo en un montón (sin private/const), privando de la comodidad del control arquitectónico en aras de la POO "pura".

Estás dispuesto a utilizar cualquier laguna de acceso directo a la memoria por comodidad en lugar de utilizar un enfoque canónico menos conveniente pero más seguro.

 
TheXpert #:

más bien lo contrario. estás dispuesto a utilizar cualquier resquicio de acceso directo a la memoria por comodidad en lugar de utilizar el enfoque canónico, menos conveniente pero más seguro.

Dos peticiones:

  1. Muestra el código para guardar y cargar la estructura.
  2. Un ejemplo de los peligros del enfoque no canónico.
 

Bueno, eso es un bicho feroz. Ejemplo:

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]

Se asigna la memoria, se llama al destructor cuando se libera (lo que insinúa el comportamiento esperado según RAII), pero se olvida llamar al constructor cuando se crea el objeto))

 

No lo he visto antes.

1...206207208209210211212213214215216217218219220...247
Nuevo comentario