¿Es posible implementar un patrón singleton en MQL4? - página 2

 
Pero por alguna razón hay muchos errores en tiempo de compilación. ¿Qué pasa?

De qué pateras podemos hablar si no sabes lo básico, ni siquiera podrías crear un campo de clase estática correctamente.

(hay muchos artículos sobre singleton en hobber, para qué sirve, cómo hacerlo y qué tiene de malo).

¿Singleton o clase estática?
Uso del patrón singleton
 
ALXIMIKS:

(hay muchos artículos en el Hubra sobre el singleton y para qué sirve, y cómo, y qué tiene de malo)

¿Singleton o clase estática?
Utilizando el patrón Singleton.

¿Crees que no me he encontrado con esto? No he entendido muy bien cómo funciona. El asunto es el siguiente. Pero resulta que no necesito un singleton. Así que me conformaré con los miembros estáticos.

ALXIMIKS:

Como podemos hablar de paternales si no sabes lo básico, ni siquiera pudiste crear un campo de clase estática correctamente.

Si sabes cómo, puedes corregirlo. Ayer escribí según la documentación. Pero también hay muchos errores. Así:

struct Symbol_Properties
{
   static datetime    gdt_Quote;           // Время поступления последней котировки
   static double      gda_Price [2];       // Текущие рыночные цены (0 - Bid, 1- Ask)
   static double      gd_Spread;           // Размер спреда в пунктах
   static double      gd_Swap;             // Своп
   static double      gd_Comission;        // Комиссия
   static double      gd_Pt;               // Величина одного пункта
   static int         gi_Digits;           // Количество знаков в цене после запятой
   static int         gi_StopLevel;        // Минимально-допустимый уровень стоп-лосса/тейк-профита в пунктах
   static int         gi_FreezLevel;       // Уровень заморозки ордеров в пунктах
};
int Symbol_Properties::gdt_Quote = 0;
int Symbol_Properties::gda_Price = 0;
int Symbol_Properties::gd_Spread = 0;
int Symbol_Properties::gd_Swap = 0;
int Symbol_Properties::gd_Comission = 0;
int Symbol_Properties::gd_Pt = 0;
int Symbol_Properties::gi_Digits = 0;
int Symbol_Properties::gi_StopLevel = 0;
int Symbol_Properties::gi_FreezLevel = 0;

¿Qué es lo siguiente?

 
static double       gd_Spread; 
int  Symbol_Properties::gd_Spread = 0;
¿no está triste por nada?
 
Естественно, создавать несколько объектов в разных классах данных структур крайне не рекомендуется.
Dime de qué se trata. Y traduce la cita anterior con más claridad, por desgracia no entiendo nada, gracias.
 

Me equivoqué. De todos modos, la versión actual es correcta aquí:

struct Symbol_Properties
{
   static datetime    gdt_Quote;           // Время поступления последней котировки
   static double      gda_Price [2];       // Текущие рыночные цены (0 - Bid, 1- Ask)
   static double      gd_Spread;           // Размер спреда в пунктах
   static double      gd_Swap;             // Своп
   static double      gd_Comission;        // Комиссия
   static double      gd_Pt;               // Величина одного пункта
   static int         gi_Digits;           // Количество знаков в цене после запятой
   static int         gi_StopLevel;        // Минимально-допустимый уровень стоп-лосса/тейк-профита в пунктах
   static int         gi_FreezLevel;       // Уровень заморозки ордеров в пунктах
};

datetime   Symbol_Properties::gdt_Quote = 0;
double     Symbol_Properties::gda_Price [2] = {0.0, 0.0};
double     Symbol_Properties::gd_Spread = 0;
double     Symbol_Properties::gd_Swap = 0;
double     Symbol_Properties::gd_Comission = 0;
double     Symbol_Properties::gd_Pt = 0;
int        Symbol_Properties::gi_Digits = 0;
int        Symbol_Properties::gi_StopLevel = 0;
int        Symbol_Properties::gi_FreezLevel = 0;

Entiendo, ¿ahora me refiero a cada variable estática con un nombre tan largo?

