MQL5 O compilador não faz distinção entre uma classe e um ponteiro para ela - página 11

Novo comentário
 
Ilya Malev:

Este aqui: (* ) não é necessário aqui.

* é necessário no µl somente quando as operações =, ==, !=, !& ou ||| são aplicadas diretamente no * ponteiro

IMHO é exatamente o que você precisa, para que não esqueça com o que está lidando (um objeto ou um ponteiro para ele).

Ilya Malev:

(Se você quiser removê-lo novamente e fingir que ele nunca existiu)))

Portanto, sim. Um maior desenvolvimento com indicadores levará a um clone completo de C++.

Talvez eles vão na direção do C# onde "código gerenciado" não tem ponteiros, mas tudo tem um objeto, mesmo os tipos comuns bool int duplo, etc.

 
Ilya Malev:

E também, a propósito, pode muito bem ser que como todos os canais oficiais (fórum, ajuda, documentação) são silenciosos sobre o operador *, talvez os administradores estejam pensando em removê-lo novamente, e fingir que ele nunca existiu))) Portanto, é perigoso confiar em seu uso em geral no momento imho.

O silêncio é provavelmente porque 99,9% dos usuários não se importam com tudo isso. Por que incomodar seus cérebros com informações desnecessárias? E aqueles que precisavam, pediam e recebiam.

Você também não se importou com essa característica até agora, não é mesmo? E agora você está desesperadamente começando a inventar desculpas porque não sabia disso ;) Que diferença faz quando ela foi introduzida: imediatamente ou após meses? Você ainda não teria sabido disso se eu não lhe tivesse dito )

 

Hmmm... Talvez também haja indicações para a matriz ? Vou ter que verificar... Tenho tantas saudades deles...

 
Georgiy Merts:

Hmmm... Talvez também haja indicações para a matriz ? Vou ter que verificar... Tenho tantas saudades deles...

Não. Você tem que colocar arrays nas aulas, eles têm indicações.

 
Ilya Baranov:

Não. Você tem que colocar arrays nas aulas, eles têm indicações para eles.

Sim, infelizmente.

Na verdade, as aulas derivadas de CArray são bastante úteis para mim. A única coisa para a qual quero apontadores de arrays é indicadores, eles passam referências a arrays, e eu tenho que "arrastar" essas referências através de toda a hierarquia de objetos, o que é muito inconveniente...

Uma vez sugeri fazer apontadores para arrays, ou fazer uma função indicadora que usaria apontadores para arrays de bibliotecas padrão, em vez de links de arrays, mas infelizmente, fui rejeitado com o argumento de que "se permitirmos apontadores para arrays, será possível usar arrays não inicializados", embora os desenvolvedores não tenham tais medos com objetos... Sim, bem, vou deixar isso para a consciência deles.

 
Georgiy Merts:

2. a MQL não tem que apagar o que não selecionou. Dmitriy estava logo acima - criar um objeto - apagá-lo. Não gosto da prática do "coletor de lixo" em C#, quando os objetos são apagados não quando eu quero, mas quando o coletor quer que eles sejam apagados.

O colhedor C# nunca removerá um objeto vivo ou um ponteiro. Seu objetivo é remover o lixo do amontoado e às vezes desfragmentá-lo.

 
Alexey Volchanskiy:

Nunca um assembler C# apagará um objeto vivo ou um ponteiro. Seu objetivo é remover o lixo do monte de cadáveres e, às vezes, desfragmentá-lo.

Não estou dizendo que o coletor de lixo vai apagar um objeto vivo ou um ponteiro. O que estou dizendo é que ele irá apagá-lo quando quiser. E isto, em minha opinião, não é bom.

Eu posso trabalhar com ou sem eliminação. E eu posso até fazer pontos inteligentes... Entretanto, penso que a eliminação de objetos deve ser possível e a pessoa que a criou deve eliminar o objeto.

Esse é o tipo de temporizador da velha escola que sou.

 
SemenTalonov:

Provavelmente, eles irão na direção do C# onde "código gerenciado" não tem ponteiros e tudo tem um objeto, mesmo tipos simples bool int duplo, etc.

Sim, mas eles ainda deixam a possibilidade de trabalhar com ponteiros em código não administrado. É verdade, tal código tem restrições de distribuição.

 
Georgiy Merts:

Não estou dizendo que o coletor de lixo vai apagar um objeto vivo ou um ponteiro. O que estou dizendo é que ele irá apagá-lo quando quiser. E isto, em minha opinião, não é bom.

Eu posso trabalhar com ou sem eliminação. E eu posso até fazer pontos inteligentes... Mas, no entanto, acho que os objetos devem ser excluídos, e quem os criou deve excluí-los.

Esse é o tipo de temporizador da velha escola que sou.

Georges, você daria um exemplo, eu não o entendo. É isso que você quer dizer? Acho que você mesmo pode fazer pontos inteligentes.

bool first = false;

int Foo()
{
  int i;
  if(!first)
  {
     first = true; 
     i = 123;
  }
  return i;   
}

// И ты будешь надеятся, что i сохранит свое значение между сотней вызовов Foo? Может да (очень редко, если Foo вызывается 100 раз подряд), а может и нет.
 
Alexey Volchanskiy:

Georges, você me dá um exemplo, eu não o entendo. É isso que você quer dizer? Provavelmente é possível fazer você mesmo pontos inteligentes.

Não. É claro que neste caso a variável deve ser apagada na saída do bloco.

Estou falando de objetos criados por novos:

CMyObj* pmoObject  = new CMyObject;

A norma C# especifica:"Tanto objetos do tipo valor, como estruturas, quanto objetos do tipo referência, como classes, são destruídos automaticamente, mas objetos do tipo valor são destruídos quando o contexto que os contém é destruído, enquanto objetos do tipo referência são destruídos pelo coletor de lixo indefinidamente depois que a última referência a eles é removida".

Aqui, eu não gosto deste "tempo indefinido". Embora, vou até admitir que o coletor de lixo pode apagar um objeto muito mais eficientemente do que eu, apagando o objeto no destruidor da classe que o criou.

1...45678910111213
Novo comentário
Razão: