Mi enfoque. El núcleo es el motor. - página 4

Nuevo comentario
 
La POO no interfiere en la implementación del núcleo, sino todo lo contrario.
Normalmente hay código y datos. El núcleo, en nuestro caso, es el código, fuertemente separado de los datos. Los datos también pueden ser el propio código. El núcleo suele tener una funcionalidad más completa para manejar datos específicos, o al menos un mínimo autosuficiente.
Este enfoque permite utilizar el formato de datos más conveniente, se supone que habrá muchos datos.
He aquí otro ejemplo en el que se puede aplicar este enfoque: hay muchas estrategias en el Asesor Experto, los datos representan sólo la lógica de las estrategias, el núcleo es la funcionalidad para gestionarlas, es decir, la gestión de órdenes, la gestión de riesgos, el trabajo con el entorno de negociación, los indicadores, el manejo de errores, la visualización de algunas o todas las estadísticas, las funciones de seguimiento/grid/.....
 

Реter Konow:

Creas un array y escribes en él los valores de las propiedades del botón que quieres crear.

Un botón consta de tres objetos: Base, Texto, Imagen.

Cada objeto existe dentro de un elemento de botón, por lo que la matriz debe ser bidimensional.

Así que, por qué molestarse con todas esas matrices cuando puedes (y debes) usar una estructura para ello. Y podemos dirigirnos a estos valores de forma humana: por el nombre del campo, no por el índice (lo que puede provocar muchos errores tontos).

Como resultado, en lugar de un array bidimensional habrá un array de estructuras. La declaración es igual de concisa, pero la simplicidad y fiabilidad es mucho mayor, además de un uso racional de la memoria, ya que cada campo tiene su propio tipo. Y la POO no tiene nada que ver.

He aquí un ejemplo:

struct TObject { char type;  string name;  int x;  int y;  int width;  int height;  color clr; };

TObject Objects[]= { { OBJ_BITMAP, "Bitmap", 100, 100, 200, 200, clrRed },
                     { OBJ_BUTTON, "Button", 150, 150, 50, 10, clrWhite },
                   };
 
Alexey Navoykov:


El resultado es un array de estructuras en lugar de un array bidimensional. La declaración es la misma, pero la comodidad y la fiabilidad son mucho mayores, además del uso racional de la memoria, ya que cada campo tiene su propio tipo. Y la POO no tiene nada que ver en absoluto.


Es un poco ambiguo... ¿qué es mejor, un array de estructuras o una estructura de arrays?

pero MQL está diseñado para trabajar con arrays Forthran, eso es un hecho...

 
Maxim Kuznetsov:

Hay un pequeño dilema aquí... ¿qué es mejor, una matriz de estructuras o una estructura de matriz?

¿De qué tipo de estructura de array estamos hablando? El autor sólo tiene arrays

 

No creo que Peter haya visto nunca cómo crear una plantilla DialogBox en Visual C++, arrastrar y soltar cualquier Control en ella, como Button, CheckBox, EditBox, ComboBox, etc.

En otras palabras, los elementos que se pueden ver en Windows, incluyendo diferentes opciones para mostrar las cadenas de BD con ajustes de campo y de cadena.

Y con el uso de MFC se pueden hacer cuadros de diálogo bastante complejos en pocos minutos y muy brevemente.

 
Alexey Navoykov:

Y por qué todas estas perversiones con un array, cuando se puede (y debe) utilizar una estructura para este propósito. Se inicializa exactamente de la misma manera - con valores, separados por comas. Y se puede acceder a estos valores humanamente - por nombre de campo, no por índice (lo que puede llevar a muchos errores tontos).

Como resultado, en lugar de un array bidimensional habrá un array de estructuras. La declaración es igual de concisa, pero la simplicidad y fiabilidad es mucho mayor, además de un uso racional de la memoria, ya que cada campo tiene su propio tipo. Y la POO no tiene nada que ver.

He aquí un ejemplo:

Es una buena solución. Pero esta estructura no puede integrarse en el núcleo. Si al construir un núcleo según mi tecnología, basta con hacer un bucle en el array con los elementos del prototipo y reescribirlos en el núcleo, en el caso de tu solución, el bucle es imposible.

Aunque podría ser posible, pero cada elemento debería estar envuelto en una estructura separada. ¿Y cómo mostrarlo en el ámbito global? Dónde declararlo todo... No está claro.

La mía es sencilla. Una matriz de prototipos de elementos. Todas las propiedades de los objetos están dentro de ella. La propia matriz es global. El acceso es el más sencillo y desde cualquier punto del programa.

 
¿No se resiste tu intestino a usar dobles? Después de todo, también es un objeto compuesto con sus propios métodos. No hay lugar para ellos en las matrices ortodoxas del núcleo. Mira, porque es impresionante (mantisa, exponente, signo):
_NEW_OBJECT, тра-та-та-та-та-та, 3, 10, 1, тра-та-та-та-та-та
 
pavlick_:
¿No se resiste tu intestino a usar dobles? Después de todo, también es un objeto compuesto con sus propios métodos. No hay lugar para ellos en las matrices del núcleo ortodoxo. Mira, es impresionante (mantisa, exponente, signo):

No lo entiendo.

 

Me deshago de la sintaxis innecesaria y de la pandereta, simplemente inicializo las propiedades de los elementos en un array global de prototipos.

Se utiliza sólo una vez: cuando se reescriben los prototipos de elementos en el Kernel.

La reescritura se realiza en un simple bucle.

Como resultado, en la etapa de construcción, el Kernel comienza a contener prototipos de elementos seleccionados por el usuario.

A continuación, comienzan nuevos ciclos en el Kernel. En ellos, escribo los valores definidos por el usuario de las propiedades de los elementos.

Al final, se obtiene un Kernel terminado, que contiene las ventanas de usuario terminadas con todos los elementos.

 

El proceso descrito anteriormente lo llamo "proceso de construcción del núcleo".

Una vez construido el núcleo, el "motor" comienza a funcionar.

El motor es el código que controla la mecánica de los elementos.

El motor sólo está capacitado para trabajar con el Kernel. Su motor son varios eventos (la mayoría procedentes de OnChartEvent()).

1234567891011...184
Nuevo comentario