Symbol_Properties::gd_Spread = 0;

O es más fácil implementarlo para que después de la descripción de la estructura de inicialización de la variable cuando se inicialice el miembro estático correspondiente se asigne a alguna variable de tipo:

double Spread = Symbol_Properties::gd_Spread = 0;

Y luego en el código referirse a las variables estáticas correspondientes por esta variable, ¿verdad?

 
hoz:

Sí, bueno... Lo principal es queVadim lo sabe :)))))

Sí, es un tipo de diálogo normal:

P: Mis amigos me han recomendado unos dulces. ¡Es justo lo que necesito!

Yo: (Desconcertado... ¿Qué tiene que ver esto con los dulces? Tal vez B vaya a la fiesta de cumpleaños de un amigo o quiera invitar a los niños, tal vez a los suyos o a los de otra persona. Tal vez se metió en el negocio y ahora vende caramelos. Tal vez era el último caramelo en Bielorrusia y B es ahora un monopolio. ¿Y si B echaba de menos los dulces? Muchas otras ideas pasaron por mi cabeza sobre el tema "por qué los caramelos y qué hacer con ellos". Una vez más, como antes con B, mis habilidades telepáticas me fallaron. No se me ocurrió nada).

Ni una pista.

Por si acaso. Es de mala educación publicar diálogos sin el consentimiento de todos los implicados en la conversación. Es mezquino.
 

1. ¿Para qué sirve todo esto?

2. Hay dos formas de acceder a los campos estáticos de una clase (la estructura es una clase de acceso público por defecto y por herencia):

(a) A través del espacio de nombres de la clase - por ejemplo,Symbol_Properties::gd_Spread

(double Spread = Symbol_Properties::gd_Spread) - el valor deSpread se hace igual agd_Spread de la claseSymbol_Properties

(double Spread = Symbol_Properties::gd_Spread =0) valor degd_Spread de laclase Symbol_Properties y el valor deSpread se hace igual a 0

b) crear un objeto de clase (por ejemplo,Symbol_Properties obj; ) y referirse a él como un campo habitual de la clase a través de este objeto

(double Spread = obj.gd_Spread)

(double Spread = obj.gd_Spread =0)

 
ALXIMIKS:

1. ¿Para qué sirve todo esto?

La comodidad... Después de todo, si estas variables se utilizan en una sola instancia, ¿por qué debería crear un objeto? Además, es mucho más cómodo leer el código cuando se hace referencia a una variable, si VARIABLE.VARIABLE NOMBRE.

ALXIMIKS:

2. Hay dos formas de acceder a los campos estáticos de la clase (la estructura es una clase con acceso público por defecto y herencia)

(a) a través del espacio de nombres de la clase - por ejemplo,Symbol_Properties::gd_Spread

(double Spread = Symbol_Properties::gd_Spread) - el valor deSpread se hace igual agd_Spread de la claseSymbol_Properties

(double Spread = Symbol_Properties::gd_Spread =0)- el valorgd_Spread de la claseSymbol_Properties y el valorSpread se hace igual a 0

¡Exactamente! Por eso lo hice así. Inmediatamente inicializo la variable que se refiere a la variable de esta estructura por cero y luego se almacena en la memoria de forma permanente. Lo cual es lógico, porque estas variables se necesitan en una sola instancia. Por eso no hay razón para crear un objeto diferente en este caso. Después de todo, es lógico... ¿No estás de acuerdo conmigo?

ALXIMIKS:

b) Crear un objeto de clase (por ejemploSymbol_Properties obj; ) y referirse a él como un campo de clase normal a través de este objeto

Entonces las variables no serán estáticas, y no hay garantía de que no mantengan sus valores a medida que el programa se ejecuta.
 
¿Qué hay de malo en las VARIABLES ESTÁTICAS, o en las constantes, por ejemplo?
 

STATE VARIABLE no me gustó, porque se utilizan en diferentes clases. Así que los agrupé.

Las constantes no gustan porque las constantes no cambian sus valores, mientras que estas variables deberían poder cambiar sus valores.