MQL5 El compilador no distingue entre una clase y un puntero a ella - página 11

Nuevo comentario
 
Ilya Malev:

Este: (* ) no es necesario aquí.

* se necesita en la µl sólo cuando las operaciones =, ==, !=, !& o || se aplican directamente al * puntero

Esto es exactamente lo que se necesita, en mi opinión, para no olvidar con qué se está tratando (un objeto o un puntero a él).

Ilya Malev:

(Si quieres eliminarlo de nuevo y hacer como si nunca hubiera existido))

Así que, sí. Un mayor desarrollo con punteros conducirá a un clon completo de C++.

Tal vez vayan en la dirección de C#, donde el "código gestionado" no tiene punteros pero todo tiene un objeto, incluso los tipos comunes bool int double, etc.

 
Ilya Malev:

Y también, por cierto, es muy posible que como todos los canales oficiales (foro, ayuda, documentación) no digan nada del operador *, quizás los administradores estén pensando en volver a quitarlo, y hacer como si nunca hubiera existido)) Así que es peligroso confiar en su uso en general en este momento, creo.

El silencio se debe probablemente a que el 99,9% de los usuarios no se preocupan por todo ello. ¿Por qué molestar sus cerebros con información innecesaria? Y los que la necesitaban, la pidieron y la obtuvieron.

Tampoco te importaba esta característica hasta ahora, ¿verdad? Y ahora empiezas desesperadamente a poner excusas de por qué no lo sabías ;) ¿Qué diferencia hay en cuándo se introdujo: inmediatamente o después de meses? Seguirías sin saberlo si no te lo hubiera dicho )

 

Hmmm... ¿Tal vez también hay punteros a la matriz? Tendré que comprobarlo... Los extraño tanto...

 
Georgiy Merts:

Hmmm... ¿Tal vez también hay punteros a la matriz? Tendré que comprobarlo... Los extraño tanto...

No. Tienes que poner los arrays en las clases, tienen punteros.

 
Ilya Baranov:

No. Tienes que poner los arrays en las clases, tienen punteros a ellos.

Sí, por desgracia.

En realidad, las clases derivadas de CArray son bastante útiles para mí. Para lo único que quiero punteros a arrays es para los indicadores, pasan referencias a arrays, y tengo que "arrastrar" estas referencias por toda la jerarquía de objetos, lo que es muy incómodo...

Una vez sugerí que se hicieran punteros a arrays, o que se hiciera una función indicadora que utilizara punteros a arrays de la Biblioteca Estándar, en lugar de enlaces a arrays, pero, por desgracia, me rechazaron con el argumento de que "si permitimos punteros a arrays, será posible utilizar arrays no inicializados", aunque los desarrolladores no tienen esos temores con los objetos... Sí, bueno, lo dejaré a su conciencia.

 
Georgiy Merts:

2. MQL no tiene que borrar lo que no ha seleccionado. Dmitriy tenía razón arriba - crear un objeto - borrarlo. No me gusta la práctica del " recolector de basura" en C#, cuando los objetos se borran no cuando yo quiero, sino cuando el recolector quiere.

El selector de C# nunca eliminará un objeto vivo o un puntero. Su propósito es eliminar la basura del montón de cadáveres y a veces desfragmentarlo.

 
Alexey Volchanskiy:

El ensamblador de C# nunca borrará un objeto o puntero vivo. Su propósito es eliminar la basura de los cadáveres del montón y, a veces, desfragmentarlo.

No estoy diciendo que el recolector de basura borre un objeto vivo o un puntero. Lo que digo es que lo borrará cuando quiera. Y esto, en mi opinión, no es bueno.

Puedo trabajar con o sin borrado. Y hasta puedo hacer smartpoints... Sin embargo, creo que el borrado de objetos debe ser posible y la persona que lo creó debe borrar el objeto.

Ese es el tipo de veterano de la vieja escuela que soy.

 
SemenTalonov:

Probablemente, irán en la dirección de C# donde el "código gestionado" no tiene punteros y todo tiene un objeto, incluso los tipos simples bool int double, etc.

Sí, pero siguen dejando la posibilidad de trabajar con punteros en código no gestionado. Es cierto que ese código tiene restricciones de distribución.

 
Georgiy Merts:

No estoy diciendo que el recolector de basura borre un objeto vivo o un puntero. Lo que digo es que lo borrará cuando quiera. Y esto, en mi opinión, no es bueno.

Puedo trabajar con o sin borrado. Y hasta puedo hacer smartpoints... Pero, sin embargo, creo que los objetos deberían ser borrados, y el que lo creó debería borrarlo.

Ese es el tipo de veterano de la vieja escuela que soy.

Georges, ¿podrías dar un ejemplo, no te entiendo? ¿Es eso lo que quieres decir? Supongo que puedes hacer smartpoints tú mismo.

bool first = false;

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

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

Georges, ¿podrías darme un ejemplo, no te entiendo? ¿Es eso lo que quieres decir? Probablemente sea posible hacer smartpoints por sí mismo.

No. Está claro que en este caso la variable debe borrarse al salir del bloque.

Me refiero a los objetos creados por new:

CMyObj* pmoObject  = new CMyObject;

El estándar C# especifica: "Tanto los objetos de tipo valor, como las estructuras, como los objetos de tipo referencia, como las clases, se destruyen automáticamente, pero los objetos de tipo valor se destruyen cuando se destruye el contexto que los contiene, mientras que los objetos de tipo referencia son destruidos por el recolector de basura indefinidamente después de que se elimine la última referencia a ellos."

Aquí, no me gusta este "tiempo indefinido". Aunque, incluso concederé que el recolector de basura puede borrar un objeto mucho más eficientemente que yo, borrando el objeto en el destructor de la clase que lo creó.

1...45678910111213
Nuevo comentario