Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Señores, ¿por qué no intentamos tener una discusión de fondo? :)
Una hoja correcta no debería requerir la implementación explícita de una nueva clase para utilizarla en una clase arbitraria.
Por lo tanto, la implementación correcta debería basarse en plantillas.
Para ser justos, no estoy seguro de que esto sea realizable en el nivel de plantilla presentado.
Pero eso está muy lejos de los problemas del artículo.
Una lista correcta no debería requerir la implementación explícita de una nueva clase para utilizarla para una clase arbitraria...
Condicionalmente, CList debe incluir diferentes tipos de nodos....
¿Por qué? ) Un contenedor es un conjunto de objetos homogéneos.
La diferencia de los objetos en sí se puede realizar por polimorfismo dentro de ya los objetos y no tiene nada que ver con la lista.
¿Por qué? ) Un contenedor es un conjunto de objetos homogéneos.
La diferencia de los objetos en sí puede realizarse mediante polimorfismo dentro de los propios objetos y no tiene nada que ver con la lista.
Una hoja correcta no debería requerir la implementación explícita de una nueva clase para poder utilizarla en una clase arbitraria.
Por lo tanto, una implementación correcta debería basarse en plantillas.
Para ser justos, no estoy seguro de que esto sea realizable al nivel de plantilla presentado.
Pero eso está muy lejos de los problemas del artículo.
Lo que propone TheXpert parece estar claro.
Si entiendo bien su idea, todos los métodos de alguna lista abstracta deberían reconocer automáticamente "su" nodo (esto es polimorfismo).
En el artículo, por ejemplo, hay clases de usuario CiSingleList (Fig.9), CDoubleList (Fig.11), CiUnrollDoubleList (Fig.12), CiCircleDoubleList (Fig.13).
Así que, en principio, todos ellos se pueden meter en una sola clase. Pero tendremos que codificar cada método para que reconozca el tipo de nodo del que se ocupa en cada momento. Y esto también requerirá un recurso... así que no todo está tan claro....
Está claro que una lista determinada incluye nodos homogéneos. Lo que quería decir es que las relaciones entre los nodos de esa lista pueden ser diferentes, lo que requiere una clase de lista diferente para cada tipo de nodo. Si se pudiera crear la misma clase de lista para nodos de distintos tipos, sería estupendo..... Personalmente aún no lo he probado..... Hay que pensar en el nivel superior de abstracción.....
Lo que propone TheXpert parece estar claro.
Si entiendo bien su idea, todos los métodos de alguna lista abstracta deberían reconocer automáticamente "su" nodo (esto es polimorfismo).
En el artículo, por ejemplo, hay clases de usuario CiSingleList (Fig.9), CDoubleList (Fig.11), CiUnrollDoubleList (Fig.12), CiCircleDoubleList (Fig.13).
Así que, en principio, todos ellos se pueden meter en una sola clase. Pero tendremos que codificar cada método para que reconozca el tipo de nodo del que se ocupa en cada momento. Y esto también requerirá un recurso... así que no todo está tan claro...
¿Qué hay que codificar?
Primer grado, segundo trimestre. Desafortunadamente, no puedes prescindir de un intermediario comunitario, porque MQL5 tiene un control de tipos extremadamente débil. Pero si tuviéramos a nuestra disposición una función ClassToString como EnumToString(), todo podría organizarse de forma mucho más elegante y sencilla.