Discusión sobre el artículo "Fundamentos de programación en MQL5 - Listas" - página 6

 
papaklass:

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.

 
TheXpert:


Una lista correcta no debería requerir la implementación explícita de una nueva clase para utilizarla para una clase arbitraria...

¿Entiendo correctamente que aunque los nodos (elementos de la lista) tengan diferente tipo y forma de conexión entre ellos, la lista debería seguir teniendo la misma implementación, es decir, referirse al mismo tipo de datos? Condicionalmente CList debería incluir diferentes tipos de nodos (CSingleNode, CDoubleNode, etc.)...
 
denkir:
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.

Когда нужно использовать указатели в MQL5
Когда нужно использовать указатели в MQL5
  • 2010.03.25
  • MetaQuotes Software Corp.
  • www.mql5.com
Все объекты в MQL5 по умолчанию передаются по ссылке, но есть возможность использовать и указатели объектов. При этом есть опасность получить в качестве параметра функции указатель неинициализированного объекта. В этом случае работа программы будет завершена критически с последующей выгрузкой. Автоматически создаваемые объекты как правило такой ошибки не вызывают, и в этом отношении они достаточно безопасны. В этой статье мы попробуем разобраться в чем разница между ссылкой и указателей, когда оправдано использование указателей и как написать безопасный код с использованием указателей.
 
TheXpert:

¿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.

Está claro que una lista concreta 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..... Necesidad de pensar en un mayor nivel de abstracción.....
 
TheXpert:

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.

Como odio admitir, el experto tiene razón aquí. Idealmente, la clase leaf debería implementarse en plantillas. Aunque la CList estándar está implementada en CObject.
 

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....

Когда нужно использовать указатели в MQL5
Когда нужно использовать указатели в MQL5
  • 2010.03.25
  • MetaQuotes Software Corp.
  • www.mql5.com
Все объекты в MQL5 по умолчанию передаются по ссылке, но есть возможность использовать и указатели объектов. При этом есть опасность получить в качестве параметра функции указатель неинициализированного объекта. В этом случае работа программы будет завершена критически с последующей выгрузкой. Автоматически создаваемые объекты как правило такой ошибки не вызывают, и в этом отношении они достаточно безопасны. В этой статье мы попробуем разобраться в чем разница между ссылкой и указателей, когда оправдано использование указателей и как написать безопасный код с использованием указателей.
 
Es bueno ver que la justicia prevalece al menos de vez en cuando. ))
 
denkir:
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.....
Sólo necesitas un tipo de nodo. Ver la implementación del CObject estándar y la implementación de las colecciones CArray, CList, CTree: Referencia MQL5 --> Librería Estándar --> Clases para Organización de Datos.
Документация по MQL5: Стандартная библиотека
Документация по MQL5: Стандартная библиотека
  • www.mql5.com
Стандартная библиотека - Документация по MQL5
 
...es mucho trabajo. Prácticamente, ¿quién me va a enseñar?
 
denkir:

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?

#include <Object.mqh>
#include <Arrays\ArrayObj.mqh>

enum ENUM_CLASS_TYPE
{
   HUMAN,
   ANIMAL,
   CAR
};

class Community : public CObject
{
   public:
      ENUM_CLASS_TYPE TypeCommunity(){return type;}
   protected:
      Community(ENUM_CLASS_TYPE cType)
      {
          type = cType;
      }
      
   private:
      ENUM_CLASS_TYPE type;
};

class Human : public Community
{
   public:
      Human() : Community(HUMAN){;}
      int IQ(){return 90;}
};

class Animal : public Community
{
   public:
      Animal() : Community(ANIMAL){;}
      int CountLegs(){return 4;}
};

class Car : public Community
{
   public:
      Car() : Community(CAR){;}
      int Speed(){return 20;}
};

void OnStart()
{
   CArrayObj elements;
   CObject* object = NULL;
   while(elements.Total() < 100)
   {
      switch(rand()%3)
      {
         
         case HUMAN:
            object = new Human();
            break;
         case ANIMAL:
            object = new Animal();
            break;
         case CAR:
            object = new Car();
            break;
      }
      elements.Add(object);
   }
   while(elements.Total() > 0)
   {
      Community* AnyObject = elements.At(0); 
      switch(AnyObject.TypeCommunity())
      {
         case HUMAN:
         {
            Human* human = AnyObject;
            printf("Element is Human, it's IQ is: " + (string)human.IQ());
            break;
         }
         case ANIMAL:
         {
            Animal* animal = AnyObject;
            printf("Element is anima, it has " + (string)animal.CountLegs() + " legs.");
            break;
         }
         case CAR:
         {
            Car* car = AnyObject;
            printf("Element is car. It has speed " + (string)car.Speed() + " km/h");
            break;
         }
      }
      elements.Delete(0);
   }
}
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.