Perguntas OOP (Object Oriented Programming) - página 8

 
C-4:
Typeid() infelizmente não existe, e a força dos gabaritos está na identificação estática. Tarefas diferentes são resolvidas por métodos diferentes e dizer que um método é ruim e o outro é bom é uma suposição agravante.

Eu tinha um caso em que a identificação dinâmica era necessária. Todas as soluções eram muito incômodas, exceto as do tipo universal. Feito através de uma classe implementando um tipo universal.

Mas eu também me meti em problemas. Algo mudou no STL (string) desde a VS 2012 e, desde então, não será compilado. Ainda não resolvi o problema.

 
Pavlick:

Huh, não são indicações, mas risos em um bastão.


A página no segundo link do meu post diz:

Na MQL4 você pode criar dinamicamente objetos de tipo complexo. Isto é feito utilizando o novo operador, que retorna o descritor do objeto criado.

O descritor tem um tamanho de 8 bytes. Sintaticamente, os descritores de objetos em MQL4 são similares aos ponteiros em C++.

Exemplos:

MyObject* hobject= new MyObject();

Novamente, ao contrário de C++, a variável hobject do exemplo acima não é um ponteiro para a memória, mas um descritor de objeto.


 
EverAlex:

A página no segundo link do meu post diz:

Na MQL4 você pode criar dinamicamente objetos de tipo complexo. Isto é feito utilizando o novo operador, que retorna um descritor do objeto criado.

O descritor tem um tamanho de 8 bytes. Sintaticamente, os descritores de objetos em MQL4 são similares aos ponteiros em C++.

Exemplos:

MyObject* hobject= new MyObject();

Novamente, ao contrário de C++, a variável hobject do exemplo acima não é um ponteiro para a memória, mas um descritor de objeto.

O camarada mql5 esclareceu a situação aqui https://www.mql5.com/ru/forum/150943/page6#950107 . Sem saber, eu estava exagerando.
 

Eu pedi suporte técnico não antes de ontem para separar o arquivo de implementação de classe do arquivo de interface. E eu tenho uma resposta:

В MQL нет файла проекта, фактически им выступает mq4 файл, а программа обязана иметь точки входа (при их отсутствии выдаётся ошибка "event handling function not found"). Поэтому при разделении интерфейса от реализации класса, файлом-реализации и интерфейса должны быть mqh файлы.

O resultado final é que essencialmente não é uma opção lógica. Afinal, o arquivo com a implementação da classe é um arquivo de implementação, a fim de protegê-lo dos clientes. E se ambos estão em uma forma aberta, ou seja, no formato .mqh, então para que precisamos fazer isso de todo?

 
hoz:

Eu pedi suporte técnico não antes de ontem para separar o arquivo de implementação de classe do arquivo de interface. E eu tenho uma resposta:

O resultado final é que esta não é uma opção lógica. Afinal, o arquivo com a implementação da classe é um arquivo de implementação, a fim de protegê-lo dos clientes. E se ambos estão em formato aberto, ou seja, em formato .mqh, então por que fazer tudo isso?

Eu nunca separo a declaração da implementação. Eu escrevo tudo em um arquivo de cabeçalho. Isto é muito mais conveniente. Você tem que acompanhar um arquivo, não dois. Fico feliz se houver apenas três métodos em uma classe. Mas e se forem 100? Você vai ficar cansado de comparar os dois arquivos. Você vai escrever em um e esquecer no outro...

Há apenas um caso quando é necessário dividir os arquivos. É quando duas ou mais classes se referem uma à outra. Tais soluções devem ser evitadas. Isto é verdade para o C++. Eu não sei como fazer isso em MQL.

 

No livro didático, e em particular aqui estão os códigos:

//+------------------------------------------------------------------+
//| Класс, реализующий элемент списка                                |
//+------------------------------------------------------------------+
class CItem
  {
   int               m_id;
   string            m_comment;
   CItem*            m_next;
public:
                     CItem() { m_id=0; m_comment=NULL; m_next=NULL; }
                    ~CItem() { Print("Destructor of ",m_id,
                                     (CheckPointer(GetPointer(this))==POINTER_DYNAMIC)?
                                     "dynamic":"non-dynamic"); }
   void              Initialize(int id,string comm) { m_id=id; m_comment=comm; }
   void              PrintMe() { Print(__FUNCTION__,":",m_id,m_comment); }
   int               Identifier() { return(m_id); }
   CItem*            Next() {return(m_next); }
   void              Next(CItem *item) { m_next=item; }
  };
//+------------------------------------------------------------------+
//| Простейший класс списка                                          |
//+------------------------------------------------------------------+
class CMyList
  {
   CItem*            m_items;
public:
                     CMyList() { m_items=NULL; }
                    ~CMyList() { Destroy(); }
    bool             InsertToBegin(CItem* item);
    void             Destroy();
  };

Os seguintes campos estão disponíveis:

void              Next(CItem *item) { m_next=item; }

 bool             InsertToBegin(CItem* item);
Por que o * em um caso está à direita e no outro à esquerda?
 
hoz:

No livro didático, e em particular aqui estão os códigos:

Há campos como este:

Por que o sinal * num caso é para a direita e no outro para a esquerda?

É o que diz o texto. Isso não importa.

Eu mesmo escrevo o operador "*" para denotar um ponteiro ao lado de um tipo à sua direita (int*) e ao dereferenciar uma variável à sua esquerda (*pnVal).

 
Zhunko:

É o que diz. Isso não importa.

Eu mesmo escrevo o "*" operador para denotar um ponteiro ao lado de um tipo à sua direita (int*) e, ao desreferenciar, ao lado de uma variável à sua esquerda (*pnVal).

Foi o que eu pensei. Talvez um programador desatento tenha escrito a amostra.

Há algumas outras coisas estranhas ali:

 CItem*            m_next;

Isso significa que à classe CItem é atribuído um descritor de objeto m_next?

 
hoz:

No livro didático, e em particular aqui estão os códigos:

Os seguintes campos estão disponíveis:

Por que o * em um caso está à direita e no outro à esquerda?

Não é à esquerda ou à direita, é entre.
 
hoz:

Isso foi o que eu pensei. Acho que um programador desatento escreveu o exemplo.

Há algumas outras coisas estranhas ali:

Isso significa que a classe CItem é atribuída com o descritor de objeto m_next?


Isto significa que uma instância tem que ser criada usando o novo operador.
Razão: