OOP, modelos e macros em mql5, sutilezas e usos - página 13

Novo comentário
 

Ainda ontem estávamos discutindo sobre este bug com métodos abstratos, mas hoje encontrei o mesmo bug em meu código ) eu costumava ter um método virtual não abstrato na classe base, então eu me referia a ele a partir de classes herdadas, então decidi tornar o método abstrato, mas o compilador não me informou que ele não era mais referível. Como resultado, o erro de recorrência foi o mais desagradável e difícil de detectar, e eu matei muito tempo. Agora eu acho que essa característica com o corpo do método abstrato padrão será muito útil aqui, pelo menos até que este bug seja corrigido.

 
Alexey Navoykov:

Sim, para tornar o mais conveniente possível a atribuição de moscas a costeletas, e ninguém sequer piscou um olho )

Se o processo de atribuição está trazendo moscas para as costeletas (ou produz um erro se não for possível), não há nada de errado com ele.

Alexey Navoykov:

1.Bem, então é apenas classe A. Por que declarar um padrão se seu parâmetro não tem nenhum significado a ver com o comportamento da classe?

2) Isso é um problema demais. Transferindo o controle de tipo para a etapa de execução. Seus códigos levarão anos para serem depurados

1. "Apenas classe A" não pode conter um campo de tipo arbitrário sem sua (classe) parametrização. E sem aqueles que dançam ao redor, que descrevi, é impossível fazer um manuseio uniforme de um parâmetro de classe por referência e por valor.

2. Você já o tem como um mantra - neste caso, um registro absolutamente inequívoco garantindo que F é T, ou seja, como se não houvesse registro do segundo modelo. mas não. Mais uma vez "Vou passar anos a depurar" ))))))

 
Ilya Malev:

1. "Apenas classe A" não pode conter um campo de tipo arbitrário sem sua (classe) parametrização. E sem os ajustes que descrevi, é impossível fazer um tratamento uniforme de um parâmetro de classe por referência e por valor.

2. Você já o tem como um mantra - neste caso, um registro absolutamente inequívoco garantindo que F é T, ou seja, como se não houvesse registro do segundo modelo. mas não. Novamente "Passarei anos depurando mais tarde" ))))))

E por que você está respondendo neste tópico? Código em um lugar, discussão em outro... )

1. Sim, tudo pode ser feito humanamente, e quase sem dançar:

struct __A
{
  template<typename T>
  void f(T&) { }  // Сюда структуры и классы
};

struct A : __A
{
  template<typename T>  
  void f(T) { }  // Сюда простые типы и указатели
};

2. não era disso que eu estava falando, mas não importa.

 
Alexey Navoykov:

Por que você está respondendo neste tópico? Código em um lugar, discussão em outro... )

1. Sim, tudo pode ser feito de uma forma humana, e quase sem dançar:

2. havia algo mais lá, mas a questão não é essa.

Ainda não é como se você fosse um moderador, para determinar em qual linha o que é mais apropriado. E os moderadores já deixaram claro que as discussões de características não devem ser realizadas no ramo de características em si, mas em um ramo separado, ou seja, aqui.

Em sua descrição, não está nada claro como se referir uniformemente a um método de classe por referência e por um valor do tipo T. Não sei o que você quer dizer com isso, mas era exatamente o que eu queria dizer ali.

 
Ilya Malev:

Ainda não é como se você fosse um moderador, para determinar quais fios são mais apropriados. E os moderadores já deixaram claro que a discussão das características não deve ser realizada no ramo das características, e em uma linha separada, ou seja, aqui.

Então, se um moderador quer movê-lo, isso é uma coisa, mas por que criar a confusão você mesmo? Eu, por exemplo, não tenho nenhum desejo de correr através dos fios.

 
Alexey Navoykov:

Então, se um moderador quer movê-lo, isso é uma coisa, mas por que criar a confusão você mesmo? Eu, por exemplo, não tenho nenhum desejo de correr através dos fios.

Se você sabe que um moderador faria algo assim, é sempre melhor fazê-lo você mesmo em vez de esperar que um moderador o faça. Entretanto, discutir as ações dos moderadores também não é um dos menus favoritos dos moderadores, portanto, seria melhor se parássemos com isso.

 
Alexey Navoykov:
Сюда простые типы и указатели

Para os indicadores, a propósito, é lógico fazer um método separado com o argumento T*, porque definitivamente não há confusão, e o benefício é que na maioria das vezes os indicadores de manuseio são diferentes dos tipos regulares (verificação de validade, exclusão, etc.)

 
Alexey Navoykov:

Código em um lugar, discussão em outro

Aqui está o código:

template<typename T>
class A
 {
public:
  A* operator<<(T&p){ Print("<< &",typename(T)); return &this; }
  template<typename F>
  A* operator<<(F p){ Print("<< ",typename(F)); return &this; }
 };

Na verdade existe outra solução além desta entrada: listar por nome todos os tipos simples passados por valor e depois escrever um método modelo com &, então também não haverá erro. Esta opção é adequada para classes sem parametrização intrínseca

 
Ilya Malev:

Se você perceber que um moderador provavelmente faria exatamente isso - é sempre melhor fazê-lo você mesmo, em vez de esperar que um moderador o faça. Entretanto, discutir as ações dos moderadores também não é um menu favorito dos moderadores, então seria melhor se parássemos com isso.

Um moderador certamente não dividiria a discussão em tópicos diferentes. Você provavelmente está tão ansioso até mesmo para se banir,"sem esperar que um moderador o faça")
 
Ilya Malev:

Se você perceber que um moderador provavelmente faria exatamente isso - é sempre melhor fazê-lo você mesmo, em vez de esperar que um moderador o faça. Entretanto, discutir as ações dos moderadores também não é um menu favorito dos moderadores, então seria melhor se parássemos com isso.

1. Seria melhor começar a falar sobre algo imediatamente, onde esse "algo" está localizado, em vez de pensar em como o moderador o faria. Caso contrário, tudo realmente se desfez em dois fios e agora, mesmo que um moderador decida que a discussão deve estar lá ou não, é uma tarefa bastante trabalhosa mover a discussão de forma normal, preservando a ordem e o significado dos cargos.

2 Discutir as ações de um moderador não é todo espirro... Não é todo espirro, mas quando você os desafia publicamente, seja para restaurar a ordem ou para acalmar um frenesi. E se você tem uma opinião, quem o proíbe de expressá-la? Talvez sua opinião seja uma sugestão muito racional, mas você tem medo de dizê-lo, para não cair no menu não amado do moderador? Então isso é uma besteira :)

1...67891011121314151617181920...28
Novo comentário
Razão: